Interoperability Standards for Prior Authorization APIs for Medicare Advantage, Medicaid, CHIP, and QHP Issuers

Content

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®) Fast Healthcare Interoperability Resources (FHIR®) implementation guides
(IGs) that are currently recommended. In addition, HHS is proposing to adopt the HL7 FHIR base standard and certain associated
specifications and IGs as the Health Insurance Portability and Accountability Act of 1996 (hereinafter referred to as “HIPAA”)
(Pub. L. 104-191, enacted Aug. 21, 1996) standards for dental, professional, and institutional “referral certification and
authorization” transactions and “eligibility for a health plan” transactions associated with prior authorization. We are proposing
to add a definition for “failure to report,” which would allow CMS to impose a civil monetary penalty (CMP) on applicable
manufacturers or applicable group purchasing organizations (GPOs) if those entities fail to grant CMS timely access to documents
for the purposes of an audit. Finally, ONC is using this rulemaking to propose to adopt updated versions of certain health
information technology (health IT) standards and specifications for HHS use, such as CMS's interoperability requirements,
to support a more robust health IT infrastructure.

DATES:

To be assured consideration, comments must be received at one of the addresses provided below, by June 15, 2026.

ADDRESSES:

In commenting, please refer to file code CMS-0062-P.

Comments, including mass comment submissions, must be submitted in one of the following three ways (please choose only one
of the ways listed):

1. Electronically. You may submit electronic comments on this regulation to http://www.regulations.gov. Follow the “Submit a comment” instructions.

2. By regular mail. You may mail written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health
   and Human Services, Attention: CMS-0062-P, P.O. Box 8013, Baltimore, MD 21244-8013.

Please allow sufficient time for mailed comments to be received before the close of the comment period.

1. 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:

CMSInteroperability@cms.hhs.gov for general inquiries.

David Koppel, (303) 844-2883, for policy issues.

Shanna Hartman, (410) 786-0092, for standards issues.

Scott Weinberg, (410) 786-6017, for Access APIs issues.

Katie Brooks, 667-414-0612, for API endpoints issues.

Emmanuelle Vasilak, 667-290-9848, for compliance issues.

Nora Simmons, (410) 786-1981, for Collection of Information or Regulatory Impact Analysis issues.

Alexander Baker, (202) 260-2048, for ONC issues.

SUPPLEMENTARY INFORMATION:

Inspection of Public Comments: All comments received before the close of the comment period are available for viewing by the public, including any personally
identifiable or confidential business information that is included in a comment. We post all comments received before the
close of the comment period on the following website as soon as possible after they have been received: http://www.regulations.gov. Follow the search instructions on that website to view public comments. CMS will not post on Regulations.gov public comments that make threats to individuals or institutions or suggest that the commenter will take actions to harm an
individual. CMS continues to encourage individuals not to submit duplicative comments. We will post acceptable comments from
multiple unique commenters even if the content is identical or nearly identical to other comments.

Plain Language Summary: In accordance with 5 U.S.C. 553(b)(4), a plain language summary of this rule may be found at https://www.regulations.gov/.

Table of Contents

I. Background, Summary of Proposals, Terms, and Severability

A. Purpose and Background

B. Summary of Major Proposals

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)

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.

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

  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).

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)

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

  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)

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)

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.

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.

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

  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.

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.

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)

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

  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)

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.

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

  certification, using technology to manage step therapy, and prior authorization requirements for laboratory tests and durable
  medical equipment, prosthetics, orthotics, and supplies (DMEPOS) items.

Electronic event notifications are valuable tools for coordinating care in the modern health care environment, and we are
seeking comment on ways to improve this process with expanded use and content of electronic event notifications (often referred
to as admission, discharge, and transfer, or “ADT” notifications). We want to understand the types of providers or other entities
that should receive ADT notifications along with technical approaches that are currently in use or that could be used for
patient event notifications. We also seek comments on health IT certification criteria for notification capabilities and strengthening
enforcement of ADT notification requirements.

Hacking, ransomware, and other cybersecurity attacks on health care systems and electronic protected health information (ePHI)
present an ever-increasing threat. These attacks have already caused, and could continue to cause, significant disruption
to the health care industry, potentially resulting in significant harm to patients, providers, payers, and the health care
ecosystem at large. We are seeking feedback on opportunities to strengthen, protect, and increase the resiliency of our health
care system in cybersecurity spaces to prevent and better handle future threats. Additionally, we would like to hear about
existing standards and technologies, as well as the current role of point-to-point connections within the health care system.

Monitoring compliance and technical conformance with standards is critical to effective interoperability within the health
care ecosystem based on the API requirements that we have established for impacted payers. We are seeking comment on steps
that we could take to improve oversight of payer APIs, for instance, through strengthening testing and transparency requirements.
We are also exploring opportunities to leverage existing programs, such as the ONC Health IT Certification Program, to ensure
that API technology used by payers meets the technical requirements we establish.

We are also seeking comments on ways to streamline the step therapy process through technology and data sharing (such as the
Payer-to-Payer API) to allow payers access to historical patient information. We seek comment on how technology may facilitate
step therapy determinations and improve current step therapy processes. This includes the role of technology in evaluating
and applying step therapy criteria and how payers evaluate and honor step therapy criteria from other payers.

Prior authorization requirements for laboratory tests and DMEPOS items have emerged, in some instances, as a barrier to care
and coverage that impacts both patients and providers. The primary issues associated with prior authorization for laboratory
tests and DMEPOS items are coordination between providers and laboratories or DMEPOS suppliers and the length of time approval
takes for tests and equipment. We are soliciting public comment on how prior authorization for laboratory tests and DMEPOS
items impacts patient care and provider burden and what can be done to mitigate that burden.

C. Specific Terms Used in This Proposed Rule

Throughout this proposed rule, we use terms such as “patient,” “consumer,” “beneficiary,” “enrollee,” and “individual.” In
this proposed rule, we use the term “patient” as an inclusive term. Each CMS program may use different terms to refer to patients
in regulation. Therefore, in this proposed rule, we use “patients” collectively across programs. However, when discussing
proposals for a particular program, we will use specific terms applicable to individuals covered under that program. Also,
when we discuss patients, the term includes, where applicable, a patient's personal representative. For example, a patient
or their personal representative may access certain types of information under the proposals in this proposed rule. However,
when we refer to a patient's medical needs or health records, we do not include the medical needs or health records of the
patient's personal representative. Pursuant to the “Standards for Privacy of Individually Identifiable Health Information”
final rule (65 FR 82462) (hereinafter referred to as the “HIPAA Privacy Rule”), which appeared in the
Federal Register
on December 28, 2000, 45 CFR 164.502(g), and related guidance, a “personal representative” is a person authorized under state
or other applicable law to act on behalf of an individual in making health care-related decisions (such as a parent, guardian,
or person with a medical power of attorney). (15 16) Under the HIPAA Privacy Rule, the individual's personal representative generally may exercise the right to access the individual's
protected health information (PHI).

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

  conduct prior authorization, it may make sense for the payer to have providers send prior authorization requests for those
  drugs directly to the PBM. In that case, if finalized, the PBM would be required to support an unexpired version of the NCPDP
  SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs, thereby making
  electronic prior authorization available to providers and meeting the proposed requirement on behalf of the impacted payer.
  Such arrangements would be permissible under these proposals, if allowed under applicable program rules. However, we emphasize
  that the ultimate responsibility for regulatory compliance would be on impacted payers themselves.

Although Medicare FFS is not directly affected by the CMS interoperability regulations, CMS continues to explore and initiate
opportunities to enhance electronic prior authorization within the Medicare FFS program, as appropriate, including those for
drugs. The Medicare FFS program has developed a Prior Authorization API that makes available Medicare coverage criteria rules
and documentation requirements to providers. This API helps providers determine whether prior authorization is required and
identify the necessary documentation. The API also facilitates the extraction of relevant clinical information from the provider's
electronic health record (EHR) to compile the required documentation and enables the electronic submission of prior authorization
requests in a structured format to CMS review contractors. We want to ensure that Medicare beneficiaries can benefit from
the policies we are proposing, regardless of their coverage or delivery system. We intend for the Medicare FFS program to
be a market leader on electronic prior authorization and therefore, seek comment throughout this proposed rule on how these
proposals could apply to Medicare FFS. In addition, Medicare FFS is a HIPAA covered entity, subject to the HIPAA Administrative
Simplification statutory provisions. Therefore, if HHS' proposals in section II.H. are finalized, Medicare FFS would be subject
to the electronic transaction standards adopted by the Secretary.

As was the case for the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization
final rules, Medicare Supplemental Insurance plans (commonly known as Medigap) are not impacted payers. Medigap plans do not
perform prior authorization but rely on coverage determinations by Medicare FFS. In addition, as stated in the 2020 CMS Interoperability
and Patient Access final rule, Program of All-Inclusive Care for the Elderly (PACE) organizations are not impacted payers
under the CMS interoperability rules (85 FR 25621).

For purposes of this proposed rule, references to QHP issuers on the FFEs exclude issuers offering stand-alone dental plans
(SADPs) on the FFEs. In the 2024 CMS Interoperability and Prior Authorization final rule, we did not propose or finalize requirements
applicable to SADP issuers because they have relatively lower enrollment and premium intake compared to individual market
QHP issuers on the FFEs. In addition, we had concerns that requiring those plans to comply with the final rule's policies
could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees (89
FR 8766). Several public comments also made this point, that a requirement for SADP issuers to implement the required FHIR
APIs would impose burden with minimal or no benefit (85 FR 25552 and 25553). Additionally, SADP issuers are not required to
cover prescription drugs. When a dental provider writes a prescription, that drug is generally processed through the enrollee's
non-dental medical benefit. Although dental providers may provide medication as part of a dental procedure, such as local
anesthesia, it is our understanding that this is generally part of the dental procedure itself and therefore dental providers
are reimbursed for the service as a bundle rather than through a separate claim for drugs. Therefore, we are not proposing
to apply requirements to SADP issuers, but we solicit comment on whether the considerations described previously do in fact
diminish the need for electronic prior authorization requirements and prior authorization process requirements for SADP issuers.
We solicit comments on whether we should consider future rulemaking to apply these proposed requirements and those finalized
in the 2024 CMS Interoperability and Prior Authorization final rule to SADP issuers.

For the purposes of this proposed rule, FFEs include FFEs in states that perform plan management functions, and as noted in
the 2024 CMS Interoperability and Prior Authorization final rule, State-based Exchanges on the Federal Platform (SBE-FPs)
are not FFEs, even though patients in those states enroll in coverage through HealthCare.gov (89 FR 8761). Hence, issuers in SBE-FPs would not be impacted payers subject to the CMS proposals in this proposed rule. We
believe that it is appropriate at this time to continue to exclude issuers on the State-based Exchanges (SBEs), including
SBE-FPs, as impacted payers to keep with prior interoperability rulemaking. As we assess the effectiveness of interoperability
policies, we will consider whether future rulemaking to include those types of issuers as impacted payers is appropriate,
as we are proposing now for small group market QHP issuers on the FF-SHOPs. Importantly, we will be informed by the Patient
Access API usage metrics required in 45 CFR 156.221(f), and, if finalized, the proposed Provider Access, Payer-to-Payer, and
Prior Authorization API usage metrics discussed in section II.F.2.c. of this proposed rule. This data, as well as information
we receive from issuers applying for QHP certification about their interoperability activities, will help us to understand
how patients, providers, and payers use these tools and the success of current requirements. We also solicit comment in this
proposed rule on whether to consider future rulemaking to extend these proposals, and those policies finalized in the 2020
CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules, to issuers
that offer coverage through SBE-FPs, SBEs, or both. In the 2024 CMS Interoperability and Prior Authorization final rule, we
encouraged these Exchanges to consider adopting similar requirements (89 FR 8761), and, in this proposed rule, we solicit
comment on the extent to which they have or may do so, as well as potential feasible deadlines for issuers in those Exchanges
to implement interoperability requirements, so their enrollees can benefit from access to their health care data and more
efficient and timely prior authorization processes.

In this proposed rule, we use the terms “provider” and “supplier” to mean individuals, organizations, and institutions that
provide or furnish health services, such as clinicians (that is, physicians and other practitioners), hospitals, skilled nursing
facilities (SNFs), home health agencies, hospice settings, laboratories, pharmacies, suppliers of DMEPOS items, and community-based
organizations, as appropriate in the context used. Similarly, we are generally not using the term “prescriber” in this rule,
as “provider” is a broader term that includes any individual who authorizes a particular prescription or order. Our proposals
related to the prior authorization of drugs are discussed in the context of providers who request

  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)

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)

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.

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.

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

  propose that the provision would be severable from the other provisions of this rulemaking and would not affect the remainder
  thereof or the application of the provision to persons not similarly situated or to dissimilar circumstances.

We propose that if any section, subsection, sentence, clause, phrase, word, provision, or application of this final rule shall
be found to be invalid, illegal, unconstitutional, or unenforceable, that finding shall not affect or undermine the validity
of any other section, subsection, sentence, clause, phrase, word, provision, or application which can be enforced without
the use of the offending provision. We request comments from the public on severability, particularly which policies could
be severable, if finalized, and how the other policies in a final rule would operate absent those particular provisions.

II. Provisions of the Proposed Rule

A. Interoperability Standards for APIs

1. Background

Standards set the foundation for consistent technical implementation to support interoperable exchange of information, which
facilitates efficient, safe, and high-quality care for patients. In the 2024 CMS Interoperability and Prior Authorization
final rule, we require impacted payers to use API technology conformant with specific standards in 45 CFR 170.215 applicable
to the interoperability APIs (89 FR 8927). We finalized requirements to use these standards through cross-references to 45
CFR 170, subpart B, where ONC adopts standards that may be used across HHS programs. Those standards, which are applicable
to different APIs, include the following:

• Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®), Release 4.0.1 in 45 CFR 170.215(a)(1);
• HL7 FHIR US Core IG, Standard for Trial Use (STU) 3.1.1 in 45 CFR 170.215(b)(1)(i) (US Core IG);
• HL7 Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Framework IG, Release 1.0.0 in 45 CFR 170.215(c)(1) (SMART App Launch IG);
• FHIR Bulk Data Access (Flat FHIR) IG, v1.0.0: STU 1 in 45 CFR 170.215(d)(1) (Bulk Data Access IG); and
• OpenID Connect Core 1.0, incorporating errata set 1, in 45 CFR 170.215(e)(1) (OpenID Connect Core). The specific standards for the interoperability APIs are listed in Table H3 of the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8945). In that same final rule, we finalized policies that allow impacted payers to use updated standards for these APIs, if specific conditions are met, which are similar to policies previously finalized in the 2020 CMS Interoperability and Patient Access final rule. (21) We also strongly recommended payers use additional IGs for each API, listed in Table H3 (89 FR 8945).

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

  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).

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.

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.

(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

  example, NCPDP SCRIPT).” [(26 27)]() That directive is intended to differentiate the scope of the FHIR IGs for prior authorization from the scope of the NCPDP
  SCRIPT standard, which is used for prior authorization of drugs under a pharmacy benefit.

The 2024 Part D and Health IT Standards final rule requires prescribers, dispensers, and Part D sponsors (as part of their
electronic prescription drug programs) to use a version of the NCPDP SCRIPT standard adopted in 170.205(b) to transmit electronic
prior authorization for covered Part D drugs for Part D eligible individuals (89 FR 51239). Any drugs covered by MA plans
other than covered Part D drugs, that is, drugs payable under Part A or Part B, are not within the scope of the NCPDP SCRIPT
standard and instead are within the scope of the Prior Authorization API (using HL7 FHIR, Release 4.0.1). However, we acknowledge
that for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on
the FFEs, there is currently no statutory or regulatory definition that distinguishes between drugs covered under a pharmacy
benefit and drugs covered under a medical benefit, as described in the NCPDP SCRIPT or Da Vinci FHIR IGs for electronic prior
authorization. Therefore, if these proposals, found in sections II.A.2. and II.B.3. of this proposed rule, are finalized as
proposed, we anticipate that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs would analyze their list of covered drugs for which they require prior authorization and determine
whether electronic prior authorization for each drug could be supported by the NCPDP SCRIPT standard or should instead be
provided through the Prior Authorization API. Drugs covered under a pharmacy benefit, which would use the NCPDP SCRIPT standard
for electronic prior authorization requests, are often those medications dispensed at a retail pharmacy. Drugs covered under
a medical benefit, which would use the Prior Authorization API, are often those dispensed by a medical provider in a health
care setting. We understand that the same drug could fall into different categories for different impacted payers based on
their terms of coverage, but we do not think that would undermine this proposal's effectiveness because impacted payers could
indicate which method a provider should use to submit a particular prior authorization.

The CRD IG has the technical capability to return specific coverage information through the “CoverageInformation” extension,
and we seek comment on how the “CoverageInformation” extension could best be utilized to indicate whether a particular drug
is covered under a medical benefit and, therefore, that the Prior Authorization API should be used for electronic prior authorization.
Similarly, we seek comment on whether the impacted payers could utilize the NCPDP Real-Time Prescription Benefit (RTPB) standard
to indicate whether a drug is covered under a medical benefit. We also solicit comment on whether there are existing technical
solutions or methods that show promise but would require additional development that impacted payers could utilize to indicate
to providers how a prior authorization request for a drug should be submitted. In addition, we discuss below how the NCPDP
Formulary & Benefit (F&B) or NCPDP RTPB standards could be used.

(2) Transactions

As of the date this proposed rule appears in the
Federal Register
, providers can use the NCPDP SCRIPT standard versions 2017071 and 2023011 for multiple transactions associated with the electronic
prior authorization of drugs covered under a pharmacy benefit. The SCRIPT standard can be used in conjunction with the NCPDP
F&B or NCPDP RTPB standards, to support a complete workflow around determining whether prior authorization is required. Additionally,
these versions of the NCPDP SCRIPT standard include transactions for requesting prior authorization for drugs, communicating
decisions, and exchanging information regarding appeals. The NCPDP SCRIPT standard version 2023011 has numerous updates from
version 20217071, including that it can facilitate a three-way transaction to notify providers and pharmacies when prior authorization
has been requested. (28 29) The NCPDP SCRIPT standard versions 2017071 and 2023011 support both the workflow to determine whether prior authorization
is required and the coverage and documentation requirements to receive a decision, as well as the technical processes to send
prior authorization requests from a provider to a payer, followed by the payer's responses (for example, approved, denied,
and additional information required). The NCPDP SCRIPT standard versions 2017071 and 2023011 also support features that minimize
manual data entry by the provider based on information in the EHR or other health IT system. These functions should reduce
the time a provider or their administrative staff spend reviewing and responding to payer documentation requirements for prior
authorization decisions. The NCPDP SCRIPT standard versions 2017071 and 2023011 can send information to a payer (or the payer's
PBM) in real time, which should result in faster prior authorization approvals and therefore faster patient access to medications
compared to manual prior authorization processes. We note that the NCPDP SCRIPT standard version 2017071 expires on January
1, 2028, which is shortly after the proposed compliance date for certain impacted payers to support an unexpired version of
the NCPDP SCRIPT standard adopted in 45 CFR 170.205(b). If our proposal is finalized, we would expect those impacted payers
to utilize only the NCPDP SCRIPT standard versions 2023011 after January 1, 2028 to meet the proposed requirements.

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:

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

  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.

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.

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)

Utilizing the proposed NCPDP standards for electronic prior authorization in the provider's workflow would likely lead to
faster prior authorization processes and thus result in improved patient access to prescribed medications.

In summary, we request comment on our proposals in the CFR citations listed in Table 2, and specifically on the following:

• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs covered under a pharmacy benefit.
• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u) to make available formulary and benefits information for drugs covered under a pharmacy benefit.
• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c) for exchanging real-time coverage information regarding drugs covered under a pharmacy benefit.

• The proposed October 1, 2027 compliance date for these proposals, as discussed in section II.B.2.c. of this proposed rule.
  In addition, we request comments on the following:

• Through what mechanisms do payers make their NCPDP F&B files available today?

• How frequently do payers or their PBMs update their F&B flat file today? How often should payers update their F&B flat file
  to account for formulary or benefit changes?

• How often do payers update the indicators for whether prior authorization is required within their F&B flat files? How often
  does that information change and is there typically a lag between policy changes and published F&B flat files?

• How frequently do providers use the NCPDP F&B standard as part of their prior authorization workflow today?

• How well integrated is the NCPDP F&B standard into providers' EHRs today?

• How accurate is the group-level information included in the NCPDP F&B standard to specific patients?

• How could impacted payers utilize the NCPDP RTPB standard to indicate whether a drug is covered under a medical benefit?

• Through what mechanisms do payers make information available using the NCPDP RTPB standard today?

• How frequently do providers use tools conforming to the NCPDP RTPB standard as part of their prior authorization workflow
  today?

• How prevalent is implementation of the NCPDP RTPB standard into providers' EHRs today? How automated are current interactions
  with the NCPDP RTPB standard within providers' EHRs and clinical workflow?

• For electronic prior authorization, would or could requiring impacted payers to make available information using the NCPDP
  RTPB standard negate the need for impacted payers to make available information using the NCPDP F&B standard? Does the NCPDP
  RTPB standard include all the necessary formulary and benefits information and functionality that would be available by using
  the NCPDP F&B standard for electronic prior authorization?

• Would requiring impacted payers to make information available using both standards add value, or create additional burden,
  specifically related to electronic prior authorization of drugs?

• Does the CRD IG have the technical capability to return specific coverage information through the “CoverageInformation” extension?
  ++ How could the “CoverageInformation” extension be best utilized to indicate whether a particular drug is covered under a
  medical benefit and whether the Prior Authorization API should be used for electronic prior authorization?

• Are there other existing technical solutions or methods that impacted payers could utilize to indicate to providers how a
  prior authorization request for a drug should be submitted?

3. Required Standards for FHIR APIs

a. Modification to Required Standards for FHIR APIs

We are proposing to require each impacted payer to implement and maintain APIs that are conformant with applicable standards
in 45 CFR 170.215 in a manner that will allow for progressive adoption of new versions of these required standards. Under
this approach, impacted payers would be permitted to conform with any updated versions of the required standards as the Secretary
adopts them, via notice and comment rulemaking, in 45 CFR 170.215. In addition, if ONC establishes an expiration date for
a standard in 45 CFR 170.215, or for a specific version thereof, upon the specified expiration date, impacted payers would
no longer be permitted to use that standard or version to meet the interoperability requirements. When more than one unexpired
version of a required standard is adopted in 45 CFR 170.215, impacted payers would be able to use any of the unexpired versions
of the adopted standard to meet the interoperability requirements. This would allow impacted payers to have more predictable
transition periods to update their APIs, and to conform with newer versions of the required standards in 45 CFR 170.215 as
they are adopted, and older versions expire. CMS and ONC will work in close collaboration to evaluate the standards adopted
in 45 CFR 170.215 and determine whether and when updated versions are ready for adoption through rulemaking.

For example, in the 2024 CMS Interoperability and Prior Authorization final rule, we required impacted payers to use API technology
conformant with the SMART App Launch IG, Release 1.0.0, in 45 CFR 170.215(c)(1) (89 FR 8927-8928). In this proposed rule,
we are proposing to revise this requirement so that impacted payers would be required to use API technology conformant with
an unexpired version of the SMART App Launch IG adopted by the Secretary in 45 CFR 170.215(c). As of the date this proposed
rule appears in the
Federal Register
, adopted versions of this standard include: (1) the SMART App Launch IG, Release 1.0.0 in 45 CFR 170.215(c)(1), which expired
on January 1, 2026, and (2) the SMART App Launch IG, Release 2.0.0 in 45 CFR 170.215(c)(2), without an expiration date. In
this example, impacted payers would need their API technology to be conformant with SMART App Launch IG, Release 2.0.0, as
that would be the only unexpired version available upon the effective date of a final rule. Finalizing this proposal, which
would require impacted payers to use an unexpired version of the required standards cross-referenced in 45 CFR 170.215, would
revise the existing requirement that impacted payers use specific versions of these standards that have since expired.

We propose to update the technical requirements for each API, for each impacted payer, to cross reference to

  locations in 45 CFR 170.215 that include all versions of the required standards adopted by the Secretary. For readability
  purposes, citations where we are proposing to require the standards and IGs in 45 CFR 170.215 for each impacted payer are
  listed in Table 2. Specifically, we propose to update the cross references to the following:

• HL7 FHIR Standard in 45 CFR 170.215(a);
• US Core IG in 45 CFR 170.215(b)(1);
• SMART App Launch IG in 45 CFR 170.215(c);
• Bulk Data Access IG in 45 CFR 170.215(d); and
• OpenID Connect Core in 45 CFR 170.215(e). We propose that the revised references to 45 CFR 170.215(a), (b)(1), and (c) through (e), as listed in Table 3, would be effective beginning on the effective date of the final rule, for all interoperability APIs.

Impacted payers would continue to be required to maintain the Patient Access and Provider Directory APIs that they are presently
required to maintain. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted
payers to make the Provider Access, Payer-to-Payer, and Prior Authorization APIs available beginning in 2027 (by January 1,
2027, for MA organizations and state Medicaid and CHIP FFS programs; by the first rating period beginning on or after January
1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January
1, 2027, for individual market QHP issuers on the FFEs) (89 FR 8759-8760). This proposal would not change those compliance
dates but would allow impacted payers to better plan for implementation by those dates as the Secretary adopts new standards
or specifies new expiration dates for existing standards, or specific versions thereof, adopted in 45 CFR 170.215.

As discussed in section II.A.1. of this proposed rule, ONC has adopted additional versions of certain required standards,
which are included in Table 2. We also expect that several of the standards and IGs we currently require, or recommend and
are proposing to require, may have newer versions published before this rule is finalized. For example, we expect that some
of the IGs discussed in this proposed rule will be updated to support newer versions of the US Core IG. In this proposed rule,
we discuss either the most recently published or most recently adopted versions of the standards and IGs at the time this
proposed rule appears in the
Federal Register
.

In summary, we request comment on our proposals in the CFR citations listed in Table 2, and specifically on the following:

• The proposal to require impacted payers to implement and maintain API technology conformant with unexpired versions of the standards adopted by the Secretary in 45 CFR 170.215, specifically 45 CFR 170.215(a), (b)(1), and (c), (d), and (e), as applicable.

• The proposal to become effective beginning on the effective date of the final rule.
  In addition, we request comments on the following:

• Whether there are opportunities to streamline our regulatory requirements in instances where requiring conformance with the
  previously recommended IGs proposed in II.A.4.b. of this proposed rule for specific API use cases would achieve the same functional
  goal as explicitly requiring conformance with both the use-case specific IGs and required IGs or standards. For instance,
  whether it is necessary to require the base FHIR standard as well as the CRD, DTR, and PAS IGs that we propose to require
  for the Prior Authorization API, or whether requiring the CRD, DTR, and PAS IGs alone, which are based on the FHIR standard,
  would provide comparable technical guidance for implementers while reducing regulatory complexity.

• Scenarios in which independently requiring both the required standards in this section (II.A.3.a. of the proposed rule)
  and use-case specific IGs proposed in section II.A.4.b. of the proposed rule could introduce alignment challenges. For instance,
  where one required standard references a specific version of another required standard, independent adoption of the latter
  standard could present further alignment challenges.

• Instances in which requiring conformance with both the required standards in this section (II.A.3.a. of this proposed rule)
  and the use-case specific IGs proposed in section II.A.4.b. of the proposed rule are necessary to fully represent necessary
  technical requirements and should be maintained.

• Comments on whether it would be helpful to payers to more specifically identify capabilities of required IGs relevant to
a specific API, to further streamline requirements and reduce unnecessary development. For instance, whether we should specify
only those capabilities of the SMART App Launch IG relevant to the Patient Access API use case (e.g. the “Patient Access for Standalone Apps” Capability Set as well as the capabilities of “launch-standalone” and “context-standalone-patient,”
and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the
“permission-online” and “permission-user”).

4. Requiring Additional Implementation Guides to Support Interoperability APIs

a. Description of the Implementation Guides

Using standards and IGs supports consistent implementation across the industry, thus leading to interoperable data exchange.
There are many FHIR IGs that exist to support data exchange between payers, providers, and patients and enable the exchange
of data such as claims, encounter, clinical, and coverage information; drug formulary information; and prior authorization
information.

Here, we provide descriptions of FHIR IGs that we require or recommend impacted payers support (89 FR 8927 and 8928, 8937,
and 8945). Specifically, we required impacted payers to use the Bulk Data Access IG for the Provider Access and Payer-to-Payer
APIs, while the other IGs described later in this section were recommended. (34) We are now proposing to require impacted payers to support these IGs as described in section II.A.4.b. of this proposed rule.
Table 2 outlines the citations to where we propose to require use of the standards for each of the specified APIs.

(1) CARIN Implementation Guide for Blue Button®

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.

(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.

(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.

(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.

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).

(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)

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)

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

  version is the PAS IG, Version 2.2.1—STU 2.2. [(45)]()

b. Requiring Implementation Guides

In the 2024 CMS Interoperability and Prior Authorization final rule, we discussed use-case specific IGs that impacted payers
can use to implement their interoperability APIs (89 FR 8937). Using those IGs supports interoperability because impacted
payers need not develop an approach independently, which should save time and resources. In that final rule, we strongly encouraged
payers to use the IGs listed as “recommended” in Table H3 for each API, in addition to the required standards in 45 CFR 170.215
(89 FR 8945). We recommended specific IGs for each API to provide guidance to the industry without locking payers into the
versions of those IGs available at the time of the 2022 CMS Interoperability and Prior Authorization proposed rule (89 FR
8937). We carefully considered the versions of the recommended IGs that were available at the time and determined that they
were not ready to be proposed as requirements. However, we acknowledged that by recommending rather than requiring certain
IGs, there is potential for implementation variation that could limit interoperability and ultimately lead to rework for impacted
payers if we required the IGs in the future (89 FR 8937). We believed that those IGs would continue to be refined as they
were tested and implemented in the real world. We stated that we would continue to monitor and evaluate the IGs' development
and consider whether to propose to require their use in the future (89 FR 8937). Since publication of the 2022 CMS Interoperability
and Prior Authorization proposed rule, those IGs have continued to mature, and updated versions of many of the recommended
IGs have been published.

Therefore, we are now proposing to require impacted payers to implement and maintain API technology conformant with specific
IGs for each applicable API. We propose to require these IGs to through cross references to the applicable citations in 45
CFR 170.215. For readability purposes, citations where we propose to require the IGs for each type of impacted payer are listed
in Table 2.

In the HTI-4 final rule, the Secretary adopted the following IGs (90 FR 37167 and 37182):

• CARIN IG for Blue Button, Version 2.0.0—STU 2 in 45 CFR 170.215(k)(1)(i);
• PDex IG, Version 2.1.0—STU 2.1 in 45 CFR 170.215(k)(2)(i);
• PDex US Drug Formulary IG, Version 2.0.1—STU 2 in 45 CFR 170.215(m)(1);
• PDex Plan Net IG, Version 1.1.0—STU 1.1 US in 45 CFR 170.215(n)(1);
• CRD IG, Version 2.0.1—STU 2 in 45 CFR 170.215(j)(1);
• DTR IG, Version 2.0.1—STU 2 in 45 CFR 170.215(j)(2)(i); and

• PAS IG, Version 2.0.1—STU 2 in 45 CFR 170.215(j)(3)(i).
  Since publication of the “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public
  Health Interoperability” proposed rule (89 FR 63498) (hereinafter referred to as the “HTI-2 proposed rule”), which appeared
  in the
  Federal Register
  on August 5, 2024, and subsequent finalization of the HTI-4 final rule, updated versions of many of the standards and IGs
  have been published. In section II.J. of this proposed rule, ONC is now proposing to adopt updated versions of standards in
  45 CFR 170.215 and proposing to add expiration dates to versions of these standards that were previously adopted in 45 CFR
  170.215. We propose to cross reference the locations in 45 CFR 170.215 that include those versions of a specific standard
  adopted by the Secretary, and specify that impacted payers must use an unexpired version of the standard at that location:

• CARIN IG for Blue Button in 45 CFR 170.215(k)(1);

• PDex IG in 45 CFR 170.215(k)(2);

• PDex US Drug Formulary IG in 45 CFR 170.215(m)(1);

• PDex Plan Net IG in 45 CFR 170.215(n)(1);

• CRD IG in 45 CFR 170.215(j)(1);

• DTR IG in 45 CFR 170.215(j)(2); and

• PAS IG in 45 CFR 170.215(j)(3).
  Requiring impacted payers to use an unexpired version of the standards adopted in 45 CFR 170.215 automatically incorporates
  updated versions into the interoperability requirements as they are adopted by the Secretary. Specifically, if the Secretary
  adopts updated versions of any of these standards, such as the updated versions ONC has proposed for adoption in section II.J.
  of this proposed rule (subject to finalization), those versions would be incorporated in 45 CFR 170.215. As noted previously,
  if the Secretary establishes an expiration date for a standard, or for specific version thereof, upon the specified expiration
  date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements.

We propose that impacted payers would be required to implement and maintain API technology conformant with an unexpired version
of the proposed additional FHIR IGs for each API as described in section II.A.4.b. of this proposed rule beginning on October
1, 2027. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized compliance dates beginning in 2027
for impacted payers to implement and maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs (89 FR 8790, 8820,
and 8860). We recognize that impacted payers may already be developing and implementing their APIs to comply with the technical
requirements established in the 2024 CMS Interoperability and Prior Authorization final rule in preparation for the January
1, 2027 compliance deadline. Some impacted payers may have opted not to use the currently recommended IGs, which we now propose
to require. Therefore, we believe that the proposed October 1, 2027 compliance date would provide impacted payers with additional
time to update their APIs to conform to the additional IGs we are proposing to require beginning on October 1, 2027. Table
3 in this proposed rule lists the required standards finalized in the 2024 CMS Interoperability and Prior Authorization final
rule and additional FHIR IGs proposed in this rule by applicable API.

(1) Patient Access API

In the 2020 CMS Interoperability and Patient Access final rule, we required impacted payers to implement and maintain a standards-based
Patient Access API (85 FR 25558). (46) The Patient Access API allows patients, through the health apps of their choice, to easily access their claims and encounter
information, including provider remittances and patient cost-sharing, as well as all data classes and data elements included
in a content standard (USCDI) adopted by the Secretary in 45 CFR 170.213. (47) In the 2024 CMS

  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.

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)

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.

(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.

(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

  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)]()

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.

(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).

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)

In summary, we request comment on our proposals in the CFR citations listed in Table 2, and specifically the following:

• The proposal to require impacted payers to use an unexpired version of the CARIN IG for Blue Button, the PDex IG, and the PDex US Drug Formulary IG adopted by the Secretary for their Patient Access API.
• The proposal to require impacted payers to use an unexpired version of the CARIN IG for Blue Button and the PDex IG adopted by the Secretary for their Provider Access API.

• The proposal to require impacted payers to use an unexpired version of the PDex Plan Net IG adopted by the Secretary for
  their Provider Directory API.
  • The proposal to require impacted payers to use an unexpired version of the CARIN IG for Blue Button and the

  PDex IG adopted by the Secretary for their Payer-to-Payer API.

• The proposal to require impacted payers to use an unexpired version of the CRD, DTR, and PAS IGs adopted by the Secretary
  for their Prior Authorization API.

• The alternative proposal to require impacted payers to use an unexpired version of the PDex US Drug Formulary IG adopted
  by the Secretary, if the drug formulary data requirement is retained, for impacted payers' Provider Access and Payer-to-Payer
  API.

• The proposed October 1, 2027 compliance date for the proposed requirements for impacted payers.

c. Using Testing Tools To Ensure Conformance With Implementation Guides

The technical requirements for the APIs we finalized in the 2020 CMS Interoperability and Patient Access and the 2024 CMS
Interoperability and Prior Authorization final rules include general requirements for impacted payers to test their interoperability
APIs (85 FR 25514 and 89 FR 8927). (60) For instance, technical requirements for APIs established by MA plans in 42 CFR 422.119(c) state that payers must conduct
routine testing and monitoring, and update as appropriate, to ensure the API functions properly. We are seeking to provide
more information about the existing testing requirement to further advance interoperable data exchange across the health care
system using standard APIs.

Testing tools are available that can help impacted payers to meet existing testing requirements for APIs, for instance, with
ensuring conformance to specified standards. The Inferno testing tool on HealthIT.gov (hereinafter referred to as “Inferno”)
is an HL7 FHIR testing tool offered by ONC. (61) Inferno is an open-source tool for creating, executing, and sharing conformance tests for numerous FHIR standards and IGs.
ONC has developed test kits within Inferno that can be used by payers to test API conformance with certain versions of the
required standards and proposed IGs. (62) For example, Inferno test kits are currently published for the following specifications:

• CRD IG, Version 2.0.1—STU 2;
• DTR IG, Version 2.0.1—STU 2;
• PAS IG, Version 2.0.1—STU 2;
• CARIN IG for Blue Button, Version 2.0.0—STU 2;
• PDex IG, Version 2.0.0—STU 2;
• PDex US Drug Formulary IG, Version 2.0.1—STU 2; and
• PDex Plan Net IG, Version 1.1.0—STU 1.1. Inferno uses a combination of automated and manual verification to assess a system's conformance. Inferno can act as a server to test an app by receiving requests, returning appropriate responses, and validating the conformance of the app's requests and its ability to handle the responses appropriately. Inferno can also test a server by acting as an app, making requests against the server and validating the conformance and appropriateness of the server's responses. We intend to work with ONC on additional and updated test kits for subsequently adopted versions of the IGs above, new versions of the IGs identified through the Standards Version Advancement Process (SVAP) that may be available for voluntary use by payers, and additional IGs identified to support payer APIs.

CMS strongly encourages impacted payers to utilize available testing tools, such as the Inferno testing tool, to meet the
existing testing requirements and ensure conformance with the required IGs. We also encourage impacted payers to publish testing
results to demonstrate conformance with the technical requirements. Doing so would increase transparency and trust that the
technology has been properly implemented to facilitate interoperability. Inferno can be downloaded for local deployment and
is hosted on ONC's website at https://inferno.healthit.gov/.

We also note that we include an RFI in section III.C. of this proposed rule soliciting public feedback on how we can continue
to strengthen oversight mechanisms to ensure the required interoperability APIs are appropriately implemented.

d. Voluntary Use of Updated Versions of Required Standards

As discussed in section II.A.1. of this proposed rule, we previously finalized policies that allow impacted payers to conform
with updated versions of the required standards in 45 CFR 170.213 and 45 CFR 170.215 under certain conditions. There are certain
conditions that must be met for impacted payers to be permitted to use updated versions of the required standards, for example,
the conditions described in 42 CFR 422.119(c) for MA plans. We emphasize two of those conditions here.

First, we note that if impacted payers choose to use updated standards, it must not disrupt an end user's ability to access
the required data as finalized in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior
Authorization final rules (85 FR 25532 and 89 FR 8935). Another condition that permits impacted payers to voluntarily use
an updated version of a required standard in 45 CFR 170.213 or 45 CFR 170.215 is when the National Coordinator has approved
the updated version for use in the ONC Health IT Certification Program. (63) The National Coordinator approves updated versions of standards for the ONC Health IT Certification Program through the Standards
Version Advancement Process (SVAP), pursuant to 45 CFR 170.555, as finalized in the “21st Century Cures Act: Interoperability,
Information Blocking, and the ONC Health IT Certification Program” final rule (85 FR 25642) (hereinafter referred to as the
“ONC Cures Act final rule”), which appeared in the
Federal Register
on May 1, 2020, as a Maintenance of Certification flexibility included in the real-world testing Condition of Certification
(85 FR 25775). This flexibility permits health IT developers to voluntarily use, in certain certified Health IT Modules, newer
versions of adopted standards if specific conditions are met, which allows the ONC Health IT Certification Program to keep
pace with the industry's standards development efforts.

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

  approved by the National Coordinator for health IT developers' voluntary use in the ONC Health IT Certification Program. ONC
  publishes updated versions of standards under consideration for SVAP and lists the updated versions of standards that the
  National Coordinator has approved as part of the Interoperability Standards Advisory (ISA) on *HealthIT.gov.* [(64)]() Members of the public can use this resource to review standards that may be approved through SVAP in the future, as well as
  provide input on which updated versions should be approved. SVAP occurs annually, meaning that newer versions of standards
  will continue to be updated and assessed by ONC for use. Impacted payers may find it beneficial to monitor the SVAP process
  to stay current on standards updates and to assess whether adoption of a newer version of a standard may be an option. We
  encourage impacted payers to review these resources to better understand how updated versions of the standards in 45 CFR 170.213
  and 45 CFR 170.215 may be approved by the National Coordinator through SVAP and meet that condition for using an updated standard.

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.

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.

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 TM), 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.

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

  IG provides for client registration, authentication, and authorization, the entity that performs the registration must have
  a “trust relationship” established.

CMS is considering whether it would be valuable to recommend additional authentication and authorization standards within
FHIR. One authentication and authorization method that can be used within the FAST Security IG is Tiered Open Authorization
(Tiered OAuth). (68 69) Tiered OAuth enables the federation of digital identity management across multiple trusted identity providers using the OpenID
Core standard. This frees a data holder (such as an impacted payer) from having to solely rely on a single identity provider
to maintain the digital identities across all accessing users.

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.

In summary, we request comment on our recommendations, and specifically on the following:

• The recommendation for impacted payers to use the ATR List IG to document and share attribution lists that identify whose patient data may be shared with a provider through the Provider Access API.
• The recommendation for impacted payers to use the CDex IG for the Prior Authorization API for exchanging attachments related to prior authorization.
• The recommendation for impacted payers to use the FAST Security IG for registration, authentication, and authorization for the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs.

• Whether any of these IGs are now mature and important enough for CMS to adopt in a final rule.
  In addition, we request comment on the following:

• How can CMS know whether and when the ATR List, CDex, and FAST Security IGs are ready for us to propose to require their
  use?

• Should CMS consider recommending or requiring the FAST Security IG “Tiered OAuth” in future rulemaking?

• If CMS proposes, in future rulemaking, to require the FAST Security IG, should we also propose to require impacted payers
  to use Tiered OAuth for user authentication? If so, to which APIs should that proposal apply? Would this be a useful solution
  to enable authentication and authorization at scale?

• Are there trust communities that exist today that impacted payers can utilize for business-to-business authentication and
  authorization? Do such communities exist for other stakeholders in the health care system, such as providers, or in other
  industries that could be used or expanded for this purpose?

• How much testing is necessary and under what readiness conditions would it be appropriate for us to propose to require use
  of the FAST Security IG for the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs?

• Should CMS consider recommending the RTPBC IG?

• Are there differences in scope or use cases between the RTPBC IG and the Da Vinci PDex Drug Formulary IG? Specifically, would
  RTPBC IG provide additional or distinct benefits compared to the PDex Drug Formulary IG, or do the two largely address overlapping
  use cases?

• Is there value in providing patients with real-time prescription drug cost and coverage information through the Patient Access
  API?

• Are there potential technical or operational challenges associated with implementing the RTPBC IG within the Patient Access
  API?

• Is there enough patient demand via third-party apps to justify the burden of implementing the RTPBC IG?

• Do any third-party apps currently include this functionality, or would developers build it, if recommended?

• Do payers or PBMs currently support the required technical standards to enable third-party apps to use the RTPBC IG and would
  payers build that functionality, if recommended?

6. Clarification of Standards for the Provider Directory FHIR API

In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that we were removing the SMART App Launch
IG in 45 CFR 170.215(c)(1) and OpenID Connect Core in 45 CFR 170.215(e), which were erroneously included as required standards
for the Provider Directory API in Table 10 of the 2022 CMS Interoperability and Prior Authorization proposed rule (87 FR 76320
and 89 FR 8928) and codified in the CFR. CMS also discussed this in the 2020 CMS Interoperability and Patient Access final
rule, where we finalized a policy that security protocols related to user authentication and authorization in 45 CFR 170.215,
namely the SMART App Launch IG and OpenID Connect Core standard, would not apply to the Provider Directory API (85 FR 25560).

We are now proposing that impacted payers be required to implement and maintain a Provider Directory API (MA organizations
in 42 CFR 422.120(a), state Medicaid FFS programs in 42 CFR 431.70(a), state CHIP FFS programs in 42 CFR 457.760(a), Medicaid
managed care plans through cross reference to 42 CFR 431.70 in 42 CFR 438.242(b)(6), and CHIP managed care entities through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d)) conformant with FHIR in 45 CFR 170.215(a) and US Core IG in 45 CFR
170.215(b)(1), but not the SMART App Launch IG in 45 CFR 170.215(c)(1) or OpenID Connect Core in 45 CFR 170.215(e)(1).

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.

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).

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®
FHIR® 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).

b. X12N 278 Transaction Standard for Prior Authorization(s)

Under the HIPAA Administrative Simplification rules, the Secretary has adopted standards for use by covered entities—which
includes all impacted payers—for, among other transactions, referral certification and authorization, a subset of which are
used for prior authorization. (98) In January 2024, HHS announced it was exercising its enforcement discretion regarding the standard adopted under HIPAA for
electronic prior authorization, the X12N 278 transaction standard. (99) HHS announced that it would not take enforcement action against HIPAA covered entities that, as part of a Prior Authorization
API, do not use the X12N 278 transaction standard. HHS issued that notice of enforcement discretion based on substantial industry
and stakeholder comments regarding the potential requirement to use the X12N 278 transaction standard in combination with
the Prior Authorization API. Stakeholders informed HHS that requiring the HIPAA standard to be used within the FHIR standard
would be duplicative, unnecessary, and burdensome. HHS's exercise of enforcement discretion is intended to promote efficiency.
In section II.H.3. of this proposed rule, HHS is proposing to replace the X12N 278 transaction standard by adopting the Prior
Authorization API as the HIPAA standard for prior authorization-related transactions.

c. The NCPDP SCRIPT Standard for Electronic Prior Authorizations

The 2020 Medicare Part D ePA final rule (85 FR 86824-86827) extensively details the NCPDP SCRIPT standard's history. For context,
we provide here some of the narrative from that final rule. Congress required electronic prior authorization in the Substance
Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (hereinafter referred
to as the “SUPPORT Act”) (Pub. L. 115-271, enacted October 24, 2018). Section 6062 of the SUPPORT Act amended section 1860D-4(e)(2)
of the Act to require Part D sponsors and prescribing health care professionals to use technical standards adopted by the
Secretary when transmitting electronic prior authorization requests and responses for coverage of a covered Part D drug for
a Part D eligible individual enrolled in a Part D plan (PDP).

The 2020 Medicare Part D ePA final rule established the NCPDP SCRIPT standard version 2017071 as the required standard for
electronic prior authorization for covered Part D drugs in 42 CFR 423.160(b)(8) (85 FR 86832). Part D sponsors and providers
were permitted to use the standard beginning

  January 1, 2021 and were required to do so beginning January 1, 2022.

In the 2024 Part D and Health IT Standards final rule, ONC finalized a January 1, 2028 expiration date for the NCPDP SCRIPT
standard version 2017071 in 45 CFR 170.205(b)(1) and adopted the NCPDP SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2).
In the same final rule, CMS finalized the requirement in 42 CFR 423.160(b)(1) that communication of electronic prior authorization
must comply with a standard in 45 CFR 170.205(b). Therefore, Part D sponsors, providers, and dispensers are permitted to use
either version of the NCPDP SCRIPT standard to conduct electronic prior authorization for drugs until January 1, 2028, when
the NCPDP SCRIPT standard version 2023011 must be used exclusively (89 FR 51247).

d. Other HIPAA Standards for Pharmacy Transactions

In 2009, the Secretary adopted the NCPDP Telecommunication Standard IG, Version D, Release 0 (Version D.0) as a HIPAA Administrative
Simplification transaction standard to improve the efficiency of retail pharmacy transactions. (100) Version D.0 is used for retail pharmacy electronic transactions between pharmacies and payers. Version D.0 allows for accurate
and consistent data exchange, reduces errors in claims processing, enhances eligibility and benefits verification, and streamlines
pharmacy transactions, contributing to an efficient health care exchange for pharmacies, health care clearinghouses (where
used as an intermediary between pharmacies and payers), and payers. Though Version D.0 is largely used for claims and eligibility
transactions, it also includes the capability to transmit prior authorization requests from, and responses to, pharmacies.

On December 13, 2024, the “Administrative Simplification: Modifications of Health Insurance Portability and Accountability
Act of 1996 (HIPAA) National Council for Prescription Drugs (NCPDP) Retail Pharmacy Standards; and Modification of the Medicaid
Pharmacy Subrogation Standard” final rule (89 FR 100763) (hereinafter referred to as the “2024 HIPAA NCPDP Pharmacy Standards
final rule”) appeared in the
Federal Register
. In that final rule, the Secretary adopted the NCPDP Telecommunication Standard IG, Version F6 (Version F6) to replace Version
D.0 to address emerging industry needs and improve the accuracy of pharmacy claim transactions, such as larger fields to accommodate
increasingly expensive drugs (89 FR 100767-100768).

The NCPDP Version F6 Telecommunications standard, like Version D.0, is designed for transactions between pharmacies and payers,
not between non-pharmacy providers and payers (89 FR 100767-100768). The CMS proposal to require payers to support the NCPDP
SCRIPT standard for electronic prior authorization does not conflict with the HIPAA transaction standard because electronic
prior authorizations utilizing the NCPDP SCRIPT standard are not intended to be used by pharmacies. This rulemaking does not
affect pharmacies, which will continue to be required by HIPAA to use Version F6.

3. Proposed Requirement To Incorporate Drugs Covered Under a Medical Benefit Into the Prior Authorization API for All Impacted

Payers

We are now proposing to require impacted payers to expand the scope of the required Prior Authorization API to incorporate
drugs covered under a medical benefit, as that term is explained in section I.C. of this proposed rule. We are proposing an
October 1, 2027 compliance date for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs.

Stakeholder input indicates that enhancing the Prior Authorization API by incorporating drugs covered under a medical benefit
would improve the prior authorization process by giving providers and patients more timely information about prior authorization
requirements to obtain these drugs. As with non-drug items and services, a Prior Authorization API enables EHRs or other health
IT to determine whether prior authorization is required, collect documentation, and submit a request. Expanding the scope
of impacted payers' Prior Authorization APIs to incorporate drugs covered under a medical benefit would streamline the administrative
process for providers and result in payers receiving more complete requests and fewer unnecessary requests, which could accelerate
decision-making. Reducing those burdens should mitigate ambiguity and reduce delays in providing patients with medically necessary
drugs.

Therefore, we are proposing to require impacted payers to enhance their Prior Authorization APIs by incorporating prior authorization
coverage and documentation requirements for drugs covered under a medical benefit, as we describe that term in section I.C.
of this proposed rule, beginning October 1, 2027. The IGs we are proposing to require for the Prior Authorization API include
a set of workflows designed to support prior authorization. Those workflows specifically include drugs covered under a medical
benefit and exclude drugs covered under a pharmacy benefit, for which prior authorization is conducted by another electronic
exchange process, such as the NCPDP SCRIPT standard.

We emphasize that adding drugs covered under a medical benefit to the non-drug items and services included in the Prior Authorization
API requires no changes to the existing standards, the IGs we are proposing to require in section II.A. of this proposed rule,
or other recommended IGs. Furthermore, the functionality of the Prior Authorization API would not need to be modified, but
the specific coverage and documentation requirements for drugs covered under a medical benefit would have to be added to the
content available via the API. (101)

While we describe some of the types of drugs that might be covered under a medical benefit versus a pharmacy benefit for each payer in section I.C. of this proposed
rule, we do not intend to specify an exhaustive list of drugs covered under a medical benefit, as each payer structures their
formularies differently while following statutory and regulatory coverage requirements. For example, while certain infusions,
injections, and services conducted in a provider's office could be included under a medical benefit, self-administered oral
medications would likely be included under a pharmacy benefit. However, we intend the categories of “drugs covered under a
medical benefit” and “drugs covered under a pharmacy benefit” to be mutually exclusive and collectively include all drugs
covered by any particular payer. Put differently, we are proposing that electronic prior authorization must be available for
all drugs covered by any impacted payer for which they require prior authorization, either through the Prior Authorization
API or NCPDP SCRIPT standards adopted by the Secretary.

In Medicare FFS, drugs are either payable by Part A or Part B, or covered by Part D prescription drug coverage. Medicare Part
B may pay for prescription drugs and biologicals (hereinafter referred to as “drugs”)

  administered in an outpatient setting under certain conditions, for example, drugs provided as part of (or incident to) a
  physician's service and drugs furnished for use with covered DMEPOS items. Many drugs payable under Part A or Part B are infused
  or injected by physicians such as oncologists, rheumatologists, and urologists. Drugs payable by Part A or Part B are not
  usually self-administered. Medicare Part D is the prescription drug benefit of Medicare, which covers most outpatient prescription
  drugs through Plan D sponsors and MA organizations offering MA-PD plans. Covered Part D drugs are defined in section 1860D-2(e)
  of the Act. A Part D drug is further defined in 42 CFR 423.100 and includes the following, if used for a medically accepted
  indication as defined by section 1860D-2(e)(4) of the Act:

• A drug that may be dispensed only upon a prescription that is described in sections 1927(k)(2)(A)(i) through (iii) of the Act.
• A biological product described in sections 1927(k)(2)(B)(i) through (iii) of the Act.
• Insulin described in section 1927(k)(2)(C) of the Act.
• Medical supplies associated with the injection of insulin.
• A vaccine licensed under section 351 of the Public Health Service Act (hereinafter referred to as the “PHSA”) (Pub. L. 115-5, enacted November 21, 1997) and its administration.

• A combination product approved and regulated by the Food and Drug Administration (FDA) as a drug, vaccine, or biologic.
  The following are excluded from the definition of Part D drugs:

• Drugs for which payment as so prescribed and dispensed or administered to an individual is available for that individual
  under Part A or Part B.

• Drugs that may be excluded from coverage or otherwise restricted under sections 1927(d)(2) or (d)(3) of the Act, except for
  smoking cessation agents.

• Medical foods that are not regulated as drugs under section 505 of the Federal Food, Drug, and Cosmetic Act (Pub. L. 75-717,
  enacted June 25, 1938).
  With some limited exceptions, MA plans are statutorily required to cover Part A and Part B benefits, including drugs. Most
  MA plans also include Part D prescription drug coverage for their Medicare enrollees. These MA-PDs include drug coverage as
  a single plan, and patients enrolled in an MA-PD plan likely do not experience a distinction between drugs that are payable
  under Part A or Part B and those covered under Part D. Medicare patients who are enrolled in an MA plan that cannot offer
  Part D coverage (like Medical Savings Account plans) or choose not to offer Part D coverage (like certain MA-only plans) can
  join a separate, standalone PDP.

For MA plans, the term “drugs covered under a pharmacy benefit” as used in this proposed rule means covered Part D drugs,
as defined in 42 CFR 423.100. Conversely, “drugs covered under a medical benefit” as used in this rule means any drugs payable
under Part A or Part B.

For Medicaid, although “prescribed drugs” is an optional Medicaid benefit category under section 1905(a)(12) of the Act, all
states currently provide this benefit for all categorically eligible individuals and most other enrollees within their Medicaid
programs. States are permitted to apply prior authorization requirements to covered outpatient drugs as long as the prior
authorization program complies with the requirements of section 1927(d)(5) of the Act. (102) Medicaid managed care plans must conduct their prior authorization programs in compliance with the requirements of section
1927(d)(5) of the Act, as if such requirements applied to the Medicaid managed care plan, if covered outpatient drugs are
included in their contracts. (103) For CHIP, section 2110(a)(6) of the Act authorizes states to cover drugs within CHIP. For CHIP managed care entities, 42 CFR
457.1230(d) cross references to the Medicaid managed care regulations in 42 CFR 438.210.

For Medicaid and CHIP FFS, we believe that the distinction between drugs within the proposed scope of the Prior Authorization
API and within the scope of the proposed NCPDP standards can be distinguished by the systems used to process claims. We expect
drugs that are processed in a claims adjudication system that is not at the point of sale would be within the proposed scope
of the Prior Authorization API. Conversely, we expect that drugs that are processed in a point of sale or real-time claims
adjudication system would be within the scope of the proposed NCPDP standards. Thus, the systems that state Medicaid and CHIP
FFS programs use to process claims may serve as an effective framework for determining which drugs fit within the scope of
the Prior Authorization API and which drugs fit within the scope of the NCPDP standards.

States that cover drugs under state Medicaid or CHIP FFS or both programs generally use their Medicaid Management Information
System (MMIS) to process medical claims and another pharmacy system, such as an electronic claims management system (ECMS),
described in 42 CFR 456.722, or PBM, to process pharmacy claims. We believe that the systems that states use to process claims
may be directly relevant to the state's determination of whether the proposed FHIR or NCPDP standards should apply for particular
prior authorization requests. To meet the requirements of the 2024 CMS Interoperability and Prior Authorization final rule,
states should already be planning to integrate the Prior Authorization API for non-drug items and services with their MMIS
or related systems. (104) States (or their PBMs) may be able to build the proposed NCPDP standards into the state Medicaid and CHIP FFS pharmacy systems.
If those systems accurately align with the scope of each standard, states could use the proposed standards for the electronic
prior authorization of drugs into separate systems without duplication or overlap. We also emphasize that this dichotomy should
not and, if finalized, would not affect any other Medicaid or CHIP policies related to drug coverage.

Section 1301(a)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the Health Care and Education Reconciliation
Act of 2010 (hereinafter referred to as the “Affordable Care Act”) (Pub. L. 111-148, enacted March 23, 2010 and Pub. L. 111-152,
enacted March 30, 2010), and section 2707 of the PHSA require QHP issuers on the FFEs to cover the essential health benefits
(EHBs), which includes items and services in the categories described in section 1302(b) of the Affordable Care Act, one of
which is prescription drugs. There is no statutory or regulatory distinction between drugs covered under a medical benefit,
as described by the scope of the Prior Authorization API, and drugs covered under a pharmacy benefit, as described by the
NCPDP SCRIPT standard, for QHP issuers on the FFEs. There are also no existing requirements for QHP issuers on the FFEs to
support electronic prior authorization for drugs

  in either category. However, we understand that most QHP issuers on the FFEs structure benefits into medical and pharmacy
  categories and therefore should follow their own distinctions for drug coverage.

Should these electronic prior authorization proposals be finalized, impacted payers would need to review the list of covered
drugs for which they require prior authorization to determine whether they fit into the scope of the Prior Authorization API
(drugs covered under a medical benefit) or the NCPDP SCRIPT standard (drugs covered under a pharmacy benefit). Once each payer
has evaluated those drugs that require prior authorization and identified those that may be processed through the Prior Authorization
API, the applicable rules, requirements, and templates would need to be developed and incorporated into the API.

We are proposing compliance dates beginning October 1, 2027 for this proposal. We believe 1 year is the appropriate period
for impacted payers to evaluate and incorporate the additional prior authorization rules and requirements into their Prior
Authorization API. In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, commenters stated that
payers and developers generally need 1 to 2 years to implement a new system (89 FR 8824-8825). In the 2024 CMS Interoperability
and Prior Authorization final rule, we finalized compliance dates for policies that require API development and enhancement
beginning in 2027, which provided impacted payers approximately 3 years to implement the finalized requirements (89 FR 8784,
8817, 8855, and 8897). That feedback was based on the totality of our policies that require API development or enhancement—to
require three new APIs and to update the Patient Access API. This proposal would not require impacted payers to build new
APIs from scratch, but to incorporate prior authorization requirements for drugs covered under a medical benefit into the
existing Prior Authorization APIs. Based on previous industry feedback on development timelines and our experience implementing
the CMS Medicare FFS Prior Authorization API, we believe the effort to add those prior authorization rules to the API would
not require more than a year.

In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following:

• The proposal to require impacted payers to incorporate coverage and documentation requirements into the Prior Authorization API to support electronic prior authorization for drugs covered under a medical benefit, as that term describes the scope of the Prior Authorization API FHIR standards.

• The proposed October 1, 2027 compliance date for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed
  care plans, CHIP managed care entities, and QHPs issuers on the FFEs.
  In addition, we request comments on the following:

• Is the scope of the Prior Authorization API, as defined by its implementation guidance and the description of drugs covered
  under a medical benefit, clear and appropriate for impacted payers?

• For MA organizations, are there drugs other than those payable under Part B, such as supplemental benefits, that should be
  covered by our proposals to require MA organizations to support electronic prior authorization?

• Is the rubric to categorize drugs as within the scope of the Prior Authorization API (covered under a medical benefit) or
  within the scope of the NCPDP standards (covered under a pharmacy benefit) based on the system through which the claims are
  processed applicable to and appropriate for all or most state Medicaid and CHIP FFS programs?

• Is the system through which claims are processed the accurate and appropriate way to differentiate the categories of drugs
  that are within scope of the Prior Authorization API versus the NCPDP standards for other types of impacted payers?

4. Proposed Requirement To Support the NCPDP SCRIPT Standard for Prior Authorization for State Medicaid and CHIP Fee-for-Service

Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated
Exchanges

We propose to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b)
for the electronic prior authorization of drugs covered under a pharmacy benefit, as that term is described in the standard,
further discussed in section I.C. of this proposed rule. We are making these proposals in response to comments we received
on the 2022 CMS Interoperability and Prior Authorization proposed rule that stated that requiring impacted payers to support
electronic prior authorization of drugs would support faster access to necessary medications for patients and reduce administrative
burden on providers.

We are proposing an October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs. Requiring state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard
adopted by the Secretary would align requirements for these payers with the existing requirement for Medicare Part D sponsors,
prescribers, and dispensers in 42 CFR 423.160(b)(1).

Specifically, as discussed in section II.A. of this proposed rule, we propose that those impacted payers would be required
to support an adopted version of the NCPDP SCRIPT standard to enable providers to electronically submit prior authorization
requests and receive prior authorization decisions for drugs covered under a pharmacy benefit using the following transactions:

• PAInitiationRequest and PAInitiationResponse
• PARequest and PAResponse
• PAAppealRequest and PAAppealResponse
• PACancelRequest and PACancelResponse

• PANotification (NCPDP SCRIPT standard version 2023011 only)
  We are not proposing to require providers to use electronic prior authorization in this proposed rule. Rather, we are proposing
  that an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary must be available for providers to use for
  prior authorization, and that the payer must send the response to the prior authorization request using the same standard.
  If ONC establishes an expiration date for an adopted version of the NCPDP SCRIPT standard in 45 CFR 170.205(b), upon the specified
  expiration date, that version would no longer be eligible for use by impacted payers to meet the interoperability requirements.
  State Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs
  may continue to make non-electronic means of conducting prior authorization (for example, fax, phone call, or direct data
  entry through a payer portal) available to providers. However, should these proposals be finalized, an unexpired version of
  the NCPDP SCRIPT standard adopted by the Secretary would be the only electronic method these payers would be

  permitted to use for the prior authorization of drugs covered under a pharmacy benefit as that term is described by the implementation
  guidance of the NCPDP SCRIPT standard, as discussed in sections II.A.2. and II.A.3. of this proposed rule.

The NCPDP SCRIPT standard is already used by Medicare Part D sponsors, prescribers, and dispensers and required for various
purposes by 15 states (for example, for electronic prior authorization and for electronic prescribing). The proposal to require
other impacted payers to support the standard should create greater efficiency for providers and drive interoperability across
CMS programs. (105)

We propose an October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by
the Secretary. That aligns with the feedback we received in response to the 2022 CMS Interoperability and Prior Authorization
proposed rule that payers and developers generally need at least a year to implement a new system (89 FR 8824). In the 2024
CMS Interoperability and Prior Authorization final rule, we finalized compliance dates beginning in 2027 for policies that
require API development and enhancement. That afforded impacted payers approximately 3 years to implement from when the rule
was finalized (89 FR 8784, 8817, 8855, and 8897). That feedback was based on the totality of our proposals that require API
development or enhancement—to require three new APIs and to update the Patient Access API. We believe it is appropriate to
afford payers and developers approximately a year to implement this proposal, which will require time for programming, testing,
education, and outreach.

In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following:

• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs covered under a pharmacy benefit.
• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an adopted version of the NCPDP SCRIPT standard using the following transactions: PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification (currently NCPDP SCRIPT standard version 2023011 only).
• The proposed October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

5. Proposed Requirement To Support the NCPDP Formulary and Benefit Standard for State Medicaid and CHIP Fee-for-Service Programs,

Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated Exchanges

We are proposing to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs to support an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u)
by October 1, 2027. Accordingly, upon the specified expiration date of a version of the NCPDP F&B standard adopted in 45 CFR
170.205(u), that version would no longer be eligible for use by impacted payers to meet this proposal, if finalized.

As discussed in section II.A.2.b. of this proposed rule, the NCPDP F&B standard enables providers to view formulary and benefit
information at a group level. The NCPDP F&B standard supports the NCPDP SCRIPT standard by giving providers information at
the point of prescribing about whether a payer covers a particular drug and whether the payer requires prior authorization.
Therefore, our proposal to require impacted payers to support an unexpired version of the NCPDP F&B standard adopted by the
Secretary should enhance providers' ability to electronically request prior authorization for drugs covered under a pharmacy
benefit. As with our other proposals, the NCPDP F&B standard should enable a more seamless exchange of prior authorization
requirements, which should help state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs more efficiently manage their pharmacy benefits and prior authorization programs. A standardized
approach to providing formulary and prior authorization information could make provider and payer operations more efficient
and reduce costs.

The 2024 Part D and Health IT Standards final rule also includes requirements for transmitting formulary and benefits information
between Part D sponsors and providers using the NCPDP F&B standard. Specifically, until January 1, 2027, that rule requires
Part D sponsors to use either NCPDP F&B standard version 3.0 or an unexpired version of the NCPDP F&B standard adopted by
the Secretary in 45 CFR 170.205(u). Beginning January 1, 2027, Part D sponsors are required to use an unexpired version of
a standard adopted by the Secretary in 45 CFR 170.205(u), which is currently NCPDP F&B standard version 60 (89 FR 51250-51251). (106) Our proposal to require the other types of impacted payers (state Medicaid and CHIP FFS programs, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs) to implement an unexpired version of the NCPDP F&B standard adopted
by the Secretary in 45 CFR 170.205(u) would align payers and should reduce the burden on providers currently using disparate
systems and standards across payers.

In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following:

• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u) to make available formulary and benefits information for drugs covered under a pharmacy benefit. • The proposed October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

6. Proposed Requirement To Support the NCPDP Real-Time Prescription Benefit Standard for State Medicaid and CHIP Fee-for-Service

Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated
Exchanges

We also propose that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs support an unexpired version of the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c)
by October 1, 2027.

The 2024 Part D and Health IT Standards final rule requires, beginning January 1, 2027, Part D sponsors' real-time benefit
tools to comply with an unexpired version of a standard adopted by the Secretary in 45 CFR 170.205(c) (89 FR 51247 and 51251). (107) Currently, the version of the NCPDP RTPB standard that the Secretary has adopted in 45 CFR 170.205(c) is NCPDP RTPB standard
version 13, adopted in 45 CFR 170.205(c)(1). As discussed in section II.A.2.c. of this proposed rule, the NCPDP RTPB standard
enables real-time, patient-specific prescription benefit information to be delivered to providers at the point of prescribing.
This proposal should coalesce support for the NCPDP SCRIPT standard and improve efficiency and accuracy. By integrating the
NCPDP RTPB standard into the prior authorization process, payers could provide immediate feedback to providers about a patient's
coverage, including whether a drug covered under a pharmacy benefit requires prior authorization, alternative covered medications,
and patient out-of-pocket costs. State Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs could reduce administrative costs by providing prior authorizations and coverage information up
front by avoiding unnecessary requests. Providers and patients could benefit from implementing the NCPDP RTPB standard because
real-time benefit information could reduce care delays or unexpected costs.

Our proposal to require these standards continues our goal towards interoperability and adoption of modern standards, reducing
industry fragmentation. This standardization could encourage innovation and development of more sophisticated clinical decision
support tools.

In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following:

• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c) to make available real-time coverage information for drugs covered under a pharmacy benefit.
• The proposed October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

7. Extensions, Exemptions, and Exceptions

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized processes for state Medicaid and CHIP FFS
programs to request an extension to the compliance date or an exemption from requirements to build some of the interoperability
APIs if they meet certain criteria. (108) We also finalized a process for individual market QHP issuers on the FFEs to request an exception from the requirement to
build the interoperability APIs under certain circumstances. (109)

However, if HHS finalizes its proposal to adopt the FHIR specifications that compose the Prior Authorization API as the HIPAA
standard for “referral certification and authorization” transactions (further discussed in section II.H. of this proposed
rule), it could affect impacted payers' (which are HIPAA covered entities) ability to request extensions, exemptions, and
exceptions from the requirement to implement the Prior Authorization API finalized in the 2024 CMS Interoperability and Prior
Authorization final rule.

a. State Medicaid and CHIP Fee-for-Service Programs

The process for state Medicaid and CHIP agencies to request an exemption from the Prior Authorization API includes requirements,
in 42 CFR 431.80(c)(2)(ii)(B)(2) and 42 CFR 457.732(d)(2)(ii)(B)(2), that states must provide an alternative plan to ensure that enrolled providers will have efficient electronic access to
the same information through other means while the exemption is in effect. At the time the 2024 CMS Interoperability and Prior
Authorization final rule was finalized and today, the existing HIPAA standard for prior authorization transactions is the
X12N 278 transaction standard. We finalized the exemption process with the understanding that a HIPAA-compliant X12N 278 transaction
standard would be an acceptable alternative to meet that requirement. However, if HHS's HIPAA proposals in section II.H. are
finalized, that standard would no longer be HIPAA-compliant as of the finalized compliance date.

Because the purpose of the HIPAA Administrative Simplification provisions is to ensure that covered entities do not use electronic
transactions other than those adopted by the Secretary, there would be no other permissible alternative electronic methods
for state Medicaid and CHIP FFS programs to use. Since there would be no other HIPAA-permitted alternative electronic methods
once HIPAA proposals are finalized, state Medicaid and CHIP FFS programs previously eligible for an exemption to the Prior
Authorization API would no longer have the ability to sustain an alternative plan to support electronic prior authorization. (110) The HIPAA Administrative Simplification statute and regulations do not provide for exceptions or exemptions, other than that
described in 45 CFR 162.940 to permit testing of proposed modifications. Therefore, in order to ensure that the Prior Authorization
API exemption requirements finalized in 42 CFR 431.80(c)(2) for state Medicaid FFS programs and in 42 CFR 457.732(d)(2) for
state CHIP FFS programs do not conflict with the proposed HIPAA Administration Simplification requirements, we are proposing
to remove the policy finalized in the 2024 CMS Interoperability and Prior Authorization final rule that allows states with
small FFS populations to request an exemption from CMS for the non-drug items and services Prior Authorization API requirements.
If finalized as proposed, removal of this policy would result in the eventual expiration of any approved exemptions without
the possibility of renewal. Notably, there are no HIPAA standard transactions related to the Patient Access, Provider Directory,
Provider Access, or Payer-to-Payer APIs, so the

  ability to request an exemption for these standards would not be affected and we are proposing no changes to the extensions
  and exemptions policies finalized in the 2024 CMS Interoperability and Prior Authorization final rule for those APIs.

However, to provide additional flexibility to state Medicaid and CHIP FFS programs, we are proposing to extend the policy
that allows any state to request extensions for additional years until the HIPAA compliance date, if HHS finalizes its proposals.
As discussed in section II.H.8. of this proposed rule, we are proposing a multiple year gap between the finalized Prior Authorization
API compliance dates for impacted payers and the proposed compliance dates to our proposals to adopt FHIR standards as the
HIPAA transaction standard for prior authorization transactions. As discussed in section II.H. of this proposed rule, we believe
it would be appropriate to give 24 months for implementation between the effective date of the final rule and the proposed
compliance date for most covered entities and 36 months for small health plans. As defined in 45 CFR 160.103, small health
plans are those with annual receipts of $5 million or less. As state Medicaid and CHIP agencies are not commercial entities,
they may generally be considered small health plans. (111) As state Medicaid and CHIP agencies are not considered for-profit entities, we would not expect them to reach the small health
plan $5 million dollar threshold and therefore would be considered small health plans for the purpose of granting extensions
up to 36 months.

Some states may be unable to meet the proposed CMS interoperability compliance dates in this proposed rule due to funding
challenges for necessary contracting and staff resources to develop and implement the technical requirements, depending on
when the final rule is published in relation to a state's FY, legislative session, budget process, and related timelines.
Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a
state's implementation of these proposals. The timeline for an openly competed procurement process and the time required to
onboard the contractor and develop the technical capabilities proposed here can be lengthy for states. A state might need
to hire new staff with the necessary skills to implement our finalized policies and proposals to require impacted payers to
support electronic prior authorization.

Overlapping requirements with varying timelines and exceptions add significant uncertainty to state FFS operations and makes
responsible stewardship of federal funding more challenging. If HHS finalizes its proposals to modify the HIPAA transaction
standard for prior authorization transactions, states would need to track multiple compliance dates, understand which standards
are permissible at different times, and potentially procure funding and staffing to revise new API system implementations
accordingly in coordination with state legislatures. These requirements, whether final or proposed, come at a time when state
resources are allocated toward implementation of recent statutory changes, notably the Working Families Tax Cut legislation
(Pub. L. 119-21, enacted July 4, 2025), making it difficult for them to reallocate or redirect resources. Providing state
Medicaid and CHIP FFS programs the ability to request extensions to the compliance dates proposed here could mitigate these
challenges. In addition, it could align with the requirements for covered entities that are not CMS impacted payers to use
the proposed FHIR standard if they engage in electronic prior authorization.

To align with the proposals to support electronic prior authorization for drugs with those for electronic prior authorization
of non-drug items and services, we also propose to offer similar flexibilities for state Medicaid and CHIP FFS programs to
request extensions to the October 1, 2027 compliance date for the proposed requirements to incorporate drugs into the Prior
Authorization API and to support the NCPDP standards for the electronic prior authorization of drugs.

Should our proposals be finalized, a state Medicaid or CHIP FFS program could request from CMS extensions to the compliance
dates for (1) the non-drug items and services Prior Authorization API requirements finalized in the 2024 CMS Interoperability
and Prior Authorization final rule; (2) the proposal to incorporate drugs into the Prior Authorization API; and (3) the proposal
to require impacted payers to support NCPDP standards for the electronic prior authorization of drugs. States must be clear
to which of these requirements they are requesting an extension and the required justification must be attenuated to the specific
requirements.

We propose that a state must submit that request as a part of its annual Advance Planning Document (APD) for MMIS operations
expenditures in sufficient time to be approved before the applicable compliance date. The state's request would have to include
the following: (1) a narrative justification describing the specific reasons why the state cannot satisfy the requirement(s)
by the compliance date and why those reasons result from circumstances that are unique to the agency operating the state Medicaid
or CHIP FFS program; (2) a report on completed and ongoing state activities that evidence a good faith effort towards compliance;
and (3) a comprehensive plan to meet the requirements before a finalized HIPAA compliance date.

Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS were to determine
that the request adequately establishes a need to delay implementation and that the state has a comprehensive plan to implement
the proposed requirements before a finalized HIPAA compliance date.

We understand that state Medicaid and CHIP FFS programs have numerous competing priorities and face additional funding and
staff limitations compared to commercial entities (89 FR 8902). Therefore, we encourage states to contact their Medicaid Enterprise
Systems (MES) officer, if necessary for proper and efficient operations, to discuss their extenuating circumstances. Any flexibility
granted to a state Medicaid or CHIP FFS program would be temporary and limited to the unique circumstances of the program.

b. Exceptions for Qualified Health Plan Issuers on the Federally-facilitated Exchanges

In the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules,
we finalized a process for individual market QHP issuers on the FFEs to submit a request for an exception from the technical
requirements finalized in those rules. (112) We explained that ability of QHP issuers on the FFEs to implement the interoperability APIs might vary based on their available
resources.

Those final rules established that individual market QHP issuers on the FFEs that apply for an exception must submit a narrative
justification as part of their QHP application. That narrative

  justification must describe the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year,
  the impact of non-compliance upon providers and/or enrollees, the current or proposed means of providing health information
  to the applicable recipient, and solutions and a timeline to achieve compliance with the requirements of the applicable section.
  As described previously, any current or proposed means that differ from the finalized interoperability standard must be compliant
  with the HIPAA administrative simplification requirements. In the 2024 CMS Interoperability and Prior Authorization final
  rule, we also noted that QHP issuer certification applications in recent years indicated that most QHP issuers on the FFEs
  are compliant with the requirements to implement and maintain a Patient Access API; that is, they did not request exceptions
  through the process. Of the QHP issuers on the FFEs that did request exceptions, many explained in their justifications that
  they planned to become compliant with the API requirements mid-way through the upcoming plan year (89 FR 8906).

CMS takes a similar approach during the QHP certification process in other instances where flexibility may be warranted based
on a QHP issuer's circumstances. For example, per 45 CFR 156.230(a)(2)(ii), if a plan applying for QHP certification to be
offered through the FFE does not satisfy the network adequacy standards described in paragraphs 45 CFR 156.230(a)(2)(i)(A)
and 45 CFR 156.230(a)(2)(i)(B), as part of its QHP application, the issuer must include a justification describing how the
plan's provider network provides an adequate level of service for enrollees and how the plan's provider network will be strengthened
and brought closer to compliance with the network adequacy standards prior to the start of the plan year. The issuer must
provide information as requested by the FFE to support this justification. Our experience with these exceptions processes
for rules that are currently in effect suggest that making an exception available prevents the FFE from potentially losing
issuer participation based on concerns the issuer will ultimately be able to address during or before the plan year, typically
resulting in no potential harm to consumers. In particular, we have observed that QHP issuers have submitted narrative justifications
that may meet or be close to meeting the standards of providing an adequate level of service to enrollees by the start of
the applicable plan year.

Therefore, we propose an exception process to the proposed NCPDP standards requirements for QHP issuers on the FFEs in 45
CFR 156.223(i). We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot
satisfy the proposed requirement to support the proposed NCPDP standards, the issuer would have to include in its QHP application
a narrative justification describing the reasons why it could not satisfy the requirements for the applicable plan year, the
effect of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers
and facilitating prior authorization, and solutions and a timeline to achieve compliance with the applicable requirements.

We propose that an FFE may grant an exception to the proposed requirement to support the NCPDP standards if it determines
that making QHPs of such issuer available through the Exchange is in the interests of qualified individuals and qualified
employers in the state or states in which the Exchange operates and that an exception is warranted to permit the issuer to
offer QHPs through the FFE. This proposal is consistent with the exceptions for individual market QHP issuers on the FFEs
that we finalized for the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. (113)

In addition, we propose to amend the requirements in 45 CFR 156.223(h)(1)(iii) to specify that QHP issuers on the FFEs, as
part of a request for an exception from the Prior Authorization API requirements in 45 CFR 156.223(b), describe the current
or proposed means of conducting prior authorization. Under the current requirement finalized in the 2024 CMS Interoperability
and Prior Authorization final rule, QHP issuers on the FFEs that are applying for an exception must describe their current
or proposed means of providing health information to providers. However, providing health information to providers does not
describe the full scope of the Prior Authorization API. While part of the purpose of the Prior Authorization API is to make
available to providers information about prior authorization requirements, it is also to facilitate prior authorization using
bidirectional data exchanges between providers and payers. To align with the full scope and purpose of the Prior Authorization
API, we believe that any QHP issuer on the FFE that applies for an exception should describe how they will facilitate prior
authorization, not just how health information will be provided to providers.

In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following:

• The proposal to remove the policy finalized in the 2024 CMS Interoperability and Prior Authorization final rule that allows states with small FFS populations to request an exemption from CMS for the non-drug items and services Prior Authorization API requirements.
• The proposal that state Medicaid and CHIP FFS programs may request extensions to the finalized compliance date to implement the Prior Authorization API and the proposed compliance date to incorporate drugs covered under a medical benefit into the Prior Authorization API.
• The proposal that state Medicaid and CHIP FFS programs may request extensions and that QHP issuers on the FFEs may request an exception from the proposed requirement to support an unexpired version of the NCPDP standards that the Secretary has adopted in 45 CFR 170.205(b), (c), or (u).

• The proposal to amend language in 45 CFR 156.223(i)(1)(iii) to require that a QHP issuer on the FFEs seeking an exception
  from the Prior Authorization API requirements and/or proposed requirement to support an unexpired version of the NCPDP standards
  that the Secretary has adopted in 45 CFR 170.205(b), (c), or (u) to describe their current or proposed means of conducting
  prior authorization.
  In addition, we request comments on the following:

• Flexibilities and options that can be provided to state Medicaid and CHIP FFS programs eligible for an exemption and QHP
  issuers on the FFEs eligible for an exception that would reduce burden for the reasons outlined previously, while ensuring
  compliance with the proposed or adopted HIPAA transaction standards.
  

8. Statutory Authorities

a. Medicare Advantage

Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent
with and carry out Part C of the Medicare statute, including the provisions in section 1852 of the Act. Section 1852(c)(1)(G)
of the Act requires that MA organizations disclose to their enrollees any rules regarding prior authorization, and section
1852(g)(1) of the Act requires MA organizations to have procedures for making timely determinations regarding whether an enrollee
is entitled to receive a health service. Section 1857(e)(1) of the Act authorizes the addition of contract terms for contracts
between the Secretary and an MA organization determined by the Secretary to be “necessary and appropriate” for the MA program.
This broad authority encompasses the adoption of standards for electronic prior authorization, which are important for improving
efficiency and reducing burdens in health care delivery.

The Prior Authorization API is an electronic means for receiving and responding to requests for coverage determinations before
the services are rendered or items furnished. The proposed requirement to incorporate drugs covered under a medical benefit
that may require prior authorization into the Prior Authorization API is consistent with MA organizations' obligations under
sections 1852(c)(1)(G) and 1852(g)(1) of the Act. Pursuant to the Secretary's authority under sections 1856(b) and 1857(e)(1)
of the Act, we are proposing to require MA organizations to expand the scope of the Prior Authorization API to incorporate
drugs covered under a medical benefit.

We propose additional requirements for MA organizations to ensure that providers have further information about drug prior
authorization through the Prior Authorization API required under regulations in 42 CFR 422.122(b). This proposed requirement
would necessitate updating the Prior Authorization API with information about the coverage and documentation requirements
for prior authorization of drugs covered under a medical benefit and responding to prior authorization requests for such drugs
through the Prior Authorization API.

We propose requiring MA organizations to expand the Prior Authorization API using recommended or updated implementation specifications
discussed in section II.A. of this proposed rule. These implementation specifications are expected to improve the prior authorization
process by addressing absences in providers' access to information about the prior authorization rules and documentation requirements
for drugs. Under our proposal, the mandatory Prior Authorization API would communicate the coverage and documentation requirements
for prior authorization for drugs covered under a medical benefit, indicating if authorization is required and what documentation
is required to support an authorization request. This electronic API-enabled access to information should improve timely access
to care for patients by mitigating delays for necessary medications known to occur when a provider is trying to determine
drug coverage or eligibility requirements or does not know what documents to submit to obtain prior authorization.

If applicable, providers' burden may be reduced if they can submit a prior authorization request and access status and decision
information for drugs through an MA organization's Prior Authorization API. The required Prior Authorization API can potentially
improve the efficiency of the prior authorization process for drugs covered under a medical benefit as much as it does for
non-drug items and services if the number of appeals, denials, and requests for additional documentation can be reduced.

We believe this proposal to extend the scope of the Prior Authorization API to incorporate drugs covered under a medical benefit
should contribute to program efficiency and effective operations and should be in the best interest of MA enrollees.

b. State Medicaid and CHIP

For Medicaid, most of the proposals described in this section are authorized by sections 1902(a)(4), 1902(a)(8), and 1902(a)(19)
of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are
found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. Section 1902(a)(8)
of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals,
which may result in faster beneficiary access to services. Section 1902(a)(19) of the Act requires states to ensure that care
and services under a Medicaid state plan are provided in a manner consistent with the simplicity of administration, which
can result in more uniform IT regulations and standards that are in the best interests of the recipients. For Medicaid managed
care, section 1932(c)(1)(A) of the Act requires that states that contract with Medicaid MCOs develop and implement a quality
assessment and improvement strategy that includes standards for access to care so that covered services are available within
reasonable timeframes. CMS relies on our authority in section 1902(a)(4) of the Act to apply these standards for PIHPs and
PAHPs.

The proposals to incorporate drugs covered under a medical benefit into the Prior Authorization API and to improve electronic
prior authorization for covered outpatient drugs by supporting the adopted version of the NCPDP SCRIPT standard by the Medicaid
programs is supported by the sections of the Act referenced previously. For this proposal, CMS would rely on our authority
in section 1902(a)(4) of the Act to adopt these standards for PIHPs and PAHPs. This would ensure that the same requirements
apply to MCOs, PIHPs, and PAHPs.

The proposal for state Medicaid FFS programs and Medicaid managed care plans to implement electronic prior authorization for
drugs is expected to improve the efficiency and timeliness of the prior authorization process for Medicaid beneficiaries,
providers, state Medicaid agencies, and Medicaid managed care plans by addressing inefficiencies that might exist in the process
today. Support for the proposed FHIR and NCPDP standards could allow a provider to determine whether a prior authorization
is required and the documentation requirements for that prior authorization request. The Prior Authorization API and NCPDP
SCRIPT standard can improve the prior authorization process by making it more efficient, including by reducing the number
of denials and appeals or eliminating requests for additional documentation. Those standards could—

• Enable providers to submit a complete prior authorization request faster and easier;
• Support more timely notice to the provider and beneficiary of the disposition of the prior authorization request; and
• Permit improved scheduling of services or filing appeals, depending on the decision. For CHIP, we are proposing these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children effectively and efficiently that is coordinated with other sources of health benefits coverage.

We are proposing to require state CHIP FFS programs and CHIP managed

  care entities to implement systems to support electronic prior authorization for all drugs to improve the prior authorization
  process for patients, providers, and payers. We believe these proposals should address deficiencies and inefficiencies that
  exist currently. Today, a payer's rules about when prior authorization is required for drugs and the documentation requirements
  are not necessarily easily accessible for providers. The Prior Authorization API and support for the proposed NCPDP standards
  should enable a provider to determine whether prior authorization is required for a drug, to access the documentation requirements,
  and to submit a prior authorization request electronically. While we expect providers to be the primary beneficiaries of these
  proposals, improving prior authorization for drugs could also serve the requirements in section 2101(a) of the Act that CHIP
  ensures access to coverage and coordinated care.

c. Qualified Health Plan Issuers on the Federally-facilitated Exchanges

Section 1311(e)(1)(A) of the Affordable Care Act requires that Exchanges only certify plans as QHPs if they meet the requirements
for certification promulgated by the Secretary under section 1311(c)(1) of the Affordable Care Act, while section 1311(e)(1)(B)
of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines that making such plans available
is in the interests of qualified individuals and qualified employers in the state or states in which the Exchange operates.

For QHP issuers on the FFEs, we are proposing to amend the QHP certification standard that we finalized in the 2024 CMS Interoperability
and Prior Authorization final rule using the same authority under section 1311(e)(1) of the Affordable Care Act. These proposals
would expand the use of specific technology and standards to promote efficiency and transparency in the prior authorization
process for drugs, which should improve access to care for enrollees in QHPs offered by issuers on the FFEs by ensuring that
the QHP issuers on the FFEs respond to prior authorization requests promptly through a modernized process and clearly explain
their rationale in cases of denial. Our proposal to require that QHP issuers on the FFEs support electronic prior authorization
for all covered drugs either through the Prior Authorization API as described in 45 CFR 156.223(b) or through an unexpired
version of the NCPDP SCRIPT standard that the Secretary has adopted in 45 CFR 170.205(b), combined with the ability of QHP
issuers on the FFEs to request an exception, is in the interest of qualified individuals and qualified employers because it
balances the goals of ensuring access to health care with robust QHP issuer participation on the FFEs.

Enrollees in QHPs on the FFEs may receive approved covered drugs more quickly when their providers can submit a prior authorization
request electronically. These proposed requirements would allow providers to determine whether prior authorization is required
for drugs, submit the necessary documentation, and receive an electronic response in real-time or near real-time. As we explained
in the 2024 CMS Interoperability and Prior Authorization final rule regarding the APIs required in that final rule (89 FR
8786), we believe that, with limited exceptions, certifying only health plans that support electronic prior authorization
for all covered drugs and adhere to the other requirements described in this section of the preamble is in the interests of
qualified individuals and qualified employers in the state or states in which a QHP issuer on the FFEs operates because of
the opportunities for improvements in patient care. We encourage SBEs, including SBE-FPs, to consider whether a similar requirement
should apply to issuers participating in their Exchanges.

C. Improving Communications and Decision Timeframes for Prior Authorizations

1. Background for Improving Prior Authorization Process

In the 2024 CMS Interoperability and Prior Authorization final rule, we described the impact of excessive wait times for prior
authorization decisions on patients, providers, and payers (89 FR 8858 and 8859). We discussed surveys, federal reports, and
studies, including a multi-year survey conducted by the American Medical Association (AMA) about delays in care and medical
risks to patients due to issues with prior authorization (89 FR 8859). (114) Concerns about prior authorization processes have remained the same. According to a 2024 AMA report, 29 percent of physicians
reported that prior authorization had led to a severe adverse event for a patient in their care, including hospitalization,
permanent impairment, or death, and 94 percent reported that prior authorization harmed patient clinical outcomes. (115) In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, many commenters stated that delays in
responding to prior authorization requests for drugs significantly impacted patient care, health, and burden on providers
(89 FR 8765).

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized specific process requirements for impacted
payers to improve the prior authorization process for non-drug items and services. We established prior authorization decision
timeframes for impacted payers other than QHP issuers on the FFEs (MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP managed care entities) and required that, when denying a prior authorization request
for non-drug items and services, impacted payers respond to the requesting provider with a specific reason for the denial
(89 FR 8897). Shortening and standardizing timeframes for prior authorization decisions across programs improves access to
health care and can mitigate the negative impacts of delays, particularly for individuals with chronic or complex conditions.
The term “denial” means that the payer has refused to authorize coverage for a recommended medical treatment, procedure, or
medication. Payers deny coverage for various reasons, such as a determination that the service or medication is not medically
necessary or does not meet their coverage criteria. Requesting providers need to clearly understand the reason for denial
so that additional information can be provided or alternative care options can be considered.

In the 2024 CMS Interoperability and Prior Authorization final rule, we also finalized requirements on impacted payers to
publicly report certain prior authorizations metrics for non-drug items and services annually beginning in 2026. (116) By sharing appropriate data, payers can build trust with their patients and providers and showcase

  their commitment to improving services. Beyond information about which services require prior authorization and the requirements
  for approval, greater transparency about payer performance on denials, timeframes, and volumes could be helpful for the public.
  Such reporting improves accountability and can identify opportunities for improvement.

The proposals in this proposed rule to extend our technical and process requirements for prior authorization to all drugs
should improve patients' access to services. We intend these proposals to create more unified processes for providers to request
and receive prior authorization for drugs. Such standardization and consistency should allow providers to spend more time
on patient care and less time on administrative tasks and paperwork. Additionally, standardized processes could reduce wait
times and resubmissions and result in more efficient and accurate decision-making.

2. Proposed Requirement To Include a Specific Reason for Denial in Response to Prior Authorization Requests for All Drugs

a. Background

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that, beginning in 2026, impacted
payers must provide a specific reason for denial in their response to a provider's prior authorization request for non-drug
items and services, regardless of the method used to communicate the prior authorization request or decision. (117) We are now proposing to add the same requirements for denied prior authorizations for all drugs for impacted payers that are
not already subject to such a requirement. Throughout the 2022 CMS Interoperability and Prior Authorization proposed rule
(87 FR 76238) and the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8758), we described opportunities
to improve the prior authorization process, specifically where better communication between payers and providers could mitigate
confusion about the status of a prior authorization and why a request was denied. Although prior authorization has a role
in the health care system, denying services that do not meet the payer's internal coverage or utilization criteria or do not
meet regulatory or statutory requirements should not adversely impact the health or well-being of the patient. If a denial
is ineffectively communicated, then it could cause a patient to delay or abandon treatment.

In the 2024 CMS Interoperability and Prior Authorization final rule, we explained that payers deny prior authorizations for
a variety of reasons, including because the payer does not consider the items to be medically necessary, the patient exceeded
limits on allowable covered care, or documentation to support the request was missing or inadequate (89 FR 8872). The reasons
for denying prior authorizations for drugs may be similar. Health plan formularies are lists of generic and brand-name drugs
covered by a health plan and may include drug tiering information. If prior authorization is denied because of a payer's formulary
or utilization management policies and that is not clearly communicated, then the provider cannot effectively act on behalf
of the patient. When a payer provides a specific reason for a denial, a provider can take appropriate actions such as resubmitting
the request with updated information, appealing the decision, or identifying alternative drugs or treatments. Payers send
denials through various channels—electronically, by mail, via portal, or by fax. When doing so, they often use proprietary
codes or narrative text to communicate the reasons for denial. For some payers, the process of communicating denials remains
both inefficient and inconsistent. The result is that providers may not have timely, clear direction on the next steps for
providing appropriate care for their patients after a denied prior authorization request.

b. Existing Requirements To Communicate With Providers About Denied Prior Authorization Requests for Drugs

As described in the 2024 CMS Interoperability and Prior Authorization final rule, some impacted payers are required by existing
federal laws and regulations to notify providers or patients when the payer denies or makes an adverse decision on a prior
authorization request (89 FR 8874-8876). We are not proposing to alter or replace existing requirements for payers to notify
patients, but to add requirements to ensure a specific reason for denial is communicated to providers. In addition to the
existing program notification requirements, communicating specific reasons for denial increases transparency, reduces burden,
and improves efficiencies for both payers and providers.

Under existing regulations, an MA organization must notify the enrollee (and the prescribing physician or other prescriber
involved, as appropriate) of its determination on a request for a Part B drug as expeditiously as the enrollee's health condition
requires but no later than 72 hours after receiving a standard request and no later than 24 hours after receiving an expedited
request. (118) When a request for a Part B drug is denied, MA organizations must provide the specific reasons for the denial along with certain
other information, such as how to request an appeal. (119) CMS provides a standardized form (120) that MA organizations must use, which captures a specific rationale of why the item, service, or Part B drug was denied, including
a description of the applicable coverage rule or applicable plan policy (for example, the Evidence of Coverage provision)
upon which the action was based and a specific explanation about what information is needed to approve coverage, if applicable.
Given that existing regulations require MA organizations to notify the enrollee and the prescriber, as appropriate, of a decision
on a Part B drug request, we are not proposing any changes related to the notice requirements for a prior authorization decision
by an MA organization in this rule. Similar notice requirements, including a reason for denial, exist for Part D sponsors
making prior authorization decisions. (121) Standardized MA and Part D denial notices, which plans must send to enrollees, require a specific reason for the denial and
the following language: “Share a copy of this decision with your doctor and discuss next steps. If your doctor asked for coverage
on your

  behalf, we already sent them a copy of this denial notice.” [(122)]()

Similarly, Medicaid managed care plans and CHIP managed care entities must notify the requesting provider and give the beneficiary
written notice of any decision by the plan to deny a service authorization request or to authorize a service in an amount,
duration, or scope that is less than requested. (123) As specified in 42 CFR 438.242(b)(8), by the rating period beginning on or after January 1, 2026, Medicaid managed care plans
must communicate a specific reason for any denials to the provider, regardless of the method used to communicate that information,
for prior authorization requests for non-drug items and services. (124) These requirements also apply to CHIP managed care entities by cross reference. (125)

While 45 CFR 156.223(a) requires QHP issuers on the FFEs to include a specific reason for the denial of a prior authorization
request to the provider, this requirement explicitly excludes prescription drugs.

c. Proposed Requirement To Include a Specific Reason for Denial to Providers When Denying Prior Authorization of All Drugs

for State Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified
Health Plan Issuers on the Federally-facilitated Exchanges

We propose that beginning October 1, 2027, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed
care entities, and QHP issuers on the FFEs be required to provide a specific reason to providers when denying a prior authorization
request for drugs, regardless of the method used to send the prior authorization request or decision. This proposal is an
effort to improve the communication between those impacted payers and providers when they deny a prior authorization request
for drugs. This proposal would align with the requirement finalized in the 2024 CMS Interoperability and Prior Authorization
final rule that impacted payers send to providers a specific reason for denying a prior authorization request for non-drug
items and services. (126) We now propose to apply that same denial notice requirement to state Medicaid and CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs for prior authorizations for drugs. This proposed change should
lead to those payers providing more transparent communication in their decision-making, allowing providers to address any
deficiencies in the request or consider alternative treatments.

The content of the response should include a specific reason for denying a prior authorization request for drugs that helps
a provider to understand why the request was denied and what actions must be taken to resubmit or appeal the decision. A specific
reason for denial could include information about the specific plan coverage criteria on which the denial is based, why documentation
did not support the medication or prescription, or why the drug is not deemed necessary. This proposal could improve the current
processes and reduce manual effort and costs by increasing the likelihood that providers whose prior authorization request
for drugs is denied have all the information they need to decide the next steps to care for the patient, including whether
and how to appeal the denial. We are proposing an October 1, 2027 effective date for this proposal, as these protections are
important to patients.

This proposal does not affect existing patient notice requirements for state Medicaid and CHIP FFS programs and QHP issuers
on the FFEs. State Medicaid and CHIP FFS programs are required to provide a beneficiary with timely and adequate written notice
of a “denial or change in benefits and services.” (127) In case of an adverse benefit determination, QHP issuers on the FFEs must include in their notice to enrollees certain information,
including the reason(s) for the adverse benefit determination, a denial code and its meaning, and a description of the QHP
issuer on the FFEs' standard that was used in the denial. (128) Like the requirement that we finalized in the 2024 CMS Interoperability and Prior Authorization final rule for non-drug items
and services, our proposed requirement should ensure that providers who submit prior authorization requests for drugs receive
information directly from impacted payers regarding an adverse prior authorization determination, which should expedite their
ability to appeal the determination or provide additional information if needed.

In addition to these new requirements, we are proposing to reorganize 42 CFR 438.210(c) and 42 CFR 438.242 to improve readability.
This proposal maintains existing program requirements for non-drug items and services while proposing these new requirements
for Medicaid managed care plans to provide specific denial reasons for drug prior authorization requests.

In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following:

• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to communicate to providers a specific reason for denying a prior authorization request for any drugs, regardless of the method used to send the prior authorization request or decision.
• The proposed October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.
• The proposed structural changes to 42 CFR 438.210(c) and 42 CFR 438.242 to improve readability.

3. Prior Authorization Decision Timeframes

a. Background

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for MA organizations, state
Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to make prior authorization decision
requests on non-drug items and services as expeditiously as a patient's health condition requires but no later than 7 calendar
days after receiving a standard request and no later than 72 hours after receiving an expedited request, effective in 2026
(89 FR 8897). However, we did not propose or finalize those requirements for QHP issuers on the FFEs, in part because existing
regulations in 45 CFR 147.136 establish timelines for all non-grandfathered

  group health plans and health insurance issuers offering individual and group health insurance coverage (“plans and issuers”)
  to notify claimants, participants, beneficiaries, and enrollees (patients) of prior authorization (referred to in those regulations
  as a “pre-service”) decisions (89 FR 8879). Specifically, 45 CFR 147.136(b)(3)(i) generally requires plans and issuers to
  meet the requirements of the claims and appeals procedures applicable to group health plans in 29 CFR 2560.503-1, as if the
  coverage were a group health plan. Under those requirements, QHP issuers on the FFEs must notify patients of a plan's benefit
  determination on a prior authorization request as expeditiously as a patient's health condition requires but no later than
  15 days after a standard request and as soon as possible, taking into account the medical exigencies, but no later than 72
  hours for expedited requests (referred to in those regulations as “urgent care” claims). Notably, these timeframes apply to
  non-drug items and services, as well as drugs. While neither 45 CFR 147.136(b)(3) nor 29 CFR 2560.503-1 require plans and
  issuers to notify the requesting provider of a prior authorization decision, when they do, HHS presumes that they do so within
  the same timeframes that they are required to notify patients. As a result, beginning in 2026, QHP issuers on the FFEs effectively
  have longer to provide notification of a decision on a standard prior authorization request for non-drug items and services
  (a maximum of 15 days) as compared to other impacted payers (a maximum of 7 days). [(129)]() In contrast, QHP issuers on the FFEs effectively have the same amount of time to provide notification of a decision on a standard
  prior authorization request for non-drug items and services as other impacted payers (a maximum of 72 hours). Finally, in
  both cases, as noted, there is no regulatory requirement that QHP issuers on the FFEs notify providers of any prior authorization
  decision.

In addition to the requirements for non-drug items and services, MA organizations, state Medicaid FFS programs, Medicaid managed
care plans, and CHIP managed care entities have existing decision timeframe requirements for prior authorization of certain
drugs. MA organizations must notify the enrollee (and the prescribing physician or other prescriber involved, as appropriate)
of a determination regarding coverage of a Part B drug as expeditiously as the enrollee's health condition requires, but no
later than 72 hours after receiving the standard request and no later than 24 hours after receiving the expedited request. (130) Similarly, Part D sponsors, including MA-PDs, have the same requirements for prior authorization decisions on Part D drugs
(with the possibility of an extension). (131) The Part D sponsor must notify the enrollee (and the prescribing physician or other prescriber involved, as appropriate) of
its determination as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving
the standard request and no later than 24 hours after receiving the expedited request. Given the existing prior authorization
decision timeframe requirements for Part B and Part D drugs, we do not believe that additional proposals for MA organizations
or Part D sponsors are necessary or appropriate at this time. However, we request comment on whether there are any drugs payable
under Part A that are not included as part of a larger bundle of inpatient services to which the timeframe to make prior authorizations
decisions should apply for MA organizations. If so, we would consider finalizing a policy to ensure that all drugs that require
prior authorization have appropriate decision timeframes.

State Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities also have existing decision timeframe
requirements for covered outpatient drugs. (132) Specifically, state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities must respond to a prior
authorization request for a covered outpatient drug within 24 hours of the request and dispense at least a 72-hour supply
of the drug in emergencies. However, there is no requirement specific to drugs for state CHIP FFS programs. Instead, state
CHIP FFS programs must adhere to the general decision-making timeframe, which mandates that prior authorization decisions
be made in accordance with the medical needs of the patient within 14 days after receiving a request for services (beginning
on January 1, 2026, the timeframe will be 7 calendar days for standard requests and 72 hours for expedited requests). (133)

As discussed in sections II.C.3.c. and II.C.3.d. of this proposed rule, we are now requesting information on whether there
are gaps in timeframe requirements for some drugs and if there are we are proposing to apply the prior authorization decision
timeframes for non-drug items and services outlined in the 2024 CMS Interoperability and Prior Authorization final rule to
that subset of drugs for which there are not already established prior authorization timeframes. This would apply to both
state Medicaid FFS programs and Medicaid managed care plans. We are also proposing to modify state CHIP FFS programs' decision-making
timeframes for the prior authorization of drugs comport with section 1927(d)(5)(A) of the Act to align with the requirements
for those programs.

b. Prior Authorization Decision Timeframes for Qualified Health Plan Issuers on the Federally-facilitated Exchanges

In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, many commenters disagreed with excluding
QHP issuers on the FFEs from the shortened timeframe requirements and asked that CMS reconsider the exclusion. Commenters
stated it would be more consistent and equitable for CMS to apply the same timeframe requirements for standard prior authorization
decisions for all impacted payers (89 FR 8880). Commenters stated that patients covered by these plans should be entitled
to the same protections as those covered by other impacted payers, and that excluding QHP issuers on the FFEs could negatively
affect patients by delaying access to care based only on the type of insurance they have. One commenter stated that they did
not believe that shortening the prior authorization decision timeframe for QHP issuers on the FFEs from a 15 day response
time for standard requests to 7 days would cause an undue burden to those plans. We also received many comments requesting
CMS consider adding additional standards to the prior authorization process to address the adverse effects of delays on patients
and providers (89 FR 8859). Multiple commenters wrote that CMS should apply even shorter prior authorization decision timeframes
to QHP issuers on the FFEs, such as 72 hours for standard

  requests and 24 hours for expedited requests.

In response to the comments received, we stated that we would evaluate opportunities for future rulemaking to alleviate provider
burdens and mitigate delays associated with prior authorization (89 FR 8859). We are aware that a growing number of states
have passed laws to reduce prior authorization decision timeframes, require technical standards, limit procedural justifications
for denials, tie decisions to clinical criteria, and increase transparency. (134) In addition to public comments that expressed concerns that patients experience delayed or deferred care because of complex
prior authorization processes, recent research has suggested that these concerns disproportionately impact those with chronic
conditions and mental health care needs. (135)

Hence, we are now proposing, in 45 CFR 156.223(i)(1)(i), that beginning October 1, 2027 in response to a request for prior
authorization for non-drug items and services, QHP issuers on the FFEs must notify the requesting provider of their decision
as expeditiously as a patient's health condition requires but no later than 7 days after receiving a standard prior authorization
request and no later than 72 hours after receiving an expedited prior authorization request.

We also propose, in 45 CFR 156.223(i)(1)(ii), that beginning October 1, 2027 in response to a prior authorization request
for any drug, QHP issuers on the FFEs must notify a requesting provider of their decision as expeditiously as the enrollee's
health condition requires, but no later than 72 hours after receiving a standard prior authorization request and no later
than 24 hours after receiving an expedited prior authorization request. These are similar to the timeframes for prior authorization
decisions for drugs that we propose for other impacted payers in this proposed rule. The proposed timeframes to require QHP
issuers on the FFEs to notify the requesting provider of a prior authorization decision would be new; that is, there is currently
no requirement for QHP issuers on the FFEs to notify providers of a prior authorization decision within any specific period
of time. This proposal would not change existing prior authorization notification requirements in 45 CFR 147.136 for patients
but would create a new requirement for QHP issuers on the FFEs to notify the requesting provider of a prior authorization
decision within a specific timeframe based on the nature of the request, and these timeframes would generally be shorter than
the maximum amount of time that QHP issuers on the FFEs have to notify patients regarding standard prior authorization requests
under existing regulations in 45 CFR 147.136. (136)

Establishing a new requirement for QHP issuers on the FFEs to notify providers of prior authorization decisions on non-drug
items and services and drugs, and aligning those timelines with current and proposed timelines for other impacted payers,
could improve patient care and minimize administrative burden for providers who would be able to expect prior authorization
decisions within the same timeframe from all impacted payers. We are not proposing to shorten the timeframes for QHP issuers
on the FFEs to notify patients of prior authorization decisions as established in 45 CFR 147.136(b)(3); however, we recognize
that QHP issuers on the FFEs may voluntarily adopt shorter patient notification timeframes that align with the proposed provider
notification timeframes to minimize administrative burden. Therefore, this proposal may result in faster notification for
patients than is required by 45 CFR 147.136(b)(3) and may result in QHP issuers on the FFEs notifying patients more quickly
than plans and issuers subject to 45 CFR 147.136(b)(3), including issuers on SBEs.

We expect that the proposed timeframes for notifying providers would be feasible for QHP issuers on the FFEs given the notification
functionality of the Prior Authorization API and NCPDP standards that we are proposing QHP issuers on the FFEs to support
for electronic prior authorization. Those standards support direct electronic communications between payers and providers
about prior authorizations. In addition, that available technology can accelerate the decision-making itself and we are of
the view that QHP issuers on the FFEs should be part of this trend in process improvement.

As noted above, we are proposing that QHP issuers on the FFEs notify the requesting provider “as expeditiously as the enrollee's
health condition requires,” subject to the proposed time limits, which is the standard for non-drug items and services used
by MA organizations, (137) Part D sponsors, (138) Medicaid, (139) and CHIP. (140) We are proposing that, in determining what an enrollee's health condition requires, QHP issuers on the FFEs must abide by
the same requirement to make decisions in accordance with established accepted standards of medical practice in assessing
an individual's medical condition, and we solicit comment on whether any other language in regulation or in sub-regulatory
guidance is necessary to ensure that QHP issuers on the FFEs adhere to this standard.

We also propose, in 45 CFR 156.223(i)(2), that for purposes of 45 CFR 156.223(i)(1), a standard prior authorization request
has the meaning given in 29 CFR 2560.503-1(m)(2) to a “pre-service claim” and an expedited prior authorization request has
the meaning given in 29 CFR 2560.503-1(m)(1) to a “claim involving urgent care,” as determined by the attending provider,
and the issuer shall defer to such determination of the attending provider. By relying on existing definitions, we seek to
maintain consistency across requirements related to prior authorization for QHP issuers on the FFEs.

We also propose, in 45 CFR 156.223(i)(3)(i), that the QHP issuer on the FFEs may extend the timeframes to notify the requesting
provider of a prior authorization decision by up to 14 calendar days under any of the following circumstances: (1) if the
provider requests the extension; (2) the extension is justified and in the provider's or enrollee's interest because the QHP
issuer on the FFEs needs additional medical evidence from another provider or the enrollee in order to issue a decision; or
(3) the extension is justified due to extraordinary, exigent, or other non-routine circumstances and is in the provider's
or enrollee's interest. If extended, the QHP issuer on the FFEs

  would be required to notify the provider of its determination as expeditiously as the enrollee's health condition requires,
  but no later than upon expiration of the extension. We also propose to require, in 45 CFR 156.223(i)(3)(ii), that when the
  QHP issuer on the FFEs extends the timeframe, it must notify the requesting provider in writing of the reasons for the extension
  and inform the provider of the right to file an expedited grievance if the provider disagrees with the QHP issuer on the FFE's
  decision to grant an extension. This language is similar to the corresponding provision that CMS finalized in the 2024 Interoperability
  and Prior Authorization final rule. We believe it is appropriate for QHP issuers on the FFEs as well, but solicit comment
  on whether that is the case or if it should be amended.

In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following:

• The proposal to require QHP issuers on the FFEs to provide notice to the requesting provider of prior authorization decisions as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after receiving a standard prior authorization request for non-drug items and services and as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving an expedited request for non-drug items and services.
• The proposal to require QHP issuers on the FFEs to provide notice to the requesting provider of prior authorization decisions as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving a standard prior authorization request for drugs and as expeditiously as the enrollee's health condition requires, but no later than 24 hours after receiving an expedited request for drugs.
• The proposal that QHP issuers on the FFEs may extend the timeframes to notify the requesting provider of a prior authorization decision by up to 14 calendar days under certain circumstances, and the QHP issuers on the FFEs must notify the requesting provider in writing of the reasons for the delay and inform the provider of the right to file an expedited grievance if the provider disagrees with the QHP issuer on the FFEs' decision to grant an extension.
• The proposal that for purposes of 45 CFR 156.223(i)(1), a standard prior authorization request has the meaning given in 29 CFR 2560.503-1(m)(2) to a “pre-service claim” and an expedited prior authorization request has the meaning given in 29 CFR 2560.503-1(m)(1) to a “claim involving urgent care” for QHP issuers on the FFEs.

• The proposed October 1, 2027 compliance date.
  In addition, we request comments on the following:

• Whether requiring QHP issuers on the FFEs to provide notice to requesting providers of prior authorization decisions in a
  shorter timeframe than they are currently required to provide notice to patients of prior authorization decisions is sufficient
  to improve enrollees' care, or if CMS should consider also applying shorter timeframes for notification to patients, as well.

• Whether there would be burden due to the different timeframes for QHP issuers on the FFEs to notify a requesting provider
  of a prior authorization decision and to notify participants, beneficiaries, and enrollees of prior authorization decisions,
  and how we could potentially alleviate that burden.

• Whether we should finalize shorter timeframes for QHP issuers on the FFEs to notify the requesting provider of prior authorization
  requests for drugs, specifically, 24 hours for all requests (standard or expedited), to align with the existing requirements
  for state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities, and our proposal for state CHIP
  FFS programs.

• Whether the requirement to make decisions as “expeditiously as the enrollee's health condition requires” is appropriate,
  or whether additional or alternative language or sub-regulatory guidance is necessary to help ensure impacted payers make
  timely decisions and for consistency with existing decision timeframes in 45 CFR 147.136(b)(3) and 29 CFR 2560.503-1(f).

• Whether QHP issuers' parent organizations that participate in multiple CMS-regulated programs, such as MA organizations or
  Medicaid managed care plans, already have experience responding to prior authorization requests more quickly than it is currently
  required by existing market wide rules that they can leverage to improve processes for their QHPs offered on the FFEs.

• Whether QHP issuers on the FFEs' plan management systems can readily distinguish between a policy applicable to a QHP offered
  on an FFE, a policy applicable to off-Exchange individual or small group coverage, or a QHP issuer in an SBE.

c. Prior Authorization Decision Timeframes for Drugs That Are Not Covered Outpatient Drugs for State Medicaid Fee-for-Service

Programs, Medicaid Managed Care Plans, and CHIP Managed Care Entities

As discussed previously, section 1927(d)(5)(A) of the Act establishes a 24-hour timeframe for state Medicaid FFS programs
to respond to requests for prior authorization of covered outpatient drugs for which FFP is available. However, that timeframe
may not apply to all drugs that are covered by states for which states receive FFP. In the 2022 CMS Interoperability and Prior
Authorization proposed rule, which addressed prior authorization decision timeframes for non-drug items and services, CMS
received comments indicating that drugs should have been included in the prior authorization timeframe policies and that gaps
exist regarding timeframe requirements on prior authorizations for certain drugs. Given that covered outpatient drugs already
have an established statutory timeframe for prior authorization pursuant to section 1927 of the Act, we seek to address the
comments concerning a possible gap in prior authorization timeframes for a subset of drugs which are not covered outpatient
drugs. In addition, to address concerns by commenters, we explain the prior authorization decision timeframes for drugs that
otherwise meet the definition of covered outpatient drugs in section 1927(k)(2) of the Act but are excluded from the definition
of covered outpatient drugs due to meeting the criteria in the limiting definition of covered outpatient drug in section 1927(k)(3)
of the Act.

Section 1927(k)(3) of the Act limits the term “covered outpatient drug” to exclude any drug, biological product, or insulin
provided as part of, or as incident to and in the same setting as, certain services (and for which payment may be made under
that subchapter as part of payment for those services and not as direct reimbursement for the drug). (141) To the extent that state Medicaid and CHIP programs cover and impose prior authorization requirements on these drugs that
are not covered outpatient drugs, we believe the same decision timeframe requirements that

  apply to prior authorization for the non-drug items and services should apply to a drug that is provided incident to those
  services. Therefore, non-covered outpatient drugs that meet the limiting definition in section 1927(k)(3) of the Act should
  align with the timeframe requirements for non-drug items and services, which is 7 calendar days for standard requests and
  72 hours for expedited requests. We believe it is most appropriate to align the prior authorization decision timeframe for
  a drug that meets the limiting definition in section 1927(k)(3) of the Act with the services it is provided as part of, or
  incident to. We believe this will ensure a prior authorization decision is rendered for the drug and non-drug items and services
  within the same timeframe as opposed to having the drug reviewed under a different timeframe than the remainder of the service
  with which it is bundled with.

One example of this subset of drugs are those that are administered in an inpatient hospital setting. Drugs administered in
an inpatient setting are typically paid for as part of a bundled payment, which includes a variety of items, services, and
drugs. Under that payment model, when prior authorization is required, it is typically submitted as a bundle and drugs are
not separated from non-drug items and services; drugs and non-drug items and services are reviewed under the same prior authorization
request and therefore same timeframe. In those situations, we do not believe there is a need for a separate timeframe for
the drug component of the prior authorization; the prior authorization timeframes established in the 2024 CMS Interoperability
and Prior Authorization final rule would apply to the entirety of the prior authorization request.

In addition, we request comment on whether there are categories of non-covered outpatient drugs for which it would be more
appropriate to finalize a decision timeframe that aligns with the statutory requirement for covered outpatient drugs at section
1927(d)(5)(A) of the Act. It is unclear whether there are drugs (that are not covered outpatient drugs) for which states require
prior authorization and for which 24 hours would be the appropriate decision timeframe, rather than the longer decision timeframe
for non-drug items and services. As stated, we do not desire to create different timeframes for prior authorization decisions
for drugs versus non-drug items and services for which reimbursement and prior authorization requests are bundled. However,
we also want to address any gaps for standalone prior authorization requests for drugs that either do not have an existing
prior authorization decision timeframe requirement, or for which the prior authorization decision timeframe is misaligned
with our other proposals in this proposed rule.

We propose that if commenters identify gaps in the decision timeframe requirements for drugs, we would apply the same requirements
to Medicaid MCOs, PIHPs, and PAHPs by amending 42 CFR 438.210 and CHIP managed care entities by the existing cross reference
to 42 CFR 438.210 in 42 CFR 457.1230(d).

We are proposing an October 1, 2027 compliance date for these proposals for state Medicaid FFS programs, Medicaid managed
care plans, and CHIP managed care entities.

In summary, we request comments on the following:

• The scope of drugs for which we are proposing these prior authorization requirements. Are there additional drugs that currently have no established prior authorization timeframe requirements for which such timeframes should be established? Is there a need to apply prior authorization timeframe requirements to the scope of drugs proposed in this rule? Are there other types of drugs for which we should finalize a requirement that aligns with the 24 hour timeframe established for covered outpatient drugs by section 1927(d)(5)(A) of the Act?
• The proposed October 1, 2027 compliance date for state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities.
• Whether we should consider future rulemaking to propose a requirement for MA organizations to respond to all prior authorization requests for drugs no later than 24 hours to align with the Medicaid and CHIP requirements for covered outpatient drugs.
• Whether there are any drugs payable under Medicare Part A that are not included as part of a larger bundle of inpatient services to which the timeframe to make prior authorizations decisions should apply for MA organizations.

d. Prior Authorization Decision Timeframes for Prescription Drugs for State CHIP Fee-for-Service Programs

To align with the existing requirements for state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care
entities requirements for covered outpatient drugs, as well as the proposals described in section II.C.3.c. of this proposed
rule, we propose to shorten the timeframe for state CHIP FFS programs to make prior authorization decisions on prescription
drugs for which the state receives FFP, as described in section 2110(a)(6) of the Act. As noted previously, the current requirement
is the same 7 days for standard requests and 72 hours for expedited requests as for non-drug items and services, while other
payers have shorter decision timeframes for the prior authorization of drugs than for non-drug items and services.

We are proposing to establish a requirement that state CHIP FFS programs must provide notice to providers and beneficiaries
of prior authorization decisions for prescription drugs for which FFP is available in accordance with the beneficiary's medical
needs but no later than 24 hours after receiving the prior authorization request. This proposal would align with the existing
state Medicaid FFS program requirements for covered outpatient drugs in section 1927(d)(5)(A) of the Act.

This proposed alignment for timeframe requirements should ensure that providers and patients have similarly efficient processes
across all impacted payers and within CMS programs, regardless of how drugs are categorized under the Act. We are proposing
an October 1, 2027 compliance date.

In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following:

• The proposal to require state CHIP FFS programs to provide notice to providers and patients of prior authorization decisions in accordance with the beneficiary's medical needs, but no later than 24 hours after receiving a prior authorization request for prescription drugs for which FFP is available.
• The proposed October 1, 2027 compliance date.

4. Update to State Medicaid and CHIP Fee-for-Service Programs' Decision Timeframe Terminology

After finalizing the 2024 CMS Interoperability and Prior Authorization final rule, we determined that the regulations in 42
CFR 440.230(e) and 42 CFR 457.495(d) needed to be written more clearly to align with the finalized policy as explained in
that rule (89 FR 8897). In 42 CFR 440.230(e), we established that state Medicaid FFS programs must make prior authorization
decisions on requests for non-drug items and services no later than 7 calendar days for standard requests and 72 hours for
expedited requests. We also provided that states could establish shorter timeframes, with which the state

  Medicaid agency would have to comply. The regulation refers to this as a “shorter minimum timeframe,” but the intent of this
  requirement is to establish a *maximum* period of time for a state to make a decision on a prior authorization request. We are therefore proposing to remove the word
  “minimum” to explain that states may establish timeframes that are shorter, but not longer, than those we finalized.

Similarly, 42 CFR 457.495(d) accounts for state laws that may establish different timeframes but does not limit those requirements
to being shorter than the 14 days for standard requests and 72 hours for expedited requests. Therefore, we are proposing to
align the language for state CHIP FFS program timeframes with that for state Medicaid FFS program timeframes by specifying
that state CHIP FFS programs must make prior authorization decisions for non-drug items and services no later than 7 calendar
days for standard requests and 72 hours for expedited requests unless a shorter timeframe is established by the state. Both
these proposals are consistent with the explanation of our finalized policies in the 2024 CMS Interoperability and Prior Authorization
final rule (89 FR 8879). We propose that this change would be effective on the effective date of the final rule, as it does
not change the existing regulatory requirement.

In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following:

• The proposal to revise regulatory language for state Medicaid FFS programs and add regulatory language for state CHIP FFS programs to explain that state Medicaid and CHIP FFS programs must make prior authorization decisions available for non-drug items and services no later than 7 calendar days for standard requests and 72 hours for expedited requests unless a shorter timeframe is established by the state.
• The proposal to become effective beginning on the effective date of the final rule.

5. Proposed Changes to Reporting Deadlines and Reporting Levels for Publicly Reported Prior Authorization Metrics for Non-Drug

Items and Services for Medicaid Managed Care Plans and CHIP Managed Care Entities

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to publicly
report certain prior authorizations metrics about non-drug items and services annually beginning in 2026. (142) By sharing these data, payers can build trust with their patients and providers and showcase their commitment to improving
services. We recognize the need for greater transparency in the prior authorization process and for information to be available
to the public. Beyond information about which services require prior authorization and the requirements for approval, greater
transparency about payer performance on denials, timeframes, and volumes could help the public and identify opportunities
for improvement.

We finalized an annual March 31 deadline for all impacted payers to publicly post prior authorization metrics for the previous
year. 31 However, we have determined that such a deadline may not align with Medicaid managed care plans' and CHIP managed care entities'
contract rating periods. For example, Medicaid managed care plan contract rating periods, as defined in 42 CFR 438.2, do not
all use the same time period and each state may choose different contract rating periods for each managed care program. Similarly
(though rate certifications are not required for CHIP managed care entities), the rating periods for CHIP managed care entities
vary across states. Because rating periods do not necessarily align with calendar years, we now believe that the March 31
reporting deadline finalized in the 2024 CMS Interoperability and Prior Authorization final rule is not appropriate for all
Medicaid managed care plans and CHIP managed care entities. (143) Therefore, to align the reporting deadlines with the contract rating period for each program, we are now proposing to require
Medicaid managed care plans and CHIP managed care entities to publicly post the required prior authorization metrics no later
than 90 days after the end of their rating period.

We also propose to amend the existing requirements for Medicaid managed care plans and CHIP managed care entities to require
that they report the prior authorization metrics finalized in the 2024 CMS Interoperability and Prior Authorization final
rule by program, as well as by plan. For consistency with the other Medicaid and CHIP managed care reporting requirements,
we believe that it is appropriate to also collect these metrics at the program level. Specifically, if a managed care plan
contracts with the state for multiple programs (for example, an adult and child acute care program and a long-term services
and supports [LTSS] program), each program's prior authorization metrics would be reported separately. This is also consistent
with how states must report all data in the Managed Care Program Annual Report (MCPAR), as described in 42 CFR 438.66(e).
Integrated plans would continue to report non-drug items and services covered by MA organizations at the MA contract level,
as the separate requirements for MA organizations and Medicaid managed care plans apply under their respective contracts.
However, integrated plans would be required to report non-drug items and services covered by Medicaid managed care plans at
both the plan and program level. That approach is consistent with the reporting requirements finalized in the 2024 CMS Interoperability
and Prior Authorization final rule for non-drug items and services (89 FR 8897). We propose that this change would be effective
on the effective date of the final rule to align the reporting requirements as soon as practicable.

In summary, we request comment on our proposals in the CFR sections listed in Table 6, and specifically on the following:

• The proposal to modify the deadlines for Medicaid managed care plans and CHIP managed care entities to report certain metrics about prior authorizations for non-drug items and services to be no later than 90 days after the end of their contract rating period.
• The proposal to require Medicaid managed care plans and CHIP managed care entities to report certain metrics about prior authorizations for non-drug items and services, finalized in the 2024 Interoperability and Prior Authorization final rule, by program, as well as by plan. • The proposals to become effective beginning on the effective date of the final rule.

6. Proposed Changes to Publicly Reported Prior Authorization Metrics for Non-Drug Items and Services for Impacted Payers

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that impacted payers report
certain prior authorization metrics aggregated for all non-drug items and services on their public websites (89 FR 8897).
After further consideration, we are proposing to amend those metrics to provide more useful and complete information. Currently,
impacted payers must report the percentage of prior authorizations that were approved, denied, approved after appeal, and
approved after the timeframe for review was extended (89 FR 8889-8890). We are proposing to also require impacted payers to
report a numeric count of prior authorization requests, as well as percentages, for certain existing metrics.

In addition, we are proposing to add four metrics that are complementary to existing metrics. For simplicity, we use the term
“reporting period” to describe the period from which data must be reported. Specifically, the reporting period for MA organizations,
state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be the calendar year and the reporting period for
Medicaid managed care plans and CHIP managed care entities would be the rating period. We propose to require impacted payers
to report the following:

• The total number and percentage of standard prior authorization requests for non-drug items and services that remain denied
after appeal during the reporting period. (144)

++ Numerator: The total number of standard prior authorization requests for non-drug items and services that were appealed
and the denial was upheld.

++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for non-drug items and services.

• The total number and percentage of expedited prior authorization requests for non-drug items and services that remain denied after appeal during the reporting period. ++ Numerator: The total number of expedited prior authorization requests for non-drug items and services that were appealed and the denial was upheld.

++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for non-drug items and
services.

• The total number and percentage of standard prior authorization requests for non-drug items and services for which the timeframe for review was extended, and the request was denied during the reporting period. ++ Numerator: The total number of standard prior authorization requests for non-drug items and services for which the timeframe for review was extended and the request was denied.

++ Denominator: The total number of standard prior authorization requests for non-drug items and services.

• The total number and percentage of expedited prior authorization requests for non-drug items and services for which the timeframe for review was extended, and the request was denied during the reporting period. ++ Numerator: The total number of expedited prior authorization requests for non-drug items and services for which the timeframe for review was extended and the request was denied.

++ Denominator: The total number of expedited prior authorization requests for non-drug items and services.

The proposed metrics for standard prior authorization requests that are “denied after appeal” and “for which the timeframe
for review was extended and the request was denied” are complementary to the existing metrics for the percentage of standard
prior authorization requests that are “approved after appeal” or “for which the timeframe for review was extended and the
request was approved.” The two sets of metrics should generally sum to the total number of standard prior authorization requests
for non-drug items and services that were appealed and the total number of standard prior authorization requests for non-drug
items and services for which the timeframe for review was extended. For all metrics we are proposing that are related to appeals,
appeals include both appeals reviewed internally by the impacted payer as well as by external organizations an impacted payer
may contract with to review and process appeals. Appeals include all levels of appeal; internal and external appeals should
not be differentiated between and should be aggregated as one metric. Appeals that have not been fully adjudicated within
the reporting period may be excluded from the metrics. In addition, we propose that impacted payers report on the following:

• The total number and percentage of expedited prior authorization requests for non-drug items and services for which the timeframe for review was extended, and the request was approved during the reporting period. ++ Numerator: The total number of expedited prior authorization requests for non-drug items and services for which the timeframe for review was extended and the request was approved.

++ Denominator: The total number of expedited prior authorization requests for non-drug items and services.

• The total number and percentage of expedited prior authorization requests for non-drug items and services that were approved after appeal during the reporting period. ++ Numerator: The total number of expedited prior authorization requests for non-drug items and services that were appealed, and the denial was overturned.

++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for non-drug items and
services.

These two metrics would align the metrics for expedited prior authorizations with those for standard prior authorizations.
For MA organizations, extensions are described in 42 CFR 422.568(b)(2). For state Medicaid FFS programs, extensions are described
in 42 CFR 440.230(e)(1)(i). For state CHIP FFS programs, extensions are described in 42 CFR 457.495(d). For Medicaid managed
care plans, extensions are described in 42 CFR 438.210(d), and by cross-reference in 42 CFR 457.1230(d) for CHIP managed care
entities. For QHP issuers on the FFEs, extensions would be described by the proposal, discussed earlier, in 45 CFR 156.223(h)(3).
Notably, 42 CFR 440.230 does not provide for expedited prior authorization requests to be extended by state Medicaid FFS programs.
Therefore, we are not proposing those metrics for state Medicaid FFS programs. The existing and proposed metrics for non-drug
items and services are listed in Table 5.

We are proposing to require impacted payers to publicly report these additional data to ensure these reports are useful and
robust, as well as to align with other CMS reporting requirements. We believe that to make these metrics truly useful, CMS
and the public must understand the scope of the prior authorization requests, both as an absolute number and as a percentage,
because these numbers are complementary. The absolute number provides a scale and reveals the number of prior authorization
requests submitted to the payer over the previous

  reporting period. A percentage, on the other hand, provides an easy-to-understand metric to compare payers. Both of those
  numbers are important to provide context to individuals reviewing the reported data. Percentages and absolute numbers also
  allow for comparison across impacted payers and could highlight differences between payers, both in the number of prior authorization
  requests that they receive, as well as the approval rates at each stage of the process. Furthermore, using both the absolute
  number and percentage of prior authorizations in these metrics may avoid misinterpretation of the data. For instance, a small
  percentage of denied prior authorizations may seem insignificant until one understands that it represents thousands of prior
  authorizations. Conversely, for a payer that requires few prior authorizations, a large percentage of denials may be misinterpreted.
  Therefore, reporting both the number and percentage of prior authorization decisions by payers over the previous reporting
  period provides more comprehensive and useful information of these data while ensuring that the interpretation of these data
  is accurate and properly contextualized.

We also propose minor wording changes to simplify the existing metrics and specify that the proposal include the “total number”
of prior authorizations for each metric rather than “aggregated for all items and services.” We do not intend this proposal
to change any policy or the definition of the metrics.

We are proposing that, if finalized, these additional metrics be effective beginning on the effective date of the final rule
to be reported in the following year. We believe that producing these metrics would be a relatively straightforward task for
impacted payers that have built their systems to generate the metrics required to be reported beginning in 2026. For example,
percentages are derived from numeric counts of numerators and denominators. The numerator should reflect the subset of interest,
such as requests approved or denied, and the denominator should be the total number of prior authorization requests (for all
metrics not related to appeals). For metrics related to appeals, the denominator should be the total number of decided appeals
of prior authorization requests during the reporting period. If an impacted payer has calculated the percentages for the existing
metrics, they should already have available the numeric counts without additional burden. The proposals would require impacted
payers to publicly report those numeric counts that they should already have. In addition, several of the proposed metrics
are complementary to the existing metrics. For example, impacted payers must currently report on the percentage of standard
prior authorization requests that were approved after appeal. In order to calculate that percentage, impacted payers would
also have to know how many requests were denied after appeal, as those two percentages should total to 100 percent of the
adjudicated appeals. Therefore, we believe there should be minimal additional burden to report the proposed new metrics and
impacted payers should be able to report the additional metrics by the effective date of the final rule. We believe that the
immediate transparency benefits to the public weigh in favor of an effective date as soon as possible. Finally, these additional
metrics should provide much-needed context to the payer's prior authorization program; therefore, we are proposing that the
additional metrics be required for the first reporting deadline after the effective date of the final rule.

In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following:

• The proposal to require impacted payers to report the prior authorization metrics regarding non-drug items and services listed as “new” metrics in Table 5 on their public websites.
• The proposal to become effective beginning on the effective date of the final rule.

7. Proposed Requirement To Publicly Report Prior Authorization Metrics for Drugs for Impacted Payers

To incorporate drugs into the existing prior authorization metrics, we are now proposing to require impacted payers to annually
report certain metrics about prior authorizations for all drugs (excluding covered Part D drugs for MA-PDs) by posting this
information on their public website. Covered Part D drugs and PDPs are not included in this proposal because they are covered
in other reporting regulations, and it would be burdensome to add new, duplicative reporting requirements on these plans.
The Part D program already has reporting requirements for aggregated coverage determinations,

  redeterminations, and reopenings for covered Part D drugs. [(145)]()

We propose that impacted payers, other than Medicaid managed care plans and CHIP managed care entities, be required to annually
report the previous calendar year's metrics regarding all drugs, excluding covered Part D drugs for MA-PDs, on their public
websites beginning in 2028 (with data from 2027) following any calendar year that any of these impacted payers offered that
type of plan. We propose to require that these metrics be made publicly available on those impacted payers' websites no later
than March 31 to be consistent with the reporting requirements finalized in the 2024 CMS Interoperability and Prior Authorization
final rule for non-drug items and services. (146) To align with our proposal to amend the reporting deadline for Medicaid managed care plans and CHIP managed care entities,
discussed previously in section II.C.5. of this proposed rule, we are proposing to require Medicaid managed care plans and
CHIP managed care entities to publicly post the required prior authorization metrics no later than 90 days after the end of
their rating period.

To tie the metrics to the appropriate terminology for covered drugs, we propose that for these metrics, MA organizations would
include any drugs payable under Part B that require prior authorization. Our understanding is that MA organizations do not
require separate prior authorization requests for drugs payable under Part A. Rather, when prior authorization is required,
it is requested and approved as part of a bundled payment for inpatient services. Therefore, because they are aggregated into
requests for other items and services, we are not including drugs payable under Part A in the scope of the metrics we are
proposing to require MA organizations to report. However, we request comment on whether there are drugs payable under Part
A that require prior authorization separate from other items and services. If that is the case, we believe that metrics about
drugs payable under Part A would be as important as those we are proposing for drugs payable under Part B. Therefore, we would
consider finalizing that MA organizations report the proposed metrics by aggregating data from drugs payable under Part A
and Part B.

State Medicaid and Medicaid managed care plans would report on all prescribed drugs described in section 1905(a)(12) of the
Act that require prior authorization. State CHIP FFS programs and CHIP managed care entities would report on all prescription
drugs described in section 2110(a)(6) of the Act that require prior authorization. Finally, QHP issuers on the FFEs would
include all drugs covered by the issuer that require prior authorization.

Excluding any category of drug would provide an incomplete picture of the burden and impact of a payer's prior authorization
practices. Some specialty and high-cost drugs may be subject to different utilization management requirements or denial rates.
By being inclusive, we promote transparency and accountability for the prior authorization process across all types of drugs.
For all of the reports for which we are proposing a percentage, we are also proposing that each impacted payer provide, as
part of its report, the metrics' calculated numerators and denominators to provide a greater level of detail. Appeals that
have not been fully adjudicated within the reporting period may be excluded. Furthermore, we recommend that impacted payers
consider the format of their reports so that the data can be easily understood both in writing and graphically. An example
of this type of report is available on the Medicare website for the FFS program. (147)

We propose to require MA organizations to post the following metrics from the previous calendar year on their public websites:

• A list of all drugs payable under Part B that require prior authorization.
• The total number and percentage of approved standard prior authorization requests for Part B drugs during the calendar year. ++ Numerator: The total number of approved standard prior authorization requests for Part B drugs.

++ Denominator: The total number of standard prior authorization requests for Part B drugs.

• The total number and percentage of denied standard prior authorization requests for Part B drugs during the calendar year. ++ Numerator: The total number of denied standard prior authorization requests for Part B drugs.

++ Denominator: The total number of standard prior authorization requests for Part B drugs.

• The total number and percentage of standard prior authorization requests for Part B drugs for which the timeframe for review was extended, and the request was approved during the calendar year. ++ Numerator: The total number of standard prior authorization requests for Part B drugs for which the timeframe for review was extended and the request was approved.

++ Denominator: The total number of standard prior authorization requests for Part B drugs.

• The total number and percentage of standard prior authorization requests for Part B drugs for which the timeframe for review was extended, and the request was denied during the calendar year. ++ Numerator: The total number of standard prior authorization requests for Part B drugs for which the timeframe for review was extended and the request was denied.

++ Denominator: The total number of standard prior authorization requests for Part B drugs.

• The total number and percentage of standard prior authorization requests for Part B drugs approved after appeal during the
calendar year. (148)

++ Numerator: The total number of standard prior authorization requests for Part B drugs that were appealed, and the denial
was overturned.

++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for Part B drugs.

• The total number and percentage of standard prior authorization requests for Part B drugs that remain denied after appeal during the calendar year. ++ Numerator: The total number of standard prior authorization requests for Part B drugs that were appealed, and the denial was upheld.

++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for Part B drugs.

• The average and median time that elapsed between the submission of requests and decisions for standard prior authorizations for Part B drugs during the calendar year.
• The total number and percentage of approved expedited prior authorization requests for Part B drugs during the calendar year. ++ Numerator: The total number of approved expedited prior authorization requests for Part B drugs.

++ Denominator: The total number of expedited prior authorization requests for Part B drugs.

• The total number and percentage of denied expedited prior authorization requests for Part B drugs during the calendar year. ++ Numerator: The total number of denied expedited prior authorization requests for Part B drugs.

++ Denominator: The total number of expedited prior authorization requests for Part B drugs.

• The total number and percentage of expedited prior authorization requests for Part B drugs for which the timeframe for review was extended, and the request was approved during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for Part B drugs for which the timeframe for review was extended and the request was approved.

++ Denominator: The total number of expedited prior authorization requests for Part B drugs.

• The total number and percentage of expedited prior authorization requests for Part B drugs for which the timeframe for review was extended, and the request was denied during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for Part B drugs for which the timeframe for review was extended and the request was denied.

++ Denominator: The total number of expedited prior authorization requests for Part B drugs.

• The total number and percentage of expedited prior authorization requests for Part B drugs approved after appeal during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for Part B drugs that were appealed, and the denial was overturned.

++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for Part B drugs.

• The total number and percentage of expedited prior authorization requests for Part B drugs that remain denied after appeal during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for Part B drugs that were appealed, and the denial was upheld.

++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for Part B drugs.

• The average and median time that elapsed between the submission of requests and decisions for expedited prior authorizations
  for Part B drugs during the calendar year.
  We propose to require state Medicaid and CHIP FFS programs to post the following metrics from the previous calendar year on
  their public websites and to require Medicaid managed care plans and CHIP managed care entities to post the following metrics
  from the previous rating period on their public websites:

• A list of all drugs that require prior authorization.

• The total number and percentage of prior authorization requests for all drugs that were approved during the reporting period.
  ++ Numerator: The total number of prior authorization requests for all drugs that were approved.

++ Denominator: The total number of prior authorization requests for all drugs.

• The total number and percentage of prior authorization requests for all drugs that were denied during the reporting period. ++ Numerator: The total number of prior authorization requests for all drugs that were denied.

++ Denominator: The total number of prior authorization requests for all drugs.

• The total number and percentage of prior authorization requests for all drugs approved after appeal during the reporting
period. (149)

++ Numerator: The total number of prior authorization requests for all drugs that were appealed, and the denial was overturned.

++ Denominator: The total number of adjudicated appeals for prior authorization requests for all drugs.

• The total number and percentage of prior authorization requests for all drugs that remain denied after appeal during the reporting period. ++ Numerator: The total number of prior authorization requests for all drugs that were appealed, and the denial was upheld.

++ Denominator: The total number of adjudicated appeals for prior authorization requests for all drugs.

• The average and median time that elapsed between the submission of requests and decisions for prior authorizations for all
  drugs during the reporting period.
  We propose to require QHP issuers on the FFEs to post the following metrics from the previous calendar year on their public
  websites:

• A list of all drugs that require prior authorization.

• The total number and percentage of standard prior authorization requests for all drugs that were approved during the calendar
  year.
  ++ Numerator: The total number of standard prior authorization requests for all drugs that were approved.

++ Denominator: The total number of standard prior authorization requests for all drugs.

• The total number and percentage of standard prior authorization requests for all drugs that were denied during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs that were denied.

++ Denominator: The total number of standard prior authorization requests for all drugs.

• The total number and percentage of standard prior authorization requests for all drugs for which the timeframe for review was extended, and the request was approved during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs for which the timeframe for review was extended and the request was approved.

++ Denominator: The total number of standard prior authorization requests for all drugs.

• The total number and percentage of standard prior authorization requests for all drugs for which the timeframe for review was extended, and the request was denied during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs for which the timeframe for review was extended and the request was denied.

++ Denominator: The total number of standard prior authorization requests for all drugs.

• The total number and percentage of standard prior authorization requests for all drugs approved after appeal during the
calendar year. (150)

++ Numerator: The total number of standard prior authorization requests for all drugs that were appealed, and the denial was
overturned.

++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for all drugs.

• The total number and percentage of standard prior authorization requests for all drugs that remain denied after appeal during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs that were appealed, and the denial was upheld.

++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for all drugs.

• The average and median time that elapsed between the submission of requests and decisions for standard prior authorizations for all drugs during the calendar year.
• The total number and percentage of expedited prior authorization requests for all drugs that were approved during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs that were approved.

++ Denominator: The total number of expedited prior authorization requests for all drugs.

• The total number and percentage of expedited prior authorization requests for all drugs that were denied during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs that were denied.

++ Denominator: The total number of expedited prior authorization requests for all drugs.

• The total number and percentage of expedited prior authorization requests for all drugs for which the timeframe for review was extended, and the request was approved during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs for which the timeframe for review was extended and the request was approved.

++ Denominator: The total number of expedited prior authorization requests for all drugs.

• The total number and percentage of expedited prior authorization requests for all drugs for which the timeframe for review was extended, and the request was denied during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs for which the timeframe for review was extended and the request was denied.

++ Denominator: The total number of expedited prior authorization requests for all drugs.

• The total number and percentage of expedited prior authorization requests for all drugs approved after appeal during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs that were appealed, and the denial was overturned.

++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for all drugs.

• The total number and percentage of expedited prior authorization requests for all drugs that remain denied after appeal during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs that were appealed, and the denial was upheld.

++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for all drugs.

• The average and median time that elapsed between the submission of requests and decisions for expedited prior authorizations for all drugs during the calendar year. We propose to align impacted payers' reporting levels with those we finalized in the 2024 CMS Interoperability and Prior Authorization final rule. (151) Specifically, we propose that MA organizations would report at the contract level (applicable integrated plans would report drugs covered by MA organizations at the MA contract level), state Medicaid and CHIP FFS programs would report at the state level, Medicaid managed care plans and CHIP managed care entities would report at the plan and program level (if coverage of drugs is included in their contract), and QHP issuers on the FFEs would report at the issuer level.

We believe that the contract level is appropriate for MA organizations because they generally have multiple plans under the
same contract (89 FR 8890). It is common for MA organizations to offer a variety of plans within a service area. The contract-level
data are aggregated data collected from the plan benefit packages (PBPs) for all MA plans provided under an individual contract.
Data are specific to the contract to which they correspond. CMS already requires MA organizations to report some contract-level
data about their organization determinations on an annual basis and assigns Star Ratings at the contract level.

We are proposing to align the reporting levels for state Medicaid and CHIP FFS programs in this proposed rule with those finalized
in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8897) and the proposed amendment for Medicaid managed
care plans and CHIP managed care entities described in section II.C.5. of this proposed rule—that is, at the state level for
state Medicaid and CHIP FFS programs and at the plan and program level for Medicaid managed care plans and CHIP managed care
entities—to create a cohesive and standardized approach to reporting for the long-term for comparability and analysis for
both medical services and drugs.

Similarly, requiring individual market QHP issuers on the FFEs to report at the issuer level is consistent with their reporting
on quality improvement strategies as described in section 1311(g) of the Affordable Care Act and 45 CFR 156.1130, which also
provides consistency with other reporting requirements for QHP issuers on the FFEs' (89 FR 8890). Our proposals for consistency
across reporting requirements aim to reduce the reporting burden on issuers and ensure the publication of metrics in a method
that issuers are familiar with. We note that it is also consistent with the Transparency in Coverage (TiC) reporting requirements
in 45 CFR 156.220 and the level at which a QHP issuer on the FFEs must submit its certification application to participate
in an FFE or an SBE-FP. This level is represented by the six-digit “Issuer ID” assigned to each QHP issuer on the FFEs as
part of the QHP Certification application process, as explained in CMS's Application Instructions. (152) While a parent organization may perform some of the work associated with reporting this information and may opt to publish
the information on its website, the information must be available based on an issuer level as is required by regulation in
45 CFR 156.220 and as specified in the QHP Certification Application Instructions.

In summary, we request comment on our proposals in the CFR sections listed in Table 6, and specifically on the following:

• The proposal to require MA organizations to report metrics about prior authorization for drugs payable under Part B, and
  to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers
  on the FFEs to report metrics about prior authorization metrics for drugs on their public websites.
  • The proposal to require MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs to annually
  report the previous calendar year's metrics on their public websites no later than March 31 following any calendar year that
  the impacted payer offered that type of plan.

• The proposal to require Medicaid managed care plans and CHIP managed care entities to annually report the previous rating
  period's metrics on their public websites no later than 90 days after the end of their rating period.

• The proposal to require MA organizations to report at the contract level (applicable integrated plans would report drugs
  covered by MA organizations at the MA contract level), state Medicaid and CHIP FFS programs to report at the state level,
  Medicaid managed care plans and CHIP managed care entities to report at the plan and program level (if coverage of drugs is
  included in their contract), and QHP issuers on the FFEs to report at the issuer level.

• The proposed 2028 compliance dates to report metrics from the 2027 reporting period.
  In addition, we request comments on the following:

• Whether there are drugs payable under Part A that require prior authorization separate from other non-drug items and services
  that should be included in the scope of the proposed metrics for MA organizations.
  BILLING CODE 4150-28-P

BILLING CODE 4150-28-C

8. Statutory Authorities

a. Medicare Advantage

Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent
with and carry out Part C of Title XVIII of the Act. In addition, section 1857(e)(1) of the Act explicitly authorizes the
addition of reporting requirements by MA organizations as a contract term between the Secretary and a MA organization where
not inconsistent with Part C of Title XVIII of the Act and as the Secretary may find necessary and appropriate. The proposal
for MA plans to publicly report additional prior authorization metrics for drugs payable under Part B reflects a necessary
and appropriate requirement that is consistent with and carries out Part C, as it should enable patients to assess the implementation
of the proposals in this rule. A review of these metrics on individual websites may help CMS understand the impact of the
proposed requirements, including the effects of using the Prior Authorization API for drugs payable under Part B. These data
may also help plans evaluate and modify their operational policies, improve their use of the Prior Authorization API, and
determine if any policy updates would be appropriate.

b. State Medicaid and CHIP

Section 1902(a)(3) of the Act addresses the requirements for the states to provide policies to protect beneficiaries through
opportunities for fair hearings when their services are denied or not acted upon with reasonable promptness. Section 1902(a)(19)
of the Act underpins timeliness standards and requires Medicaid state plans to provide safeguards necessary to assure that
eligibility for Medicaid-covered services will be determined and such services will be provided consistently with simplicity
of administration and in the best interests of recipients. We have proposed that state Medicaid FFS programs and Medicaid
managed care plans publish additional data about their prior authorization performance specific to drugs, and we rely on the
authorities for Medicaid managed care plans under section 1932(c)(2)(A)(i) of the Act, which supports managed care access
standards and requires that states that contract with Medicaid MCOs develop and implement a quality assessment and improvement
strategy that includes standards for access to care so that covered services are available within reasonable timeframes. For
this proposal, CMS would rely on our authority in section 1902(a)(4) of the Act to adopt these standards for PIHPs and PAHPs.
This would ensure that the same requirements apply to MCOs, PIHPs, and PAHPs.

For CHIP, we propose these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose
of Title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children effectively
and efficiently that is coordinated with other sources of health benefits coverage. This provision authorizes us to propose
these requirements for CHIP to obtain access to program data for analysis. Such analysis supports improvements in the efficacy
of CHIP programs and more efficient administration of services.

We expect that the proposal for state CHIP FFS programs to make prior authorization decisions on all drugs no later than 24
hours should improve timeliness and support process improvements for the state, which is consistent with our authorities under
section 2101(a) of the Act in that it enhances the efficiency of the CHIP program.

Further, as authorized under section 2107(b)(1) of the Act, the proposal to require state CHIP FFS programs and CHIP managed
care entities to report prior authorization metrics publicly should also support the states' oversight, evaluation, and administration
responsibilities.

c. Qualified Health Plan Issuers on the Federally-facilitated Exchanges

The proposals to require QHP issuers on the FFEs to provide the specific reason for denial of prior authorizations of drugs
when notifying the provider; notify providers of prior authorization decisions for non-drug items and services and drugs,
and to do so within specified timeframes; and publish certain metrics on their websites, are authorized by section 1311(e)(1)
of the Affordable Care Act. Section 1311(e)(1)(A) of the Affordable Care Act requires that Exchanges only certify plans as
QHPs if they meet the requirements for certification promulgated by the Secretary under section 1311(c)(1) of the Affordable
Care Act, and section 1311(e)(1)(B) of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines
that making available such plans available is in the interests of qualified individuals and qualified employers in the state
or states in which such Exchange operates. We are of the view that these proposals are appropriate QHP certification requirements
because they strive to expand several key regulatory and patient-protection obligations established under the Affordable Care
Act.

We are proposing to require QHP issuers on the FFEs to notify providers of prior authorization decisions for non-drug items
and services within the same timeframes applicable to other impacted payers, as established in the 2024 CMS Interoperability
and Prior Authorization final rule (89 FR 8878). Specifically, we are proposing to require QHP issuers on the FFEs to notify
providers of prior authorization decisions on non-drug items and services as expeditiously as a patient's health condition
requires but no later than 7 calendar days after receiving a standard request and no later than 72 hours after receiving an
expedited request. If finalized, this proposal would allow enrollees in health plans on the FFEs to receive covered services
more quickly, which may improve patient care.

We also propose to require that QHP issuers on the FFEs make prior authorization decisions to providers on all drugs as expeditiously
as the enrollee's health condition requires, but no later than 72 hours after receiving a standard request and, as expeditiously
as the enrollee's health condition requires, but no later than 24 hours after receiving an expedited request. This proposal
to require QHP issuers on the FFEs to provide notice to requesting providers of prior authorization decisions in a shorter
timeframe than they are currently required to provide notice to patients of prior authorization decisions should allow providers
to more quickly alter treatment plans, including to send updated prescriptions to pharmacies if a prior authorization is denied.
We consider the proposal to require QHP issuers on the FFEs to notify the requesting provider of a prior authorization decision
within a specific timeframe based on the nature of the request necessary because delays can directly impact a patient's health.
Drugs sometimes need to be taken soon after a diagnosis is rendered and often need to be taken consistently and on time for
optimal effectiveness. Delays in obtaining and taking medication could lead to a worsening of a patient's condition, create
complications, and potentially require more intensive or costly interventions at a later time.

With respect to the proposal to require QHP issuers on the FFEs to publish certain metrics on their websites, we believe that,
as payers create and analyze prior authorization metrics reports, they would use the data to learn about and improve their
own

  performance in adjudicating prior authorization requests. Additionally, we believe that the public availability of prior authorization
  decision data would further transparency in the interests of qualified individuals and qualified employers in the state in
  which the Exchange operates by providing clear information to consumers that they could use when selecting a new plan. Similarly,
  some providers may find metrics about prior authorization approvals or appeals useful when selecting payer networks.

If finalized, publicly reported prior authorization metrics for drugs could enable CMS to assess the implementation of the
policies proposed in this rule. Reviewing these metrics on individual websites may help CMS understand the impact of the proposed
requirements, including using the Prior Authorization API for drugs. At the same time, the reports could help QHP issuers
on the FFEs evaluate and improve their own operational processes.

For the reasons stated in the paragraphs in this section above, we have determined that the proposed changes described in
sections II.C.2.c. and II.C.3.b. of this proposed rule are in the interests of qualified individuals and qualified employers
in the state or states in which an QHP issuer on the FFEs operates.

D. Requirements for Issuers That Offer Small Group Market Qualified Health Plans on the Federally-Facilitated Small Business

Health Options Program Exchanges

1. Introduction

We propose to apply the existing requirements in 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223, which were finalized
in the 2020 CMS Interoperability and Patient Access final rule and in the 2024 CMS Interoperability and Prior Authorization
final rule (85 FR 25510 and 89 FR 8758), to small group market QHP issuers on the FF-SHOPs. As discussed in section I.B. of
this proposed rule, we are also proposing that small group market QHP issuers on the FF-SHOPs be considered impacted payers
for purposes of the proposed QHP issuer requirements described throughout this proposed rule. (153) We emphasize that neither individual market QHP issuers on the SBEs nor small group market QHP issuers on the SBEs are impacted
payers and therefore, would not be subject to these proposals.

For requirements in 45 CFR 156.221 that have already taken effect for issuers offering individual market QHPs on the FFEs,
we propose compliance dates in the future for small group market QHP issuers on the FF-SHOPs. For example, we are proposing
a compliance date of plan years beginning on or after January 1, 2028 for small group market QHPs on the FF-SHOPs to comply
with 45 CFR 156.221(a), whereas the compliance date for individual market QHPs on the FFEs was for plan years beginning on
or after January 1, 2021. For requirements in 45 CFR 156.222 and 45 CFR 156.223 that we expect to take effect before this
proposed rule can be finalized, we are also proposing separate compliance dates for small group market issuers on the FF-SHOPs
that we believe are reasonable. For example, we are proposing compliance dates for plan years beginning on or after January
1, 2028 for the Provider Access and Payer-to-Payer API requirements in 45 CFR 156.222(a) and (b), and the requirement in 45
CFR 156.221(f) to report Patient Access API usage metrics to CMS. We are also proposing compliance dates of October 1, 2027
for the Prior Authorization API requirements in 45 CFR 156.223(b) and the requirement in 45 CFR 156.223(a) to provide a reason
to providers for denying a prior authorization for non-drug items and services. We believe that the proposed compliance dates
are the earliest dates that are feasible to implement proposals for small group market QHP issuers given the rulemaking timeline.

We are proposing the same compliance dates of October 1, 2027 for certain proposals in this rule that would newly apply to
both small group market QHPs on the FF-SHOPs and individual market QHPs on the FFEs. Those proposals include the requirements
to implement and maintain certain HL7® FHIR® and NCPDP standards to support electronic prior authorization for drugs in 45
CFR 156.223(b)(1)(iii) and (e), as well as notice requirements that create prior authorization decision timeframes in 45 CFR
156.223(i). We are also proposing the same compliance dates, beginning in 2028, for proposals in this rule that would newly
apply to both small group market QHPs on the FF-SHOPs and individual market QHPs on the FFEs regarding reporting API usage
metrics to CMS in 45 CFR 156.222(a)(6) and (b)(8) and 45 CFR 156.223(e) and publicly reporting prior authorization metrics
for drugs in 45 CFR 156.223(d).

We did not apply these policies to small group market QHP issuers on the FF-SHOPs in previous rulemaking due to concerns about
placing burden on these issuers (85 FR 25553 and 89 FR 8767). However, based on additional research, all issuers that offer
small group market QHPs on the FF-SHOPs as of the time of this proposal also offer individual market QHPs on the FFEs. Therefore,
we anticipate that the burden for these issuers to implement these policies for their small group market QHPs on the FF-SHOPs
should be relatively low because these issuers are already required to implement the policies for their individual market
QHPs on the FFEs. Additionally, we believe that enrollees in small group market QHPs on the FF-SHOPs should have access to
the benefits of health data transparency discussed in previous rulemaking such as better coordinated care and the ability
to make more informed decisions about their care (85 FR 25523 and 89 FR 8820). If these policies are finalized as proposed,
and these considerations change in the future—for example, if an issuer that does not offer one or more individual market
QHPs on the FFEs newly enters an FF-SHOP, then under this proposal, we could consider whether to provide an exception to one
or more of these requirements through our established process, as described in section II.D.7. of this proposed rule, during
the annual QHP certification process, if it is appropriate based on the interests of qualified individuals and qualified employers
in the state or states in which such Exchange operates and an exception is warranted to permit the issuer to offer QHPs through
the FFE. (154)

2. General API Requirements Background

In the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules,
we finalized general API requirements that apply across the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization
APIs. (155) We are now proposing to

  require small group market QHP issuers on the FF-SHOPs to implement these requirements, which already apply to individual
  market QHP issuers on the FFEs.

The previously finalized rules required impacted payers, including individual market QHP issuers on the FFEs, to implement
and maintain API technology conformant with certain applicable standards adopted by ONC in 45 CFR 170.215. (156) Table 3 in this proposed rule lists the required and recommended standards and IGs to support API implementation, including
updates proposed in this rulemaking. Impacted payers are permitted to use an updated version of a required standard for the
APIs under certain conditions. Specifically, payers may use updated versions of standards in 45 CFR 170.213 and 45 CFR 170.215
if the following conditions are met: (1) the National Coordinator has approved the updated version for use in the ONC Health
IT Certification Program; (2) the updated version of the standard does not disrupt an end user's ability to access the required
data via that API; and (3) the updated standard is not prohibited by law. Payers may also use an updated version if required
by other applicable law. (157)

To ensure that the APIs function properly, impacted payers must conduct routine testing and monitoring and perform updates
as appropriate. That includes assessments to verify that the API is fully and successfully implementing privacy and security
features, such as those required for compliance with the HIPAA Privacy Rule and “Security Standards for the Protection of
Electronic Protected Health Information” (68 FR 8334) (hereinafter referred to as the “HIPAA Security Rule”) which appeared
in the
Federal Register
on February 20, 2003 (45 CFR part 160 and subparts A and C of part 164), 42 CFR part 2, and other applicable laws protecting
privacy and security of individually identifiable health data. (158)

As established in the 2020 CMS Interoperability and Patient Access final rule, to ensure that developers have the information
necessary to interact with the APIs, impacted payers must make publicly accessible, by posting on their website or via publicly
accessible hyperlink(s), complete accompanying documentation. That documentation must contain: (1) API syntax, function names,
required and optional parameters supported and their data types, return variables and their types/structures, exceptions and
exception handling methods and their returns; (2) the software components and configurations an app must use in order to successfully
interact with the API and process its response(s); and (3) all applicable technical requirements and attributes necessary
for an app to be registered with any authorization server(s) deployed in conjunction with the API. (159)

As established in the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization
final rules, the only reason impacted payers may deny an app or developer API access is if it would present an unacceptable
level of risk to the security of PHI on the payer's system. (160) These risks include, for example, insufficient authentication or authorization controls, poor encryption, or reverse engineering.
The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across
all apps and developers. (161)

3. Patient Access API

a. Background

As discussed in the 2020 CMS Interoperability and Patient Access final rule, one critical issue in the U.S. health care system
is that people cannot easily access their health information in interoperable forms. Patients and the health care providers
caring for them are often presented with an incomplete picture of their health and care as pieces of their information are
stored in various, unconnected systems and do not accompany them to every care setting (85 FR 25511). There are numerous benefits
associated with individuals having access to their health data through a method that is built upon widely used standards.
In the 2020 CMS Interoperability and Patient Access final rule, we finalized requirements for impacted payers, including individual
market QHP issuers on the FFEs, to implement and maintain a Patient Access API conformant with certain FHIR standards that
permit third-party apps to retrieve certain health information, with the approval and at the direction of a current individual
enrollee or the enrollee's personal representative (85 FR 25558). The ability to easily obtain, use, and share claims, encounter,
and other health data enables patients to more effectively and easily use the health care system. Providing this ability to
enrollees in all QHPs on the FFEs, including small group market QHPs on the FF-SHOPs, would empower more people to access
their health information in a manner best suited for them.

b. Proposals

In the 2020 CMS Interoperability and Patient Access final rule, we finalized a requirement that individual market QHP issuers
on the FFEs must implement and maintain a Patient Access API conformant with certain FHIR standards that permit third-party
apps to retrieve certain health information, with the approval and at the direction of a current individual enrollee or the
enrollee's personal representative. (162) Starting with plan years beginning on or after January 1, 2021, impacted payers, including individual market QHP issuers on
the FFEs, have been required to make available any claims and encounter data and all data classes and data elements included
in a content standard in 45 CFR 170.213 (USCDI) (163) with a date of service on or after January 1, 2016. (164) Those data must be made available no later than 1 business day after the claim is processed or the data are received by the
individual market QHP issuers on the FFEs. (165)

Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers would be required to make available
through the Patient Access API certain data about prior authorizations for non-drug items and services that they maintain,
beginning in 2027. (166) The required prior authorization information includes the prior authorization status; the date the prior authorization was
approved or denied; the date or circumstance under which the prior authorization ends; the non-drug items and services approved;
if denied, a specific reason why the request was denied; and related structured administrative and clinical documentation
submitted by a provider. (167) That prior authorization information must be accessible no later than 1 business day after the payer receives a prior authorization
request, must be updated no later than 1 business day after any status change,

  and must continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's
  last status change. [(168)]()

To inform and assist patients who want to access their health information via the Patient Access API, the 2020 CMS Interoperability
and Patient Access final rule also requires impacted payers to provide, in an easily accessible location on their public websites
and through other appropriate mechanisms that they ordinarily use to communicate with current and former enrollees, educational
resources in non-technical, simple, and easy-to-understand language. These resources must explain at a minimum: (1) general
information on steps the individual may consider taking to help protect the privacy and security of their health information,
including factors to consider in selecting an app including secondary uses of data, and the importance of understanding the
security and privacy practices of any app to which they would entrust their health information; and (2) an overview of which
types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities
of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how to submit a complaint to those entities. (169)

In the 2024 CMS Interoperability and Prior Authorization final rule, we also finalized a requirement that, beginning in 2026,
impacted payers, including individual market QHP issuers on the FFEs, must annually report Patient Access API metrics to CMS
in the form of aggregated, de-identified data. Specifically, individual market QHP issuers on the FFEs must report at the
issuer level the following metrics: (1) the total number of unique patients whose data are transferred via the Patient Access
API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more
than once via the Patient Access API to a health app designated by the patient. The 2024 CMS Interoperability and Prior Authorization
final rule requires individual market QHP issuers on the FFEs to report the previous calendar year's metrics to CMS by March
31 following any year that they offer an individual market QHP on the FFEs. (170)

We are now proposing to apply each of these requirements to small group market QHP issuers on the FF-SHOPs to report data
from plan years beginning on or after January 1, 2028, with reporting deadlines beginning in 2029.

For reporting on Patient Access API usage, we are proposing to require small group market QHP issuers on the FF-SHOPs to annually
report the metrics in 45 CFR 156.221(f) at the issuer level in the form and manner and within the timeframes specified by
the Secretary. That would allow flexibility for CMS to include API usage metrics reporting within specific deadlines set for
the QHP certification process, which in practice is generally the final deadline for the QHP certification process that takes
place the following year. (171) We are proposing to apply this requirement to small group market QHP issuers on the FF-SHOPs for plan years beginning on or
after January 1, 2028, following each plan year that the QHP issuer offers a small group market QHP on the FF-SHOP. For example,
QHP issuers on the FF-SHOPs would be required to submit metrics from plan years in 2028 as part of the QHP certification process
during 2029 for plan years in 2030. This is consistent with our proposal to modify the Patient Access API usage reporting
deadline from an annual March 31 date, as further discussed in section II.F.2.b. of this proposed rule. We believe it is also
appropriate to align the reporting deadline for small group market QHP issuers on the FF-SHOPs with the annual QHP certification
process for the reasons discussed in section II.F.2.b., and so that issuers do not have to adhere to different sets of deadlines
for small group market QHPs on the FF-SHOPs and individual market QHPs on the FFEs, which could cause administrative burden.

In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and
in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

4. Provider Access API

a. Background

While the Patient Access API was a significant first step toward sharing individual patient health information with providers,
in the 2024 CMS Interoperability and Prior Authorization final rule we explained our belief that it would benefit patients
if payers were required to make patient data directly available to providers via an API that is conformant with certain FHIR
standards. In the normal course of business, many providers already maintain EHRs and share data for a variety of purposes
authorized by the patient and/or existing law. Therefore, in the 2024 CMS Interoperability and Prior Authorization final rule,
we required impacted payers to implement and maintain a FHIR API that makes patient data available to providers who have a
contractual relationship with the payer and a treatment relationship with the patient. (172) The Provider Access API has the potential to allow payers to build upon their existing systems and processes to enhance access
to patient data, while continuing to protect patient privacy and data security (89 FR 8787).

b. Proposals

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a policy that, beginning in 2027, impacted
payers, including individual market QHP issuers on the FFEs, must implement and maintain a Provider Access API to make available
patient data upon request from an in-network provider if all the following conditions are met: (1) the payer authenticates
the identity of the provider that requests access and attributes the patient to the provider under the required attribution
process; (2) the patient does not opt out of the Provider Access API; and (3) disclosure of the data is not prohibited by
law. Individual market QHP issuers on the FFEs must make those data available no later than 1 business day after receiving
a request from such a provider. (173)

The data that impacted payers must make available via the Provider Access API include claims and encounter data (excluding
provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard
in 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service
after January 1, 2016. The required prior authorization information includes the prior authorization status; the date the
prior authorization was approved or denied; the date or circumstance under which the prior authorization ends; the non-drug
items and services approved; if denied, a specific reason why the request was denied; and related structured administrative
and clinical documentation submitted by a provider. That prior authorization information must be accessible no later than
1 business day after the individual market QHP issuer on the FFE receives a prior authorization request, must be updated no
later than 1 business day after any

  status change, and must continue to be accessible for the duration that the authorization is active and at least 1 year after
  the prior authorization's last status change. [(174)]()

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that impacted payers, including
individual market QHP issuers on the FFEs, beginning in 2027, must establish and maintain an attribution process to associate
patients with their in-network providers to ensure that the payer only sends a patient's data to providers who have a treatment
relationship with that patient. (175) We also finalized a requirement for impacted payers, including individual market QHP issuers on the FFEs, to provide on their
website and through other appropriate provider communications, information in plain language explaining the process for requesting
patient data using the Provider Access API. The resources must include information about how to use the payer's attribution
process to associate patients with their providers. (176)

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a policy that impacted payers, including
individual market QHP issuers on the FFEs, beginning in plan years that start on or after January 1, 2027, must establish
and maintain a process for patients to opt out of data exchange via the Provider Access API and that allows patients to change
their permission at any time. (177) This process must be made available to enrollees before the first date on which the payer makes their information available
via the Provider Access API, and at any time during their enrollment with the payer. (178) Impacted payers, including individual market QHP issuers on the FFEs, are also required to provide educational resources in
plain language to their patients about the Provider Access API. (179) Those resources must include information about the benefits of API data exchange with providers; patients' opt out rights;
and instructions for both opting out of data exchange and for subsequently opting in, should patients choose to do so. (180) Impacted payers must make this information available to patients before the first date on which the payer makes their information
available via the Provider Access API, no later than 1 week after the start of coverage, and at least annually. (181 182) These resources must also be available in an easily accessible location on payers' public websites (89 FR 8817-8818). (183)

We are now proposing to apply each of these requirements to small group market QHP issuers on the FF-SHOPs for plan years
beginning on or after January 1, 2028. We believe that this proposal's compliance date provides sufficient time for those
issuers to incorporate their small group market QHPs on the FF-SHOPs into their previous API implementation for individual
market QHPs on the FFEs given that small group market QHP issuers on the FF-SHOPs also offer individual market QHPs on the
FFEs. However, we solicit comment on whether this is the case.

In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and
in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

5. Payer-To-Payer API

a. Background

In addition to sharing data with their providers, having a patient's data follow them when they change payers, or shared when
they have health insurance coverage through multiple payers, can have a multitude of benefits for patient care. For example,
a payer receiving data when a new patient enrolls can better support the patient through care coordination related to a chronic
condition or ongoing treatment needs. If necessary, patient data can give payers the information they need to assign a case
manager or help the patient find providers in their new network. Data exchange among payers—specifically, sending patient
data from a patient's previous payer to their new one—is a powerful way to ensure that data follows patients through the health
care system and improves care continuity, and helps patients to maintain access to their record over time. In the 2024 CMS
Interoperability and Prior Authorization final rule, we required impacted payers, including individual market QHP issuers
on the FFEs, to build a Payer-to-Payer API, with certain standards that would facilitate patient data exchange at the start
of coverage and between concurrent payers. (184)

b. Proposals

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a policy that, for plan years beginning
on or after January 1, 2027, individual market QHP issuers on the FFEs must implement and maintain a Payer-to-Payer API to
exchange patient health information when an enrollee changes payers or has concurrent coverage with two or more payers if
the following conditions are met: (1) the payer that requests access has its identity authenticated and includes an attestation
with the request that the patient is enrolled with the payer and has opted into the data exchange; and (2) the exchange is
not prohibited by law. Impacted payers, including individual market QHP issuers on the FFEs, must make those data available
no later than 1 business day after receiving a request from another payer that meets those requirements. (185)

The data that impacted payers must make available via the Payer-to-Payer API include claims and encounter data (excluding
provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard
in 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service
within 5 years of the request. The required prior authorization information does not include denied prior authorization requests.
It does include the prior authorization status, the date the prior authorization was approved, the date or circumstance under
which the prior authorization ends, the non-drug items and services approved, and related structured and unstructured administrative
and clinical documentation submitted by a provider. This prior authorization information must be accessible no later than
1 business day after the impacted payer receives a prior authorization request, must be updated no later than 1 business day
after any status change, and must continue to be accessible for the duration that the authorization is active and at least
1 year after the prior authorization's last status change. (186)

In the 2024 CMS Interoperability and Prior Authorization final rule, we also

  finalized requirements that, for plan years beginning on or after January 1, 2027, impacted payers, including individual market
  QHP issuers on the FFEs, must establish and maintain processes to request that an enrollee opt into the payer to payer data
  exchange and submit information about their previous and concurrent payers. [(187)]() Those processes must be in place for current enrollees by the compliance date of plan years beginning on or after January
  1, 2027, and then, for new enrollees, no later than 1 week after the coverage start date, or, if coverage has a retroactive
  start date, no later than 1 week after the coverage is effectuated (89 FR 8855). [(188)]() In addition, enrollees must be permitted to change their preference at any time. [(189)]() If an enrollee does not respond or additional information is necessary, the payer must make reasonable efforts to engage with
  the enrollee to collect this information. [(190)]() By that compliance date, impacted payers, including individual market QHP issuers on the FFEs, are also required to provide
  educational resources in plain language to their patients about the Payer-to-Payer API. [(191)]() Those resources must include the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission,
  and instructions for doing so. [(192)]() Impacted payers must make this information available to patients when requesting an enrollee's permission for Payer-to-Payer
  API data exchange and at least annually thereafter. [(193)]() These resources must also be available in an easily accessible location on payers' public websites. [(194)]()

If an enrollee opts in and provides sufficient information about their previous or concurrent payers, then impacted payers,
including individual market QHP issuers on the FFEs, must request the specified data from those payers no later than 1 week
after they have sufficient identifying information about previous or concurrent payers and the enrollee has opted in. (195) In addition, at an enrollee's request, payers must make the same request within 1 week. (196) Any data received in response to such a request must be incorporated into the payer's records about the enrollee. (197) In addition, if an enrollee has concurrent payers, the payer must request data from all known concurrent payers at least quarterly
and must respond to such a request from other concurrent payers within 1 business day. (198)

We are now proposing to apply each of these requirements to small group market QHP issuers on the FF-SHOPs for plan years
beginning on or after January 1, 2028. We believe that this proposal's compliance date provides sufficient time for those
issuers to incorporate their small group market QHPs on the FF-SHOPs into their previous API implementation for individual
market QHPs on the FFEs given that small group market QHP issuers on the FF-SHOPs also offer individual market QHPs on the
FFEs. However, we solicit comment on whether this is the case.

In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and
in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

6. Prior Authorization API and Prior Authorization Process

a. Background

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement for impacted payers, including
individual market QHP issuers on the FFEs, to implement and maintain a Prior Authorization API to improve the prior authorization
process between payers and providers for non-drug items and services. (199) This Prior Authorization API would streamline the prior authorization process for providers and for office staff who support
the prior authorization process by automating certain prior authorization tasks, thereby mitigating some of the obstacles
of the existing prior authorization process and expediting approval of needed care or explaining why a submitted request is
not sufficient. The API would also allow a provider to query the payer's system to determine whether a prior authorization
was required for certain non-drug items and services and identify documentation requirements. It would automate the compilation
of necessary data for populating the electronic prior authorization request and enable payers to provide the status of the
prior authorization decision, including whether the request has been approved or denied. The 2024 CMS Interoperability and
Prior Authorization final rule also included requirements that payers include a specific reason for denial of a prior authorization
request in their responses to providers, (200) and publicly report certain prior authorization metrics. (201)

The 2022 CMS Interoperability and Prior Authorization proposed rule and the 2024 CMS Interoperability and Prior Authorization
final rule both discussed the current burden associated with prior authorization processes and explained how making the prior
authorization process electronic would reduce the time and burden, expediting patients' access to care and allowing providers
to put time back into direct patient care (87 FR 76286 and 89 FR 8862). Requiring all QHP issuers on the FFEs, including small
group market QHP issuers on the FF-SHOPs, to adopt electronic prior authorization processes for non-drug items and services
would provide these benefits to more patients, and potentially help more providers and administrative staff to mitigate burnout.
Including small group market QHP issuers on the FF-SHOPs in requirements to publicly report certain prior authorization metrics
and to provide a reason for denial of prior authorization in responses to providers would improve understanding of prior authorization
processes' impact on more enrollees and help ensure transparency for more prior authorization requests.

The 2024 CMS Interoperability and Prior Authorization final rule also required impacted payers other than individual market
QHP issuers on the FFEs (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed
care entities), to respond to prior authorization requests within shorter timeframes than they were previously subject to
(89 FR 8897). We are proposing to apply these requirements, and additional requirements related to drug prior authorization,
to all QHP issuers on the FFEs, including individual market QHP issuers on the FFEs and small group market QHP

  issuers on the FF-SHOPs, in this rule. For discussion of those proposals please see section II.C.3. of this proposed rule.

b. Proposals

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement for individual market QHP
issuers on the FFEs to implement and maintain a Prior Authorization API to improve the prior authorization process between
payers and providers for non-drug items and services. (202) The purpose of the API is to streamline the process and ensure that payers use technology to provide more useful information
about when and how to obtain a prior authorization and the status of an approved or denied prior authorization (89 FR 8897).

We finalized a policy that, for plan years beginning on or after January 1, 2027, individual market QHP issuers on the FFEs
must implement and maintain a Prior Authorization API that—(1) is populated with the payer's list of non-drug items and services
that require prior authorization; (2) can identify all documentation required for approval of any non-drug items or services
that require prior authorization; (3) supports a HIPAA-compliant prior authorization request and response; and (4) communicates
whether the payer approves the prior authorization request (and the date or circumstance under which the authorization ends),
denies the prior authorization request (with a specific reason), or requests more information. (203)

In addition, we finalized two process requirements for impacted payers, including individual market QHP issuers on the FFEs,
to improve the prior authorization process generally. We finalized a policy that beginning January 1, 2026, if an impacted
payer denies a prior authorization request (excluding a request for coverage of drugs as defined for QHPs on the FFEs in 45
CFR 156.221(b)(1)(v)), the response to the provider must include a specific reason for the denial, regardless of the method
used to communicate that information. (204)

We also finalized a requirement that beginning in 2026, following each year it offers an individual market QHP on the FFEs,
an individual market QHP issuer on the FFE must report prior authorization data, excluding data on drugs as defined in 45
CFR 156.221(b)(1)(v), at the issuer level by March 31. The individual market QHP issuer on the FFE must make the following
data from the previous calendar year publicly accessible by posting them on its website:

• A list of all non-drug items and services that require prior authorization.
• The percentage of standard prior authorization requests that were approved, aggregated for all non-drug items and services.
• The percentage of standard prior authorization requests that were denied, aggregated for all non-drug items and services.
• The percentage of standard prior authorization requests that were approved after appeal, aggregated for all non-drug items and services.
• The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all non-drug items and services.
• The percentage of expedited prior authorization requests that were approved, aggregated for all non-drug items and services.
• The percentage of expedited prior authorization requests that were denied, aggregated for all non-drug items and services.
• The average and median time that elapsed between the submission of a request and a determination by the individual market QHP issuer on the FFE, for standard prior authorizations, aggregated for all non-drug items and services. • The average and median time that elapsed between the submission of a request and a decision by the individual market QHP issuer on the FFE for expedited prior authorizations, aggregated for all non-drug items and services. (205)

We are now proposing to apply each of these requirements to small group market QHP issuers on the FF-SHOPs. Specifically,
we propose to amend the requirements in 45 CFR 156.223(a) to respond to providers with a reason for denial and in 45 CFR 156.223(b)
to implement and maintain a Prior Authorization API to include small group market QHP issuers on the FF-SHOPs with a compliance
date of October 1, 2027. In addition, we propose to amend the requirement in 45 CFR 156.223(c) to publicly report prior authorization
metrics to apply it to small group market QHP issuers on the FF-SHOPs beginning in 2028 for calendar year 2027 data. Given
that those issuers have met or are working on meeting these proposed requirements for their individual market QHPs on the
FFEs, we believe that the proposed compliance dates provide sufficient time to extend their technology solutions and business
processes to their small group market QHPs on the FF-SHOPs. However, we solicit comment on whether this is the case.

In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and
in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

7. Exceptions

a. Background

The 2020 CMS Interoperability and Patient Access final rule and the 2024 CMS Interoperability and Prior Authorization final
rule finalized an exceptions process for individual market QHP issuers on the FFEs that are not able to implement the Patient
Access API. An individual market QHP issuer on the FFE can apply for an exception for a particular plan year by submitting
a narrative justification as part of its QHP certification application that describes the reasons why it cannot reasonably
satisfy the requirements for the applicable plan year, the effect of non-compliance upon providers and enrollees, the current
or proposed means of providing the required information to providers or other payers, and solutions and a timeline to achieve
compliance with the requirements. (206)

As discussed in the 2024 CMS Interoperability and Prior Authorization final rule, we believe that certifying only health plans
that implement these APIs is generally in the interests of enrollees (89 FR 8786 and 8820). However, as also discussed in
that final rule, while some individual market QHP issuers on the FFEs are in a position to implement the updates that the
rule requires, a wide range of issuers participate in the FFEs and vary in terms of available resources to adopt these requirements
(89 FR 8906). Plan offerings can also vary by region and even by county, with some areas in the FFEs having more limited plan
offerings than others. Therefore, this exceptions process exists as a safeguard to prevent potential enrollees from going
without access to QHP coverage because an issuer is unable to implement these APIs.

b. Proposals

We propose to apply the same exceptions process to the proposed requirements for small group market

  QHP issuers on the FF-SHOPs as currently applies to individual market QHP issuers on the FFEs per 45 CFR 156.221(h), including
  as cross referenced in 45 CFR 156.222(c) and 45 CFR 156.223(d). As we discussed in the 2024 CMS Interoperability and Prior
  Authorization final rule, we anticipate that the volume of requests for exceptions should be low based on our experience with
  individual market QHP issuers on the FFEs, among which exception requests are uncommon, and a number of requests have specified
  that the issuer intends to comply within the upcoming plan year even though they may not be able to do so by January 1 of
  the upcoming year (89 FR 8906). As also discussed in the 2020 CMS Interoperability and Patient Access final rule, with regard
  to individual market QHPs on the FFEs, we believe that it is important to provide the FFEs with the option to waive this requirement
  on a limited basis, for example, if not certifying the issuer's QHP or QHPs would result in consumers having few or no plan
  options in certain areas (85 FR 25552). We believe that this rationale also applies to small group market QHPs on the FF-SHOPs—that
  is, that the FF-SHOPs should have the option to consider coverage availability for qualified employers and their employees
  as a factor when determining whether to certify an FF-SHOP plan notwithstanding its failure to comply with requirements for
  the Patient Access API in 45 CFR 156.221, the Provider and Payer-to-Payer APIs in 45 CFR 156.222(a) and (b), or the Prior
  Authorization API in 45 CFR 156.223(b).

In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and
in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

BILLING CODE 4150-28-P

BILLING CODE 4150-28-C

E. Reporting Payer API Endpoints and Associated Information for CMS To Publish

1. API Endpoints

In the 2020 CMS Interoperability and Patient Access final rule, we finalized a requirement that impacted payers must implement
and maintain Patient Access and Provider Directory APIs (85 FR 25513). In the 2024 CMS Interoperability and Prior Authorization
final rule, we finalized requirements that impacted payers must also implement and maintain Provider Access, Payer-to-Payer,
and Prior Authorization APIs (89 FR 8759). During those rulemakings, we received numerous public comments that emphasized
the importance of a centralized location to discover payers' API endpoints, which would realize the full potential of these
interoperability APIs (85 FR 25562 and 89 FR 8767).

An API's endpoint is the digital location, often a URL or IP address, that is set up to accept secure queries to the API.
Developers need to know an API's endpoint to configure their apps to interact with the API. Without properly structured and
functioning endpoints, an API will not work as intended. APIs can be set up with multiple endpoints, each used for specific
data or purposes, or a single endpoint that offers different data depending on how it is queried.

We have received public feedback that a centralized listing of impacted payers' API endpoints would significantly improve
the ability of payers, providers, patients, and developers to use the interoperability APIs (89 FR 8767). Various entities
within the health care system need to have information about payers' API endpoints to achieve the envisioned ecosystem of
data exchange via the interoperability APIs. For the Patient Access API, app developers must connect to payers' API endpoints
for patients to access their data maintained by that payer. For the Provider Access API, EHR developers must configure providers'
EHRs or other health IT to query payers' API endpoints to retrieve patient information maintained by that payer. To use the
Payer-to-Payer API, payers must locate patients' previous or concurrent payers' API endpoints in order to send a request for
patient data, as required in the 2024 CMS Interoperability and Prior Authorization final rule. For the Prior Authorization
API, providers must be able to find the correct payer API endpoint to submit electronic prior authorization requests. Similarly,
for the Provider Directory API, third-party developers and health care entities need discoverable endpoints to create innovative
apps that help patients find in-network providers and enable care coordination between providers, making centralized endpoint
reporting essential for realizing the full potential of publicly accessible provider directory information.

Stakeholder feedback from our 2019 CMS Interoperability and Patient Access proposed rule, 2020 CMS Interoperability and Patient
Access final rule, 2022 CMS Interoperability and Prior Authorization proposed rule, and 2024 CMS Interoperability and Prior
Authorization final rule demonstrates that endpoint discovery remains a significant implementation challenge, with multiple
commenters requesting a centralized directory and noting that third-party apps currently struggle with implementation barriers
when working with payers. Finding API endpoints individually in myriad locations could be a significant task for app developers,
EHR developers, providers, and payers, because without specific requirements, those endpoints are unlikely to be listed or
discoverable in a standardized manner. While payers may have some incentive to make their endpoints discoverable, market dynamics
may create barriers to voluntary standardization. For example, individual payers may invest resources into comprehensive endpoint
discovery while competitors benefit without making similar investments or competitive considerations, which could lead some
payers to maintain integration complexity. As part of our oversight and compliance process, CMS has engaged in exercises to
discover endpoints from a sampling of impacted payers. Our own work was heavily manual, and we have experienced first-hand
that endpoints are listed in a wide variety of locations and formats, including PDFs, from which automated data retrieval
is particularly difficult. Instead, we believe it would help everyone in the health care industry for CMS to collect API endpoints
and make them publicly available in a standardized format that can easily be accessed and used by app developers, EHR developers,
providers, and payers.

Furthermore, if payers' API endpoints have to be discovered individually by developers, or entities that want to use the API,
the endpoint is more likely to be hard coded into the software systems used by those developers or entities. Individual endpoint
discovery is likely to create a manual, resource-intensive process where developers must research each payer's documentation,
extract endpoint information, and integrate it directly into their code. The alternative—building a dynamic endpoint discovery
system—requires industry-wide coordination and significant development resources that many organizations cannot justify, making
individual developer hard coding the more practical, albeit less flexible, solution. Once endpoints are hard coded, maintenance
becomes increasingly burdensome, as developers must manually monitor hundreds of payers for changes, modify code, test, and
redeploy systems for each endpoint update. Developers may not realize that an endpoint has changed until they receive reports
that their software is no longer successfully connecting to an API, at which point they would have to push software updates.
This process could take days or weeks, during which API integrations may fail and end users may experience service disruptions.
This creates operational challenges for all entities that depend on API access; entities may need to wait for software updates
to restore connectivity and access accurate data, potentially causing delays in patient care, data exchange, and administrative
processes. Providers using EHRs, health systems relying on integration platforms, and payers using third-party software solutions
would all experience service interruptions when hard-coded endpoints become outdated, regardless of whether they maintain
in-house development capabilities.

Instead, a centralized registry could create greater flexibility and allow for more timely endpoint data availability. Software
could make a call to that registry and, with appropriate identifying data, find the latest information about a payer's API
endpoint. The software could then automatically use that information to call the payer's API without manual intervention by
the developer or entity making the request. Such a process could be implemented into health apps (for the Patient Access and
Provider Directory APIs), EHRs or other provider systems (for the Provider Access, Prior Authorization, and Provider Directory
APIs), and payers' systems (for the Payer-to-Payer API).

Therefore, we are proposing to require, in the CFR citations listed in Table 8, impacted payers to report to CMS their API
endpoints for each required interoperability API unless the impacted payer is a state Medicaid or CHIP FFS program that has
been granted an extension or a QHP issuer on the FFEs that has been granted an exception from implementing any or all of the

  interoperability APIs. [(207)]() To ensure the standardization of payer endpoints, we are proposing to require impacted payers to report their API endpoints
  as an Endpoint Resource, as defined by an unexpired version of the Health Level Seven (HL7®) FHIR® standard adopted in 45
  CFR 170.215(a). We are proposing that impacted payers would be required to initially report their API endpoints no later than
  60 days after the effective date of a final rule. In future years, we are proposing that new impacted payers would be required
  to report this information no later than 60 days before they begin covering patients under the applicable CMS program. Thereafter,
  impacted payers would be required to report changes to CMS within 1 week of any changes to their API endpoint(s) and verify
  every 12 months that there have been no changes and their data are accurate. API endpoints support time-sensitive health care
  operations including prior authorization requests, care coordination, and patient data access. Outdated endpoints immediately
  disrupt these critical functions; the underlying statutory requirements for timely care, efficient operations, and patient
  access cannot be met with stale endpoint information. Verification every 12 months ensures ongoing accuracy of the centralized
  registry, compliance with existing statutory obligations for current information, and efficient program administration, through
  reliable endpoint data.

2. API Documentation

In the 2020 CMS Interoperability and Patient Access final rule, we finalized a requirement that impacted payers make the specific
business and technical documentation necessary to interact with their Patient Access and Provider Directory APIs freely and
publicly accessible (85 FR 25542). In the 2024 CMS Interoperability and Prior Authorization final rule, we extended that requirement
to the Provider Access, Payer-to-Payer, and Prior Authorization APIs (89 FR 8815). We explained that transparency is necessary
for developers to easily obtain the information needed to develop systems technically compatible with the payer's API. Transparency
is also needed so that developers can understand how to successfully interact with a payer's API. This includes how to satisfy
any requirements the payer may establish for verifying a developer's identity and their apps' authenticity.

As explained in the preamble to the 2020 CMS Interoperability and Patient Access final rule (85 FR 25542), impacted payers
must make publicly accessible documentation necessary to interact with their APIs. The existing regulations in 42 CFR 422.119(d),
42 CFR 431.60(d), 42 CFR 457.730(d), and 45 CFR 156.221(d) require impacted payers to make publicly available documentation
that includes API syntax, function names, required and optional parameters, software components and configurations, and technical
requirements for apps to interact with their APIs. FHIR capability statements are mandatory resources, as defined by an unexpired
version of the FHIR standard adopted in 45 CFR 170.215(a), making them inherently part of this required documentation.

The required authorization and authentication protocols and implementation details build upon the existing requirement for
impacted payers to use the SMART App Launch IG and OpenID Connect Core—to implement certain interoperability APIs. (208) The SMART App Launch IG is a standards-based framework for secure app connections to health IT systems, and OpenID Connect
Core is an identity verification layer built on OAuth 2.0. Those existing requirements necessitate public documentation of
authentication protocols. API registration information, when required by payers, constitutes essential documentation that
falls within the existing requirement in 42 CFR 422.119(d)(3), 42 CFR 431.60(d)(3), 42 CFR 457.730(d)(3), and 45 CFR 156.221(d)(3)
to make publicly accessible all applicable technical requirements and attributes necessary for an app to be registered with
any authorization server(s) deployed in conjunction with the API. Without registration procedures, developers cannot establish
the necessary access credentials to use the APIs.

To ensure that the business and technical documentation is publicly available and easily discoverable, we are proposing to
require impacted payers to report to CMS the URLs for specific required documentation, at the CFR citations listed in Table
8. (209) CMS would then publish these URLs for centralized access. CMS proposes that the required URLs must include, as applicable:
a direct URL to the FHIR capability statement, as defined by an unexpired version of the FHIR standard adopted in 45 CFR 170.215(a);
and one or more URLs for a publicly accessible website with authorization and authentication protocols and implementation
details; and API registration information. (210) Each of those items are elements of the existing standards and documentation requirements that already must be publicly available. (211)

The proposed URL reporting requirements directly correspond to existing requirements to make technical documentation publicly
available, as follows:

(1) FHIR Capability Statement—The capability statement can satisfy the existing requirements to make publicly accessible documentation
that includes API syntax, function names, required and optional parameters supported and their data types, return variables
and their types/structures, exceptions and exception handling methods and their returns. (212) Because capability statements document API implementation details, functional capabilities, and operational parameters,

  they should serve as a the primary source of technical documentation necessary to interact with the API.

(2) Authorization and Authentication Protocols and Implementation Details—This documentation should satisfy the existing requirements
to make publicly accessible all applicable technical requirements and attributes necessary for an app to be registered with
any authorization server(s) deployed in conjunction with the API. (213) Specific information about authorization and authentication protocols and implementation details is essential for developers
to ensure that their software can communicate and exchange information with an API.

(3) API Registration Information—This documentation can satisfy the requirements to make publicly accessible the software
components and configurations an application must use in order to successfully interact with the API and process its response(s). (214) Without registration procedures, developers cannot establish the necessary access credentials to use the APIs.

These three documentation types—capability statements, authorization and authentication protocols and implementation details,
and API registration information—represent discrete components of the broader documentation already required under existing
regulations. The proposed URL reporting requirements do not expand the scope of required documentation but rather add to existing
requirements by establishing a standardized mechanism for verifying compliance and facilitating discoverable access to required
documentation.

The URL reporting proposal is integral to the effectiveness of API endpoint reporting. API endpoints are only functional when
developers can access the technical documentation needed to integrate with them, including FHIR capability statements, authorization
and authentication protocols and implementation details, and API registration information. Without discoverable documentation,
centralized endpoint information provides limited value to the health care ecosystem. Both proposals, to report API endpoints
and documentation URLs, could facilitate patient access to health information, support care coordination, enable efficient
program administration, and reduce administrative burden on developers, providers, and payers.

While impacted payers must already make API documentation publicly available under existing regulations, CMS currently lacks
an efficient mechanism to systematically verify compliance and facilitate standardized discovery of this documentation across
hundreds of payers. The URL reporting proposal could enable CMS to systematically verify that required documentation is publicly
accessible, monitor ongoing compliance with existing documentation obligations, and identify compliance gaps more efficiently
than manual discovery processes. This could transform fragmented compliance into systematic, verifiable accessibility that
serves both regulatory oversight and industry needs. CMS cannot efficiently gather this information independently because
doing so would require continuous monitoring of hundreds of payer websites across multiple programs (MA, Medicaid, CHIP, and
QHPs on the FFEs), technical staff to locate and verify documentation across varying website structures, and ongoing maintenance
as payers modify their websites. Manual discovery by CMS could result in outdated information, discovery delays, and verification
challenges, while requiring disproportionate resource allocation compared to the benefit for the industry.

This proposal explicitly addresses registration requirements that impacted payers must already meet. The proposed URL reporting
requirements are authorized under the same statutory provisions that support the existing documentation requirements and would
enable CMS to facilitate centralized discovery of documentation that must already be publicly available under existing regulations. (215)

Maintaining API technology conformant with an unexpired version of the FHIR standard adopted in 45 CFR 170.215(a) is a requirement
for all the interoperability APIs; and within that FHIR standard, capability statements are a mandatory resource. A capability
statement documents how a FHIR API has been implemented, including the particular unexpired version of the FHIR standard,
and which aspects of the standard have been implemented and how. (216) The statement can be used to describe how to interface with the FHIR server and thus can provide a degree of self-configuration
for software clients. For example, a capability statement could indicate whether the FHIR server allows clients to push updates
to patient information, or which fields are searchable to find the appropriate patient. Furthermore, a thorough and accurate
capability statement would help impacted payers meet their documentation requirements. (217)

Because capability statements document API implementation details, functional capabilities, and operational parameters, they
are a primary source technical documentation that could satisfy the requirement to make documentation that includes API syntax,
function names, required and optional parameters, software components and configurations, and technical requirements for apps
to interact with their APIs publicly accessible. Ensuring that direct URLs to capability statements are readily available
for all payers in a centralized location would reduce developer burden to find each payer's capability statement. Reducing
developer burden—whether for a developer of patient apps, EHRs, or payer systems—could expedite patient data exchange and
lead to more timely and informed care. We emphasize that we are proposing that impacted payers would have to provide a direct
URL to the capability statement itself and not to a documentation site that includes the capability statement. Because the
capability statement is a structured file, we believe it is important that software be able to find it automatically without
additional manual intervention to find

  the file within a site reported by the payer.

In addition, we propose to require impacted payers to report to CMS a URL or URLs with information about authorization and
authentication protocols and implementation details for their API. That information is already required to be posted in a
publicly accessible location by impacted payers, but we are now proposing to require impacted payers to report to CMS the
location where they have made it available. (218 219) Specific information about authorization and authentication protocols and implementation details is essential for developers
to ensure that their software can communicate and exchange information with an API. Authorization is the process by which
the server gives the requesting client permission to access data. Authentication protocols are those that a payer uses to
verify the identity of the requesting entity. However, there is no single protocol for authentication that will address all
use cases. (220) Additionally, within a single API, implementers may need to utilize more than one protocol to address specific population
and trading partner needs. Therefore, it is essential that developers know how to design their software, whether for patients,
providers, or payers, to successfully access the appropriate data.

Often, API servers require apps or other software that interact with an API to be registered with the server and receive a
key that verifies the app or program making the API call (API key). (221) That allows the server to identify the app and ensure it has the access rights required to make the particular API call. API
keys are not intended to fulfill the same security functions as authorization and authentication protocols for users, but
they help payers monitor their APIs and gather data on usage. Because registration is sometimes necessary to connect to an
API, if the payer requires registration, we propose to require impacted payers to report to CMS a public URL with information
about how developers can register their apps with the API server. We are making those proposals in the CFR citations listed
in Table 8. Not all APIs require registration. For example, the 2020 CMS Interoperability and Patient Access final rule (85
FR 25583 and 25584) established that provider directory information must be accessible via an API without requiring authentication.
Therefore, payers implementing Provider Directory APIs would not have API registration information to report for that API,
and the requirement would not apply.

We propose that CMS would publish those API endpoints and URLs in a centralized location for easy discovery by developers.
We emphasize that we are not proposing that impacted payers would be required to report their supporting documentation itself
to CMS. Rather, we are proposing that impacted payers would be required to report to CMS one or more public URLs where that
documentation can be publicly accessed. However, we request comment on whether a single URL to a site that contains the authorization
and authentication protocols and implementation details and API registration information is sufficient, or whether impacted
payers should report a separate URL for each of these items. In addition, we request comment on whether there are discrete
pieces of information, such as the specific authentication protocol a payer uses, that we should collect to facilitate faster
API integration with patient health apps, provider EHRs, and payer systems. We wish to balance the benefits of making as much
information available in a standardized and centralized location against the burden of reporting.

3. Alternative Proposal—National Directory of Healthcare Providers & Services Implementation Guide

As an alternative to our primary proposal, the National Directory of Healthcare Providers & Services (NDH) IG could provide
a framework for payers to report the proposed information. (222) The NDH IG has been developed to facilitate and standardize a national directory infrastructure. The NDH IG provides a framework
for standardized information sharing about providers, health organizations, and related services, their relationships, and
technical connectivity details (for example, electronic endpoints) in FHIR. Within the NDH IG is an Endpoint Profile resource
that has already been developed with the resource structure we are proposing for payer endpoint reporting. (223) The Endpoint Profile within the NDH IG includes several of the data elements we are proposing here, as well as additional
information for developers. The NDH IG Endpoint Profile includes extensions to document IG versions, authentication information,
trust frameworks, UDAP dynamic registration, environment type (production/test/development), and more. While the NDH IG has
not been adopted by HHS at this time, it may provide a simpler method for data submission, as it has been developed by FAST,
an HL7 FHIR accelerator program, using the same FHIR standards as the other specifications and IGs discussed in this proposed
rule. Tying reporting requirements to an existing FHIR IG may simplify the process for payers to report the proposed data
and developers to use the data within a potential centralized registry.

Under this alternative proposal, we propose to require impacted payers to report NDH IG Endpoint Profile compliant resources
containing the relevant information for each interoperability API. A single Endpoint Resource would be sufficient for cases
where a single endpoint manages multiple API types with the same server or service address (URL), requirements, and other
documentation. Under this alternative proposal, impacted payers would be required to populate all elements and extensions
identified in the profile that are relevant to the specific interoperability API, including, but not limited to: FHIR IGs
and

  versions, dynamic registration information, trust framework, secure exchange artifacts, access control mechanisms, payload
  Multipurpose internet Mail Extension (MIME) type, and environment type. This alternative proposal is limited to proposing
  to require impacted payers to submit relevant Endpoint Resources that are compliant with the NDH Endpoint Profile, as opposed
  to proposing to require full support and implementation of the NDH IG as a whole.

4. Reporting Timelines

In the 2020 CMS Interoperability and Patient Access final rule, we finalized compliance dates in 2021 for the Patient Access
and the Provider Directory APIs (except for QHP issuers on the FFEs, which are not subject to the Provider Directory API requirement)
(85 FR 25558 and 25559 and 85 FR 25563 and 25564). Therefore, the information we are proposing to require impacted payers
to report to CMS should already be publicly available for those two APIs. In the 2024 CMS Interoperability and Prior Authorization
final rule, we established compliance dates in 2027 for impacted payers to implement the Provider Access, Payer-to-Payer,
and Prior Authorization APIs. We believe that it would benefit payers, providers, and patients to have endpoints publicly
available as soon as possible. Therefore, rather than tying a compliance date to the beginning of a calendar year, plan year,
or rating period, we are proposing that all impacted payers be required to report the proposed data to CMS no later than 60
days after the effective date of a final rule. The proposed information about their own APIs should be readily available to
impacted payers. Therefore, we believe the benefits of making endpoints publicly available, as discussed here, compel an expedited
reporting process and deadline.

As new payers participate in CMS programs, we propose that they would be required to report the proposed information to CMS
no later than 60 days before they begin covering patients under the applicable CMS program. Specifically, that means that
a new impacted payer would be required to report 60 days before January 1 for MA organizations and state Medicaid and CHIP
FFS programs, 60 days before the beginning of a rating period for Medicaid managed care plans or CHIP managed care entities,
and 60 days before a plan year for QHP issuers on the FFEs, depending on the type of plan(s) the impacted payer is offering.

After the proposed deadline, we propose that impacted payers would be required to update the information reported to CMS within
1 week of any changes. In addition, to ensure that the latest information is available, we propose that impacted payers would
be required to verify that the reported information is still correct every 12 months from the date of the last update or verification.
We believe that the burden of reporting API endpoints to CMS would be minimal compared to the burden on payers to individually
locate other payers' API endpoints for the Payer-to-Payer API. We seek comment on the burden that reporting API endpoints
could place on payers and how CMS can reduce that burden, either with the information we collect or the method of collection.
Impacted payers could meet the proposed requirements to verify their information at any time during the year. For instance,
we expect that QHP issuers could report (if a new QHP issuer) or verify every 12 months (if an existing QHP issuer) at the
same time they apply for certification on the FFEs, which could streamline their reporting requirements and allow CMS to verify
that the QHP issuer has met the conditions for certification.

While only impacted payers would be subject to these proposals, if finalized, CMS would collect and publish API endpoints
and URLs from any payer that implements interoperability APIs, including those that are not impacted payers under the CMS
interoperability rules. As we continue to strongly encourage payers not subject to our interoperability rules to participate
in data exchange, according to the requirements and standards established in those rules, we would want to facilitate their
participation by publishing their API endpoints and documentation URLs.

5. Publication

While we are not making any proposals as to the specific methods, formats, or systems that could be used to collect and publish
the proposed information, we seek comment on how CMS could do so in a manner that would balance the burden on payers with
the benefits to developers, patients, providers, and payers.

6. Summary

In summary, we request comment on our proposals in the CFR citations listed in Table 8, and specifically on the following:

• The proposal to require impacted payers to report all API endpoints to CMS, in the form of an Endpoint Resource, as defined by an unexpired version of the FHIR standard adopted in 45 CFR 170.215(a), including, if multiple, appropriate use cases for each.
• The proposal to require impacted payers to report URLs with the required documentation for each of their interoperability APIs, as applicable: ++ A direct URL to the API FHIR capability statement.

++ Authorization and authentication protocols and implementation details.

++ API registration information.

• The proposal to require impacted payers to report this information to CMS no later than 60 days after the effective date of a final rule.
• The proposal to require new impacted payers to report this information no later than 60 days before they begin covering patients under the applicable CMS program.
• The proposal to require impacted payers to update CMS within 1 week of any changes to the reported information and verify their information at least once every 12 months.

• The alternative proposal to require impacted payers to report to CMS all NDH IG Endpoint Profile resources containing the
  relevant information for each interoperability API.
  In addition, we request comment on the following:

• Is the proposal to collect a direct URL for the FHIR capability statements necessary, or would a payer endpoint be sufficient
  to indicate that the capability statement is located at [API endpoint]/metadata, as is required by the FHIR standard, or is
  that data element duplicative?

• Whether a single URL to a site that contains the authorization and authentication protocols and implementation details, and
  API registration information is sufficient, or whether impacted payers should report separate direct URLs for each of these
  items?

• Whether there are discrete pieces of information, such as the specific authentication protocol a payer uses, that we should
  collect to facilitate faster API integration with patient health apps, provider EHRs, and payer systems?

• Would aligning the reporting requirements with the NDH Endpoint Profile resource reduce payer burden to report the proposed
  information and/or developer burden to use a centralized registry?
  • If the alternative proposal is finalized, would it negate the need for impacted payers to report URLs to documentation related
  to authorization and authentication protocols and implementation details and API registration information?

• The burden that reporting API endpoints could place on payers and how CMS can reduce that burden, either with the information
  we collect or the method of collection.

• How CMS could collect and publish the reported information in a manner that would balance the burden on payers with the benefits
  to developers, patients, providers, and payers. For example:
  ++ Would a machine-readable file on CMS's website be sufficient?

++ What would the benefits be of a FHIR-enabled registry, either for reporting or publishing? Would using FHIR standards allow
a more streamlined and automated reporting process for payers? Would it allow greater flexibility for third-party app developers
and EHR developers, which could improve the patient and provider experience?

BILLING CODE 4150-28-P

BILLING CODE 4150-28-C

7. Statutory Authorities

a. Medicare Advantage

For MA organizations, we are proposing these new requirements under our authority in the following sections of the Act:

• Section 1852(d)(1)(A) of the Act requires MA organizations offering an MA plan to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner that assures continuity in the provision of benefits.
• Section 1852(g)(1)(A) of the Act requires an MA organization to have a procedure for making determinations about whether an enrollee is entitled to receive a health service, how much the enrollee is required to pay for such service, and to provide an enrollee with a written notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act also requires that coverage determinations be made on a timely basis.
• Section 1852(h) of the Act requires that MA organizations have procedures in place to maintain accurate and timely medical records and other health information regarding MA enrollees and to assure enrollees have timely access to such records and information.
• Section 1856(b) of the Act authorizes the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, including the provisions in section 1852 of the Act.
• Section 1857(e)(1) of the Act explicitly authorizes the adoption of additional MA contract terms and conditions, including required reporting to CMS by MA organizations, where necessary and appropriate and not inconsistent with Part C of the Medicare statute. One-Week Update Requirement —Section 1857(e)(1) of the Act explicitly authorizes additional contract terms and conditions, including required reporting to CMS by MA organizations, where necessary and appropriate. The proposed 1-week update requirement is necessary to ensure that the centralized registry maintains current endpoint information that supports the statutory requirements in sections 1852(d)(1)(A) (continuity of care), 1852(g)(1)(A) (timely coverage determinations), and 1852(h) (timely access to health records) of the Act. Section 1856(b) of the Act authorizes regulatory standards that carry out Part C requirements. Timely endpoint updates are essential to maintain the effectiveness of these statutory obligations, as outdated endpoints immediately disrupt API functionality and undermine patient access and care coordination.

Verification Requirement —The proposed requirement to verify every 12 months is necessary and appropriate to ensure ongoing compliance with API endpoint
reporting obligations and the underlying statutory requirements they support, and therefore may be adopted by the Secretary
as an additional MA contract term under section 1857(e)(1) of the Act. In addition, section 1856(b) of the Act authorizes
the Secretary to establish standards that ensure continued compliance with statutory requirements, including verification
that reported information remains accurate to support ongoing patient access and care coordination.

API URL Reporting —The proposed requirement for MA organizations to report URLs for API documentation is supported by the same statutory authorities
as the 1-week update and verification requirements. Section 1857(e)(1) of the Act authorizes additional contract terms including
required reporting to CMS where necessary and appropriate to effectuate the interoperability API requirements established
under sections 1852(d)(1)(A), 1852(g)(1)(A), and 1852(h) of the Act. Section 1856(b) of the Act supports the URL reporting
proposal as a regulatory standard necessary to ensure that technical information required for API functionality is discoverable,
supporting timely patient access to health records, continuity of care, and coverage determinations. Without discoverable
documentation, the API endpoints themselves cannot function effectively to serve these statutory purposes.

Patient Access API —If developers have to find payer API endpoints individually, it could result in delays to the enrollee's ability to access
their records in a timely manner. Therefore, we propose to collect and publish payer API endpoints under our authority under
section 1856(b) of the Act to establish standards to carry out section 1852(h), as well as our authority under section 1857(e)(1)
of the Act. Facilitating patients' access to their own health information could allow them to identify errors or missing data,
thus improving the accuracy and timeliness of the medical records maintained by the MA organization. In the 2024 CMS Interoperability
and Prior Authorization final rule, we stated that making these data available through the Patient Access API is consistent
with our programmatic authority to establish standards to implement section 1852(h) of the Act and could help patients be
more informed about and active in their own care, which could potentially lead to better health outcomes. (224)

Provider Access API —Without a centralized location for providers to find API endpoints, the increased burden may lead to delays in receiving
patient data, or providers deciding not to request patient data at all. Therefore, we propose to collect and publish payer
API endpoints under our authority under section 1856(b) of the Act to establish standards to carry out sections 1852(d)(1)(A)
and 1852(h) of the Act, as well as our authority under 1857(e)(1) of the Act. Facilitating providers' access to patient data
would give insight into health history and previous care, thus creating conditions for benefits to be accessible in a manner
that assures the continuity of care. As discussed in the 2024 CMS Interoperability and Prior Authorization final rule, the
Provider Access API would facilitate exchanges of information about enrollees that are necessary for effective and continuous
patient care, which is consistent with the requirement at section 1852(d)(1)(A) of the Act for continuing the provision of
benefits. (225)

Payer-to-Payer API —One of the most important purposes of our payer to payer data exchange policy is to facilitate care continuity at the time
a patient changes payers. Delays in being able to find the previous payer's API endpoint to request patient data could diminish
those benefits. Therefore, we propose to collect and publish payer API endpoints under our authority under section 1856(b)
of the Act to establish standards to carry out section 1852(d)(1)(A), as well as our authority under section 1857(e)(1) of
the Act. Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers are required to make a “reasonable
effort to locate information about a patient's previous payer,” including that payer's API endpoints. (226) Requiring impacted payers to report their API endpoints would ease the burden of finding other payers' endpoints, thus potentially
leading to more payer to payer data exchange as envisioned by the CMS interoperability regulations.

Prior Authorization API —Collecting and publishing payer API endpoints would allow developers to configure provider systems to dynamically find and
use the appropriate payer's API endpoint rather than hard coding each payer API endpoint or requiring a provider to find the
API endpoint

  themselves to submit a prior authorization request. Such process barriers could result in untimely delays to patient care
  and negate some of the benefits that the Prior Authorization API would provide. Therefore, we propose to collect and publish
  payer API endpoints under our authority under section 1856(b) of the Act to establish standards to carry out section 1852(g)(1)(A),
  as well as our authority under section 1857(e)(1) of the Act. Reporting API endpoints would facilitate the required procedure
  for making determinations about enrollee benefits and costs, which would lead to more timely coverage determinations.

Provider Directory API —Collecting and publishing payer API endpoints for Provider Directory APIs could facilitate provider and patient access to
current, accurate provider network information. Without centralized endpoint discovery, providers and patients face increased
burden in locating and accessing provider directory information, which could delay care coordination and patient access to
in-network providers. Therefore, we propose to collect and publish payer API endpoints under our authority under section 1856(b)
of the Act to establish standards to carry out section 1852(d)(1)(A), as well as our authority under section 1857(e)(1) of
the Act. Facilitating access to provider directory information supports the requirement that MA organizations make covered
benefits available and accessible in a manner that assures continuity in the provision of benefits.

b. Medicaid

For state Medicaid FFS programs and Medicaid managed care plans, we are proposing these new requirements under our authority
in the following sections of the Act:

• Section 1902(a)(4) of the Act requires that a state Medicaid plan provides such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan, which includes ensuring that contracted managed care plans comply with federal interoperability requirements.
• Section 1902(a)(6) of the Act requires states to make reports in a form and containing information required by the Secretary, which can include ensuring that managed care plans under contract provide necessary endpoint information to the state for reporting to CMS.
• Section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals.
• Section 1902(a)(19) of the Act requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.
• Section 1903(m)(2)(A)(xi) of the Act requires that contracts with Medicaid MCOs include provisions that ensure compliance with applicable requirements. This provides direct authority to impose endpoint reporting requirements on managed care plans through their contracts with states.
• Section 1932(a) of the Act provides authority for states to implement managed care arrangements and includes certain waiver provisions. Section 1932(d)(1) of the Act establishes that managed care entities must comply with requirements the Secretary determines necessary to carry out the purposes of the Medicaid program One-Week Update Requirement— Section 1902(a)(6) of the Act requires states to make reports “in a form and containing information required by the Secretary,” which includes the timing and frequency of such reports. The proposed 1-week update requirement ensures that CMS receives timely information necessary for proper program oversight. Section 1902(a)(4) of the Act requires methods of administration necessary for proper and efficient program operation. Outdated endpoint information could undermine the efficient operation of the Medicaid program by disrupting API functionality that supports beneficiary access to care and data.

Verification Requirement— Section 1902(a)(6) of the Act supports verification every 12 months as part of the reporting requirements necessary for proper
program oversight and monitoring. Section 1902(a)(4) of the Act requires ongoing administrative methods that ensure proper
program operation, which includes verifying the accuracy of reported endpoint information that supports beneficiary services.

API URL Reporting —Section 1902(a)(6) of the Act supports the URL reporting proposal as part of the reporting requirements necessary for CMS
to facilitate the interoperability framework established under our Medicaid API requirements. This also directly supports
requiring states to collect and report API endpoint information from both their FFS programs and contracted managed care plans.
Section 1902(a)(4) of the Act requires this as a method of administration necessary for proper and efficient program operation,
as centralized documentation discovery supports efficient API implementation and reduces administrative burden on providers
and developers. Additionally, section 1902(a)(4) of the Act requires states to ensure proper administration of their Medicaid
programs, which includes oversight of managed care plan compliance with federal requirements, including endpoint reporting.
States have existing obligations to monitor and ensure managed care plans' compliance with federal requirements, and endpoint
reporting falls within this oversight responsibility. Section 1902(a)(19) of the Act supports this requirement as consistent
with simplicity of administration and beneficiary interests, as centralized URLs simplify API integration and serve beneficiary
interests in data access and care coordination.

Patient Access API —We finalized the Patient Access API based on our authority in sections 1902(a)(4) and (a)(19) of the Act. The requirement
to make Medicaid patients' health information available through interoperable technology can facilitate beneficiary access
to their information in a convenient, timely, and portable way, which is essential for these programs to be effectively and
efficiently administered in the best interests of beneficiaries. We have received feedback from developers that when they
have to find payer API endpoints individually, it can delay beneficiaries' access to their records. Making these API endpoints
publicly accessible through a centralized registry could further enhance beneficiary access by enabling broader innovation
in third-party apps and reducing barriers for developers to create patient-friendly tools that help beneficiaries interact
with their health information. As explained in the 2020 CMS Interoperability and Patient Access final rule, giving beneficiaries
access to their own health data is necessary for the proper and efficient administration of the state plan. (227) Therefore, we propose to collect and publish payer API endpoints under our authority in sections 1902(a)(4), (6), and (19)
of the Act.

Provider Access API —Collecting and publishing payer API endpoints would decrease provider burden, which may facilitate a provider's ability to
request patient information. Otherwise, there could be delays in receiving patient information or a provider may decide not
to request patient data due to that burden. Making patient health information available to providers at the point of care
can significantly improve

  their ability to render Medicaid services effectively, efficiently, and appropriately. The Provider Access API policies should
  help states fulfill their obligations to operate their state plans efficiently and to ensure that Medicaid services are furnished
  with reasonable promptness and in a manner consistent with the best interest of the recipients. [(228)]() Therefore, we propose to collect and publish payer API endpoints under our authority in sections 1902(a)(4), (6), and (19)
  of the Act.

Payer-to-Payer API —Collecting and publishing payer API endpoints would decrease payer burden to locate payer API endpoints to make a request
for patient data. That would accelerate payers' ability to make a timely request for patient data, at a point when delays
could lead to gaps in care. Those data can provide the information necessary to ensure the beneficiary has timely continuity
of care. Therefore, we propose to collect and publish payer API endpoints under our authority in sections 1902(a)(4), (6),
(8), and (19) of the Act. Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers are required
to make a “reasonable effort to locate information about a patient's previous payer,” including that payer's API endpoints. (229) Requiring impacted payers to report their API endpoints would ease the burden of finding other payers' endpoints, thus potentially
leading to more payer to payer data exchange as envisioned by the CMS interoperability regulations.

Prior Authorization API —As explained in the 2024 CMS Interoperability and Prior Authorization final rule, the Prior Authorization API should improve
the efficiency and timeliness of the prior authorization process for Medicaid beneficiaries, providers, state Medicaid agencies,
and Medicaid managed care plans by addressing inefficiencies that exist today. (230) Collecting and publishing payer API endpoints would allow developers to configure provider systems to dynamically find and
use the appropriate payer's API endpoint rather than hard coding each payer API endpoint, which may create maintenance burdens
and system fragility, or requiring a provider to find the API endpoint themselves to submit a prior authorization request.
Doing so would significantly improve the efficiency and timeliness of the prior authorization process, which would ensure
that Medicaid services are furnished with reasonable promptness to all eligible individuals. Therefore, we propose to collect
and publish payer API endpoints under our authority in sections 1902(a)(4), (6), (8), and (19) of the Act.

Provider Directory API— We propose to collect and publish Provider Directory API endpoints under our authority in sections 1902(a)(4), (6), and (19)
of the Act. Section 1902(a)(4) of the Act requires states to provide methods of administration necessary for the proper and
efficient operation of state Medicaid plans. Collecting and publishing Provider Directory API endpoints constitutes such a
method of administration because it enables systematic verification of API accessibility and compliance monitoring. Section
1902(a)(6) of the Act requires states to make reports in a form and containing information required by the Secretary, which
includes the timing and frequency of such reports. This authority supports the proposed requirement for impacted payers to
report Provider Directory API endpoints, update CMS within 1 week of changes, and verify information every 12 months. Section
1902(a)(19) of the Act requires states to provide safeguards to ensure that care and services will be provided in a manner
consistent with simplicity of administration and the best interests of recipients. Centralized endpoint discovery would serve
the best interests of Medicaid beneficiaries by facilitating access to accurate provider directory information, which supports
beneficiaries' ability to locate in-network providers and make informed health care decisions. Therefore, we propose to collect
and publish Provider Directory API endpoints under our authority in sections 1902(a)(4), (6), and (19) of the Act.

c. CHIP

For state CHIP FFS programs and CHIP managed care entities, we are proposing these new requirements under our authority in
the following sections of the Act:

• We finalized the interoperability APIs under our general authority in section 2101(a) of the Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage.
• Section 2107(b)(1) of the Act requires state CHIP agencies to collect data, maintain records, and furnish reports in order to enable the Secretary to monitor state program administration and compliance and to evaluate and compare the effectiveness of state plans under this title. One-Week Update and Verification Requirements —Section 2107(b)(1) of the Act requires data collection and reporting to enable monitoring and evaluation. Timely endpoint updates are necessary for CMS to effectively monitor API implementation and ensure continued program effectiveness. Verification every 12 months is necessary for ongoing program monitoring and evaluation of API effectiveness.

API URL Reporting —Section 2107(b)(1) of the Act supports URL reporting as necessary data collection and reporting to enable CMS to monitor
effective API implementation and evaluate program success. Section 2101(a) of the Act establishes the purpose of providing
child health assistance in an effective and efficient manner, and centralized documentation discovery supports efficient API
implementation that benefits CHIP beneficiaries by facilitating seamless data exchange and care coordination.

Patient Access API —Requiring state CHIP FFS programs to make beneficiaries' health information available through interoperable technology increases
patient access to their health information, which can improve the efficacy of state CHIP FFS programs, allow for more efficient
communication and administration of services, and promote coordination across various sources of health benefits coverage.
As we stated in the 2024 CMS Interoperability and Prior Authorization final rule, the Patient Access API should increase patient
access to their health information, which can improve the efficacy of state CHIP FFS programs, allow for more efficient communication
and administration of services, and promote coordination across various sources of health benefits coverage. (231) If developers have to find payer API endpoints individually, it could result in delays to the beneficiaries' ability to access
their records in a timely manner. Therefore, we propose to collect and publish payer API endpoints under our authority in
section 2107(b)(1) of the Act to help state CHIP FFS programs provide coverage to low-income children more effectively and
efficiently.

Provider Access API —The more information a provider has to make informed decisions about a patient's care, the more likely it is that patients
will receive care that best meets their needs. As explained in the 2024 CMS

  Interoperability and Prior Authorization final rule, providers can be more effective and efficient in their delivery of CHIP
  services by having direct access to patient utilization and authorization information. [(232)]() If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time
  focused on the patient, rather than on their need to collect information. Therefore, we propose to collect and publish payer
  API endpoints under our authority in section 2107(b)(1) of the Act to help state CHIP FFS programs provide child health assistance
  to uninsured, low-income children in an effective and efficient manner.

Payer-to-Payer API —The Payer-to-Payer API is central to the goal of coordination with other sources of health benefits coverage for children
in section 2101(a) of the Act. Centralizing payer API endpoints could facilitate more efficient and accurate requests for
patient information, faster data exchange, and ultimately better care continuity and coordination for CHIP beneficiaries as
they enter or exit CHIP coverage. Therefore, we propose to collect and publish payer API endpoints under our authority in
section 2101(a) of the Act to help state CHIP agencies provide child health assistance to uninsured, low-income children in
an effective and efficient manner that is coordinated with other sources of health benefits coverage. Per the 2024 CMS Interoperability
and Prior Authorization final rule, impacted payers are required to make a “reasonable effort to locate information about
a patient's previous payer,” including that payer's API endpoints. (233) Requiring impacted payers to report their API endpoints would ease the burden of finding other payers' endpoints, thus potentially
leading to more payer to payer data exchange as envisioned by the CMS interoperability regulations.

Prior Authorization API —The Prior Authorization API facilitates the more efficient and effective exchange of information required to submit a prior
authorization request and receive a decision. An improved process may reduce administrative costs for providers and payers
and improve timeliness in responding to providers and patients. As explained in the 2024 CMS Interoperability and Prior Authorization
final rule, making this information available in a standardized way and permitting access through an API will also serve the
requirements in section 2101(a) of the Act that state CHIP agencies ensure access to coverage and coordinated care. (234) Collecting and publishing payer API endpoints would allow developers to configure provider systems to dynamically find and
use the appropriate payer's API endpoint rather than hard coding each payer API endpoint or requiring a provider to find the
API endpoint themselves to submit a prior authorization request. Therefore, we propose to collect and publish payer API endpoints
under our authority in section 2107(b)(1) of the Act to help state CHIP agencies provide child health assistance to uninsured,
low-income children in an effective and efficient manner.

Provider Directory API —Centralizing Provider Directory API endpoints could facilitate more efficient access to provider network information, supporting
the coordination of care with other sources of health benefits coverage as required under section 2101(a) of the Act. This
would help state CHIP agencies provide child health assistance in an effective and efficient manner that is coordinated with
other coverage sources. Therefore, we propose to collect and publish payer API endpoints under our authority in sections 2101(a)
and 2107(b)(1) of the Act.

d. Qualified Health Plan Issuers on the Federally-facilitated Exchanges

For QHP issuers on the FFEs, we finalized the API requirements under our authority in section 1311(e)(1) of the Affordable
Care Act. Section 1311(e)(1)(A) of the Affordable Care Act requires that Exchanges only certify plans as QHPs if they meet
the requirements for certification promulgated by the Secretary under section 1311(c)(1) of the Affordable Care Act, while
section 1311(e)(1)(B) of the Affordable Care Act affords the Exchanges the discretion to certify QHPs if the Exchange determines
that making available such health plans through the Exchange is in the interests of qualified individuals and qualified employers
in the state or states in which such Exchange operates.

One-Week Update and Verification Requirements— Section 1311(e)(1)(B) of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines that making
such plans available is in the interests of qualified individuals and qualified employers in the state or states in which
such Exchange operates. Maintaining current endpoint information through timely updates would serve these interests by ensuring
reliable API access for enrollees—enabling them to access their health data, coordinate care with providers, and facilitate
seamless data exchange between payers without delays caused by outdated or inaccessible API endpoints. Verification every
12 months would ensure that certified QHPs continue to serve the interests of qualified individuals and qualified employers
through reliable, accessible API endpoints.

API URL Reporting —Section 1311(e)(1)(B) of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines that making
such plans available is in the interests of qualified individuals and qualified employers in the state or states in which
such Exchange operates. The proposal to require URL reporting ensures that certified QHPs maintain discoverable API documentation,
serving enrollee interests in data access and care coordination. We believe it is in the interest of qualified individuals
for health plans provide accessible technical documentation that enables effective API integration and operation.

Patient Access API —In the 2020 CMS Interoperability and Patient Access final rule, we stated that generally certifying only health plans that
make enrollees' health information available to them in a convenient, timely, and portable way is in the interests of enrollees
in the state or states in which a FFE operates (85 FR 25526). If developers have to manually locate payer API endpoints individually,
it could introduce operational inefficiencies and development delays that may hinder the enrollee's timely access to their
records. Therefore, we propose to collect and publish payer API endpoints under our authority in section 1311(e)(1)(B) of
the Affordable Care Act, as we believe it is in the interest of qualified individuals and qualified employers to collect and
publish QHP issuers on the FFEs' API endpoints.

Provider Access API —In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that it is in the interest of enrollees to
generally only certify health plans that make enrollees' health information available to their providers via the Provider
Access API (89 FR 8820). Giving providers access to their enrollees' health information supplied by QHP issuers on the FFEs
should ensure that providers are better positioned to provide enrollees with seamless and coordinated care and ensure that
enrollees are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the enrollee's
more complete medical information could also maximize the efficiency of an enrollee's office visits.

  Without a centralized location to find payer API endpoints, the increased burden may lead to delays in receiving enrollee
  information or providers deciding not to request enrollee data at all. Therefore, we propose to collect and publish payer
  API endpoints under our authority in section 1311(e)(1)(B) of the Affordable Care Act, as we believe it is in the interest
  of qualified individuals and qualified employers to collect and publish QHP issuers on the FFEs' API endpoints.

Payer-to-Payer API —In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that it is in the interest of enrollees to
generally only certify health plans that have a Payer-to-Payer API in place to exchange information with other payers about
new enrollees, concurrent enrollees, and enrollees who have moved to another payer (89 FR 8858). Having enrollee information
at the beginning of a new plan may assist the new payer in identifying enrollees who need care management services, which
could reduce the cost of care. Delays in being able to find the previous payer's API endpoint to request enrollee data could
diminish those benefits. Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers are required
to make a “reasonable effort to locate information about a patient's previous payer,” including that payer's API endpoints. (235) Requiring impacted payers to report their API endpoints would ease the burden of finding other payers' endpoints, thus potentially
leading to more payer to payer data exchange as envisioned by the CMS interoperability regulations. Therefore, we propose
to collect and publish payer API endpoints under our authority in section 1311(e)(1)(B) of the Affordable Care Act, as we
believe it is in the interest of qualified individuals and qualified employers to collect and publish QHP issuers on the FFEs'
API endpoints.

Prior Authorization API —In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that it is in the interest of enrollees for
CMS to generally only certify health plans that have a Prior Authorization API because it enables more accurate submission
and processing of prior authorization requests, which could improve the delivery of services to enrollees (89 FR 8901). Collecting
and publishing payer API endpoints would allow developers to configure provider systems to dynamically find and use the appropriate
payer's API endpoint rather than hard coding each payer API endpoint or requiring a provider to find the API endpoint themselves
to submit a prior authorization request. We believe that in reducing provider administrative burden, providers would spend
less time on administrative tasks, allowing them to spend more time on enrollee care. Therefore, we propose to collect and
publish payer API endpoints under our authority in section 1311(e)(1)(B) of the Affordable Care Act, as we believe it is in
the interest of qualified individuals and qualified employers to collect and publish QHP issuers on the FFEs' API endpoints.

Provider Directory API —QHP issuers on the FFEs are not subject to Provider Directory API requirements.

F. Updates to Patient Access, Provider Directory, Provider Access, and Payer-to-Payer APIs; API Usage Metrics

1. Information About Prior Authorizations for Drugs in the Patient Access, Provider Access, and Payer-to-Payer APIs

a. Background

In the 2024 CMS Interoperability and Prior Authorization final rule, we required impacted payers to make available certain
information about prior authorizations for non-drug items and services via a Patient Access API. (236) We also required impacted payers to make available similar information via Provider Access and Payer-to-Payer APIs (89 FR
8817 and 8855). We finalized compliance dates beginning in 2027 for each of these APIs (by January 1, 2027 for MA organizations
and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027 for Medicaid managed
care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027 for individual market
QHP issuers on the FFEs) (89 FR 8784, 8817, and 8855). Specifically, impacted payers must make all of the following information
available about prior authorization requests and decisions for non-drug items and services via the Patient Access and Provider
Access APIs:

• The prior authorization status.
• The date the prior authorization was approved or denied.
• The date or circumstance under which the prior authorization ends.
• The items and services approved.
• If denied, a specific reason why the request was denied.
• Related structured administrative and clinical documentation submitted by a provider (89 FR 8784 and 8817). Impacted payers must make the same prior authorization information available through the Payer-to-Payer API, except they are not required to include denied prior authorizations (or a specific reason why the request was denied). (237) Additionally, impacted payers must make available via the Payer-to-Payer API both structured and unstructured administrative and clinical documentation submitted by a provider. (238) For each of these APIs—the Patient Access, Provider Access, and Payer-to-Payer APIs (collectively “Access APIs”), we required that impacted payers make this information about prior authorizations available no later than 1 business day after the payer receives a prior authorization request and must update that information no later than 1 business day after any status change. This information must be available for the duration that the authorization is active and at least 1 year after the prior authorization's last status change (89 FR 8784, 8817, and 8855). Like the rest of the 2024 CMS Interoperability and Prior Authorization final rule, those requirements do not apply to any kind of drugs.

b. Proposals

We emphasize the importance of access to prior authorization information for drugs in section II.B. of this proposed rule.
For the reasons we explained in that section and in response to public feedback received on the 2022 CMS Interoperability
and Prior Authorization proposed rule, we propose to add information about prior authorization requests and decisions for
all drugs to the categories of data impacted payers are required to make available through the Access APIs. We propose to
amend the Access API

  provisions that require impacted payers to make available information about prior authorizations for non-drug items and services
  and drugs. Consistent with our policies for non-drug items and services, the information about prior authorizations for drugs
  that we are proposing be made available via the Patient Access and Provider Access APIs is the following:

• The prior authorization status.
• The date the prior authorization was approved or denied.
• The date or circumstance under which the prior authorization ends.
• The drug or drugs approved (including the dosage).
• If denied, a specific reason why the request was denied.

• Related structured administrative and clinical documentation submitted by a provider.
  For the Payer-to-Payer API, the information about prior authorizations for drugs we propose is the following:

• The prior authorization status.

• The date the prior authorization was approved.

• The date or circumstance under which the prior authorization ends.

• The drug or drugs approved (including the dosage).

• Related structured and unstructured administrative and clinical documentation submitted by a provider.
  In the 2024 CMS Interoperability and Prior Authorization final rule, we excluded denied prior authorization requests for non-drug
  items and services from the set of information that must be exchanged between payers via the Payer-to-Payer API and are proposing
  the same for prior authorizations for drugs (89 FR 8827). We propose to exclude denied prior authorization requests because
  they generally would not reflect ongoing treatment, as it does not demonstrate that patients actually received items, services,
  or drugs. If a patient ultimately received those items, services, or drugs despite the denied request, that information would
  have to be gathered from elsewhere (such as clinical data), regardless of whether the requesting payer receives information
  about the prior authorization decision. Many commenters cited similar justifications for excluding denied prior authorizations
  in response to the 2022 CMS Interoperability and Prior Authorization proposed rule, and we thus did not finalize a requirement
  to include denied prior authorization decisions in the Payer-to-Payer API policies. The value of including such information
  would likely be outweighed by the additional burden on impacted payers to include it and we therefore believe its exclusion
  remains justified. We refer readers to the 2024 CMS Interoperability and Prior Authorization final rule for a full discussion
  of our reasoning for this exclusion (89 FR 8830).

We propose an October 1, 2027 compliance date for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to make the proposed information about prior authorizations
for drugs available via the Access APIs. Because impacted payers are already required to make available information about
prior authorizations for non-drug items and services beginning in 2027 (by January 1, 2027, for MA organizations and state
Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans
and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) (89
FR 8784, 8817, and 8855), we believe a 9-month implementation window following that date strikes the appropriate balance between
urgency and operational feasibility. An October 1, 2027 compliance date allows impacted payers to build upon the infrastructure
and processes established for the January 1, 2027 deadline, while providing a defined period to extend that infrastructure
to drug prior authorization data. However, we encourage these payers to make this information available via their APIs as
soon as possible to benefit their patients.

We propose that the requirement to make available information about prior authorization for drugs would be subject to the
same timeframes established for making available prior authorization information for non-drug items and services—no later
than 1 business day after the payer receives a prior authorization request—and the payer must update that information no later
than 1 business day after any status change. This proposal not only aligns with our previously finalized policy, but we continue
to believe that 1 business day is the appropriate timeframe for the reasons discussed in the 2024 CMS Interoperability and
Prior Authorization final rule (89 FR 8775-8776). Similarly, that 1 business day timeframe aligns with the existing requirements
to make claims and encounter data and all data classes and data elements included in a content standard in 45 CFR 170.213
(USCDI) available via the Access APIs no later than 1 business day after being processed or received by the payer.

Additionally, we propose that information about prior authorizations for drugs be required to be available via the Access
APIs for as long as the authorization is active and at least 1 year after the last status change. Information about denied
and expired prior authorizations for drugs would therefore be available for at least 1 year after expiring or being denied.
Consistent with the requirements to make available information about prior authorizations for non-drug items and services,
we are not proposing to require payers to share a patient's full prior authorization history because that could comprise a
significant amount of information that may no longer be clinically relevant. Furthermore, as payers' prior authorization policies
may change over time, that information has a limited lifespan of usefulness for a patient's current care. However, our proposal
would require payers to make available information about all active authorizations for as long as they are active, which may
indicate a relationship to ongoing care.

In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following:

• The proposal to require impacted payers to add information about prior authorization requests and decisions for all drugs to the categories of data they are required to make available through the Access APIs, within the timeframes established for non-drug items and services.
• The proposed October 1, 2027 compliance dates for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

2. Reporting Usage Metrics for Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs

a. Background

Beginning in 2026, impacted payers are required to annually report to CMS certain metrics about patient data requests made
via the Patient Access API. Impacted payers must annually report Patient Access API metrics to CMS in the form of aggregated,
de-identified data following any year that the payer was subject to the requirement to make the Patient Access API available.
Specifically, by March 31, 2026, MA organizations at the contract level, state Medicaid and CHIP FFS programs at the state
level, and Medicaid managed care plans and CHIP managed care entities at the plan level must report the following metrics:
(1) the total number of unique patients whose data are transferred via the

  Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred
  more than once via the Patient Access API to a health app designated by the patient. [(239)]() The current regulation in 45 CFR 156.221(f) provides that individual market QHP issuers on the FFEs at the issuer level also
  report these data by March 31, 2026, but CMS has specified to plans in sub-regulatory guidance that we will collect Patient
  Access API usage metrics during the QHP certification process. [(240)]()

These data will help CMS better understand whether the Patient Access API requirement is effectively and efficiently providing
patients access to their health information and whether payers are providing that required information in a transparent and
timely way. Additionally, aggregated usage data from each impacted payer will help us evaluate whether the Patient Access
API policies are achieving the desired goals. By gathering that information, we can provide targeted support or guidance to
impacted payers, if needed, to ensure that patients have access to their data and can use their data consistently across impacted
payers. Multiple data transfers indicate repeat access, showing that patients are either using multiple apps or allowing apps
to update their information over the course of the year. While data transfers may not indicate to what extent patients are
using apps to manage their health care, it would be a preliminary indicator of interest in the technology (89 FR 8779).

The current regulation requires that impacted payers report metrics from the previous calendar year to CMS by March 31 of
each year. (241) In the first year of the requirement, impacted payers will report calendar year 2025 data by March 31, 2026. A MA organization,
Medicaid managed care plan, CHIP managed care entity, or individual market QHP issuer on the FFEs that is newly offering coverage
in a particular market would naturally have no data to report in its first year of operation and is required to report data
following its first year subject to the Patient Access API requirement (89 FR 8780). We did not propose, and thus did not
finalize, policies for impacted payers to report usage metrics to CMS about Provider Access, Payer-to-Payer, or Prior Authorization
APIs.

b. Proposed Changes to Patient Access API Usage Metrics for Medicaid Managed Care Plans, CHIP Managed Care Entities, and Individual

Market QHP Issuers on the FFEs

After finalizing the Patient Access API usage metrics in the 2024 CMS Interoperability and Prior Authorization final rule,
we determined that additional proposals would be appropriate for Medicaid managed care plans, CHIP managed care entities,
and individual market QHP issuers on the FFEs to align reporting deadlines for API usage metrics with other reporting deadlines.
Similar proposals for small group market QHP issuers on the FF-SHOPs, with a later applicability date, are discussed in section
II.D. of this proposed rule.

Specifically, Medicaid managed care plans' and CHIP managed care entities' program contracts do not all use the same time
period, and each state may choose different contract rating periods for each managed care program. Medicaid managed care plans'
and CHIP managed care entities' contracts may use any 12-month period and collecting Patient Access API usage data based on
a calendar year would thus be out of alignment with other reporting obligations in the contracts. Because rating periods do
not necessarily align with calendar years, we now believe that the March 31 reporting deadline finalized in the 2024 CMS Interoperability
and Prior Authorization final rule may not be appropriate for all Medicaid managed care plans and CHIP managed care entities.
Therefore, to align the reporting deadlines with the contract rating period and its requirements, we are now proposing to
require Medicaid managed care plans and CHIP managed care entities to report Patient Access API usage metrics from each rating
period to the state no later than 90 days after the end of each rating period. For Medicaid managed care plans, these metrics
will be reported to CMS by states in their MCPARs, which are due 180 days after the end of the rating period. Having Medicaid
managed care plans report Patient Access API usage metrics to the state no later than 90 days after the end of each rating
period provides states with ample time to collect and process the data for inclusion in their MCPARs. To simplify the cross-referencing
regulatory text, we also propose, in 42 CFR 438.242(b)(5)(ii)(B), to be explicit that the requirement for Medicaid managed
care plans and CHIP managed care entities is to report API usage metrics to the state, rather than to CMS directly.

Furthermore, we propose to amend the requirements for Medicaid managed care plans and CHIP managed care entities to clarify
that they would be required to report the Patient Access API usage metrics by program, as well as by plan. We plan to collect
metrics from Medicaid managed care plans via the states through the MCPAR system, which is set up to receive reports from
plans by program. (242) For consistency with the other Medicaid and CHIP managed care reporting requirements, we believe that it is appropriate to
also collect these metrics at the program level. Specifically, this proposal means that if a specific managed care plan contracts
with the state for multiple programs (for example, an adult and child acute care program and an LTSS program), each program
would separately report Patient Access API usage metrics. This is also consistent with how states must report all data in
the MCPAR, as described in 42 CFR 438.66(e). For CHIP managed care entities, we are currently working to finalize the mechanism
for states to submit Patient Access API usage metrics to CMS. We plan to provide future guidance for states on CHIP managed
care entities reporting requirements and processes.

The certification process for new and existing QHP issuers on the FFEs for the next plan year begins in the prior calendar
year. QHP issuers on the FFEs are required to submit to CMS their initial application for plan certification for each plan
year in June of the previous calendar year. Because the current annual March 31 reporting deadline finalized in 45 CFR 156.221(f)
in the 2024 CMS Interoperability and Prior Authorization final rule falls before the annual QHP certification application
deadline, we believe it would be more appropriate to align the deadlines so that QHP issuers on the FFEs can submit Patient
Access API usage metrics as part of the annual QHP certification process. Further, other

  reporting requirements in 45 CFR part 156, subpart C do not generally include specific dates by which issuers must report
  the required information but rely on the annual application deadline. [(243)]() Therefore, we propose regulatory text to refer to the reporting deadline for Patient Access API usage metrics in a manner
  similar to the reporting deadlines for other plan data that CMS collects during the annual QHP certification process. Specifically,
  we propose that following each year it offers a QHP on a FFE, a QHP issuer on the FFEs must report the specified metrics to
  CMS as aggregated, de-identified data at the issuer level in the form and manner and within the timeframes specified by the
  Secretary. That would allow flexibility for CMS to include API usage metrics reporting within specific deadlines set for the
  QHP certification process, which in practice, is generally the final deadline for the QHP certification process that takes
  place the following year. [(244)]() For example, QHP issuers on the FFEs would be required to submit metrics from plan years in 2026 as part of the QHP certification
  process during 2027 for plan years in 2028. In practice, CMS has already issued sub-regulatory guidance that CMS will collect
  Patient Access API usage metrics during the QHP certification process. [(245)]() Amending the regulatory text to align with how 45 CFR part 156, subpart C frames other QHP certification-related deadlines
  would streamline reporting by allowing issuers to report metrics at the same time and to the same systems as the QHP certification
  application. We are proposing that these changes become effective beginning on the effective date of the final rule.

In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following:

• The proposal for Medicaid managed care plans and CHIP managed care entities to report Patient Access API usage metrics to the state no later than 90 days after the end of each rating period.
• The proposal for QHP issuers on the FFEs to report Patient Access API usage metrics to CMS in the form and manner and within the timeframes specified by the Secretary.
• The proposal to require Medicaid managed care plans and CHIP managed care entities to report certain metrics about Patient Access API usage, as finalized in the 2024 CMS Interoperability and Prior Authorization final rule, by program, as well as by plan.
• The proposal to become effective beginning on the effective date of the final rule.

c. Proposal to Report Metrics About the Provider Access, Payer-to-Payer, and Prior Authorization API Usage for All Impacted

Payers

We are proposing that impacted payers be required to report metrics about usage of the Provider Access, Payer-to-Payer, and
Prior Authorization APIs, which are required under the 2024 CMS Interoperability and Prior Authorization final rule. We propose
that, beginning in 2028, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed
care entities, and QHP issuers on the FFEs would be required to annually report metrics in the form of aggregated, de-identified
data.

The reporting period for MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be the
calendar year, while the reporting period for Medicaid managed care plans and CHIP managed care entities would be the rating
period. We propose that, beginning in 2028, MA organizations and state Medicaid and CHIP FFS programs be required to report
the previous calendar year's metrics to CMS by March 31 of each year. We propose that by the first rating period beginning
on or after January 1, 2028, Medicaid managed care plans and CHIP managed care entities be required to report metrics to states
from each rating period no later than 90 days after the end of each rating period. We propose that for plan years beginning
on or after January 1, 2028, following each year it offers a QHP on a FFE, unless granted an exception for the previous year,
a QHP issuer on the FFEs must report usage metrics to CMS in the form and manner and within the timeframes specified by the
Secretary. Impacted payers would thus be required to begin reporting these data in 2028 for the previous reporting period
(for most impacted payers, calendar year 2027). As discussed in section II.C.6. of this proposed rule, we use the term “reporting
period” to describe the period from which data must be reported in order to account for certain differences between impacted
payers.

We also propose that MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would report the
metrics at the same reporting levels, that is, the organizational levels at which the payer aggregates and submits the required
data, as finalized for the Patient Access API usage metrics. MA organizations would thus report at the contract level, state
Medicaid and CHIP FFS programs at the state level, and QHP issuers on the FFEs at the issuer level. We also propose that Medicaid
managed care plans and CHIP managed care entities would report metrics at the plan and program level for the reasons discussed
previously. By way of examples, reporting at the issuer level means that a QHP issuer on the FFEs would aggregate data across
the plans it offers on a FFE, while reporting at the plan level means that a Medicaid managed care plan would report data
specific to that individual plan. As we finalized for the Patient Access API (89 FR 8780), dual eligible special needs plans
(D-SNPs) would report consistent with MA organizations at the contract level, and with Medicaid managed care plans at the
plan level. Therefore, the MA organization would report information about Provider Access, Payer-to-Payer, and Prior Authorization
API usage by its D-SNP enrollees to CMS at the contract level. The affiliated Medicaid managed care plan would report on information
about Patient Access API usage by its enrollees to CMS at the plan and program level.

In the 2024 CMS Interoperability and Prior Authorization final rule, we explained that we believe that it is most appropriate
for MA organizations to report these usage data at the contract level (89 FR 8780). Contract level data represent aggregated
information from all PBPs that fall under a single MA contract, with reporting organized by individual contracts rather than
by individual plans. We already require MA organizations to annually report contract level data about their organization's
determinations to CMS. Maintaining consistent contract level reporting in the MA program would give us useful information
while limiting payer burden. By requiring contract level reporting for these metrics, the format of these reported data would
remain consistent with other data that MA organizations are required to report. There could be value in requiring MA organizations
to report on a plan level in the future to get more discrete data.

  However, at this time, we continue to believe that the burden of requiring MA organizations to report at the plan level, especially
  given the small sample sizes of some plans, outweighs the benefits of obtaining that information.

Commenters agreed with our proposals in the 2022 CMS Interoperability and Prior Authorization proposed rule that requiring
state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans and CHIP managed care entities
to report at the plan level, and individual market QHP issuers on the FFEs to report at the issuer level balances the reporting
burden and the meaningfulness of the data (89 FR 8780). We explained in the 2024 CMS Interoperability and Prior Authorization
final rule that requiring individual market QHP issuers on the FFEs to report at the issuer level, thereby aggregating plans
under their purview, is consistent with their reporting on quality improvement strategies, as described in section 1311(g)
of the Affordable Care Act and codified in 45 CFR 156.1130(a), which provides consistency with other QHP reporting requirements
(89 FR 8890). Likewise, for these proposals, state Medicaid and CHIP FFS programs would report at the state level, Medicaid
managed care plans and CHIP managed care entities at the plan and program level, and QHP issuers on the FFEs at the issuer
level. Our proposed reporting levels and deadlines are summarized in Table 9.

As with the existing Patient Access API metrics (89 FR 8781), if we finalize this proposal, we do not plan to publicly report
these metrics at the contract, state, plan and program, or issuer level, but may reference or publish aggregated and de-identified
data that does not include names of specific payers or plans.

We are also not proposing a specific form or manner of reporting these metrics at this time but would issue specific format
and process guidance for submitting these metrics, should they be finalized.

We propose that, beginning in 2028, impacted payers be required to annually report Provider Access API usage metrics in the
form of aggregated, de-identified data. MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs
would be required to report these metrics directly to CMS and Medicaid managed care plans and CHIP managed care entities would
be required to report these metrics to states.

Specifically, impacted payers would be required to report the following metrics about their Provider Access API:

• The total number of unique providers who requested patient data via their Provider Access API.
• The total number of unique patients whose data were transferred via their Provider Access API to a provider's health IT system (for example, an EHR or health IT system).
• The total number of patient data transfers via their Provider Access API. In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, some commenters expressed skepticism that providers would use the Provider Access API (89 FR 8792 through 8794). We are proposing these metrics because we believe that they would give us valuable insight into how frequently the Provider Access API is being used. In addition, we believe that obtaining these metrics would be manageable for impacted payers and thus not present a substantial burden.

For the purposes of this proposal, payers must count each provider who queries the Provider Access API. As we established
in the 2024 CMS Interoperability and Prior Authorization final rule, the Provider Access API should be available to all providers,
whether they are an individual, a facility, or a group of providers who have come together as an accountable care organization
(ACO), who are appropriately licensed, provide items and services, or drugs eligible for coverage by the payer, and are enrolled
with the payer or in the payer's provider network. Though we do not require payers to share patient data with out-of-network
or unenrolled providers, we encourage them to do so to the extent permitted by law if they can verify a treatment relationship
(89 FR 8790 and 8791). This proposed approach ensures payers would comprehensively report all usage of the Provider Access
API, including out-of-network and unenrolled providers where applicable. We believe that impacted payers would be able to
obtain these metrics based on their records of which providers have been authenticated and authorized to receive requested
patient data. We also recognize, however, that there may be other ways for these payers to obtain these metrics, as well as
other outstanding factors that they would need to address to obtain the metrics that we may not be considering.

We propose that, beginning in 2028, impacted payers be required to annually report Payer-to-Payer API usage metrics in the
form of aggregated, de-identified data. MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs
would be required to report these metrics directly to CMS and Medicaid managed care plans and CHIP managed care entities would
be required to report these metrics to states.

Specifically, impacted payers would be required to report all of the following metrics about their Payer-to-Payer API:

• The percent of patients who have opted in to the payer to payer data exchange.
• The total number of unique patients whose data have been sent to other payers.
• The total number of unique patients whose data have been received from other payers. We believe that by monitoring the patient opt in rate, we could better understand patient receptiveness to payer to payer data exchange, as well as how impacted payers are implementing it. For example, this information may identify potential barriers to patient opt in, such as unclear patient educational resources.

We propose that, beginning in 2028, impacted payers would be required to annually report Prior Authorization API usage metrics
in the form of aggregated, de-identified data. MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on
the FFEs would be required to report these metrics directly to CMS and Medicaid managed care plans and CHIP managed care entities
would be required to report these metrics to states.

Specifically, impacted payers would be required to report all of the following metrics about their Prior Authorization API:

• The total number of unique providers who request a prior authorization for items, services, or drugs through their Prior Authorization API.
• The number of unique prior authorization requests for items, services, and drugs received through their Prior Authorization API.

• The percentage of all prior authorization requests that were received through their Prior Authorization API.
  We finalized a requirement in the 2024 CMS Interoperability and Prior Authorization final rule that impacted payers implement
  and maintain a Prior Authorization API to facilitate electronic prior authorization for providers to send prior authorization
  requests and receive decisions from payers. (246) While we strongly encourage

  providers to use the Prior Authorization API, specific requirements regarding provider adoption are implemented by other programs,
  such as the Electronic Prior Authorization measures in the MIPS Promoting Interoperability performance category and the Medicare
  Promoting Interoperability Program. We believe that these additional data regarding provider usage would complement the data
  we would eventually receive from MIPS eligible clinicians, eligible hospitals, and CAHs reporting the Electronic Prior Authorization
  measures under those programs (89 FR 8909 through 8927). Understanding how many providers are adopting the processes to send
  and receive electronic prior authorizations through the API would give CMS information to shape future interoperability and
  prior authorization policies.

In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following:

• The proposal to require impacted payers to report metrics about the usage of the Provider Access, Payer-to-Payer, and Prior Authorization APIs in the form of aggregated, de-identified data.
• The proposal to require MA organizations to report at the contract level, state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans and CHIP managed care entities to report at the plan and program level, and QHP issuers on the FFEs at the issuer level.

• The proposed compliance dates beginning in 2028 to report metrics from the 2027 reporting period, and the proposed reporting
  deadlines thereafter (summarized in Table 9).
  In addition, we request comments on the following:

• CMS's position that it does not plan to publicly report these metrics at the contract, state, plan and program, or issuer
  level, but may reference or publish aggregated and de-identified data that does not include names of specific payers or plans.

• With respect to the proposed Provider Access API usage metrics, the feasibility of separately reporting the total number
  of individual providers and groups of providers who request patient data via the Provider Access API, and whether we should
  finalize requirements for these payers to report separate metrics for individuals and groups of providers.

• With respect to the proposed Payer-to-Payer API usage metrics, whether we should disaggregate these metrics by data exchanges
  between an old and new payer and those between concurrent payers.

• Whether there are different metrics that we should consider requiring impacted payers to report.

• With respect to states reporting usage metrics to CMS via the APD process described in 45 CFR part 95, subpart F, whether
  there are existing or alternative reporting mechanisms for Medicaid and CHIP data for states to leverage to better facilitate
  the reporting process. Specifically, whether the use of an online portal or form would be simpler to meet the annual deadlines
  or whether a FHIR® server to automate reporting would be preferred, and what the anticipated level of burden would be.
  

3. Removing Drug Formulary Information From the Provider Access and Payer-to-Payer APIs

a. Background

In the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules, we
required that certain impacted payers make available information about their drug formularies through the Access APIs. MA-PDs
must make available drug formulary information, including covered Part D drugs and any tiered formulary structure or utilization
management procedure which pertains to those drugs. State Medicaid and CHIP FFS programs, Medicaid managed care plans, and
CHIP managed care entities must make available information about covered outpatient drugs, including, where applicable, preferred
drug list information. (247) We did not require QHP issuers on the FFEs to make drug formulary data available, as they are already required to provide
these data in

  a machine-readable format to CMS and post it on their websites. [(248)]()

b. Proposals

Upon further examination of this finalized policy, we determined that the inclusion of drug formulary data in the Provider
Access API and Payer-to-Payer API may be unnecessary and burdensome. We believe that providers already have sufficient access
to drug formulary information through other means, such as payer websites and standard payer communications materials, and
both impacted payers and patients would have little use for this information if they received it from a previous or concurrent
payer. We thus believe that the benefit of including drug formulary data in these APIs does not outweigh the additional effort
it would take impacted payers to make them available. Therefore, we propose to remove drug formulary information as data required
to make available via the Provider Access and Payer-to-Payer APIs for MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP managed care entities. If finalized, we propose that this would be effective beginning
on the effective date of the final rule. While we propose removing these data from our requirements, we remind impacted payers
that they would not be prohibited from continuing to include them should they see value in doing so. We emphasize that we
are not proposing to change the current requirement for MA organization, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, and CHIP managed care entities to make the required formulary information available via the Patient Access API.

In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following:

• The proposal to remove drug formulary information as data required to be made available via the Provider Access and Payer-to-Payer APIs for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities.

• The proposal to become effective beginning on the effective date of the final rule.
  In addition, we request comments on the following:

• Whether there are use cases where it would be helpful for any party to have access to drug formulary data via those APIs.

4. Denial or Discontinuation of Access to the Provider Directory API

a. Background

In the 2020 CMS Interoperability and Patient Access final rule and 2024 CMS Interoperability and Prior Authorization final
rule, we finalized requirements that impacted payers must implement and maintain Patient Access, Provider Access, Payer-to-Payer,
and Prior Authorization APIs conformant with certain technical standards, documentation requirements, and denial or discontinuation
policies (85 FR 25524 through 25559, 89 FR 8817, 8855, and 8897). We believe that consistently applying these requirements
to all of the APIs would minimize the cost and burden of implementation and support payer risk mitigation strategies. However,
we do not currently require the Provider Directory API, also finalized in the 2020 CMS Interoperability and Patient Access
final rule, to be conformant with the denial or discontinuation policies for the other APIs. (249) Specifically, those impacted payers may only deny or discontinue any third-party app's connection to the API if they (1) reasonably
determine, consistent with their security risk analysis required by the HIPAA Security Rule, that allowing an app to connect
or remain connected to the API would present an unacceptable level of risk to the security of PHI on their systems; and (2)
make this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and
developers through which parties seek to access electronic health information (EHI), as defined in 45 CFR 171.102, including
but not limited to, criteria that rely on automated monitoring and risk mitigation tools. (250) Because QHP issuers on the FFEs were already required to make provider directory information available in a specified, machine-readable
format, (251) we did not require them to make provider directory information available through an API.

b. Proposals

To align requirements across all APIs, we are now proposing that MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed care entities update their Provider Directory API policies to conform with the denial
or discontinuation policies that apply to the other APIs. We are proposing that impacted payers would be required to implement
that policy by the effective date of the final rule. We believe that those impacted payers should not have difficulty implementing
this policy change, as it would not require developing or modifying any technology but rather applying the same denial and
discontinuation policy that exists for other APIs to the Provider Directory API. However, we encourage the impacted payers
to whom this proposal applies to update their denial and discontinuation policy for the Provider Directory APIs as soon as
possible.

In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following:

• The proposal to require MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to update their Provider Directory APIs denial or discontinuation policies.
• The proposal to become effective beginning on the effective date of the final rule.

5. Other Amendments to Access API Requirements

a. Applicability Dates

In the 2020 CMS Interoperability and Patient Access final rule, we finalized requirements that impacted payers must implement
and maintain a Patient Access API beginning in 2021 (by January 1, 2021 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). We also
finalized a requirement that impacted payers make available through the Patient Access API the specified data they maintain
with a date of service on or after January 1, 2016 (85 FR 25558 through 25560). We finalized those requirements in an applicability
paragraph in 42 CFR 422.119 for MA organizations, 42 CFR 431.60 for state Medicaid FFS programs, 42 CFR 457.730 for state
CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for

  Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities,
  and 45 CFR 156.221 for individual market QHP issuers on the FFEs.

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements that impacted payers must implement
and maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs with compliance dates in 2027 (by January 1, 2027
for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027
for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027 for
individual market QHP issuers on the FFEs) (89 FR 8817, 8855, and 8897). We also finalized requirements that impacted payers
make available through the Provider Access API specified data they maintain with a date of service on or after January 1,
2016 and, through the Payer-to-Payer API, to exchange data they maintain with a date of service within 5 years of the request
(89 FR 8799 and 8855).

To simplify the regulatory text, we propose to incorporate the 2021 applicability date into the paragraph that includes the
Patient Access API requirements in 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, and 45 CFR 156.221(a) for QHP issuers on the FFEs. We further propose to incorporate
the requirement for impacted payers to make available data with a date on or after January 1, 2016 in 42 CFR 422.119(b)(1)
for MA organizations, 42 CFR 431.60(b) for state Medicaid FFS programs, 42 CFR 457.730(b) for state CHIP FFS programs, and
45 CFR 156.221(b)(1) for individual market QHP issuers on the FFEs. These proposals would not change any existing requirements
or impose any new requirements.

Because the requirements for the Provider Access and Payer-to-Payer APIs cross reference to the accessible content available
through the Patient Access API, we believe that this would simplify and explain the regulatory requirements for all three
of these APIs. This proposal would become effective beginning on the effective date of the final rule.

In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following:

• The proposal to incorporate the existing Patient Access API 2021 implementation date into 42 CFR 422.119(a), 42 CFR 431.60(a), 42 CFR 457.730(a), and 45 CFR 156.221(a).
• The proposal to incorporate the existing requirement for impacted payers to make available data with a date on or after January 1, 2016 into 42 CFR 422.119(b)(1), 42 CFR 431.60(b), 42 CFR 457.730(b), and 45 CFR 156.221(b)(1).
• The proposal to become effective beginning on the effective date of the final rule.

b. Exceptions for QHP Issuers on the FFEs

In the preambles to the 2022 CMS Interoperability and Prior Authorization proposed rule and 2024 CMS Interoperability and
Prior Authorization final rule, we discussed that issuers seeking to offer QHPs on the FFEs that submit an exception request
would have to describe the effect of non-compliance upon enrollees, providers, and payers and the current or proposed means
of providing the required information to providers or other payers, as applicable to each API (87 FR 76263, 87 FR 76281, and
89 FR 8905). However, the regulatory text in 45 CFR 156.222(c)(1)(iii) only requires QHP issuers on the FFEs that are applying
for an exception to describe the impact of non-compliance on providers and enrollees and the current or proposed means of
providing health information to payers.

Therefore, we propose to amend 45 CFR 156.222(c)(1)(ii) and 45 CFR 156.222(c)(1)(iii) to incorporate the requirement to describe
the impact on all applicable parties. Specifically, we propose to amend 45 CFR 156.222(c)(1)(ii) to require QHP issuers on
the FFEs applying for an exception describe the impact of non-compliance upon enrollees and providers, if the exception request
is for the Provider Access API, or upon enrollees and payers, if the exception request is for the Payer-to-Payer API. In addition,
we propose to amend 45 CFR 156.222(c)(1)(iii) to refer to the current or proposed means of providing health information to
providers if the exception is for the Provider Access API, or to other payers if the exception request is for the Payer-to-Payer
API. Similarly, we propose to amend 45 CFR 156.223(i)(1)(iii) to require QHP issuers on the FFEs that apply for an exception
to describe the current or proposed means of providing prior authorization coverage and documentation requirements and facilitating
prior authorization requests and decisions.

In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following:

• The proposal to amend language in 45 CFR 156.222(c)(1)(ii) and 45 CFR 156.222(c)(1)(iii), and 45 CFR 156.223(i)(1)(iii) to require QHP issuers on the FFEs applying for an exception to describe the impact of non-compliance on all applicable parties.

6. Federal Matching Funds

In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that we expected that states operating state
Medicaid and CHIP FFS programs would be able to access federal matching funds to support their implementation of the required
APIs (89 FR 8907). We explained that all of the required APIs would support the efficient data exchange and prior authorization
processes, consistent with sections 1902(a)(4) and 2101(a) of the Act. Similarly, FFP could be available for state expenditures
to meet the proposals in this proposed rule at a rate of 50 percent under section 1903(a)(7) of the Act for the proper and
efficient administration of the Medicaid state plan.

Furthermore, as with requirements in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8907), state
expenditures to implement certain proposals in this proposed rule could be eligible for 90 percent enhanced FFP under section
1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, and installation of mechanized
claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP, under section 1903(a)(3)(B) of
the Act, could be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval
systems. States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process
described in 45 CFR part 95, subpart F. Additionally, 42 CFR 433.112(b)(12) and 42 CFR 433.116(c) require that any system
for which states are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the
ONC Health IT standards adopted in 45 CFR part 170, subpart B. The proposals that would require API implementation or enhancement
in this proposed rule complement this requirement to support interoperability by using standards adopted by ONC.

Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618 limiting administrative costs to no more
than 10 percent of a state's total computable expenditures for a FY

  would apply to administrative claims for complying with the proposals in this proposed rule, if finalized.

7. Statutory Authorities

a. Medicare Advantage Organizations

For MA organizations, we are proposing the new requirement to add information about prior authorizations for drugs to the
Access APIs under our authority at the following sections of the Act:

• Section 1856(b)(1) of the Act, which requires the Secretary to promulgate regulations implementing MA standards, including the requirements in section 1852(h) of the Act for MA organizations that maintain medical records or other health information about enrollees to maintain such records in a manner that is accurate and timely and to ensure access for enrollees to such records and information.
• Section 1857(e)(1) of the Act, which authorizes the Secretary to add contract terms determined by the Secretary to be necessary and appropriate and not inconsistent with the requirements in Part C of Title XVIII of the Act (that is, Part C of the Medicare statute).
• Section 1852(d)(1)(A) of the Act, which requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner which assures continuity in the provision of benefits.

(1) Patient Access API

The Patient Access API proposal in section II.E.1.b. of this proposed rule that would require MA organizations to make an
enrollee's prior authorization requests and related clinical documentation for drugs available through the APIs, would, if
finalized as proposed, allow these enrollees to have access to that information in a convenient, timely, secure, and portable
way, which is in enrollees' best interests. This proposed requirement is consistent with section 1852(h) of the Act. It is
essential for CMS to ensure that each MA organization has a standardized system in place that offers enrollees access to their
own data, including data that pertain to their prior authorizations for drugs, using existing and emerging technologies of
their choice, specifically in this case, health apps. Therefore, making these data available through the Patient Access API
is consistent with our programmatic authority to establish standards to implement section 1852(h) of the Act, and could encourage
patients to be more active participants in their own care, which could potentially lead to better health outcomes.

Making this information available via the Patient Access API could help enrollees support the prior authorization process,
as well. Enrollees could see what information is needed and what information has been provided on their behalf to facilitate
a prior authorization request. Enrollees, using a third-party app, could monitor the process and give their provider any missing
information needed by the payer to reach a decision. This could allow MA organizations to address prior authorization requests
more promptly, streamlining this process, and thus simplifying prior authorization for the MA organizations. This could also
improve an enrollee's experience with the process, by facilitating timelier and potentially more successful initial prior
authorization requests. This, again, supports efficient operation and timely provision of information and services.

(2) Provider Access API

For the Provider Access API, our proposals would provide a mechanism for providers to access information about pending, approved,
or denied prior authorization requests for all drugs in a timely and efficient manner. As noted in this section of this proposed
rule, these regulations are consistent with and facilitate the requirements in section 1852(d)(1)(A) of the Act that MA organizations,
as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner which
assures continuity in the provision of benefits. The Secretary has authority under section 1856(b)(1) of the Act to promulgate
regulations implementing MA standards, including the requirements in section 1852(d)(1)(A) of the Act. As previously stated,
the Secretary also has authority under section 1857(e)(1) of the Act to add new contract terms, including additional standards
and requirements, for MA organizations that the Secretary finds necessary and appropriate and that are not inconsistent with
Part C of the Medicare statute.

In implementing section 1852(d)(1)(A) of the Act, we previously adopted a regulation, in 42 CFR 422.112(b)(4), that requires
MA organizations offering coordinated care plans to ensure the continuity of care and integration of services through arrangements
with providers that include procedures to ensure that the MA organization and the contracted providers have access to the
information necessary for effective and continuous patient care. This proposal to expand the scope of information available
to providers through the Provider Access API aligns with, and provides a means for, MA organizations to comply with that existing
regulatory requirement. Our proposal for MA organizations to add prior authorization information for all drugs to their existing
Provider Access API would facilitate exchanges of information about enrollees that are necessary for effective and continuous
patient care, which is consistent with the requirement in section 1852(d)(1)(A) of the Act for assuring continuity in the
provision of benefits. In addition, if a patient moves from one provider to another, the new provider would be able to ensure
continuity of care if they are able to access additional relevant health information about the patient (such as prior or existing
prior authorization approvals and denials) from the MA organization in an efficient and timely way. The inclusion of prior
authorization information for drugs in the Provider Access API could support this; thus, the proposal would carry out and
be consistent with the Part C statute.

This proposal would complement and align with MA organization obligations in 42 CFR 422.112(b)(4) by providing more information
through the Provider Access API, which could further support effective and continuous patient care. The inclusion of drug
prior authorization information in the API would make the Provider Access API an even more effective and efficient way to
fulfill program requirements. Adding this information could increase the efficiency and simplicity of administration. It would
give providers access to more of their patients' information with limited effort, and it could reduce the amount of time needed
during provider visits to establish a patient's prior history, which could introduce efficiencies and improve care. This proposal
would also allow for better access to prior authorization decisions for all drugs requested by other providers for the patient,
which could give a provider a more holistic view of a patient's care and reduce the likelihood of ordering duplicate or misaligned
services. Ultimately, we anticipate that sharing more patient information through an established Provider Access API would
ensure that providers receive patient information in a timely manner and could lead to more appropriate service utilization
and higher patient satisfaction. Thus, the proposed inclusion of drug prior authorization data in the Provider Access API
would be necessary and appropriate for the MA program and consistent with existing requirements.

(3) Payer-to-Payer API

For the Payer-to-Payer API, the exchange of drug prior authorization data about enrollees could further

  facilitate continuity of care and enhance care coordination. Thus, the proposal for payers to share additional information
  could apply as well to data exchanges using the Payer-to-Payer API. It could give payers access to more of their enrollees'
  information with limited effort and enable the subsequent or other concurrent payer to then make that information available
  to providers and to enrollees through the Provider Access and Patient Access APIs. It could reduce the amount of time needed
  to evaluate a patient's current care plan and possible implications for care continuity, which could introduce efficiencies
  and improve care. If a new payer is able to receive information and documentation about prior authorization requests for drugs
  from a previous payer (for example, from a previous plan year), the new payer could review this information and determine
  that a new prior authorization review may not be necessary for a drug that was previously approved. Instead, the same care
  could be continued, reducing burden on both payers and providers and improving patient care, 42 CFR 422.112(b)(8)(i)(B) further
  requires coordinated care plans to provide a minimum 90-day transition period when an enrollee currently undergoing treatment
  switches to a new MA plan, during which the new MA plan may not require prior authorization for the active course of treatment. [(252)]() The proposed policy would, taken together with both the “Medicare Program; Contract Year 2024 Policy and Technical Changes
  to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of
  All-Inclusive Care for the Elderly” final rule (88 FR 22120), which appeared in the 
  Federal Register
  on April 12, 2023, and the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8758), continue to support
  an even more streamlined process for prior authorization in the MA program, which would ultimately lead to reduced burden
  in health care. While the statutory provisions governing the MA program do not explicitly address sharing data with other
  payers that cover or have covered an enrollee, the benefits to be gained by sharing more data make adoption of this proposal
  necessary and appropriate for the MA program. Further, requiring the inclusion of drug prior authorization information in
  the existing Payer-to-Payer API and the specifications for data to be shared provides a step toward greater interoperability
  among payers. Ultimately, the inclusion of this information could lead to more appropriate service utilization and higher
  beneficiary satisfaction. This proposal would facilitate the exchange of enrollee information necessary for continuity of
  care, consistent with the requirements of section 1852(d)(1)(A) of the Act, which mandates that MA organizations provide enrollees
  with access to covered services in a manner that ensures continuity of care. The enhanced data sharing through the Payer-to-Payer
  API directly supports this statutory obligation by enabling seamless transitions between plans and reducing disruptions in
  treatment regimens. CMS is proposing this requirement under its authority pursuant to section 1856(b) of the Act to adopt
  standards consistent with, and to carry out, the Part C statute, including the continuity of care provisions in section 1852(d)(1)(A).
  Additionally, CMS has authority under section 1857(e)(1) of the Act to establish contract terms and conditions that ensure
  MA organizations meet their obligations to enrollees. By requiring the inclusion of drug prior authorization information in
  payer to payer data exchanges under these statutory authorities, this proposal would create a more integrated health care
  system that prioritizes beneficiary needs while maintaining appropriate oversight of MA plan operations.

(4) Reporting Provider Access, Payer-to-Payer, and Prior Authorization API Metrics

In addition, to ensure the requirements proposed here and finalized in the 2024 CMS Interoperability and Prior Authorization
final rule would be most effective, CMS proposes in this rule that MA organizations report specific metrics to CMS on enrollee
and provider use of the Provider Access, Payer-to-Payer, and Prior Authorization APIs. Section 1857(e)(1) of the Act authorizes
the Secretary to adopt additional MA contract terms and conditions, including required reporting by MA organizations, where
necessary and appropriate and not inconsistent with Part C of the Medicare statute. Here, required reporting of these proposed
metrics would facilitate CMS's oversight, evaluation, and administration of patient health data access in the Part C program
and therefore, these data collections are necessary and appropriate to adopt.

To the extent that the proposals discussed in this section apply to prior authorization information for Part D drugs offered
by MA-PD plans, we are also relying on our authority under sections 1857(e)(1) and 1860D-12(b)(3)(D) of the Act. Section 1860D-12(b)(3)(D)
of the Act provides that MA-PD plans are subject to the requirements of section 1857 of the Act to the extent the Secretary
determines appropriate. Together, these authorities support CMS's proposal to require MA-PD plans to make information about
prior authorization requests and decisions for Part D drugs available through the Access APIs.

b. Medicaid

Our proposed requirements in this section for state Medicaid FFS programs and Medicaid managed care plans fall generally under
the authority in all of the following provisions of the statute:

• Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan.
• Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals.
• Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.
• Section 1932(b)(4) of the Act, which provides that each Medicaid MCO (and PIHP and PAHP, which this section of the Act extends to through regulations based on our authority under section 1902(a)(4) of the Act) must establish an internal grievance procedure under which a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. • Section 1932(c)(1)(A) of the Act, which requires states that contract with Medicaid MCOs (and extended to PIHPs and PAHPs through regulations based on our authority under section 1902(a)(4) of the Act), to develop and implement a quality assessment and improvement strategy that includes standards for access to care so that covered services are available within reasonable timeframes and in a manner that ensures continuity of care and adequate primary care and specialized services capacity and procedures for monitoring and evaluating the quality and appropriateness of care and services to enrollees and requirements for provision of quality assurance data to the state.

(1) Patient Access API

For the Patient Access API, we expect that beneficiaries would more easily obtain information about the status of prior authorization
requests for drugs submitted on their behalf. Beneficiaries could potentially use that information to make more informed decisions
about their health care, and, if needed and desired by the beneficiary, provide missing information to their provider that
the state (or Medicaid managed care plan, if applicable) needs to reach a decision. Receiving missing information more quickly
could enable more prompt responses from state Medicaid FFS programs and Medicaid managed care plans to drug prior authorization
requests, thus facilitating more timely and successful prior authorizations, which would help states fulfill their obligations
to provide care and services in a manner consistent with simplicity of administration and the best interests of the recipients,
and to furnish services with reasonable promptness to all eligible individuals. Improving the prior authorization process
could also improve the efficient operation of the state plan by potentially improving the speed and consistency of prior authorizations,
which could, in turn, facilitate faster access to care for beneficiaries. In these ways, these proposals are consistent with
section 1902(a)(4), (8), and (19) of the Act.

In addition, the proposal for the Patient Access API would implement section 1932(b)(4) of the Act. CMS has traditionally
extended requirements applicable to Medicaid MCOs via regulations to other Medicaid managed care plan types as efficient and
proper methods of administration under section 1902(a)(4) of the Act to ensure that Medicaid beneficiaries have the same protections,
benefits, and responsibilities regardless of the type of managed care plan in which they are enrolled. Allowing beneficiaries
to access the status of their denied drug prior authorization requests within 1 business day could enable beneficiaries to
file appeals timelier and receive faster resolution. Enabling beneficiaries to monitor the status of drug prior authorization
requests submitted on their behalf is also consistent with section 1932(c)(1)(A) of the Act. Knowing within 1 business day
that a prior authorization has been approved could enable a beneficiary to more promptly schedule or obtain care.

Finally, section 1902(a)(7) of the Act requires that a state's plan for medical assistance provides safeguards which restrict
the use or disclosure of information concerning applicants and beneficiaries, (253) in relevant part, to purposes directly connected with the administration of the plan. Our implementing regulations in 42 CFR
part 431, subpart F set forth certain purposes that CMS has determined are directly connected to Medicaid state plan administration
(42 CFR 431.302) and requirements for states to safeguard Medicaid applicants' and beneficiaries' information in accordance
with section 1902(a)(7) of the Act. Our regulations in 42 CFR part 431, subpart F include requirements for safeguarding the
information, what types of information must be safeguarded, and when and how to release otherwise safeguarded information.

Our proposal to require that the drug prior authorization data described in this section be shared via the Patient Access
API would be consistent with the requirement that states may share these data only for purposes directly connected to the
administration of the Medicaid state plan, since providing beneficiaries with their own data could directly affect their ability
to receive appropriate Medicaid services, a permissible purpose listed in 42 CFR 431.302(c). As mentioned in the 2024 CMS
Interoperability and Prior Authorization final rule, giving a patient access to their own health information can make them
a more active participant in ensuring they receive timely and appropriate care (89 FR 8785).

(2) Provider Access API

For the Provider Access API, a requirement for states to include information about prior authorizations for drugs could improve
states' ability to ensure that care and services are provided in a manner consistent with simplicity of administration, and
to cover services more efficiently. The proposal would support efficient and prompt delivery of care, which would be in the
beneficiaries' best interests. This proposal would also be expected to give providers better access to prior authorization
decisions for care provided by other enrolled Medicaid providers, which would give a provider a more holistic view of a patient's
care and reduce the likelihood of ordering duplicate or misaligned drugs. This could also facilitate easier and more informed
decision-making by the provider and would therefore support efficient coverage decisions in the best interest of patients.
The inclusion of drugs would result in a more complete picture of the patient to the provider at the point of care, which
could improve the quality and efficiency of a patient visit, thus enabling the provider to treat more patients. These outcome
and process efficiencies could help states fulfill their obligations to ensure prompt access to services that are in the best
interest of beneficiaries, consistent with sections 1902(a)(8) and (19) of the Act, and the efficiencies created for providers
might help the state administer its Medicaid program more efficiently, consistent with section 1902(a)(4) of the Act. These
analyses apply similarly to state Medicaid FFS programs and Medicaid managed care plans and delivery systems, so we are exercising
our authority to adopt regulatory requirements for adding prior authorization data for all drugs to the Provider Access API
for both state Medicaid FFS programs and Medicaid managed care plans.

Finally, consistent with section 1902(a)(7) of the Act and our implementing regulations in 42 CFR part 431, subpart F, any
request for beneficiary information via the Provider Access API would be from an enrolled Medicaid provider and for purposes
directly connected with the administration of the state plan. An enrolled Medicaid provider would have a provider agreement
with the state Medicaid agency in order to provide Medicaid benefits and services under its state plan. As such, enrolled
Medicaid providers are part of the state's Medicaid program, assisting the state agency in carrying out core functions of
the state's Medicaid state plan, providing benefits and services to beneficiaries. Therefore, the state Medicaid agency would
not be required to obtain additional consent (beyond the beneficiary not opting out of sharing the specified data via the
Provider Access API, as finalized in 42 CFR 431.61(a)(4)) from the beneficiary or their authorized representative, as generally
required under 42 CFR 431.306(d), (254) prior to sharing the individual's information with a requesting Medicaid provider. However, the state Medicaid agency would
continue to be required to provide the beneficiary or their authorized representative an opportunity to opt out of sharing
the specified data via the Provider Access API, as finalized in the 2024 CMS

  Interoperability and Prior Authorization final rule (89 FR 8817 and 8978). [(255)]()

While the beneficiary's permission would not be required under 42 CFR 431.306(d) for the Provider Access API proposals we
discuss here, other laws or regulations, such as the regulations that address the confidentiality of substance use disorder
patient records in 42 CFR part 2, may require such permission.

(3) Payer-to-Payer API

For the Payer-to-Payer API, these proposals are consistent with sections 1902(a)(4), (a)(8), and (a)(19) of the Act for the
following reasons. First, because the Payer-to-Payer API is designed to enable efficient exchange of data between payers,
we anticipate that adding information about prior authorizations for drugs would help state Medicaid FFS programs improve
the efficiencies and simplicity of their own operations, consistent with sections 1902(a)(4) and (a)(19) of the Act. It could
give Medicaid and CHIP agencies and their managed care plans access to more of their beneficiaries' information in a standardized
manner and enable the state to then make that information available to providers and to patients through the Patient Access
and Provider Access API. It could also reduce the amount of time needed to evaluate a patient's current care plan, which could
in turn introduce efficiencies and improve care.

As discussed in the 2022 CMS Interoperability and Prior Authorization proposed rule, if a state Medicaid FFS program has access
to a previous payer's prior authorization decisions, the Medicaid program could choose to accept the existing decision and
support continued patient care without requiring a new prior authorization or duplicate tests (87 FR 76284).

This information exchange might also improve care continuity for beneficiaries who have concurrent coverage in addition to
Medicaid by improving the coordination of health coverage they receive, reducing gaps, or duplication of coverage.

Our proposal, if finalized, is expected to help states and Medicaid managed care plans furnish Medicaid services with reasonable
promptness and in a manner consistent with beneficiaries' best interests, consistent with sections 1902(a)(8) and (a)(19)
of the Act. A significant portion of Medicaid beneficiaries experience coverage changes and churn each year. (256) Therefore, exchanging more information with a beneficiary's next payer could also better support care continuity for Medicaid
beneficiaries. If states were to share information about Medicaid beneficiaries or former beneficiaries with their concurrent
and next payers, they could support opportunities for improved care coordination for Medicaid beneficiaries and former beneficiaries.
Exchanging information about Medicaid beneficiaries and former beneficiaries between payers might also reduce the amount of
time needed to evaluate beneficiaries' current care plans, their health risks, and their health conditions at the time they
enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to
improve care continuity for beneficiaries who might churn into and out of Medicaid coverage. The proposal could also improve
the provision of Medicaid services, by potentially helping to ensure that Medicaid beneficiaries who may require coordinated
services with concurrent payers could be identified and provided case management services, reduce duplication of drugs, and
improve the coordination of care, as appropriate.

For Medicaid managed care plans, the proposed exchange of the patient's drug prior authorization requests and decisions would
greatly enhance an MCO's, PIHP's, or PAHP's ability to fulfill its obligations under 42 CFR 438.208(b) to implement procedures
to deliver care to and coordinate services for all enrollees, including coordinating services between settings of care, with
services an enrollee receives from any other MCO, PIHP, or PAHP, with services an enrollee receives in FFS Medicaid, and with
services an enrollee receives from community and social support providers. The proposed additional data provided via the Payer-to-Payer
API in this rule would give Medicaid managed care plans more information needed to perform these required functions more easily,
thus enhancing the effectiveness of the care coordination, and helping beneficiaries receive the most appropriate care in
an effective and timely manner.

(4) Reporting Provider Access, Payer-to-Payer, and Prior Authorization API Metrics

We are also proposing to require state Medicaid agencies and Medicaid managed care plans to report Provider Access, Payer-to-Payer,
and Prior Authorization APIs metrics to CMS annually. We believe that having these metrics would support CMS's oversight,
evaluation, and administration of the Medicaid program, as it would allow us to evaluate beneficiary and provider use to these
APIs. Use of these APIs could indicate that the policies are supporting program efficiencies and ensuring access to information
in a timely and efficient way and in the best interest of beneficiaries, as intended, and as is consistent with sections 1902(a)(4)
and (19) of the Act. Additionally, section 1902(a)(6) of the Act requires Medicaid state plans to provide that the state Medicaid
agency will make such reports, in such form and containing such information, as the Secretary may from time to time require.
These metrics would serve as a report to evaluate the implementation and execution of the Provider Access, Payer-to-Payer,
and Prior Authorization APIs.

c. CHIP

Our proposed requirements in this section for CHIP generally fall under the authority in section 2101(a) of the Act, which
states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured,
low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage.
We believe the proposed requirements could strengthen states' abilities to fulfill these statutory obligations under Title
XXI of the Act in a way that would recognize and accommodate the use of electronic information exchange in the health care
industry today and would facilitate a significant improvement in the delivery of quality health care to CHIP beneficiaries.

Additionally, the requirements to safeguard applicant and beneficiary information in 42 CFR part 431, subpart F (which implement
section 1902(a)(7) of the Act) are also applicable to CHIP for each of the Access APIs through a cross reference in 42 CFR
457.1110(b). Finally, section 2107(b)(1) of the Act requires that state child health plans include an assurance that the state
will collect the data, maintain the records, and furnish the reports to the Secretary, at the times and in the standardized
format the Secretary may require in order to enable the Secretary to monitor state program administration and compliance and
to evaluate and compare the effectiveness of state plans under this title.

(1) Patient Access API

For the Patient Access API, this provision provides us with authority to adopt these requirements for CHIP because the proposed
requirements increase the access of patients and of the parents/legal guardians (or personal representatives) of minor patients
to their health information, which can improve the efficacy of CHIP programs, allow for more efficient communication and administration
of services, and promote coordination across different sources of health benefits coverage.

We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP beneficiaries' drug prior authorization
data available to these beneficiaries or their personal representatives (usually the parent or guardian of a minor child)
through the existing Patient Access API would ultimately lead to these beneficiaries or personal representatives accessing
that information in a convenient, timely, and portable way. This improved access would help administer services effectively,
efficiently, and in the best interests of beneficiaries, consistent with the requirements in section 2101(a) of the Act. We
believe making these additional data available would result in better health outcomes and patient satisfaction and improve
the cost effectiveness of the entire health care system, including CHIP.

These proposals also align with section 2101(a) of the Act in that they also would improve the efficiency of CHIP programs.
Adding information about drug prior authorization requests to the Patient Access API would allow beneficiaries or their personal
representatives to easily obtain the status of prior authorization requests made on their behalf. This would in turn allow
patients or their personal representatives to make scheduling decisions, and provide any missing information needed by a payer
to reach a decision, which makes the prior authorization process more efficient, and ultimately streamlining the entire process.

(2) Provider Access API

For the Provider Access API, when providers have access to more prior authorization information—namely, that information about
drugs—from payers or other health IT systems, they can provide higher quality care. Improving the quality of care aligns with
section 2101(a) of the Act, which requires states to provide CHIP services (via either state CHIP FFS programs or CHIP managed
care entities) in an effective and efficient manner. The more information a provider has to make informed decisions about
a patient's care, the more likely it is that patients would receive care that best meets their needs. Additionally, providers
could be more effective and efficient in their delivery of CHIP services by having direct access to prior authorization information.
If a provider has more drug information about a patient prior to or at the point of care, the provider would be able to spend
more time focused on the patient, rather than on their need to collect information. In addition, the information that providers
do collect would not be based solely on patient or personal representative recall. This could save time, improve the quality
of care, and increase the total amount of direct care provided to CHIP beneficiaries. When data are standardized, and able
to be incorporated directly into the provider's EHR or health IT system, they can be leveraged as needed at the point of care
by the provider and also can be used to support coordination across providers and payers. This is inherently more efficient,
and ultimately, more cost-effective, as the information does not have to be regularly repackaged and reformatted to be shared
or used in a valuable way. As such, the Provider Access API proposals also align with section 2101(a) of the Act in that these
proposals could improve coordination between either CHIP agencies or CHIP managed care entities and other health coverage.
For these reasons, we believe this proposal is in the best interest of the beneficiaries and within our long-established statutory
authorities.

(3) Payer-to-Payer API

For the Payer-to-Payer API, the current payer could use data from the previous payer to respond to a request for a prior authorization
more effectively or accurately, because under this proposal, a new payer would have drug prior authorization information along
with the currently required historical claims and clinical data upon which they may review a request with more background
data. Access to more information about new patients could enable appropriate staff within the CHIP program, whether it is
a state CHIP FFS program or CHIP managed care entity, to coordinate care and conduct care management more effectively because
they would have more data available to make decisions for planning. In many cases, patients or their personal representatives
do not remember the drugs they were prescribed or other possibly relevant encounters that could help payers manage their care.
This proposal is consistent with the goal of providing more informed and effective care coordination, which could help to
ensure that CHIP services are provided in a way that supports quality care, which aligns with section 2101(a) of the Act.

Additionally, the requirements to safeguard applicant and beneficiary information in 42 CFR part 431, subpart F are also applicable
to CHIP through a cross reference in 42 CFR 457.1110(b). As discussed previously for Medicaid, CHIP agencies' data exchange
through the Access APIs would be related to providing services to beneficiaries, which is described in 42 CFR 431.302(c) as
a purpose directly related to state plan administration.

(4) Reporting Provider Access, Payer-to-Payer, and Prior Authorization API Metrics

Finally, proposing to require state CHIP agencies and CHIP managed care entities to report Provider Access, Payer-to-Payer,
and Prior Authorization API metrics to CMS annually would help states and CMS understand how these APIs can be used to continuously
improve the effectiveness and efficiency of state CHIP operations by providing information about their use, which is an indication
of the APIs' uptake among patients (or their personal representatives) and providers, including how many only use it for a
one-time setup, consistent with section 2107(b)(1) of the Act. The more we understand about the use of the Provider Access,
Payer-to-Payer, and Prior Authorization APIs, the better we can assess that the APIs are leading to improved operational efficiencies
and providing information to beneficiaries (or their personal representatives) and providers in a way that supports their
best interests.

d. Qualified Health Plan Issuers on the Federally-facilitated Exchanges

For QHP issuers on the FFEs, we propose these new requirements for the Access APIs under our authority in section 1311(e)(1)
of the Affordable Care Act. Section 1311(e)(1)(A) of the Affordable Care Act requires that Exchanges only certify plans as
QHPs if they meet the requirements for certification promulgated by the Secretary under section 1311(c)(1) of the Affordable
Care Act, while section 1311(e)(1)(B) of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines
that making available such plans available is in the interests of qualified individuals and qualified employers in the state
or states in which such Exchange operates.

(1) Patient Access API

For the Patient Access API, we believe generally that certifying only health plans that take steps to make qualified individuals'
and qualified employers' prior authorization requests for drugs and related clinical documentation available through interoperable
technology (unless they have been granted an exception under 45 CFR 156.221(i)) would ultimately lead to these qualified individuals
and qualified employers having access to that information in a convenient, timely, and portable way, which is in qualified
individuals' and qualified employers' best interests. Adding information about prior authorization requests for drugs to the
Patient Access API would allow qualified individuals and qualified employers to more easily obtain the status of prior authorization
requests submitted on their behalf and use that information effectively to make more informed decisions about their health
care, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information needed by the
QHP issuer on the FFEs to reach a decision on a prior authorization request. This could allow QHP issuers on the FFEs to more
promptly address drug prior authorization requests. This would also facilitate timelier and potentially more successful initial
prior authorization requests. We encourage SBEs, including SBE-FPs, to consider whether a similar requirement should be applicable
to issuers participating in their Exchanges.

(2) Provider Access API

For the Provider Access API, we believe that certifying only health plans that make enrollees' health information available
to their providers (unless they have been granted an exception under 45 CFR 156.222(c)) is in the interests of enrollees.
Giving providers access to their patients' information supplied by QHP issuers on the FFEs would ensure that providers are
better positioned to provide enrollees with seamless and coordinated care and could reduce duplicate prescriptions or delays
in care and diagnosis. Access to the patient's more complete medical information could also maximize the efficiency of an
enrollee's office visits. We encourage SBEs, including SBE-FPs, to consider whether a similar requirement should be applicable
to issuers participating in their Exchanges.

(3) Payer-to-Payer API

For the Payer-to-Payer API, we believe that adding more information to this existing API would reduce administrative burden
and result in more timely and efficient care coordination and responses to prior authorization requests. We believe it is
in the interest of qualified individuals and qualified employers that QHP issuers on FFEs continue to have systems in place
that send information that is important to care coordination with departing enrollees, and that QHP issuers on FFEs also have
systems in place to receive such information from payer to payer on behalf of new and concurrent enrollees, as appropriate
and consistent with the proposals in this section. Therefore, we believe certifying health plans that make enrollees' health
information available to other payers (unless they have been granted an exception under 45 CFR 156.222(c)) in a convenient,
timely, and portable way is in the interests of qualified individuals and qualified employers in the state in which an FFE
operates.

(4) Reporting Provider Access, Payer-to-Payer, and Prior Authorization API Metrics

Finally, proposing to require QHP issuers on the FFEs to report Provider Access, Payer-to-Payer, and Prior Authorization API
metrics to CMS annually would help CMS assess the effect these APIs are having on enrollees and providers. In addition, those
data would inform how CMS could either enhance the policies or improve access or usage, whether through activities, such as
additional patient and provider education, or additional rulemaking. These data could help CMS understand how best to leverage
these APIs, improve meaningful patient and provider access to data, ensure these requirements are being met efficiently, and
are adding value to QHP operations, including leading to the efficiencies intended.

G. Open Payments Civil Monetary Penalties

1. Open Payments Policies

a. Background

The Open Payments program (257) is a statutorily mandated program that promotes the transparency of pharmaceutical and medical device industry financial relationships
with certain types of health care providers by providing the public with certain payment or transfer of value information.
Section 1128G of the Act, and implementing regulations promulgated in the “Medicare, Medicaid, Children's Health Insurance
Programs; Transparency Reports and Reporting of Physician Ownership or Investment Interests” final rule (78 FR 9458) (hereinafter
referred to as the “Open Payments final rule”), which appeared in the
Federal Register
on February 8, 2013, require manufacturers of covered drugs, devices, biologicals, or medical supplies (hereafter referred
to as “applicable manufacturers”), as well as applicable GPOs, to annually submit information for the preceding calendar year
about certain payments or other transfers of value made to “covered recipients,” originally defined as physicians and teaching
hospitals. (258) On October 24, 2018, the SUPPORT Act was signed into law. Section 6111 of the SUPPORT Act broadened the definition of “covered
recipient” in section 1128G(e)(6)(A) of the Act to add physician assistants (PAs), nurse practitioners (NPs), clinical nurse
specialists (CNSs), certified registered nurse anesthetists (CRNAs), anesthesiologist assistants, and certified nurse midwives
(CNMs). The rulemaking in 84 FR 62568, which appeared in the
Federal Register
on November 15, 2019, codified that definition in 42 CFR 403.902 and made additional reporting clarifications and updated
several Nature of Payment Categories and standardized product information such as mandating unique device identifiers.

Payments or other transfers of value that must be reported include, but are not limited to, such things as research-related
payments, honoraria, gifts, travel expenses, meals, grants, and other compensation. (259) The type of information required to be reported includes, but is not limited to, the date and amount of the payment or other
transfer of value, identifying information about the covered recipient, and details about products associated with the transaction. (260) When a payment or other transfer of value is related to marketing, education, or research specific to a covered drug, device,
biological, or medical supply, the name of that covered drug, device, biological, or medical supply also must be reported. (261)

Section 1128G of the Act establishes certain minimum dollar thresholds for required reporting of individual and aggregate
payments or transfers of value. To determine if multiple small individual payments or other transfers of value made to a covered
recipient exceed the de minimis reporting threshold, applicable manufacturers and

  applicable GPOs must aggregate all individual payments made across all payment categories within a given reporting year. The
  initial (calendar year 2013) reporting thresholds were $10 for individual payments or other transfers of value and $100 for
  aggregated payments. The statute requires the reporting threshold to be annually increased by the consumer price index for
  the preceding 12-month period ending in June of the previous year. [(262)]() The calendar year 2025 thresholds are $13.46 for individual payments or other transfers of value and $134.54 for aggregate
  payments. [(263)]()

The Open Payments program yields information about providers for the general public and researchers may use Open Payments
data to study whether there may be any relation between provider behavior and their financial relationships. This information
is collected and published on an annual cycle, with the data annually becoming public by June 30. The Open Payments program
has made public more than 118.2 million records between its August 2013 start and the June 2024 publication cycle, enabling
significant transparency into applicable exchanges of value. We are committed to stakeholder engagement in an effort to limit
the Open Payments program reporting burden and improve clarity for the public. The estimated burden of these reporting requirements,
as outlined under the Office of Management and Budget (OMB) control number 0938-1237, is approximately 1.9 million hours over
the course of 1 year. Additional background about the program and guidance, including frequently asked questions, regarding
how the program works and what type of information is required to be reported is available at https://www.cms.gov/priorities/key-initiatives/open-payments.

Section 1128G(e)(10)(A) of the Act defines the term “payment or other transfer of value” as a transfer of anything of value,
though some exclusions apply, while sections 1128G(e)(4) and (5) of the Act define covered drugs, devices, biologicals, or
medical supplies as those covered under Medicare, a state plan under Medicaid or CHIP (or a waiver of either such state plan).
Section 1128G(a) of the Act requires applicable manufacturers and applicable GPOs to disclose any ownership or investment
interests in such entities held by physicians or physicians' immediate family members, as well as information on any payments
or other transfers of value provided to such physician owners or investors.

As a statutorily mandated public reporting program, our ability to validate the timeliness, completeness, and accuracy of
the Open Payments records that entities are required to report to us is crucial to ensuring data accuracy and reliability,
and hence, the value of the program itself. Section 1128G(b)(1) of the Act authorizes penalties for non-compliance and gives
us the authority to impose CMPs for instances of “failure to report,” for records that were not reported to CMS. Because it
is axiomatic that CMS cannot find unreported information in records that are reported, we interpret the language of section
1128G(b)(1) of the Act, which provides that any applicable manufacturer or applicable GPO “that fails to submit information
required . . . in a timely manner in accordance with rules or regulations promulgated to carry out such subsection, shall
be subject to a civil money penalty,” as encompassing our ability to impose a CMP upon an applicable manufacturer or applicable
GPO that fails to timely submit, in accordance with our regulations, required information, including the information requested
to perform an audit.

We codified our authority to require audit responsiveness via regulation in 42 CFR 403.912(e)(2), which states that “HHS,
CMS, [Office of Inspector General (OIG)] or their designees may audit, inspect, investigate and evaluate any books, contracts,
records, documents, and other evidence of applicable manufacturers and applicable group purchasing organizations that pertain
to their compliance with the requirement to timely, accurately or completely submit information in accordance with the rules
established under this subpart.” The Open Payments final rule preamble repeatedly mentioned audits because access to such
information is essential to facilitating our ability to adequately oversee regulated entities' Open Payments program compliance. (264)

To facilitate audits, we finalized in the Open Payments final rule a requirement under 42 CFR 403.912(e)(1) that applicable
manufacturers and applicable GPOs must maintain all books, records, documents, and other materials sufficient to enable an
audit, evaluation or inspection of the applicable manufacturer's or applicable GPO's compliance with the requirements in section
1128G of the Act and the implementing regulations. To ensure that those materials are available for a sufficient period to
allow audits, we require applicable manufacturers and applicable GPOs to maintain these books, records, documents, and other
materials for a period of at least 5 years from the date the payment or other transfer of value, or ownership or investment
interest is published publicly on the website. (265)

b. Proposal to Add a Definition of “Failure to Report” in 42 CFR 403.902

The Open Payments final rule preamble frequently mentioned audits because access to this information is essential to facilitating
our ability to adequately oversee regulated entities' Open Payments program compliance. CMS began exercising the Open Payments
program audit authority in 2022 by requiring certain reporting entities to provide relevant documentation pertaining to their
reported records—such as copies of checks, written agreements, or a general ledger—to verify that payments had been reported
accurately. But upon attempting to conduct such audits, certain reporting entities thwarted our efforts by refusing to comply
with our audit requests and rendering it impossible for us to evaluate their Open Payments reporting compliance. We must remedy
that to ensure we can effectively oversee Open Payment reporting compliance, and, therefore, in this proposed rule we propose
certain new measures to refine the effectiveness of our auditing authority.

To do that, first we propose to include in section 42 CFR 403.902 a definition of “failure to report,” which would be foundational
to enabling us to impose a CMP upon a reporting entity that failed to provide records pursuant to a CMS audit. Our rationale
is succinct: the information reported by entities statutorily required to report to the Open Payments program can be verified
by an audit, but in administering the program we currently have no way to compel an Open Payment program reporting entity
to comply with our audit request. Absent our ability to issue

  a CMP for a failure to produce requested audit documents, we would have no adequate enforcement route should a reporting entity
  fail to comply with an audit request.

The phrase “failure to report”—that we borrow from the statute in section 1128G(b)(1)(A) of the Act—is not presently a defined
term within the definitions section of our rules in 42 CFR 403.902, but we do explicitly apply the “failure to report” concept
in 42 CFR 403.912(a)(1) which refers to the failure “to timely, accurately or completely report the information required in
accordance with the rules established under this subpart” (and auditing already is encompassed in the subpart in 42 CFR 403.912(e)(2).
To ensure clarity that we not only require applicable manufacturers and applicable GPOs to provide us the specified information
required when reporting a record, but also that they furnish the required item of information that CMS determines necessary
when it conducts an Open Payment audit, we believe that we must define “failure to report” in 42 CFR 403.902, and propose
here to do so. The proposed definition is based on the existing reference in 42 CFR 403.912(a)(1), and its scope would encompass
the information already required to be provided to CMS under the Open Payment regulations. This addition would help clarify
that an Open Payment reporting party's refusal to comply with or respond to an audit request would carry consequences. (266)

If finalized as proposed, our proposal would encourage Open Payment reporting party compliance with the exercise of our auditing
oversight authority. Absent compliance, for each requested document that an entity would fail to provide we could impose a
CMP under a “failure to report” category (limited by the statutory ceiling and floor amounts per record and per program year).
This would align with the current regulation in 42 CFR 403.912(e) as the auditable documentation would correspond to a reported
or reportable record. We do not propose to alter the existing CMP calculation methodology and would continue to calculate
CMPs using records and their documents on a per-record “failure to report” basis as required by section 1128G(b) of the Act.
This proposed rule would define the information applicable manufacturers and applicable GPOs are required to timely, accurately,
and completely provide in the course of reporting information to HHS, CMS, OIG or their designees.

Explicitly defining “failure to report” to make clear that it includes reporting entities' furnishing the required item of
information that CMS determines necessary when it conducts an Open Payment audit would rectify this shortcoming, clarify that
there would be consequences for applicable manufacturers and applicable GPOs that refuse to participate in a program audit,
and enhance program compliance. Reporting entities are already required to keep contact information updated, per 42 CFR 403.908(c)(3),
and this information would be used to notify audited entities. We propose to make it unambiguously clear that CMS may impose
a CMP should an applicable manufacturer or applicable GPO fail to grant timely access to documents for the purposes of an
audit authorized by 42 CFR 402.912(e)(2). We would accomplish this by adding a definition for “failure to report” in 42 CFR
403.902.

We propose to define a “failure to report” in 42 CFR 403.902 to include a failure to submit requested information, to the
Open Payments program per existing requirements in 42 CFR 403.912. This definition would include a failure to timely, accurately,
and completely provide to HHS, CMS, OIG or their designees the documentation that is required according to program requirements,
including records that are subject to CMS's audit authority in 42 CFR 403.912(e)(2). We propose that an applicable manufacturer's
or applicable GPO's failure to provide, within 30 calendar days of the date of the audit request, the documents or other listed
items requested by CMS or its agents, would constitute a “failure to report.” We propose that each document requested but
not provided to CMS within the timeframe would be subject to the CMP calculation within the annual cap. (267) We believe that this 30-day deadline would not affect any existing requirements, such as the requirement to attest to records
by the 90th day of the calendar year or to report any errors or omissions immediately upon confirmation of the error or omission.

We propose that a CMP associated with a “failure to report” for the purposes of an audit would explicitly be considered a
violation of reporting requirements, including the requirement to maintain documents for the purposes of audits in 42 CFR
403.912(e), and therefore would be subject to the monetary limitations imposed by the Open Payments statute in section 1128G(b)(2)
of the Act. If finalized as proposed, the authority to impose a CMP for documents requested for the purposes of an audit that
applicable manufacturers or applicable GPO fail to provide within 30 calendar days of the request would begin on the effective
date of the final rule. This proposal does not alter the definition of “know, knowing, or knowingly” and therefore a “failure
to report” may escalate to a “knowing failure to report” under the existing circumstances.

In summary, we request comment on our proposals, and specifically on the following:

• The proposal to add a definition for “failure to report” in 42 CFR 403.902, which would allow CMS to impose a CMP on applicable manufacturers or applicable GPOs should either of those entities fail to grant timely access (within 30 calendar days of the date of the audit request) to any books, contracts, records, documents, and other evidence sufficient to enable the audit, evaluation, and inspection of the records for the purposes of an audit authorized by 42 CFR 402.912(e)(2).
• The proposal to become effective beginning on the effective date of the final rule.

2. Statutory Authorities

Four legal authorities ground our proposals:

• Sections 1102 and 1871 of the Act, which provide general authority for the Secretary to prescribe regulations for the efficient administration of the Medicare program.
• Section 1861 of the Act, which defines providers and suppliers.
• Section 1128G of the Act, as amended by section 6111 of the SUPPORT Act, which requires applicable manufacturers of drugs, devices, biologicals, or medical supplies covered under Medicare or a state plan under Medicaid or CHIP to report annually to the Secretary certain payments or other transfers of value to physicians and teaching hospitals, and to PAs, NPs, CNSs, CRNAs, and CNMs for information required to be submitted under section 1128G of the Act on or after January 1, 2022.

H. Modifications to HIPAA Standards Related to Prior Authorization

1. Background

The Health Insurance Portability and Accountability Act of 1996 (HIPAA)

  (Pub. L. 104-191, August 21, 1996) requires the Secretary to adopt standards for electronically conducting certain health
  care administrative transactions between certain entities. The proposals herein would, if finalized as proposed, marks a sea
  change in HIPAA Administrative Simplification as the first time we have proposed adopting Health Level Seven (HL7®) Fast Healthcare
  Interoperability Resources (FHIR®) standards. We believe the standards world is changing and aim to keep pace.

Section 1172(a) of the Act applies HIPAA Administrative Simplification transaction standards to health plans, health care
clearinghouses, and health care providers that electronically transmit health information in connection with those transactions,
collectively referred to as HIPAA covered entities. (268) HHS's proposals in this section pertain to two HIPAA transactions, the “referral certification and authorization” transaction
in 45 CFR part 162, subpart M, and the “eligibility for a health plan” transaction in 45 CFR part 162, subpart L. Importantly,
unlike CMS's proposals discussed elsewhere in this proposed rule that would apply only to impacted payers (as that term is
defined in section I.A. in the proposed rule and used throughout other sections of this rule), the proposals in this HHS section
would apply to all HIPAA covered entities.

The HIPAA statutory paradigm contemplates that processes and standards continue to evolve, and as such, paves the way for
such change by speaking to additions and modifications to standards and requiring periodic review processes to ensure standards
are continually updated and improved. (269) To encourage innovation and promote the maturation of new standards, in the “Health Insurance Reform: Standards for Electronic
Transactions final rule” (hereinafter referred to as the “2000 Standards for Electronic Transactions final rule”), which appeared
in the August 17, 2000,
Federal Register
(65 FR 50312) we established an exceptions process by which an organization may request an exception from the adopted standard
to test a proposed modification in 45 CFR 162.940 (65 FR 50343). The exceptions process enables entities to test new standards,
which permits us to evaluate real-world results, and much of the discussion herein is framed around testing results from the
exception granted to the HL7 Da Vinci Project that was authorized pursuant to that process.

2. The Relevant Transactions and Definitions

a. Referral Certification and Authorization Transactions

Prior authorization is the process by which a health care provider obtains approval from a health plan before rendering certain
items, services, or drugs to a patient. Health plans establish prior authorization requirements to help control costs and
ensure payment accuracy by verifying, before they are rendered, that certain items, services, or drugs are medically necessary
for the specific patient, meet coverage criteria, and are consistent with standards of care.

Prior authorization is not a single transmission, but an interactive process that fundamentally comprises two parts—a prior
authorization request from a health care provider and a prior authorization decision issued by a health plan. However, it
may also involve intermediate information exchanges. For instance, a health plan may transmit a request for clarification
or additional documentation, and health care providers would transmit responses before a final health plan determination.
Each such step would occur within the scope of the standards we propose here. Although prior authorization can serve an important
function in the health care system by improving utilization management and controlling costs, effectuating it often involves
burdensome processes. Specifically, issues with complex health plan policies, limited use of electronic standards, and other
technical barriers can create workflow challenges and burden health care providers and their staff with challenging requirements
that lead to delays in the provision of medically necessary care and can compromise patient safety and health outcomes. (270)

Section 1173(a) of the Act requires the Secretary to adopt HIPAA standards and data elements for nine specified transactions,
including the “referral certification and authorization” transaction in section 1173(a)(2)(I) of the Act. We have promulgated
standards to conduct the transmissions composing the electronic prior authorization process at 45 CFR 162, subpart M, the
“referral certification and authorization” transaction. As described in 45 CFR 162.1301, the “referral certification and authorization”
transaction comprises the following transmissions: (1) a request from a health care provider to a health plan for the review
of health care to obtain an authorization for a health care service for a patient; (2) a request from a health care provider
to a health plan to obtain authorization for referring a patient to another health care provider; and (3) a response from
a health plan to a health care provider to a request described in (1) or (2).

In the 2000 Standards for Electronic Transactions final rule, the Secretary adopted standards for eight electronic health
care transactions, including “referral certification and authorization.” There, the Secretary adopted, in 45 CFR 162.1302,
the Accredited Standards Committee (ASC) X12N 278—Health Care Services Review—Request for Review and Response, Version 4010
transaction standard for dental, professional, and institutional “referral certification and authorization” transactions (65
FR 50341). HHS amended the standard in 45 CFR 162.1302(b)(2), to include the Addenda to the Electronic Data Interchange (EDI)
Transaction Set IG for X12N 278 Health Care Services Review Request for Review and Response, Version 4010 in the “Health Insurance
Reform: Modifications to Electronic Data Transaction Standards and Code Sets” final rule (68 FR 8381), which appeared in the

  Federal Register
  on February 20, 2003. [(271)]() Subsequently, the Secretary adopted, in 45 CFR 162.1302(b)(2)(ii), the updated ASC X12 Standards for EDI Technical Report
  Type 3—Health Care Services Review—Request for Review and Response, Version 5010 and Errata (X12N 278 transaction standard)
  in the “Health Insurance Reform; Modifications to the Health Insurance Portability and Accountability Act (HIPAA) Electronic
  Transaction Standards” final rule (74 FR 3296), which appeared in the 
  Federal Register
  on January 16, 2009.

Notably, the “referral certification and authorization” transaction, and the transmissions it comprises, includes, but is
not limited to, prior authorization. Aside from prior authorization, the “referral certification and authorization” transaction's
scope may pertain to many different health care events, treatment authorizations, specialty referrals, pre-admission certifications,
certifications for health

  care services (such as home health and ambulance), extension of certifications, and certification appeals. [(272)]() Because the “referral certification and authorization” transaction, and the transmissions it comprises, pertain to more than
  just prior authorization, and because some of the proposals herein pertain only to prior authorization, we propose in 45 CFR
  162.103 to define prior authorization to mean (1) transmissions described in 45 CFR 162.1301(a) used by health care providers
  to obtain authorization for health care; [(273)]() and (2) transmissions described in 45 CFR 162.1301(c) used by health plans to respond to such requests.

These are the same transmissions, within the ambit of the “referral certification and authorization” transaction, for which
we proposed an attachment standard in the “Administrative Simplification: Adoption of Standards for Health Care Attachments
Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard
proposed rule” (87 FR 78438) (hereinafter referred to as the “2022 HIPAA Standards for Health Care Attachments proposed rule”),
which appeared in the
Federal Register
on December 21, 2022. Public comments opposing our proposed prior authorization attachment standard led us not to finalize
it when we finalized that proposed rule in the “Administrative Simplification: Adoption of Standards for Health Care Attachments
Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard
final rule” (91 FR 14350) (hereinafter referred to as the “2026 HIPAA Standards for Health Care Attachments final rule”),
which appeared in the
Federal Register
on March 24, 2026.

In that proposed rule, we proposed to adopt the X12N 275 attachment standard for “health care claims or equivalent encounter
information” transactions and “referral certification and authorization” transactions. However, commenters to that proposed
rule overwhelmingly and persuasively counseled us against finalizing the proposed X12N 275 attachment standard for prior authorization
transactions for which the X12N 278 is the transaction standard. Commenters cited concerns including limited industry experience
implementing the X12N 275 attachment standard for prior authorization transactions, variability in current prior authorization
workflows, and potential conflict with other federal interoperability initiatives requiring FHIR-based standards to support
Prior Authorization application programming interface (API) capabilities. Specifically, commenters asserted that previous
attempts to leverage the X12N 275 attachment standard to support prior authorizations had failed and the X12N 278 transaction
standard itself has never fully been embraced or implemented in the industry. Commenters added that while the X12N 275 attachment
standard supports the types of attachments used with “health care claims or equivalent encounter information” transactions,
it does not support the full scope of file types that may be attached to prior authorization transactions, such as FHIR questionnaires.
Commenters urged us to consider FHIR standards, both for attachments and the underlying prior authorization transactions,
to align with separate CMS rulemaking in the 2024 CMS Interoperability and Prior Authorization final rule. We agreed with
commenters that efficient, cost-effective, simplified standards would be impeded by mismatches between HHS requirements under
HIPAA and CMS requirements under its interoperability rulemaking.

In this proposed rule, we propose to adopt the HL7 FHIR standard and certain FHIR IGs for prior authorization transactions.
Importantly, our proposals address prior authorization transactions between health care providers and health plans; (274) we are not proposing changes to the adopted standards for retail pharmacy drugs, for which the adopted standards are developed
and maintained by NCPDP. This proposal aligns with the overall sentiment that commenters articulated in the 2026 HIPAA Standards
for Health Care Attachments final rule.

In addition, and in the alternative, we are proposing to adopt the proposed standards for all “referral certification and
authorization transactions” described in 45 CFR 162.1301, including those related to referral certification, as the FHIR standards
we are proposing herein are capable of performing referral certification as well as authorization transmissions.

b. Eligibility for Health Plan Transaction

Prior to submitting a request for prior authorization, health care providers must first determine whether prior authorization
is required, and, if so, the health plan's documentation requirements that are required to obtain an approval. That antecedent
for prior authorization falls in the scope of the HIPAA “eligibility for a health plan” transaction, which describes a health
care provider's inquiry to a health plan (or a health plan's inquiry to another health plan) for eligibility, coverage, or
benefits information for a patient, and the constituent transmissions described in 45 CFR 162.1201. In 45 CFR 162.1202(a)(2),
the Secretary adopted standards for the dental, professional, and institutional “eligibility for a health plan” transaction,
specifically the ASC X12N 270/271 Health Care Eligibility Benefit Inquiry and Response transaction standard (X12N 270/271
transaction standard). The “eligibility for a health plan” transaction serves multiple purposes, and in this proposed rule
we are proposing to modify the standard for that transaction only when an inquiry and response are used to determine whether
prior authorization, as HHS proposes to define that term in 45 CFR 162.103, is required. Our proposals would not alter the
standards for other “eligibility for a health plan” transactions described in 45 CFR 162.1202 unrelated to prior authorization,
for which the adopted standard would remain the X12N 270/271 transaction standard.

Section 1173(g) of the Act requires the Secretary to adopt a single set of operating rules for each adopted HIPAA transaction
with the goal of creating as much uniformity in the implementation of the electronic standards as possible. We have not yet
adopted operating rules for the “referral certification and authorization” transaction, but have adopted operating rules associated
with the present X12N 270/271 transaction standard for the “eligibility for a health plan” transaction. We are not proposing
operating rules for the proposed subset of “referral certification and authorization” transactions because, unlike existing
X12N transaction standards, the proposed FHIR base

  standard [(275)]() and IGs themselves specify all the necessary operating requirements so they do not require operating rules. Consistent with
  that, we propose amending 45 CFR 162.1203 to specify that the existing operating rules associated with “eligibility for a
  health plan” transactions would exclude prior authorization-related transmissions, and explain that they would continue to
  apply to other “eligibility for a health plan” transactions that would continue to utilize the X12N 270/271 transaction standard.

In summary, HHS requests comment on its proposals summarized in section II.H.10. of this proposed rule, which includes the
proposals discussed above, and the CFR citations listed in Table 11.

3. The Proposed FHIR Standards

Based on the recommendations of the National Council for Vital and Health Statistics (NCVHS), the positive results of the
HL7 Da Vinci Project's testing discussed herein, consultation with HL7 International as a DSMO, extensive public comment to
various notices of HHS and CMS proposed rulemaking, and our own analysis, we are proposing a modification to the dental, professional,
and institutional “referral certification and authorization” transaction standard for transmissions related to prior authorization
to replace the present X12N 278 transaction standard with the FHIR standard. We propose to add a new 45 CFR 162.1302(g)(2)
that would adopt the following specifications as the standard for the “referral certification and authorization” transactions
within the contours of our proposed definition of prior authorization. Our proposals to adopt specific versions of the following
specifications are discussed further later in this section:

• The HL7 FHIR Standard,
• HL7 FHIR US Core IG (US Core IG),
• HL7 Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Framework IG (SMART App Launch IG),
• HL7 FHIR Da Vinci Coverage Requirements Discovery IG (CRD IG),
• HL7 FHIR Da Vinci Documentation Templates and Rules IG (DTR IG), and

• HL7 FHIR Da Vinci Prior Authorization Support IG (PAS IG).
  In addition, in a new 45 CFR 162.1202(f)(2)(i), we propose adopting the following specifications as the standards for “eligibility
  for a health plan” transactions for dental, professional, and institutional health care eligibility inquiry and response,
  when used to determine whether prior authorization is required:

• The HL7 FHIR Standard,

• US Core IG,

• SMART App Launch IG, and

• CRD IG.
  Collectively, the proposed standards would enable the use of a Prior Authorization API. An API is a set of rules or protocols
  defining how requests for data should be made and responses should be returned that enables different software applications
  to communicate and exchange data with each other, and a Prior Authorization API is an API used to electronically transmit
  and receive health information related to prior authorizations. Per our proposal, the system resulting from the appropriate
  implementation of the proposed FHIR specifications would be known as a “Prior Authorization API.” Independently, the proposed
  IGs do not have a functionality; rather they define how to implement a Prior Authorization API, which comprises multiple FHIR
  IGs integrated to support the full prior authorization workflow from initial coverage inquiry through final authorization
  decision, in a manner that has been standardized for industry interoperability.

The FHIR standard, US Core IG, and SMART App Launch IG are implementation specifications widely used across FHIR APIs for
a variety of use cases. The CRD, DTR, and PAS IGs work in concert to inform, submit, and respond to prior authorization requests.
These IGs' capabilities and functionality, briefly discussed here for reference, are discussed more extensively in section
II.A.4.a. of this proposed rule. When used to implement a Prior Authorization API, the proposed IGs define the format and
data content (as those terms are defined in 45 CFR 162.103) for the relevant transactions.

The HL7 FHIR standards architecture is built upon a foundational base FHIR standard, that is open source and free to use with
no restrictions, to which health care entities can add specific functionalities via modular building blocks that can be assembled
into a variety of systems and applications, including payer servers, provider EHRs, mobile apps, and cloud communications
to standardize interoperable health data exchange. (276) FHIR IGs define how FHIR capabilities are used in particular data exchanges or to solve particular problems, and the other
specifications and IGs discussed in this section of the proposed rule are all built upon the base FHIR standard.

Frequently, health care entities have specific technical requirements, for needs such as custom data fields or workflow processes,
beyond the standard FHIR specifications. For use cases that are common across a large segment of the health care industry,
those added functionalities can be standardized as IGs that effect a common solution to those use cases. This add-on approach
keeps the base FHIR standard manageable while allowing health care entities to tailor systems to meet specific operational
needs. In the case of prior authorization, the CRD, DTR, and PAS IGs are designed using the FHIR base standard, but to the
specific requirements of their use cases within the prior authorization process. As the needs of industry and technology evolve,
developers and implementers can customize FHIR APIs within the strictures of the IGs, and HL7, as the Standards Setting Organization
(SSO), has greater flexibility to modify FHIR standards and IGs.

The US Core IG is a set of rules that define how data, such as patient records, medication, and lab results, are formatted
and exchanged in the United States. (277) The IG is built to follow other HHS requirements, particularly the US Core Data for Interoperability (USCDI), which is an/ONC-maintained
set of health data classes and data elements for nationwide, interoperable health information exchange established under authority
independent of HIPAA. (278) The US Core IG is an essential underlying specification for any FHIR implementation within the United States that provides
basic data structure and formatting rules required for FHIR APIs exchanging data elements within the USCDI.

SMART is an open standard that enables health apps to securely connect to and interact with EHRs and other health IT systems.
The SMART App Launch IG is a set of technical implementation specifications that define how client health apps can securely
authorize, authenticate, and integrate with a FHIR-based data

  system. [(279)]() This standardized approach allows health apps to work across different EHRs and other health IT systems without requiring
  custom integration for each system. “SMART on FHIR” apps (“SMART apps”) that are built using both the SMART and FHIR standards
  can be integrated into existing health IT systems to provide additional functionality.

The SMART App Launch IG allows SMART apps to access the FHIR server, regardless of the underlying architecture of the client's
health IT system. (280) SMART apps function similarly to mobile apps on a smartphone—they can be added to existing systems to provide new capabilities.
These apps are currently used across various EHRs, other health IT, and mobile devices. For prior authorization, we expect
that the primary use case would be health care providers using SMART apps (which are enabled by a FHIR API being implemented
with SMART App Launch IG) within their health IT system to extend that system's functionality to interact with Prior Authorization
APIs and provide additional automation for the prior authorization process, such as checking coverage requirements, submitting
requests, and tracking approval status. SMART apps have been developed to interpret the health plan's structured prior authorization
requirements from the CRD and DTR IGs and to automate the process of collecting documentation.

The CRD IG is used to define a workflow for health plans to transmit information about coverage requirements, such as health
plans' requirements to request and receive prior authorization, to health care providers through their health IT system. (281) The CRD IG enables health care providers to query the Prior Authorization APIs to determine whether prior authorization is
required, and also provides information about a health plans' prior authorization coverage rules so a health care provider
knows what is necessary to support its prior authorization request to obtain authorization for health care for a patient.

The CRD IG is designed solely for prior authorization use cases, not any other type of eligibility or benefit information,
so prior authorization-related transmissions are the sole use case for which we propose to modify the X12N 270/271 transaction
standard adopted in 45 CFR 162.1202. Therefore, our proposal for the “eligibility for a health plan” transaction is limited
to those where the CRD IG can be used, that is, for transmissions related to prior authorization (as we propose to define
that term in 45 CFR 162.103) to determine whether prior authorization is required. We propose no changes to “eligibility for
a health plan” transactions described in 45 CFR 162.1202 unrelated to prior authorization, for which the standard transactions
would continue to be the adopted X12N 270/271 transaction standard.

The DTR IG specifies how a health plan's documentation requirements for prior authorization requests are communicated to a
health care provider, (282) streamlining prior authorization and documentation by enabling payers to send interactive, automated forms known as FHIR Questionnaires
and rules directly into a provider's EHR. Typically triggered by an automated CRD IG check, health plans use the DTR IG to
code prior authorization documentation requirements, which, for example, could apprise health care providers that a prior
authorization approval requires particular test results or that they would need to fill out a certain form with patient medical
history. The DTR IG can automate the assembly of documentation to support a prior authorization request, enabling health care
providers to download FHIR questionnaires from the health plan (for example, structured forms or templates that health plans
use to collect specific clinical information needed to evaluate whether a requested service meets coverage criteria and medical
necessity requirements). EHRs, other health IT systems, or SMART apps could use that information to automatically populate
the required test results and patient history to transmit to the health plan.

The PAS IG, used when a health care provider submits a prior authorization request and required documentation to a health
plan, enables a prior authorization request to be transmitted via FHIR API from a health care provider's EHR or other health
IT system and a health plan to notify a provider of its decision. (283) 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.

4. Reports and Recommendations

On April 20, 2021, the Secretary approved exceptions requested by the HL7 Da Vinci Project to test FHIR standards. (284) The exceptions covered the two adopted transactions discussed previously related to prior authorization: (1) dental, professional,
and institutional “referral certification and authorization” transactions; and (2) the “eligibility for health plan” transactions
when used to determine whether prior authorization is required. (285) Like our current proposals, these exceptions only applied to “eligibility for a health plan” transactions used to determine
whether prior authorization is required, not the full scope of “eligibility for a health plan” transactions described in 45
CFR 162.1202. After a year of testing, on June 25, 2024, the HL7 Da Vinci Project submitted to HHS its required report on
the test results, (286) including the required cost-benefit analysis, which is discussed later in this section. On April 29, 2025, the Secretary issued
a
Federal Register
notice regarding the availability of the HL7 Da Vinci Project's report on an HHS website (90 FR 17827).

The Health Information Technology Advisory Committee (HITAC) is a Federal Advisory Committee established by section 3002 of
the PHSA, as amended by the 21st Century Cures Act (hereinafter referred to as the “Cures Act”) (Pub. L. 114-255, enacted
December 13, 2016). HITAC offers recommendations to ONC on health IT policies, standards, implementation specifications, and
certification criteria

  relating to the implementation of a health IT infrastructure that advances electronic access, exchange, and use of health
  information. In 2020, ONC charged HITAC to establish a task force, that became known as the Intersection of Clinical and Administrative
  Data Task Force (ICAD), to consider the convergence of clinical and administrative data and make recommendations to HITAC.
  In what resulted in a November 2020 report to ONC, HITAC and NCVHS joined forces in ICAD's effort to support the convergence
  of clinical and administrative data and improve data interoperability across the ecosystem to enhance patient access and improve
  health care efficiency. [(287 288)]()

ICAD's report stated that one of the primary factors contributing to the X12N 278 transaction standard's low adoption is the
transaction set's lack of specificity and flexibility. (289) FHIR's flexibility can, we believe, address those shortcomings and we identify three specific attributes: (1) the FHIR standard
and associated specifications were developed using a consensus-based process to capture requirements across health care settings;
(2) the quality of data that can be exchanged using the FHIR standards is greater than can be exchanged with other standards,
including the X12N 278 transaction standard; and (3) a FHIR API's architecture allows the exchange of more types and a greater
quantity of data. ICAD and the NCVHS also identified the lack of an attachment standard for prior authorizations as a factor
contributing to low adoption. We had proposed, but elected not to finalize, the X12N 275 attachment standard for prior authorization
transactions in the 2022 HIPAA Standards for Health Care Attachments proposed rule, ultimately finalizing the more limited
2026 HIPAA Standards for Health Care Attachments final rule and electing to later proceed with this proposal to adopt the
HL7 Da Vinci Clinical Data Exchange (CDex) IG, as the HIPAA standard for attachments to prior authorization transactions. (290)

On July 28, 2022, the NCVHS sent HHS a recommendation letter to “support the transformative changes occurring in health care
delivery systems, payment methodologies, standards development, and rule adoption.” (291) That letter's recommendations were based on an NCVHS listening session held on June 9, 2022 and letters of public comment
from the “National Committee on Vital and Health Statistics: Notice of Meeting and Request for Public Comment” (86 FR 33318). (292 293) The NCVHS also cited the HITAC/ICAD report as originating its vision. (294) In that letter, the NCVHS stated that support for API technology, including the FHIR standard, could be more effective and
efficient than certain current adopted transaction standards. The NCVHS stated that the advantages of FHIR standards for some
stakeholders could include better workforce availability, lower total labor costs, or technical compatibility. We agree with
the NCVHS's analysis that adopting FHIR standards could benefit the industry by providing needed flexibility to address the
wide range of business processes that HIPAA covered entities use to request prior authorization and make and communicate prior
authorization decisions. The NCVHS highlighted a quote from the listening session that costs and benefits should be looked
at holistically, and, though organizations would have upfront FHIR implementation costs, the benefit of a smoother experience
and faster process outweighs the cost.

In that letter, the NCVHS also recommended that HHS adopt multiple standards for each transaction to co-exist for specific
business needs. Specifically, they suggested that we allow some HIPAA covered entities to use FHIR standards while others
could use the extant X12N transaction standard, as doing so would allow various standards to be tested and used for specific
business needs. Notably, we agree only in part with that recommendation. We understand that the same standards may not meet
the needs of every use case and segment of the health care industry, which, for example, is why we have adopted different
standards, developed by NCPDP, for retail pharmacies across many of the standard transactions. Similarly, for the “health
claims or equivalent encounter information” transaction, we have adopted, in 45 CFR 162.1102, different standards for four
types of claims: retail pharmacy drugs, dental health care, professional health care, and institutional health care. With
these proposals, we continue to make those distinctions, as section 1173(a)(3) of the Act requires the Secretary to accommodate
the needs of different types of health care providers.

However, we disagree that the industry would benefit from our indefinitely adopting multiple standards for the same types
of transactions. Section 1172(b) of the Act requires that any standard adopted by the Secretary be consistent with HIPAA Administrative
Simplification's objective of reducing the administrative costs of providing and paying for health care. We have incorporated
reasonable transition periods into certain HIPAA rulemaking, (295) but believe that adopting in perpetuity multiple overlapping standards would contravene the statutory purpose by potentially
requiring that HIPAA covered entities support both the X12N and FHIR standards, which could increase the health care system's
administrative burden and costs.

Furthermore, the NCVHS sent its recommendation letter before the HL7 Da Vinci Project's exceptions testing concluded and its
report was published. The NCVHS' July 28, 2022 letter to HHS included a recommendation to allow

  stakeholders to test, evaluate, and plan for modified standards; the HL7 Da Vinci Project's report offers the results of just
  that sort of real-world testing and demonstrates the FHIR standards' benefits. The exceptions testing report, which fulfilled
  several NCVHS recommendations, was a natural sequent to the recommendations and evidenced many of the NCVHS's points that
  a modified and modernized standard could benefit the industry and should be considered by HHS for adoption.

After the April 20, 2021, HIPAA exceptions approval, but before the June 25, 2024 testing report, and in accordance with separate
rulemaking and legal authority, CMS proposed and later finalized its 2024 CMS Interoperability and Prior Authorization final
rule (87 FR 76238, 89 FR 8869). There, CMS finalized a requirement that “impacted payers” implement and maintain a Prior Authorization
API, requiring impacted payers to use a version of the base FHIR standard adopted in 45 CFR 170.215(a)(1), a version of the
US Core IG adopted in 45 CFR 170.215(b)(1)(i), and a version of the SMART App Launch IG adopted in 45 CFR 170.215(c)(1) (89
FR 8945). CMS also recommended that impacted payers use the CRD, DTR, and PAS IGs that were at the time being tested by the
HL7 Da Vinci Project under the approved exceptions (89 FR 8945). (296) Those standards which we propose to adopt in this HIPAA rulemaking section, are described further in section II.A. of this
proposed rule, along with CMS's proposals to require impacted payers to use updated versions of the previously recommended
IGs.

In response to public comments received on multiple notices of proposed rulemaking and extensive stakeholder outreach to HHS,
including regular interim discussions with the HL7 Da Vinci Project about the status of its exceptions testing, we issued
a notice of enforcement discretion on February 28, 2024. (297) That notice stated that we would not take administrative simplification enforcement action against HIPAA covered entities
that elected not to use the X12N 278 transaction standard but instead used the FHIR standards for prior authorization transactions.
We also stated that we would continue to evaluate the HIPAA prior authorization transaction standards. In part as a result
of that analysis, we did not finalize in the 2026 HIPAA Standards for Health Care Attachments final rule the X12N-based prior
authorization attachment requirements we had previously proposed, and, instead, now make these proposals.

5. Benefits of Setting Prior Authorization on FHIR

The adopted X12N 278 transaction standard has a low implementation rate among health plans. According to the Council for Affordable
Quality Healthcare (CAQH), as of 2024 just 35 percent of medical plans have adopted the electronic standard, while 43 percent
use a payer-specific portal and 22 percent rely on manual processes, such as phone, email, or fax. (298) Health plan adoption of the other adopted HIPAA standards ranges from 77 percent to 100 percent, so the X12N 278 transaction
standard's aberrantly low industry adoption rate suggests there may be a problem, which may be that it does not meet many
HIPAA covered entities needs. (299)

Multiple sources report that health care providers find prior authorization to be their most burdensome administrative transaction.
The AMA reports that physicians and their staff spend an average of 13 hours each week completing prior authorization requests
and 40 percent have staff who work exclusively on prior authorizations. (300) The proposed modification to the standard transactions would not entirely alleviate that burden, but analyses indicate that
our adoption of the FHIR standards could significantly reduce health care provider and staff time spent on prior authorizations.
According to the 2024 CAQH Index Report, providers reported that it took, on average, 24 minutes to request an authorization
from a health plan using manual processes and 16 minutes using a health plan portal, (301) while conducting the X12N 278 transaction standard as a fully electronic process reduced the time it took providers to 10
minutes on average. But, based on its testing the HL7 Da Vinci Project reported that a FHIR-based transaction reduced the
time required to perform the necessary activities to request a prior authorization to 5 to 6 minutes per transaction on average, (302) thus amounting to a 40-60% time savings that clinicians could potentially rededicate to patients as opposed to bureaucracy!
That decrease was primarily due to receiving real-time feedback as part of the clinical workflow within an EHR or other health
IT.

Unlike other existing standards that utilize point-to-point EDI, such as X12N transaction standards, the Prior Authorization
API's real-time and interactive nature would allow health care providers to use their EHRs or other health IT to automate
processes such as documentation collection and to receive real-time feedback on missing information or errors. Historically,
EDI, like the X12N 278 transaction standard, has generally relied on batch-processing using standardized document formats
to asynchronously exchange data; by contrast, APIs' web-based technology enables real-time synchronous data exchange using
flexible formats that can offer faster implementation, near-instantaneous results, and lower costs.

While EDI remains the standard for many established administrative transactions, HHS believes that APIs such as the FHIR API
may represent the future direction of health data exchange. Unlike EDI and most of the current adopted HIPAA standards that
rely on narrow and granularly specified transmissions, transactions using APIs may consist of many interactions and data exchanges
between the server and client systems. Regardless of the inner workings of the API and data exchange, for the purposes of
HIPAA rulemaking,

  we consider the entire process of requesting prior authorization and receiving a decision—including any intermediate steps—to
  comprise the transaction for which we are proposing to adopt the FHIR standard and applicable FHIR IGs as the HIPAA standard.

The 2024 AMA Prior Authorization Physician Survey revealed that 61 percent of physicians reported that it was difficult to
determine whether prior authorization was required for medical services, and thirty percent of physicians reported that prior
authorization information in their EHR was rarely or never accurate. (303) Our understanding is that prior authorization requirements available through EHRs or other health IT today are generally static
lists that must be continually updated or the information available may become out-of-date. By contrast, interactions with
a Prior Authorization API could be integrated into health care providers' clinical workflows through their health IT system,
enabling them to directly query a health plan as to whether prior authorization would be required while discussing treatment
with a patient, rather than performing such a check later. The HL7 Da Vinci Project's testing revealed that providers immediately
received a health plan response in their EHR when using the CRD IG to query whether prior authorization was required, and
that 84 percent of those immediate responses apprised them that services or treatments did not require prior authorization. (304) That immediacy could contribute to the proposed FHIR standards biggest operational efficiency gains and enable health care
providers to focus on patient care as opposed to wasting significant time and effort submitting a prior authorization request
that, in the majority of instances, was unnecessary.

By contrast, the current X12N 278 transaction standard generally is not executed in real time. Though it is capable of being
exchanged in real time as CAQH Core operating rules do allow that, our understanding, informed by industry and SSO feedback,
is that those real-time operating rules, which have not been adopted under HIPAA, are rarely if ever implemented and used. (305) The time to simply determine whether prior authorization is required could delay treatment in instances when prior authorization
is not even required.

Similarly, we believe that HIPAA covered entities' use of FHIR, and specifically the CRD IG for the “eligibility for health
plan” transaction, could decrease the number of requests for prior authorization that a health plan would have to process,
only to determine that prior authorization was not required. We believe that dynamic was, for example, reflected in a comparison,
during the exceptions testing, of the number of prior authorization requests that were voided by the health plan or health
care provider because they were duplicates, were cancelled, or had data issues. The HL7 Da Vinci Project reported that 20
percent of requests were voided using the FHIR standards while 45 percent of requests were voided using a payer's portal with
the integrated X12N 278 transaction standard. (306) Both methods had 8 percent of requests denied and 1 percent partially approved. The 25 percent difference in voided requests
directly correlates to the number of requests fully approved—71 percent with FHIR and 46 percent with a direct data entry
portal and the X12N 278 transaction standard. These data suggest that a significant percentage of X12N 278 transaction standard
requests that were ultimately approved were first voided because of data issues or procedural problems with the request. Unnecessary
requests often impose excessive and unwarranted burdens on HIPAA covered entities that we believe could be avoided with the
more flexible, interactive, and real-time FHIR standards we are proposing.

The HL7 Da Vinci Project's testing also showed that the Prior Authorization API significantly reduced the time it took for
health plans to communicate prior authorization decisions, which difference was demonstrated both with respect to decisions
that could be automated and those that required human review. For example, 75 percent of prior authorization requests for
Endometrial Ablation using a health plan's portal and the X12N 278 transaction standard were approved within 5 days; that
time decreased to just 5 minutes when using FHIR. (307) Similarly, testing demonstrated that 90 percent of requests for Intensity Modulated Radiation Therapy of the thorax, abdomen,
and pelvis were approved within 49 days using a portal, which decreased to 11 days using a Prior Authorization API. The HL7
Da Vinci Project's testing exceptions report attributed the quicker decisions to the FHIR standards' capability to codify
documentation policies for automated extraction from an EHR. One of the testing participants highlighted that the FHIR standard
enabled discrete data sharing without the need for attachments and enabled the ability to automate workflows to display prior
authorization results in provider portals for transparency.

Therefore, we believe that adopting the FHIR standard and certain FHIR IGs as the HIPAA standards for “referral certification
and authorization” transactions and prior authorization-related “eligibility for health plan” transactions could significantly
reduce costs and burden on patients, health care providers, health plans, and, more generally, any HIPAA covered entity involved
in the prior authorization process. Reducing burden and costs would directly effectuate HIPAA Administrative Simplification's
explicit aims: improving Medicare, Medicaid, and the efficiency and effectiveness of the health care system and reducing clinical
burden on patients, health care providers, and health plans by establishing uniform standards for the electronic transmission
of certain health information. (308)

In summary, HHS requests comment on its proposals summarized in section II.H.10. of this proposed rule, which includes the
proposals discussed above, and the CFR citations listed in Table 11.

6. Proposed Modifications and Subsequent Maintenance

Each proposed specification constantly evolves as new technologies and use cases emerge, enhancements are requested by industry,
and errors are corrected. We specifically propose to adopt for dental, professional, and institutional “referral certification
and authorization” transactions related to

  prior authorization, in 45 CFR 162.1302(g)(2), the following versions of the standards, which are the same versions that ONC
  separately proposes to be adopted and that CMS proposes be required for impacted payers in other sections of this rulemaking:

• The HL7 FHIR Standard, Release 4.0.1;
• US Core IG, Standard for Trial Use (STU) 6.1.0;
• SMART App Launch IG, Release 2.0.0;
• CRD IG, Version 2.2.1—STU 2.2;
• DTR IG, Version 2.2.0—STU 2.2; and

• PAS IG, Version 2.2.1—STU 2.2.
  In addition, in a new 45 CFR 162.1202(f)(2)(i), we propose to adopt the following specification versions as the standards
  for “eligibility for a health plan” transactions for dental, professional, and institutional health care eligibility inquiry
  and response, when used to determine whether prior authorization is required:

• The HL7 FHIR Standard, Release 4.0.1;

• US Core IG, STU 6.1.0;

• SMART App Launch IG, Release 2.0.0; and

• CRD IG, Version 2.2.1—STU 2.2.
  We encourage all interested parties to engage with the standards development process to best ensure the standards reflect
  input from across the health care industry, and acknowledge that the versions of the proposed standards may be updated in
  the period between publication of this proposed rule and any final rulemaking (should we finalize this rule) pursuant to updates
  in the normal course as a result of the SSO's consensus-based process. We request public comment on whether we should adopt
  an updated version of any proposed standard, should such become available by the time of final rulemaking. Doing so would
  allow us to adopt, and HIPAA covered entities to use, the latest and most up-to-date versions of the standards available at
  the time of a final rule rather than locking in versions specified in this proposed rule. Newer versions would include consensus-based
  updates made through the SSO's development and maintenance process. That could better align the HIPAA transaction standards
  with other HHS initiatives that encourage interoperability and efficient information exchange in the health care industry.

While we propose to adopt specific versions of the proposed standards, we also look to balance industry desire to be able
to use later versions of adopted standards once they are finalized by the SSO without additional rulemaking. The HIPAA regulatory
paradigm envisions ongoing maintenance to the adopted standards, as described in 45 CFR 162.910(b). As defined at 45 CFR 162.103,
“maintenance” refers to activities necessary to support the use of a standard adopted by the Secretary, including technical
corrections to an implementation specification that could be non-substantive or error correction. To enable that maintenance,
as described in 45 CFR 162.910(a), the Secretary may designate an organization that agrees to maintain adopted standards.
Maintenance, as described in 45 CFR 162.910(b), is a process performed by the appropriate DSMO, if done in accordance with
the processes the Secretary may require. Even with respect to maintenance changes, the normal ANSI-accredited standards development
process still would require public notification and comment, but regulatory action is not required. We further describe the
standards development and maintenance process in the 2022 HIPAA Standards for Health Care Attachments proposed rule (87 FR
78440 and 78441).

The term “maintenance” excludes the activities related to the adoption of a new standard or implementation specification,
or modification to an adopted standard or implementation specification. As discussed in the “Health Insurance Reform; Announcement
of Maintenance Changes to Electronic Data Transaction Standards Adopted Under the Health Insurance Portability and Accountability
Act” final rule (65 FR 50322), which appeared in the
Federal Register
on October 13, 2010, and which referenced the 2000 Standards for Electronic Transactions final rule, when a change is substantial
enough to justify publication of a new version of an implementation specification, such change is considered a modification
and must be adopted by the Secretary through regulation.

HL7 uses semantic versioning, a standardized numbering system that indicates the type and scope of changes made to software
specifications, with a “Major.Minor.Patch” version format where each term is represented by an integer (for example, 1.2.3).
The “Major” number is incremented when HL7 publishes a significant new release of the FHIR specification. The “Minor” number
is incremented for updates that introduce minor substantive changes, potentially including “limited breaking changes,” which
are changes that may affect specific optional features or add new required fields while maintaining compatibility with previous
versions. The “Patch” number is incremented to indicate an update including only technical corrections to a prior release.
Patches, we believe, are equivalent to the errata to the current adopted standards that, pursuant to maintenance updates,
are effectuated without rulemaking, and we would consider patches to be maintenance updates rather than modifications to the
adopted standard. The same schema would be applied, as applicable, for all FHIR specifications and IGs. For example, the PAS
IG has, between 2020 and 2026, advanced as follows: 2020—version 1.0.0; 2021—version 1.1.0; 2022—version 1.2.0; 2023—version
2.0.0; 2024—version 2.0.1; 2025—version 2.1.0; and 2026—version 2.2.1.

Specifically, that means that if HL7 publishes a version with the same major and minor versions as the adopted standard, but
indicates that technical corrections are included by using a patch version, HIPAA covered entities would be permitted to use
that updated version as it would be considered a maintenance update. Such a framework would allow HIPAA covered entities to
update their Prior Authorization APIs or health IT systems to address identified issues without waiting for additional rulemaking.
The Secretary would rely on HL7, as the DSMO, and its existing versioning system, as an indicator of whether scope changes
to the adopted standard would be “technical corrections” as described in the definition of “maintenance” in 45 CFR 162.103,
or would be more substantive modifications requiring rulemaking to adopt. For example, this means that if our proposal to
adopt the PAS IG, Version 2.2.1 were finalized, and HL7 were to subsequently publish PAS IG, Version 2.2.2, that later version
would be considered a maintenance update to the adopted standard, as described in Section 1174 of the Act and 45 CFR 162.910.
Therefore, HIPAA covered entities would be permitted to use the PAS IG, Version 2.2.2 without additional rulemaking. However,
if a subsequent version of the PAS IG were to be published, for example PAS IG, Version 2.3.0, that would indicate to us that
the changes were substantive enough to require modification via rulemaking.

We believe such a framework would be consistent with the discussion of maintenance in 45 CFR 162.910 and, should this proposed
rule be finalized as proposed, we anticipate relying upon it. However, we also request comment on whether versioning is the
appropriate indicator on which we should rely, or whether we should require other considerations or processes.

In summary, HHS requests comment on its proposals summarized in section II.H.10. of this proposed rule, which includes the
proposals discussed above, and the CFR citations listed in Table 11.

7. FHIR Standard for Attachments to Prior Authorization Transactions

In the 2022 HIPAA Standards for Health Care Attachments proposed rule, we proposed the X12N 275 transaction standard for “health
care attachments” for certain HIPAA Administrative Simplification transactions. Specifically, we proposed the X12N 275—Additional
Information to Support a Health Care Services Review (06020X316) standard to support “referral certification and authorization”
transactions and the X12N 275—Additional Information to Support a Health Care Claim or Encounter (06020X314) standard to support
“health care claims or equivalent encounter” transactions (87 FR 78447).

In response to that proposed rule, many commenters urged us instead to adopt the CDex IG, (309) a FHIR IG, rather than the X12N 275 attachment standard for prior authorization transactions. The CDex IG provides guidance
for implementers to support FHIR-based interactions for specific clinical data exchanges. In particular, the CDex IG supports
real-time exchange for both structured and unstructured clinical data through FHIR APIs, which can improve efficiency and
reduce administrative burden. Commenters viewed the CDex IG as a modern and flexible solution that supports industry needs
and the federal government's broader interoperability and administrative simplification goals. Commenters reasoned that the
CDex IG facilitates exchanging any information a health care provider holds in a patient's health record as it is not limited
to FHIR resources, but includes the ability to attach files, such as C-CDA documents, PDFs, text files, and other formats.
Commenters added that the flexibility to include a variety of file types is particularly relevant to prior authorization documentation
requirements as contrasted with the types of attachments that typically are necessary to submit claims. The CDex IG supports
FHIR-based communication between health plans and health care providers, allowing documentation and attachments to be shared
more seamlessly across health IT systems.

Commenters raised numerous points, including that: (1) the CDex IG allows health plans to be explicit about the data they
are requesting, which would prevent health care providers from having to spend time gathering and sending more information
than necessary; (2) the CDex IG would complement the FHIR standards finalized in the 2024 CMS Interoperability and Prior Authorization
final rule, and harmonizing standards would promote consistent, scalable, and flexible data exchange (89 FR 8864 and 8941);
(3) adopting the CDex IG would enable faster, automated determinations of medical necessity, and could eliminate redundant
manual steps by allowing health plans to request and receive clinical data directly; (4) this approach would integrate with
existing prior authorization workflows and would support information exchanges needed to make coverage determinations; and
(5) many prior authorizations require additional documentation, and that even with the X12N 275 attachment standard, obtaining
this information would be burdensome for health care providers and health plans.

Similarly, in response to the 2024 CMS Interoperability and Prior Authorization final rule, which did not propose to require
impacted payers to implement an attachment standard, multiple commenters urged CMS to formally recommend the CDex IG (as it
did with other IGs) in the final rule and stated that it is a critical part of burden reduction and plays an important role
in supporting FHIR prior authorization transactions (89 FR 8864). CMS declined to do so, but encouraged impacted payers to
participate in ongoing testing and stated that it would consider requiring or recommending CDex IG in future rulemaking (89
FR 8941).

After considering the significant and persuasive public comments in opposition, we did not finalize the proposed attachment
standard for “referral certification and authorization” transactions in the 2026 HIPAA Standards for Health Care Attachments
final rule. We declined to finalize those provisions in part because the proposed X12N 275 attachment standard would not align
with the 2024 CMS Interoperability and Prior Authorization final rule published in the
Federal Register
on January 17, 2024 (89 FR 8758). As described previously, the FHIR standard permits more granular data to be transmitted,
obviating in many instances the need for an additional attachment standard. However, even should our proposal to adopt FHIR
be finalized as proposed we understand that some prior authorization use cases still would require an attachment. Therefore,
we believe that HIPAA covered entities could benefit from using the CDex IG for prior authorization attachments, and propose
to adopt the CDex IG, Version 2.1.0—STU 2.1, in 45 CFR 162.1302(g)(2)(vii) as the standard for attachments to prior authorization
transactions. We are not proposing at this time to adopt the CDex IG for any transaction other than prior authorizations because
that is the only HIPAA Administrative Simplification transaction for which we are proposing to adopt FHIR standards.

Because the Da Vinci Project did not include the CDex IG in its testing exception, we continue to evaluate the CDex IG's maturity
for adoption in HIPAA Administrative Simplification standard for attachments to prior authorization transactions. In its July
28, 2022 recommendation letter, NCVHS noted HL7 FHIR could be more effective and efficient for certain HIPAA transactions.
NCVHS recommended that HHS not disrupt HIPAA transactions that are working well using the current adopted standards, but that
standards that are not well adopted or utilized by industry—namely prior authorization or attachments—could be instances where
FHIR “provides an on-ramp for a new generation of standards.” (310) At the December 2025 listening session, we asked the named consultative organizations and DSMOs to comment on the maturity
of the CDex IG and whether it is adequately mature for us to propose as the attachments standard for prior authorization transactions. (311) Multiple organizations reported both in that session and in follow-up letters that the CDex IG would be the appropriate attachment
standard for any transactions using FHIR, and urged us to propose to adopt the CDex IG for attachments to prior authorization
transactions.

In summary, HHS requests comment on its proposals summarized in section II.H.10. of this proposed rule, which includes the
proposals discussed above, and the CFR citations listed in Table 11.

8. Compliance Date

HHS proposes, in 45 CFR 162.1202(e) and 45 CFR 162.1302(f), that HIPAA covered entities would be required to comply with the
proposed modified standard no later than 24 months from the effective date of a final rule, except for small health plans, (312) for which the compliance date would be 36 months from the effective date of a final rule.

Section 1175(b)(2) of the Act specifies that the compliance date for a modification to a standard or implementation specification
cannot be sooner than 180 days after the date the modification is adopted. A modification is “adopted” on the date it becomes
effective, which here would be 60 days after its publication in the
Federal Register
. Although these proposals would constitute modifications to an existing standard, as described in section 1174(b) of the
Act, the modifications would represent a significant departure from the currently adopted standard. We expect that most HIPAA
covered entities would, by virtue of other requirements, be familiar with the proposed FHIR standards by 2027. In the 2024
CMS Interoperability and Prior Authorization final rule, CMS provided approximately 3 years between its February 2024
Federal Register
publication and the 2027 compliance dates (89 FR 8758). There, CMS stated that commenters expressed that impacted payers would
need between 18 and 36 months to implement the interoperability APIs finalized in that rule (89 FR 8763).

In addition to the Prior Authorization API, CMS finalized in the 2024 CMS Interoperability and Prior Authorization final rule
requirements for impacted payers to implement and maintain Provider Access and Payer-to-Payer APIs, as well as requirements
to modify their Patient Access APIs. Thus, the compliance dates proposed in the 2022 CMS Interoperability and Prior Authorization
proposed rule were made with consideration of commenters' responses for implementing requirements for API development and
enhancement. Because the HIPAA proposals we make here only include the technical standards that support one of the APIs CMS
finalized in that rule, we believe it is appropriate to propose a shorter compliance timeframe.

Therefore, we believe it is reasonable to follow the statutory timeline for new standards in section 1175(b)(1) of the Act.
We propose a compliance date 24 months after the modified standard is adopted, which would be 60 days after a final rule appears
in the
Federal Register
. Aligning with the statutory requirement for initial standards, we propose that small health plans would have an additional
12 months before being required to comply with the modified standards. We believe that proposing to provide small health plans
an additional 12 months would be appropriate considering CMS's existing requirements for impacted payers. We believe that
health insurance companies that do not offer health plans as MA organizations, Medicaid MCOs, CHIP managed care entities,
or QHP issuers on the FFEs would more likely be small health plans than the impacted payers. As non-impacted payers, they
would be less likely to be on the path to implementing a Prior Authorization API using these proposed HIPAA transaction standards.

Therefore, we anticipate that health IT vendors that offer implementation support to health care providers and other HIPAA
covered entities would be familiar with the proposed HIPAA transaction standards by 2027. In addition to CMS requirements,
ONC has finalized certification criteria for electronic prior authorization through the ONC Health IT Certification Program
in 45 CFR 170.315(g)(31) through (33). Those certification criteria are based on the implementation of the CRD, DTR, and PAS
IGs. While those are criteria aimed at certifying health IT used by health care providers, we expect that other developers
and vendors of systems supporting health plans may gain familiarity with the proposed FHIR standards through the requirements
and resources available through the ONC Health IT Certification Program.

As discussed elsewhere in this proposed rule, pursuant to CMS rulemaking, impacted payers are already required to implement
and maintain a Prior Authorization API using the same standards as proposed here, under HIPAA. (313) CMS established 2027 compliance dates for impacted payers. Most large health insurance companies across the country offer
health plans as MA organizations, Medicaid MCOs, CHIP managed care entities, or QHP issuers on the FFEs. We expect that as
impacted payers, most non-small plans will have experience implementing a Prior Authorization API no later than 2027. In addition,
in the HTI-4 final rule, the Secretary adopted the CRD, DTR, and PAS IGs and ONC finalized associated certification criteria
for the ONC Health IT Certification Program (90 FR 37167). Therefore, we anticipate that health IT vendors that offer implementation
support to health plans, health care providers, and other HIPAA covered entities would be familiar with the proposed HIPAA
transaction standards by 2027.

We believe that many HIPAA covered entities would not want to maintain both methods of electronic prior authorization, using
the X12N transaction standards and the FHIR standards, until the compliance date. We anticipate that the enforcement discretion
we announced on February 28, 2024, would be effective through the proposed compliance dates, (314) under which HIPAA covered entities, as agreed to by trading partners, could use either standard from the effective date of
a final rule until the compliance dates.

In summary, HHS requests comment on its proposals summarized in section II.H.10. of this proposed rule, which includes the
proposals discussed above, and the CFR citations listed in Table 11.

9. Statutory Authority

These proposals are made under the authority of Title XI, Part C—Administrative Simplification, of the Act. Section 1172(b)
of the Act requires that any standard adopted be consistent with the objective of reducing the administrative costs of providing
and paying for health care. As discussed previously, we analyzed costs for the current X12N 270/271 and X12N 278 transaction
standards, as well as the proposed FHIR standards. While the present X12N transaction standards provide significant savings
versus manual or partially electronic methods of exchanging prior authorization information, evidence shows that the proposed
FHIR standards would further reduce administrative costs for health care plans and health care providers. We do not meaningfully
address clearinghouses in this proposed rule because we do not believe they play a significant role in prior authorization
transactions, that we understand are typically made directly between health care providers and health plans, and as contrasted
with clearinghouses' significant roles with many other

  HIPAA transactions. Nothing, however, would preclude the use of health care clearinghouses with respect to the proposed standards.

Using the proposed FHIR standards could significantly reduce health care providers' burden and costs by allowing them to streamline
the prior authorization processes within their clinical workflow. Health care providers might require fewer administrative
staff and be able to devote more time and resources to patient care. Similarly, by receiving requests in the comprehensive
and flexible FHIR format, we believe that health plans could find efficiencies in their prior authorization processes, including
that by receiving fewer unnecessary requests, more complete documentation, and real-time transactions health plans likely
could reduce administrative costs. In addition, because CMS's interoperability rulemaking already requires impacted payers
to implement and maintain a Prior Authorization API that meets the proposed HIPAA transaction standards, moving away from
the present X12N transaction standards would allow them to reduce duplicative systems.

Section 1172(c)(1) of the Act requires adopted standards to be developed, adopted, or modified by an SSO. Section 1171(8)
of the Act and 45 CFR 160.103 define an SSO as an organization that is accredited by ANSI that develops standards for information
transactions, data elements, or any other standard that is necessary to, or will facilitate, the implementation of Part C
(Administrative Simplification) of Title XI of the Act. HL7 is an ANSI-accredited SSO that meets these requirements, as demonstrated
when HHS named it a DSMO as described in 45 CFR 162.910 (65 FR 50373). (315 316)

On December 10, 2025, HHS organized a listening session with the four organizations named in section 1172(c)(3)(B) of the
Act and the six DSMOs (some of which are both) regarding the use of a FHIR standard for prior authorization transactions. (317) HHS invited each organization to present remarks as well as to submit written materials to meet the consultation requirements
in section 1172(c)(3)(A) of the Act. Those organizations were asked to opine on the impact, benefits, and costs of adopting
FHIR as the HIPAA transaction standard for those transactions. In addition, we asked for feedback on whether adopting FHIR
would reduce portal usage, how to manage version updates, and feedback on the CDex IG for attachments. During that session
we heard from each organization, and their feedback has been incorporated into the discussion of the proposals in this section.

Section 1172(d) of the Act requires the Secretary to establish specifications for implementing each of the adopted standards.
As discussed previously, the proposed specifications are: (1) the base FHIR standard; (2) US Core IG, (3) SMART App Launch
IG; (4) CRD IG; (5) DTR IG; and (6) PAS IG. Section 1172(e) of the Act requires that a standard adopted under this part shall
not require disclosure of trade secrets or confidential commercial information by a person required to comply with this part.
We do not believe anything in this proposed rule would require parties to disclose trade secrets or confidential commercial
information.

Section 1172(f) of the Act requires the Secretary to rely on the recommendations of the NCVHS, appropriate federal and state
agencies, and private organizations, and provides that the Secretary shall publish in the
Federal Register
any NCVHS recommendation regarding the adoption of a standard. Section 1172(c)(3) of the Act provides that the Secretary may
not adopt a standard that has been developed, adopted, or modified by an SSO unless the SSO consulted with four named organizations:
the National Uniform Billing Committee (NUBC), the National Uniform Claim Committee (NUCC), the Workgroup for Electronic Data
Interchange (WEDI), and the American Dental Association (ADA). As discussed previously, we relied on the NCVHS's July 28,
2022 recommendation letter to HHS to develop these HIPAA transaction standard proposals. The ADA, one of the named organizations
in the statute, stated that the X12N transaction standards are not working for dentistry, and that FHIR-based solutions should
be developed and replace the HIPAA transactions for dentistry. In addition to the ADA, NUCC and WEDI, organizations named
for consultation in section 1172 of the Act, submitted comment letters in response to the NCVHS's Request for Public Comment,
which we have also reviewed.

Section 1173(a)(4)(A) of the Act requires that the standards: (1) to the extent feasible and appropriate, enable determination
of an individual's eligibility and financial responsibility for specific services prior to or at the point of care; (2) be
comprehensive, requiring minimal augmentation by paper or other communications; (3) provide for timely acknowledgment, response,
and status reporting that supports a transparent claims and denial management process; and (4) describe all data elements
in unambiguous terms, require that such data elements be required or conditioned upon set terms in other fields, and generally
prohibit additional conditions (except where necessary to implement state or federal law, or to protect against fraud and
abuse). In addition, section 1173(a)(4)(B) of the Act requires that, in adopting standards and operating rules for transactions
referred to under paragraph (1), the Secretary seeks to reduce the number and complexity of forms (including paper and electronic
forms) and data entry required by patients and providers.

Our proposals to adopt the FHIR standards would directly and specifically address and satisfy these requirements. Specifically,
the CRD IG, which we propose to adopt for “eligibility for a health plan” transactions related to prior authorizations, could
be used at the point-of-care to determine an individual's eligibility, coverage, and benefits for health care services, which
could affect the patient's financial responsibility. The real-time nature of these transactions could increase the frequency
that this information could be determined before or at the point-of-care, so that providers could discuss options with patients
based on their individual coverage and prior authorization requirements. The FHIR standards that we propose to adopt for “referral
certification and authorization” transactions would be more comprehensive than the current X12N transaction standards adopted
in 45 CFR 162.1302, and could provide more timely acknowledgment, response, and status reporting for prior authorizations
which could support a more transparent claims and denial management process. In addition, as discussed previously, based on
the HIPAA exceptions testing, the FHIR standards have demonstrated that they require minimal augmentation by paper or other
communications and reduce

  clerical burden on patients and providers.

Section 1175(b)(2) of the Act requires the Secretary, when adopting a modification to a standard, to set an appropriate compliance
date, considering the time needed to comply due to the nature and extent of the modification. That compliance date may not
be less than 180 days from the date the modification is adopted. In addition, the Secretary may extend the time for compliance
for small health plans, if appropriate. As discussed previously, we propose a 24-month interval between adoption and compliance,
which we believe is an appropriate period for HIPAA covered entities to implement the proposed standards. In addition, we
propose to provide small health plans with an additional 12 months.

10. Summary of Standards Proposals for Prior Authorization Related Transactions

In summary, we request comment on our proposals related to prior authorization transactions and on the CFR citations listed
in Table 11, and specifically on the following:

• The proposal to define prior authorization to mean transmissions described in 45 CFR 162.1301(a) used by health care providers
to obtain authorization for health care, and transmissions described in 45 CFR 162.1301(c) used by health plans to respond
to such requests (see section II.H.2. of this proposed rule).

• The alternative proposal to adopt the FHIR standards of this proposed rule for all “referral certification and authorization transactions” described in 45 CFR 162.1301 (see section II.H.2. of this proposed rule). • The proposal to modify the current operating rules that are associated with the “eligibility for a health plan” transaction to exclude prior authorization-related transmissions (see section II.H.5. of this proposed rule).

• The proposal to adopt the following FHIR specifications as the standard for dental, professional, and institutional “eligibility
for a health plan” transactions for health care eligibility inquiry and response, when used to determine whether prior authorization
is required: HL7 FHIR, Release 4.0.1. US Core IG, STU 6.1.0; SMART App Launch IG, Release 2.0.0; CRD IG, Version 2.2.1—STU
2.2 (see section II.H.6. of this proposed rule).

• The proposal to adopt the following FHIR specifications as the standard for dental, professional, and institutional “referral
certification and authorization” transactions, within the proposed definition of prior authorization: HL7 FHIR, Release 4.0.1;
US Core IG, STU 6.1.0; SMART App Launch IG, Release 2.0.0; and CRD IG, Version 2.2.1—STU 2.2; DTR IG, Version 2.2.0—STU 2.2;
and the PAS IG, Version 2.2.1—STU 2.2 (see section II.H.6. of this proposed rule).

• The proposal to adopt the CDex IG, Version 2.1.0—STU 2.1 as the attachments standard for prior authorization transactions
(see section II.H.7. of this proposed rule).

• The proposal to adopt modified standards for dental, professional, and institutional health care eligibility transactions
when used to determine whether prior authorization is required with a compliance date 24 months from the effective date of
a final rule, except for small health plans, for which the compliance date would be 36 months from the effective date of a
final rule (see section II.H.8. of this proposed rule).

• The proposal to adopt modified standards for dental, professional, and institutional prior authorization transactions in
45 CFR 162.1302(f) with a compliance date 24 months from the effective date of a final rule, except for small health plans,
for which the compliance date would be 36 months from the effective date of a final rule (see section II.H.8. of this proposed rule).

• The proposal to adopt the proposed standard for attachments to prior authorization transactions in 45 CFR 162.1303 with
a compliance date 24 months from the effective date of a final rule, except for small health plans, for which the compliance
date would be 36 months from the effective date of a final rule (see section II.H.8. of this proposed rule).

In addition, HHS requests comment on the following:

• Whether adopting the FHIR standards for prior authorization transmissions and retaining the currently adopted X12N transaction
standards for other referral certification transmission use cases would increase burden on HIPAA covered entities to maintain
the ability to conduct electronic transactions using two different standards (see section II.H.2. of this proposed rule).

• Whether there are benefits to maintaining the existing X12N 278 transaction standard, currently adopted in 45 CFR 162.1302,
for referral certification transmissions (see section II.H.2. of this proposed rule).

• Should HHS adopt any later versions of the proposed standards, including more recent versions that are currently available
and versions that may become available between the publication of the proposed and final rules (see section II.H.6. of this proposed rule)?

• Should HHS rely on the HL7's Major.Minor.Patch approach to reflect that updates from the adopted version are maintenance
changes that do not require additional rulemaking (see section II.H.6. of this proposed rule)?

• Rather than adopting the CDex IG, would it be appropriate to recommend it at this time to give the industry an opportunity
to test the CDex IG in real-world applications (see section II.H.7. of this proposed rule)?

• Would adopting the CDex IG affect HIPAA covered entities' ability to implement the other proposed FHIR standards (without
attachments) for prior authorization transactions before the proposed compliance date, discussed later in this section? Should
HHS finalize a later compliance date for CDex to phase implementation of these proposals (see section II.H.7. of this proposed rule)?

• Conversely, would it be economical for HIPAA covered entities to implement the CDex IG at the same time as the proposed
prior authorization transaction standards (see section II.H.7. of this proposed rule)?

11. Requests for Comment

In the 2000 Standards for Electronic Transactions final rule, we finalized an exception, in 45 CFR 162.923(b), that “direct
data entry” methods of transmitting data need only conform to the data content, not the format portion, of the standard. Direct
data entry is the process by which data are directly keyed by a health care provider into a health plan's computer. While
the 2000 Standards for Electronic Transactions final rule refers to a variety of technologies, we understand that the vast
majority of direct data entry transactions take place through health plan portals. As discussed previously, the CAQH Index
reveals that prior authorization has the lowest adoption of fully electronic transactions among health care administrative
transactions, at 35 percent. Relatedly, prior authorization has the highest usage of “partially electronic” transactions,
which includes web portals and interactive voice response systems, in use by 43 percent of health plans. Because many health
plans are not required to offer electronic prior authorization, even as manual processes have decreased, the usage of partially
electronic prior authorization transactions has increased at a greater rate than fully electronic transactions.

Direct data entry portals create a significantly higher burden on health care providers than fully electronic transactions.
CAQH survey data show that providers spend an average of 16 minutes requesting prior authorization using a health plan's portal, (318) while the HL7 Da Vinci Project reported, based on its testing, the use of FHIR decreased the time required to perform the
necessary activities to request a prior authorization to 5 to 6 minutes per transaction on average. In addition, because health
care providers or their staff need to manually type information into a portal (hence the direct data entry), errors are likely
to be more common than using electronic transactions that can pull data directly from provider systems. Erroneous data can
lead to requests for clarification, delays, and additional burden on health care plans and health care providers, which can
ultimately result in worse care for patients.

Provisions for direct data entry were appropriate based on the technology available at the time of the 2000 Standards for
Electronic Transactions final rule, but subsequent technological advancements may now make it ripe to revisit that exception.
We are not making any proposals in this proposed rule, but, instead, seek comment about whether and how the exception should
be revisited for possible future rulemaking. While portal usage is most prevalent for prior authorization transactions, the
subject of this proposed rule, the direct data entry exception applies to all HIPAA Administrative Simplification transactions.

HHS requests comment on the following:

• Should we revisit the direct data entry exception in 45 CFR 162.923(b) in order to incentivize or require HIPAA covered entities to move from portal-based transactions to fully electronic transactions using the adopted standards? If so, how should we amend or remove the direct data entry exception to achieve that goal?
• Were we to amend or remove the direct data entry exception, how would that affect standard transactions other than prior authorization?
• Are there benefits to health plan web portals for HIPAA covered entities that we have not considered? Specifically, which types of HIPAA covered entities? Which types of transactions?
• What would be the burden to HIPAA covered entities of amending or removing the direct data entry exception? Specifically, which types of HIPAA covered entities? With respect to which types of transactions?
• Would amending or removing the direct data entry exception lead to greater adoption of electronic transaction standards or would it perversely incentivize HIPAA covered entities to move to fully manual transactions?
• Are there particular types of HIPAA covered entities that would be especially affected, such as small or rural health care practices? BILLING CODE 4150-28-P

BILLING CODE 4150-28-C

J. Adoption of Health Information Technology Standards and Incorporation by Reference

1. Overview

In this section, ONC proposes to adopt standards and implementation specifications in 45 CFR 170.215 for interoperability
APIs and related activities on behalf of HHS under the authority in section 3004 of the PHSA (42 U.S.C. 300jj-14). ONC proposes
these standards for adoption by HHS as part of a nationwide health IT infrastructure that supports reducing burden and health
care costs and improving patient care. ONC proposes to adopt these standards on behalf of HHS in one location within the CFR
for use within other HHS programs. These proposals reflect a unified approach across HHS to adopt standards for interoperability
API activities. This approach is intended to increase alignment across HHS and reduce regulatory burden for interested parties
subject to program requirements that incorporate these standards.

In this proposed rule, ONC is proposing to adopt updated versions of certain standards that the Secretary adopted in the HTI-4
final rule for HHS use (90 FR 37162 and 37181). ONC is proposing to adopt these updated versions (listed in section II.J.6.
of this proposed rule) in 45 CFR 170.215. If the adoption of these proposed standards is finalized, they would be indicated
for use by CMS subject to any other requirements that are finalized from this proposed rule. In addition to these updated
versions, ONC is proposing to adopt an additional standard in 45 CFR 170.215(k)(3) that supports the exchange of attachment
information for prior authorization transactions. Summaries of the standards that ONC proposes to adopt and subsequently incorporate
by reference can be found below in section II.J.8. of this proposed rule.

2. Adoption of Standards and Implementation Specifications

The Health Information Technology for Economic and Clinical Health Act (hereinafter referred to as the “HITECH Act”), Title
XIII of Division A and Title IV of Division B of the “American Recovery and Reinvestment Act of 2009” (Pub. L. 111-5), was
enacted on February 17, 2009. The HITECH Act amended the PHSA and created “Title XXX—Health Information Technology and Quality”
to improve health care quality, safety, and efficiency through the promotion of health IT and exchange of EHI. Subsequently,
Title IV of the Cures Act amended portions of the HITECH Act by modifying or adding certain provisions to the PHSA relating
to health IT.

Section 3001 of the PHSA directs the National Coordinator to perform duties in a manner consistent with the development of
a nationwide health IT infrastructure that allows for electronic use and exchange of information.

Section 3004 of the PHSA identifies a process for the adoption of health IT standards, implementation specifications, and
certification criteria, and authorizes the Secretary to adopt such standards, implementation specifications, and certification
criteria. As specified in section 3004(a)(1) of the PHSA, the Secretary is required, in consultation with representatives
of other relevant federal agencies, to jointly review standards, implementation specifications, and certification criteria
endorsed by the National Coordinator under section 3001(c) of the PHSA and subsequently determine whether to propose the adoption
of any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to
publish all determinations in the
Federal Register
.

Section 3004(b)(3) of the PHSA, which is entitled “Subsequent Standards Activity,” provides that the Secretary shall adopt
additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule
published by HITAC. As noted in the “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition
Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” final rule (80 FR 62602),
which appeared in the
Federal Register
on October 16, 2015, ONC considers this provision in the broader context of the HITECH Act and the Cures Act to grant the
Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that
have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health
IT standards, implementation specifications, and certification criteria (80 FR 62606).

Under the authority outlined in section 3004(b)(3) of the PHSA, the Secretary may adopt standards, implementation specifications,
and certification criteria as necessary even if those standards have not been recommended and endorsed through the process
established for the HITAC under section 3002(b)(2) and (3) of the PHSA. Moreover, while HHS has traditionally adopted standards
and implementation specifications at the same time as adopting certification criteria that reference those standards, the
Secretary's authority under section 3004(b)(3) of the PHSA is not limited to adopting standards or implementation specifications
at the same time certification criteria are adopted.

Finally, the Cures Act amended the PHSA by adding section 3004(c), which specifies that in adopting and implementing standards
under section 3004, the Secretary shall give deference to standards published by SDOs and voluntary consensus-based standards
bodies.

3. Alignment With Federal Advisory Committee Activities

The HITECH Act established two federal advisory committees, the Health IT Policy Committee (hereinafter referred to as the
“HITPC”) and the Health IT Standards Committee (hereinafter referred to as the “HITSC”). Each committee was responsible for
advising the National Coordinator on different aspects of health IT policy, standards, implementation specifications, and
certification criteria.

Section 4003(e) of the Cures Act amended section 3002 of the PHSA and replaced the HITPC and HITSC with one committee, the
HITAC. After that change, section 3002(a) of the PHSA now establishes that the HITAC advises and recommends to the National
Coordinator standards, implementation specifications, and certification criteria relating to the implementation of a health
IT infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. The
Cures Act specifically directs the HITAC to advise on two areas: (1) a policy framework to advance an interoperable health
IT infrastructure (section 3002(b)(1) of the PHSA); and (2) priority target areas for standards, implementation specifications,
and certification criteria (section 3002(b)(2) of the PHSA).

For the policy framework, as described in section 3002(b)(1)(A) of the PHSA, the Cures Act tasks the HITAC with providing
recommendations to the National Coordinator on a policy framework for adoption by the Secretary consistent with the Federal
Health IT Strategic Plan under section 3001(c)(3) of the PHSA. In February of 2018, the HITAC made recommendations to the
National Coordinator for the initial policy framework and subsequently published a schedule in the
Federal Register
and an annual report on the work of the HITAC and ONC to implement and evolve that

  framework. [(319 320)]() For the priority target areas for standards, implementation specifications, and certification criteria, section 3002(b)(2)(A)
  of the PHSA identifies that, in general, the HITAC would recommend to the National Coordinator, for purposes of adoption under
  section 3004 of the PHSA, standards, implementation specifications, and certification criteria and an order of priority for
  the development, harmonization, and recognition of such standards, specifications, and certification criteria. In October
  2019, the HITAC finalized recommendations on priority target areas for standards, implementation specifications, and certification
  criteria. [(321)]()

4. Interoperability Standards Advisory

ONC's ISA supports the identification, assessment, and public awareness of interoperability standards and implementation specifications
that can be used by the health care industry to address specific interoperability needs. (322 323) The ISA is updated on an annual basis based on recommendations received from public comments and subject matter expert feedback.
This public comment process reflects ongoing dialogue, debate, and consensus among industry and interested parties when more
than one standard or implementation specification could be used to address a specific interoperability need.

The ISA currently includes the implementation specifications proposed in section II.J.6. of this proposed rule. ONC encourages
interested parties to review the ISA to better understand key applications for the implementation specifications it is proposing
for adoption in this rule.

5. National Technology Transfer and Advancement Act

The National Technology Transfer and Advancement Act of 1995 (hereinafter referred to as the “NTTAA”) (Pub. L. 104-113, enacted
March 07, 1996; 15 U.S.C. 3701 et seq.) and OMB Circular A-119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary
consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular
A-119 provide exceptions to electing only standards developed or adopted by voluntary consensus bodies, namely when doing
so would be inconsistent with applicable law or otherwise impractical. Agencies have the discretion to decline the use of
existing voluntary consensus standards if it is determined that such standards are inconsistent with applicable law or otherwise
impractical, and instead use a government-unique standard or other standard. In addition to the consideration of voluntary
consensus standards, the OMB Circular A-119 recognizes the contributions of standardization activities that take place outside
of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be
inconsistent with applicable law or otherwise impracticable, other standards should be considered that meet the agency's regulatory,
procurement or program needs; deliver favorable technical and economic outcomes; and are widely utilized in the marketplace.

6. Proposal To Adopt Standards for Use by HHS

Consistent with sections 3004(b)(3), 3001(b), and 3001(c) of the PHSA, ONC proposes to adopt standards in 45 CFR 170.215(j),
(k), (m), and (n) on behalf of the Secretary to support the continued development of a nationwide health IT infrastructure
and support ongoing federal alignment of standards for interoperability and health information exchange. ONC previously adopted
versions of these standards in the HTI-4 final rule (90 FR 37130). In addition, ONC is proposing to adopt an additional standard
in this proposed rule, the HL7 Da Vinci Clinical Data Exchange (CDex) Implementation Guide (IG) in 45 CFR 170.215(k)(3). Specifically,
ONC proposes to adopt the following versions of the standards and incorporate them by reference in 45 CFR 170.299(g).

• HL7 FHIR® Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.2.1—STU 2.2 (proposed in 45 CFR 170.215(j)(1)(ii)). (324)

ONC previously adopted version 2.0.1—STU 2 of the CRD IG in 45 CFR 170.215(j)(1)(i) in the HTI-4 final rule (90 FR 37167).
This updated version of the CRD IG includes improvements such as setting clearer expectations for handling failure states,
correcting contexts for order-dispatch, clarifying expectations for mandatory hook support, and setting expectations for endpoints
and endpoint discovery. This version also includes substantive clarifications, corrections, and enhancements for the Coverage
Information FHIR extension, which is a core profile in the IG by which payer systems communicate coverage and prior authorization
requirements to provider systems.

• HL7 FHIR® Da Vinci Documentation Templates and Rules (DTR) Implementation Guide, Version 2.2.0—STU 2.2 (proposed in 45 CFR 170.215(j)(2)(ii)). (325)

ONC previously adopted version 2.0.1—STU 2 of the DTR IG in 45 CFR 170.215(j)(2)(i) in the HTI-4 final rule (90 FR 37167).
This updated version of the DTR IG includes improvements such as aligning endpoint discovery language with CRD IG requirements,
addressing CMS enforcement discretion regarding the use of X12N 278 transaction standard, requiring DTR clients to appropriately
manage access to data that is sensitive per policy and regulatory requirements when responding to queries from a DTR application,
and streamlining questionnaire retrieval if the CRD workflow is used in combination with the DTR workflow.

• HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.2.1—STU 2.2 (proposed in 45 CFR 170.215(j)(3)(ii)). (326)

ONC previously adopted version 2.0.1—STU 2 of the PAS IG in 45 CFR 170.215(j)(3)(i) in the HTI-4 final rule (90 FR 37167).
This updated version of the PAS IG includes improvements such as clarifying how to

  cancel an entire prior authorization claim instead of cancelling individual items, addressing concerns about required fields
  that are specified in the license restricted X12N TRN03 guide (which is referenced within the PAS IG), and updating the guide
  to be compliant with US Core IG STU 3.1.1, 6.0.1, and 7.0.0. This version also provides new guidance regarding how a provider
  system can query the payer system for a specific prior authorization submission, and new requirements to support the “rest-hook”
  subscription channel by which payer systems can provide updates on prior authorization submissions.

• HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.2.0—STU
2.2 (proposed in 45 CFR 170.215(k)(1)(ii)). (327)

ONC previously adopted version 2.0.0—STU 2 of the CARIN IG for Blue Button in 45 CFR 170.215(k)(1)(i) in the HTI-4 final rule
(90 FR 37182). This updated version of the CARIN IG for Blue Button includes improvements such as additional updates to ensure
alignment with US Core IG STU 7.0.0 and 6.1.0, updates to certain profiles, updates and refinements to codes identified in
the IG, and updates to search parameters.

• HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.1.0—STU 2.1 (proposed in
45 CFR 170.215(m)(2)). (328)

ONC previously adopted version 2.0.1—STU 2 of the PDex US Drug Formulary IG in 45 CFR 170.215(m)(1) in the HTI-4 final rule
(90 FR 37182). This updated version of the PDex US Drug Formulary IG includes improvements such as updated references to multiple
versions of US Core IG, guidance for more granular pharmacy benefits, updates to search parameters, and guidance regarding
authentication.

• HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.2.0—STU 1.2 (proposed in 45 CFR 170.215(n)(2)). (329)

ONC previously adopted the version 1.1.0—STU 1.1 US of the PDex Plan Net IG in 45 CFR 170.215(n)(1) in the HTI-4 final rule
(90 FR 37182). This updated version of the PDex Plan Net IG includes improvements such as updates to dependencies to reference
multiple versions of the US Core IG, updates to dependencies to reference the HL7 FHIR Da Vinci—Health Record Exchange (HRex)
IG, Version 1.1.0—STU 1.1, updates to search parameters, and the addition of a bulk export operation.

• HL7 FHIR® Da Vinci Clinical Data Exchange (CDex) Implementation Guide, Version 2.1.0—STU 2.1 (proposed in 45 CFR 170.215(k)(3)). (330)

ONC proposes to adopt version 2.1.0—STU 2.1 of the CDex IG in this proposed rule. In section II.H.7. of this proposed rule,
HHS is proposing to adopt the CDex IG as the attachment standard for prior authorization transactions under the required HIPAA
Administrative Simplification provisions. ONC is separately proposing to adopt this standard in 45 CFR 170.215(k)(3) to make
it available for use by other programs; for instance, programs that may wish to incorporate this standard into regulations
to align with the HIPAA Administrative Simplification requirements, if the proposals in section II.H.7. of this proposed rule
are finalized.

In summary, ONC requests comment on our proposals in the CFR citations listed in Table 12, and specifically on the proposal
to adopt standards in 45 CFR 170.215(j), (k), (m), and (n) on behalf of the Secretary.

7. Proposed Expiration Dates for Certain Versions of Adopted Standards

Finally, ONC proposes to add an expiration date of January 1, 2028, to corresponding versions of standards currently in 45
CFR 170.215(j), (k), (m), and (n) if our proposals to adopt newer versions of adopted standards and specifications in 45 CFR
170.215(j), (k), (m), and (n) are finalized. ONC proposes this expiration date to provide certified health IT developers and
other entities required to use these standards with a transition period during which they may update and deploy health IT
conformant with either the existing or updated versions of these standards. After the expiration date, only non-expired versions
of the relevant standards in 45 CFR 170.215(j), (k), (m), and (n) would be available for use. ONC believes that a coordinated
transition period that establishes a single expiration date across the relevant IGs in 45 CFR 170.215(j), (k), (m), and (n)
would create consistency for industry and facilitate interoperability by ensuring that health IT systems leveraging these
standards under different HHS programs use the same baseline standards for the same use cases. In addition, ONC believes a
transition period would allow those health IT developers and other entities required to use these standards flexibility to
complete development towards the existing standards in 45 CFR 170.215(j), (k), (m), and (n), and to iterate to newer standards.

However, ONC also believes that this flexibility may lead to more heterogeneity where some deployed health IT uses one standard
and other deployed health IT uses newer versions of those standards, thus complicating shared goals with CMS to facilitate
a FHIR-based ecosystem for prior authorization, payer to payer exchange, and patient access to coverage information. Therefore,
ONC is proposing an alternative approach to updating these standards. Specifically, as an alternative to the proposal above,
ONC proposes to remove and replace standards in 45 CFR 170.215(j), (k), (m), and (n) with the standards it has proposed upon
the effective date of a final rule, without providing for a transition period during which multiple versions of each standard
would be available for HHS use.

ONC understands that both certified health IT developers and other health IT developers wish to have a single, baseline standard
across use cases as quickly as practicable for purposes of consistency and interoperability. We believe this alternative proposal
could help advance this goal, particularly in areas such as electronic prior authorization. For instance, under this alternative
proposal, a certified health IT developer with a Health IT Module certified to the “provider prior authorization API—documentation
templates and rules” criterion for electronic prior authorization in 45 CFR 170.315(g)(32), and currently using the standard
in 45 CFR 170.215(j)(2)(i) (which is the DTR IG, Version 2.0.1—STU 2), would need to use the newer version of the standard
to remain certified to the criterion in 45 CFR 170.315(g)(32) as of the effective date of a final rule, which ONC proposes
in this rule to be the DTR IG, Version 2.2.0—STU 2.2.

In summary, ONC requests comment on our proposals in the CFR citations listed in Table 12, and specifically on the following:

• The proposal to add an expiration date of January 1, 2028, to corresponding standards currently in 45 CFR 170.215(j), (k), (m), and (n) if our proposals to adopt newer versions of these standards are finalized.
• The alternative proposal to remove and replace the standards in 45 CFR 170.215(j), (k), (m), and (n) with the newer versions of the standards, without a transition period for use of multiple versions.

8. Incorporation by Reference

The Office of the Federal Register has established requirements for materials (for example, standards and implementation specifications)
that agencies propose to incorporate by reference in the CFR (79 FR 66267, 1 CFR 51.5(b)). Specifically, 1 CFR 51.5(b)(2)
requires agencies to discuss, in the preamble of a proposed rule, the ways that the materials they incorporate by reference
are reasonably available to interested parties and how interested parties can obtain the materials; and summarize, in the
preamble of the proposed rule, the material it proposes to incorporate by reference.

To make the materials ONC intends to incorporate by reference reasonably available, it provides a URL for the standards and
implementation specifications. In many cases, these standards and implementation specifications are directly accessible through
the URLs provided. In most of these instances, access to the standard or implementation specification can be gained through
no-cost (monetary) participation, subscription, or membership with the applicable SDO or custodial organization. Alternatively,
a copy of the standards may be viewed for free at the U.S. Department of Health and Human Services, Office of the National
Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201. Please call (202) 690-7171 in advance
to arrange inspection.

The NTTAA and the OMB Circular A-119 require the use of, wherever practical, technical standards that are developed or adopted
by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and
OMB Circular A-119 provide exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies,
namely when doing so would be inconsistent with applicable law or otherwise impractical. As discussed in section II.J.5. of
this preamble, ONC has followed the NTTAA and OMB Circular A-119 in proposing standards and implementation specifications
for adoption, including describing any exceptions in the proposed adoption of standards and implementation specifications.
Over the years of adopting standards and implementation specifications for certification, ONC has worked with SDOs, such as
HL7, to make the standards it proposes to adopt, and subsequently adopt and incorporate by reference in the
Federal Register
, available to interested parties. As described previously, this includes making the standards and implementation specifications
available through no-cost memberships and no-cost subscriptions.

As required by 1 CFR 51.5(a), ONC provides summaries of the standards it proposes to adopt in 45 CFR 170.215(j), (k), (m),
and (n), and subsequently incorporate by reference in 45 CFR 170.299(g). ONC and CMS also provide relevant information about
these standards and implementation specifications throughout the preamble.

Application Programming Interface Standards—45 CFR 170.215

• HL7 FHIR® Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.2.1—STU 2.2, March, 27, 2026.

URL: https://hl7.org/fhir/us/davinci-crd/2.2.1/en/

This is a direct access link.

Summary: The CRD IG defines a workflow to allow payers to provide information about coverage requirements to health care providers
through their provider systems at the time treatment decisions are being made. This would ensure that clinicians and administrative
staff have the capability to make informed decisions and meet the requirements of the patient's insurance coverage.

• HL7 FHIR® Da Vinci Documentation Templates and Rules (DTR) Implementation Guide, Version 2.2.0—STU 2.2, March 27, 2026.

URL: https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/

This is a direct access link.

Summary: The DTR IG provides a mechanism for payers to express their documentation requirements computably in a way that allows clinicians
and other EHR users to navigate and quickly specify the needed information in a context-specific way. The guide allows rules
to be written in a way that supports automatically extracting existing EHR information for review/confirmation and adjusting
the information prompted for based on what data is already known or entered to minimize impact on provider time while expediting
subsequent payer interactions.

• HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.2.1—STU 2.2, March 27, 2026.

URL: https://hl7.org/fhir/us/davinci-pas/2.2.1/en/

This is a direct access link.

Summary: The PAS IG enables direct submission of prior authorization requests from EHR systems using FHIR. The IG also defines capabilities
around the management of prior authorization requests, including checking the status of a previously submitted request, updating
a previously submitted request, and canceling a request. Direct submission of prior authorization requests from the EHR can
result in faster prior authorization decisions, reducing costs for both providers and payers and improving patient experience.

• HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.2.0—STU
2.2, March 27, 2026.

URL: https://hl7.org/fhir/us/carin-bb/STU2.2/

This is a direct access link.

Summary: The CARIN IG for Blue Button Framework and Common Payer Consumer Data Set (CPCDS) provides a set of resources that payers
can display to consumers via a FHIR API. The CARIN IG for Blue Button was defined by the CARIN Alliance to meet the requirements
in the 2020 CMS Interoperability and Patient Access final rule for impacted payers to make available claims and encounter
data via Patient Access, Provider Access, and Payer-to-Payer APIs. This IG is primarily used to exchange financial (claims
and encounter) data, with some limited associated clinical data.

• HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.1.0—STU 2.1, February 26,
2025.

URL: https://hl7.org/fhir/us/davinci-drug-formulary/STU2.1/

This is a direct access link.

Summary: The PDex US Drug Formulary IG defines a FHIR interface to a health insurer's drug formulary information for patients/consumers.
The primary use cases for this FHIR interface enable consumers, members, and patients to understand the costs and alternatives
for drugs that have been prescribed, and to compare their drug costs across different insurance plans.

• HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.2.0—STU 1.2, February 5, 2025.

URL: https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.2/

This is a direct access link.

Summary: The PDex Plan Net IG defines a FHIR interface to access information about a health insurer's insurance plans, their associated
networks, and the organizations and providers that participate in these networks. Publication of these data through a standard
FHIR API would enable third parties to develop applications through which consumers and providers can query the participants
in a payer's network that may provide services that address their health care needs.

• HL7 FHIR® Da Vinci Clinical Data Exchange (CDex) Implementation Guide, Version 2.1.0—STU 2.1 February 11, 2025.

URL: https://build.fhir.org/ig/HL7/davinci-ecdx/

This is a direct access link.

Summary: The CDex IG helps implementers use FHIR-based interactions to exchange specific clinical data between providers and payers
(or other providers). This IG documents the Direct Query, Task-Based, and Attachments transaction approaches for requesting
and sending information. Key scenarios this IG can support include requesting and sending attachments for claims and prior
authorization transactions, requesting documentation to support payer operations such as claims audits, and exchanging clinical
data between referring providers.

III. Requests for Information

This section contains RFIs only. In accordance with the implementing regulations of the “Paperwork Reduction Act of 1995”
(hereinafter referred to as “PRA”), specifically 5 CFR 1320.3(h)(4), this general solicitation is exempt from the PRA. Facts
or opinions submitted in response to general solicitations of comments from the public that appear in the
Federal Register
or other publications, regardless of the form or format thereof, provided that no person is required to supply specific information
pertaining to the commenter, other than that necessary for self-identification, as a condition of the agency's full consideration,
are not generally considered information collections and therefore not subject to the PRA.

Respondents are encouraged to provide complete but concise responses. These RFIs are issued solely for information and planning
purposes; they do not constitute a Request for Proposal (RFP), applications, proposal abstracts, or quotations. These RFIs
do not commit the U.S. Government to contract for any supplies or services or make a grant award. Further, CMS is not seeking
proposals through these RFIs and will not accept unsolicited proposals. Responders are advised that the U.S. Government will
not pay for any information or administrative costs incurred in response to these RFIs; all costs associated with responding
to these RFIs will be solely at the interested party's expense. Not responding to these RFIs does not preclude participation
in any future procurement, if conducted. It is the responsibility of the potential responders to monitor these RFI announcements
for additional information pertaining to this request. Please note that CMS will not respond to questions about the policy
issues raised in these RFIs. CMS may or may not choose to contact individual responders. Such communications would only serve
to further clarify written responses. Contractor support personnel may be used to review RFI responses. Responses to this
notice are not offers and cannot be accepted by the U.S. Government to form a binding contract or issue a grant. Information

  obtained as a result of these RFIs may be used by the U.S. Government for program planning on a non-attribution basis. Respondents
  should not include any information that might be considered proprietary or confidential. These RFIs should not be construed
  as a commitment or authorization to incur cost for which reimbursement would be required or sought. All submissions become
  U.S. Government property and will not be returned. CMS may publicly post the comments received, or a summary thereof.

A. Request for Information: Electronic Event Notifications for Value-Based Care and Care Coordination

1. Background

In the 2020 Centers for Medicare & Medicaid Services (CMS) Interoperability and Patient Access final rule (85 FR 25510), CMS
finalized changes to the condition of participation (CoP) regulation in 42 CFR 482.24(d) to require hospitals—including psychiatric
hospitals (42 CFR 482.61(f)), Critical Access Hospitals (CAHs) (42 CFR 485.638(d)), and Rural Emergency Hospitals (REHs) (42
CFR 485.540(d))—that utilize a health information technology (health IT) system conforming to the Health Level Seven (HL7®)
v2.5.1 standard in 45 CFR 170.205(d)(2) to make a reasonable effort to send electronic event notifications to all applicable
post-acute care (PAC) services providers and suppliers, as well as to any of the following practitioners and entities, which
need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes: (1)
the patient's established primary care practitioner; (2) the patient's established primary care practice group or entity;
or (3) other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group
or entity, primarily responsible for his or her care. Facilities must send real-time electronic notifications to the designated
practitioners or entities when a patient is admitted to, transferred to, or discharged from the facility, including emergency
department visits. For purposes of this Request for Information (RFI), applicable PAC services providers and suppliers would
be those PAC services providers and suppliers with whom the patient has an established care relationship with prior to admission.
Additionally, a relationship is established when a patient is being transferred or referred for additional care for purposes
of treatment and/or care coordination post-discharge from the hospital.

In the years since the finalization of these requirements, we have received feedback from interested parties about hospitals'
success implementing electronic event notifications and the degree to which these notifications are effectively reaching the
recipients intended under the regulation. Survey data show that in 2022, three out of four non-federal acute care hospitals
routinely electronically notified a patient's primary care provider upon his or her entry to the hospital's emergency department—a
percentage that has nearly doubled since 2012. (331) Seventy percent of all hospitals routinely electronically notified primary care providers inside the hospital's system, whereas
59 percent of all hospitals routinely electronically notified physicians outside the hospital's system. Additionally, in 2023,
the Office of the Assistant Secretary for Planning and Evaluation (ASPE) reported that over 80 percent of nursing homes and
home health agencies have electronic health records (EHRs), (332) but only 16 percent of hospitals reported sending summary of care records to most PAC providers. (333) While these data reflect broader information exchange rather than electronic event notifications specifically, they suggest
that exchange with PAC providers occurs less frequently than with primary care or hospital-based providers. Thus, while the
share of hospitals reporting that they routinely send electronic event notifications has continued to grow over time, we understand
that some hospitals and providers that should receive these notifications may continue to face implementation challenges.

In addition, we recognize that there are entities other than those specified in 42 CFR 482.24(d) whose involvement in a patient's
care may support improved care coordination when they receive electronic notifications from hospitals. While current requirements
do not explicitly state accountable care organizations (ACOs) as required recipients of electronic event notifications, many
patients are under the care of a primary care practitioner or primary care practice group that is part of an ACO or other
value-based care entity, and the regulation does not prohibit hospitals from sending notifications to these entities. Additionally,
the CMS State Operations Manual hospital interpretive guidance (QSO-21-18) (334) explains that hospitals may notify additional entities, including ACOs, based on facility policy or patient attribution lists.
Commenters who supported the final rule noted that greater availability of electronic event notifications created the potential
for improved care coordination with providers outside of hospitals and primary care (for example, behavioral health providers,
social services providers, etc.) (85 FR 25510). Finally, we recognize that payers that conduct care management activities
for patients may also benefit from receiving patient event notifications.

Since CMS finalized these requirements in 42 CFR 482.24(d), technical standards and solutions that support electronic event
notifications when a patient is admitted to, transferred to, or discharged from a care facility, have continued to advance.
For example, health information exchanges (HIEs) and other data exchange networks continue to facilitate exchange of HL7 v2
admission, discharge, and transfer (ADT) data between hospitals, physician groups, and other clinicians by automatically routing
electronic event notification information to organizations that belong to the HIE or network. (335 336) Survey data from 2023 found that ADT capabilities are widely supported by HIEs nationwide, with 96 percent of HIEs routinely
receiving notifications from hospitals and routing them to primary care physicians. (337)

Nationwide connectivity facilitated through the Trusted Exchange Framework and Common Agreement

  (TEFCA) [(338)]() may offer further opportunities to ensure electronic event notifications shared by hospitals are able to reach authorized
  recipients. Additionally, standards development activities have focused on a new paradigm for receiving ADT data. The HL7
  Subscriptions Framework enables the establishment of proactive electronic event notifications from a Fast Healthcare Interoperability
  Resources (FHIR®) server to another system for a wide number of potential use cases, including ADT data. [(339 340)]() Specifically, we note that the HL7 Da Vinci Unsolicited Notifications Implementation Guide (IG) includes an Admit/Discharge/Transfer
  use case and we are monitoring this effort as it evolves within HL7's consensus-based standards development process. [(341)]()

2. Request for Information

CMS seeks public comments on the following:

• Use and Content of Patient Event Notifications ++ In the 2020 CMS Interoperability and Patient Access final rule, we finalized a minimum set of information that must be shared as part of a patient electronic event notification but encouraged hospitals to send more information, if possible (85 FR 25587). To what degree are hospitals sending additional information with patient electronic event notifications and what additional information is being sent?

++ What data standards, if any, are hospitals using to send that additional information with patient electronic event notifications?
What standards could be used to improve the minimum set of information that currently must be shared?

++ What can CMS do to expand the use of patient event notifications and provider engagement with those notifications to improve
patient care?

++ What additional information should be included in patient event notifications, beyond the minimum set of information that
hospitals are currently required to send (patient name, treating practitioner name, and sending institution name), for more
effective and useful patient event notifications to better support transitions of care?

++ What are the challenges with standardizing patient event notifications?

++ What operational or technical challenges could hospitals, CAHs, and REHs face if CMS were to require additional standardized
data elements related to patient care to be included with the patient event notifications?

++ If additional data elements are included in patient event notifications, how can technology mitigate any additional clinician
burden?

++ Are there privacy or data governance considerations if hospitals include additional information in patient electronic event
notifications?

++ Could additional process requirements or guidance (for example, minimums for directory entry updates/corrections/removals
or outreach/verification efforts) improve the quality of notifications or the likelihood that notifications are delivered
to intended recipients?

• Types of Providers and Entities Receiving Patient Event Notifications ++ How are ACOs or payers that are currently receiving patient event notifications receiving them? What innovative strategies have ACOs or payers employed to receive patient event notifications? Do ACOs or payers that receive patient event notifications use the information in a meaningful way?

++ What actions should CMS consider, such as updating the hospital CoP, that would encourage or require hospitals to exchange
alerts with any ACO and other PAC provider and supplier types or payers to which a patient is attributed or assigned?

++ What challenges prevent hospitals from sharing electronic event notifications with ACOs and other PAC provider and supplier
types today?

++ How do hospitals receive authorization to send an electronic event notification to an ACO? What are the challenges for
hospitals to receive that authorization?

++ Should CMS encourage or require hospitals to send alerts to emergency medical services (EMS)? Behavioral health providers?
Pharmacies? Social service providers? Other provider types?

++ What challenges do long-term care or PAC providers face in receiving patient event notifications? What steps could CMS
take to help address these challenges?

++ To what extent do PAC providers currently receive patient electronic event notifications in a timely manner to support
safe admission, transfer, or follow-up care? How have hospitals integrated electronic event notification requirements with
discharge planning requirements to enhance post-discharge continuity of care?

++ What processes are in place for attribution and patient matching between hospitals and ACOs or other value-based care arrangements,
payers, PAC facilities, long-term care facilities, social service providers, EMS providers, behavioral health providers, etc.?
Are these adequate? What is missing from these processes?

++ How can improved standardization, sharing, and use of provider directories contribute to better electronic event notifications?

• Complementary Policy Approaches ++ In what ways could CMS leverage other programs, such as the Medicare Promoting Interoperability Program to advance the use of patient event notifications? For instance, what measures could CMS add to the Medicare Promoting Interoperability Program for eligible hospitals and CAHs that assess the degree to which notifications are sent to recipients?

++ What are other ways that CMS could incentivize improved delivery and use of patient event notifications?

++ In what ways could CMS coordinate with the Office of the National Coordinator for Health Information Technology (ONC) to
establish certification criteria for health IT that would enable authorized users, including authorized ACOs or other value-based
care providers, to be able to subscribe to patient event notification alerts?

++ How could CMS leverage the TEFCA (342) network to improve the quality of notifications and/or improve the likelihood that electronic event notifications shared by
hospitals are able to reach authorized recipients?

• Technical Approaches to Patient Electronic Event Notifications ++ Under current CoP requirements, hospitals have significant flexibility in the technical approaches they use to implement patient electronic event notifications. What technical approaches are most widespread among hospitals to send patient electronic event notifications? What are the key benefits and challenges hospitals face with current technical approaches used?

++ What technical approach(es) would provide additional functionality/

  value to the patient event notification process (for example, the HL7 Subscriptions Framework and HL7 Da Vinci Unsolicited
  Notifications IG discussed above)? Can the HL7 FHIR Da Vinci Member Attribution (ATR) List IG (ATR List IG) be utilized as
  part of patient event notifications? [(343)]() How does network participation or status impact this process?

++ How can CMS incentivize or require hospitals to adopt more advanced approaches to electronic event notifications? Are the
CoPs the most appropriate policy vehicle to define technical requirements for notifications? What other policy levers should
CMS consider besides the CoPs to more effectively implement new technical approaches to electronic event notifications?

++ What standards-based mechanisms exist or could be improved to support authorized ACOs or other value-based care entities,
payers, and other provider types to be able to subscribe to patient event notification alerts? For example, could certain
standards or requirements for patient matching improve event notifications?

• Enforcement ++ To what degree have existing enforcement mechanisms for the CoPs helped to advance compliance with patient event notification requirements?

++ What additional steps, if any, should CMS take to strengthen existing enforcement mechanisms and address concerns about
some hospitals not adhering to the patient event notification requirements?

++ What additional guidance, technical assistance, or other supports could CMS provide to help hospitals improve compliance
and effective use of patient event notifications?

B. Request for Information: Increasing Health Care Resiliency

1. Health Care Cybersecurity Background

The health care system is increasingly reliant on a digital infrastructure to store and transmit sensitive health care data,
and more organizations are consolidating their resources and technology to improve efficiency. The reliance on digital infrastructure
and large information technology (IT) systems, run by industry players that span the nation and interact with a high volume
of large payers, may create vulnerabilities that could be exploited by cybercriminals. Recent security breaches, ransomware
attacks, and other incidents have disrupted health care operations, put patient safety and privacy at risk, and potentially
undermined public and private sector initiatives to move towards new standards and technologies. The Centers for Medicare
& Medicaid Services (CMS) is committed to enhancing the resilience of the health care system against cyber threats.

Statistics show a disturbing trend in the vulnerability of health care organizations to cyber threats. As noted in the “HIPAA
Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information” proposed rule (90 FR 898) (hereinafter
referred to as the “HIPAA Cybersecurity proposed rule”), which appeared in the
Federal Register
on January 6, 2025, between 2018 and 2023, the number of breaches of unsecured protected health information (PHI) reported
to the Department of Health and Human Services (HHS) grew at an alarming rate (100 percent increase), as did the number of
individuals affected by such breaches (950 percent increase). The reports reflect rampant escalation of cyberattacks using
hacking (260 percent increase) and ransomware (264 percent increase) (90 FR 913). Cyber incidents affecting hospitals and
health systems have led to extended care disruptions, delayed medical procedures, and data loss, all putting patient safety
at risk. These breaches impact a variety of IT systems, including network servers, email accounts, electronic health records
(EHRs), desktop and laptop computers, and portable electronic devices. With 77 percent of breaches of unsecured PHI reported
to the Office for Civil Rights (OCR) that affected 500 or more individuals impacting network servers in 2023, it is critical
to protect health systems and patients with vigilance. (344)

According to a 2025 report, health care has remained the most expensive industry for electronic data breaches since 2011,
with the average data breach costing $7.42 million. (345) The sector continues to be highly vulnerable to cyberattacks, putting patient safety at risk. Notably, financial consequences
associated with breaches have worsened in recent years. The cost of post-breach responses and lost business rose by 11 percent
from 2023 to 2024, underscoring the persistent challenges that health care organizations face in securing sensitive data.

There are several statutes and regulations promulgated to prevent and mitigate data breaches within the health care sector.
First, as part of HIPAA, Congress authorized the Secretary to promulgate standards for protecting the privacy and security
of certain health information. (346) The HIPAA Security Rule requires that covered entities and their business associates implement administrative, physical, and
technical safeguards to ensure the confidentiality, integrity, and availability of electronic protected health information
(ePHI). (347 348) These safeguards include many long-standing cybersecurity best practices, such as conducting periodic risk analyses, implementing
risk management processes, establishing data backup and disaster recovery plans, implementing security incident procedures,
conducting security training, implementing access and audit controls, reviewing system activity, and encrypting ePHI where
reasonable and appropriate. (349) The HIPAA Security Rule also requires covered entities and business associates (both defined in 45 CFR 160.103) to review
and modify their security measures to continue provision of reasonable and appropriate protection of ePHI. (350)

Second, the Federal Information Security Management Act of 2002 (hereinafter referred to as “FISMA”) (351) (Title III, Pub. L. 107-347, enacted December 17, 2002) (amended in 2014) provides for additional guidelines and security
standards; it requires all federal agencies to implement agency-wide FISMA-compliant information security programs and to
review these programs annually. FISMA requirements impact both federal agencies and contractors to the extent: (a) contractors
collect or maintain information “by or on behalf of an agency;” or (b) there are “information systems used or operated by
an agency or by a contractor of an agency or other organization on behalf

  of an agency.” [(352)]() As a consequence, state and local government agencies that receive federal funding and/or administer federal programs, and
  private organizations with a contractual relationship with the federal government that involves the creation, collection,
  storage, and/or processing of federal data may be subject to FISMA. For example, Medicare Administrative Contractors (MACs),
  private health care organizations that contract with CMS to administer Part A and Part B medical claims and claims for durable
  medical equipment, prosthetics, orthotics, and supplies (DMEPOS) items for Medicare fee-for-service (FFS) beneficiaries, are
  subject to FISMA requirements according to the Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (Pub.
  L. 108-173, enacted December 8, 2003). [(353 354 355)]()

Third, the HITECH Act was enacted to promote nationwide adoption and standardization of health IT to support electronically
sharing clinical data. (356) Congress acknowledged that security challenges emerged with health IT adoption and mandated stronger safeguards for privacy
and security of ePHI in the HITECH Act. Among other changes with respect to HIPAA, the HITECH Act extended the HIPAA Security
Rule to apply to business associates, making them directly liable for violations of the HIPAA Security Rule and required business
associate agreements to include new security-related provisions. (357) In addition, the HITECH Act directed the Secretary to regularly issue guidance on the most appropriate and effective technical
safeguards. (358) The HITECH Act was amended in 2021 to require the Secretary to consider, as a mitigating factor, adequately demonstrated implementation
of recognized security practices in certain HIPAA Security Rule investigations and audit determinations. (359)

The White House's 2024 National Security Memorandum on Critical Infrastructure Security and Resilience reaffirmed “Healthcare
and Public Health” as a critical infrastructure sector, underscoring the ongoing federal focus on cybersecurity protection
for health care systems. (360) Subsequently, HHS published the HIPAA Cybersecurity proposed rule, which would strengthen cybersecurity by updating the HIPAA
Security Rule's standards to better address ever-increasing threats to the health care sector. These efforts reflect the federal
government's commitment to both addressing data breaches through enhanced cybersecurity measures and advancing secure digital
health innovation through foundational initiatives announced in support of the new digital health ecosystem. Key components
of these initiatives include enhanced Medicare Plan Finder tools, improved interoperability frameworks, and early adopter
programs, all designed with cybersecurity as a core element. (361 362) These initiatives demonstrate HHS' recognition that effective health care technology adoption must be balanced with comprehensive
security measures to protect patient data and maintain system resilience. Several other HHS agencies have issued guidance
on securing electronic information systems and electronic health information (EHI). In 2016, ONC released the Safety Assurance
Factors for EHR Resilience (SAFER) Guides, which provide foundational, infrastructure, and clinical process guides to support
health care organizations in addressing EHR best practices and methods to optimize safe use of EHRs. (363) To encourage adoption of these recommended safety practices, CMS established attestation measures as part of the Medicare
Promoting Interoperability and the MIPS Promoting Interoperability performance category of the Quality Payment Program (QPP). (364) In 2025, ONC released an updated version of the SAFER Guides, which streamline the best practices presented in the guides
and incorporate recent evidence on safety practices. (365)

In addition, since 2016, OCR has published cybersecurity newsletters and videos to help HIPAA covered entities and business
associates respond to cybersecurity incidents to safeguard ePHI to prevent, detect, contain, mitigate, and recover from cybersecurity
threats, and improve compliance with the HIPAA Security Rule. (366 367) Additionally, ONC, in collaboration with OCR, has developed a downloadable Security Risk Analysis tool to help health care
providers conduct security risk assessments, as required by the HIPAA Security Rule. (368) The tool is specifically designed to be used by medium and small health care providers to reveal areas where their organization's
PHI could be at risk.

In 2023, the Health Sector Coordinating Council (HSCC), the Cybersecurity and Infrastructure Security Agency (CISA), and HHS
began working together to produce a toolkit with resources, training, information, and tools to support efforts to improve
health care cybersecurity. Among the

  resources in this toolkit is the Healthcare Sector Cybersecurity Strategy Concept Paper, which outlines a health care cybersecurity
  strategy built on the 2023 National Cybersecurity Strategy. [(369 370)]() Specifically, the paper focuses on four pillars of action to promote resiliency among hospitals, patients, and communities:
  (1) produce Cybersecurity Performance Goals (CPGs), (2) work with Congress to develop incentives and support for hospitals
  to improve cybersecurity, (3) increase accountability and coordination within the health care system, and (4) expand and mature
  the one-stop shop within HHS for health care sector cybersecurity. The CPGs are delineated into two categories to help health
  care entities prioritize cybersecurity practices: (1) essential goals, which include mitigating known vulnerabilities; email
  security; multifactor authentication; basic cybersecurity training; strong encryption; revoking credentials for departing
  workforce members, including employees, contractors, affiliates, and volunteers; basic incident planning and preparedness;
  unique credentials; separate user and privileged accounts; and vendor/supplier cybersecurity requirements; and (2) enhanced
  goals, which include asset inventory; third-party vulnerability disclosure; third-party incident reporting; cybersecurity
  testing; cybersecurity mitigation; detecting and responding to relevant threats and tactics, techniques, and procedures; network
  segmentation; centralized log collection; centralized incident planning and preparedness; and configuration management. [(371)]()

Additionally, the Administration for Strategic Preparedness and Response (ASPR) and the National Institute of Standards and
Technology (NIST) collaborated to produce the “Health Care and Public Health Sector Cybersecurity Framework Implementation
Guide” in 2023. (372) The implementation guide (IG) is intended to help Health Care and Public Health Sector organizations implement the NIST Cybersecurity
Framework as an integral part of their cybersecurity and cyber risk management programs. Also in 2023, the HHS 405(d) Program
published the “Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients,” and the Federal Trade Commission
(FTC) produced the “Start with Security: A Guide for Business,” both containing best practices, methodologies, and guidelines
for protecting the security of ePHI. (373 374) In February 2024, NIST published an updated Cybersecurity Resource Guide to provide practical guidance for covered entities
to safeguard ePHI and better understand the security concepts discussed in the HIPAA Security Rule. (375)

Despite these efforts, the health care sector remains a prime target for cyberattacks, and these attacks have a significant
impact on stakeholders. Cyberattacks can lead to data breaches, loss of privacy, and potentially life-threatening disruptions
in care. For example, ransomware attacks can lock health care providers out of critical IT systems, delaying surgeries, patient
care, and access to medication. (376) Health care providers face operational disruptions, financial losses due to system downtimes, and damage to their reputation. (377) At hospitals specifically, cyberattacks can lead to process slowdowns, cancelled procedures, delayed hospital or unit lockdowns
and transfers, increased wait times for individuals, and decreased health care provider capacity. (378) The post-attack restoration of IT systems and data integrity often requires substantial resources. (379) Insurance payers and other entities are affected by compromised claims systems, fraudulent activities following data breaches,
and increased premiums due to the rising costs of cybersecurity insurance. (380 381 382)

The evolving nature and sophistication of cyber threats necessitate continual reassessment and strengthening of existing regulations.

2. Request for Information

This Request for Information (RFI) is intended to delve into the vulnerabilities exposed by health care cyberattacks and to
explore strategies to make the health care system more resilient. Additionally, CMS seeks public input and perspectives about
how it can leverage its authorities to supplement regulations and guidance from other agencies, such as OCR and FTC, to improve
the health care system's preparedness, response, recovery, and resiliency capabilities for addressing cyber threats, which
have increased, and are likely to continue to increase. Comments submitted in response to this RFI regarding the HIPAA Cybersecurity
proposed rule will not be considered as part of that separate rulemaking, but only in the context of this RFI.

• Cybersecurity
  ++ How have existing statutes and regulations, within CMS's purview, shaped your cybersecurity strategies, and what changes
  or additions by CMS

  would enhance your ability to safeguard health information?

++ What are the most significant cybersecurity challenges faced by health care organizations, providers, and entities—including
hospitals, clinics, state Medicaid and Children's Health Insurance Program (CHIP) agencies, commercial plans, and other health
care stakeholders—in securing patient data and preventing and recovering from cyberattacks?

++ What are the most effective current practices, technologies, and innovative strategies for preventing, detecting, and responding
to cyberattacks in the health care sector? Should CMS propose any of these practices or strategies as regulatory requirements
within its purview?

++ What are the major challenges and barriers that health care organizations face in implementing robust cybersecurity measures?
How have health care organizations overcome these challenges and barriers?

++ What are some best practices for cybersecurity training? How can CMS promote best practices in cybersecurity?

++ In the broader context of ransomware attacks, how do offsite backups, redundant systems, and security protocols enhance
health care resiliency? Are there other approaches, tools, or policies, within CMS's purview, that would enhance resiliency
following an attack?

++ How do the enrollment and implementation processes for health care clearinghouses affect the health care industry's ability
to remain resilient? How could this be improved?

++ What perspectives, needs, barriers, and challenges specifically affect the ability of health care providers in small and
rural practices, who participate in health care programs within CMS's authority, to improve their cybersecurity preparedness,
response, recovery, and resiliency?

• Standards and Technologies ++ What standards and technologies, within CMS's purview, should CMS re-evaluate to support a more resilient health care system?

++ How do the standards for interoperability, including those required in previous interoperability rules or proposed to be
required in this proposed rule, interact with the requirements of the HIPAA Security Rule to promote health care resiliency,
and how can CMS use its authority: (1) to fill regulatory gaps, if any, to improve the resilience of the health care industry;
or (2) to reduce duplicative requirements in a way that does not threaten the security of patient data?

++ How could the Trusted Exchange Framework and Common Agreement (TEFCA) be used to support health care resiliency goals?

++ How can interoperability be improved in a manner that enhances, rather than compromises, security?

• Point-to-Point Connections ++ What are the potential benefits and challenges of a health care system with more point-to-point connections?

++ What role do health care clearinghouses play in supporting point-to-point connections, and what role do they play in supporting
the exchange of health care data?

++ What options are available or recommended for streamlining transition processes, including moving from one health care
clearinghouse to another, when one is impacted by a cyber attack?

C. Request for Information: Improving Implementation of Payer Application Programming Interface Technology

1. Background

As the U.S. health care system increasingly adopts digital solutions to enhance care delivery, the interoperability of these
systems becomes crucial. Interoperability, facilitated by application programming interfaces (APIs), allows different health
information technology (health IT) systems and software apps to communicate, exchange data, and effectively use the information
that has been exchanged. (383)

The Centers for Medicare & Medicaid (CMS) interoperability initiative has a mission to “promote the secure exchange, access,
and use of electronic health information (EHI) to better support informed decision making and a more efficient health care
system.” (384) To support this mission, CMS has taken several actions to improve interoperability in health care, including working with
standards developing organizations (SDOs) to promote the development of Health Level Seven (HL7®) Fast Healthcare Interoperability
Resources (FHIR®) standards and associated implementation guides (IGs), implementing standardized APIs at CMS, and requiring
impacted payers to exchange data via FHIR APIs in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability
and Prior Authorization final rules (85 FR 25510 and 89 FR 8758). (385)

Even as standardized API usage increases throughout the health care system, CMS continues to receive stakeholder reports of
incomplete or broken API implementations, which have the potential to impede interoperability, patient safety, and the security
of EHI. In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, commenters emphasized the importance
of making available test data, staging environments, sandboxes, and other mechanisms to help developers test their software
and prevent non-standard implementation of APIs across the industry. For example, missing or incorrect data due to non-conformant
implementation could result in incomplete health information being exchanged. CMS seeks to reduce these risks and to improve
health care interoperability by exploring opportunities to ensure that required APIs are effectively implemented. While CMS
is proposing to require certain IGs in this rule to improve API interoperability, strengthening oversight mechanisms could
further enhance standardization and ensure APIs are implemented correctly. We emphasize that we are not proposing a requirement
for certification in this proposed rule; rather, CMS seeks to establish a roadmap to promote consistent implementation among
payers.

As discussed in section II.A.4.b. of this proposed rule, the technical requirements for the FHIR APIs we finalized in the
2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules include general
requirements for impacted payers to test their interoperability APIs (see, for instance, requirements for Medicare Advantage
(MA) plans in 42 CFR 422.119(c)(2)). We are considering how we can build on those testing requirements. For instance, the
open-source Inferno testing tool is available for developers to create, execute, and share conformance tests for numerous
FHIR-based standards and IGs. The Office of the National Coordinator for Health Information Technology (ONC)

  has developed test kits within Inferno that can be used by payers to test their APIs' conformance with certain versions of
  the FHIR standards and IGs. [(386)]() Inferno is available to download for local deployment and is hosted on ONC's website at *https://inferno.healthit.gov/.*

CMS strongly encourages payers to utilize available testing tools, such as Inferno, to meet the existing testing requirements.
We also encourage payers to publish their test results to demonstrate conformance with the technical requirements. We are
further considering additional requirements that would increase transparency as to whether an API has been tested for conformance
through such tools. For instance, we could consider requiring impacted payers to publish testing results or report them to
CMS, for CMS to potentially publish. Doing so could increase transparency and trust that API technology deployed by payers
has been properly implemented to facilitate interoperability. While such a requirement may initially focus on testing with
the existing Inferno tools, we are also interested in how such a requirement could incorporate other testing tools that may
be developed in the future to meet payers' needs. For instance, the National Coordinator has historically approved alternative
test methods under the ONC Health IT Certification Program. (387)

We have also received feedback from the public that, in addition to demonstrating API conformance with the required standards,
the availability of a “sandbox environment” is an important approach to ensuring that systems seeking to access an API can
test and develop robust connections. We believe that such environments could accelerate durable connections between third-party
apps and payers' APIs, and we are considering whether to propose to require impacted payers implement and maintain a sandbox
environment for testing.

While the ideas we have described previously could be proposed as discrete provisions for each API, we also request public
comment on an overarching certification approach to the interoperability APIs. For instance, the ONC Health IT Certification
Program's testing and certification infrastructure could provide a streamlined approach to demonstrate conformance with technical
requirements. The ONC Health IT Certification Program, established under section 3001(c)(5) of the PHSA, is a voluntary program
for health IT developers and is designed to ensure the availability and functionality of certified health IT (referred to
as Health IT Modules) using adopted health IT standards. In the program, developers certify their Health IT Modules by demonstrating
conformance to standards adopted by the Department of Health and Human Services (HHS) through specific certification criteria
and using test procedures (that may have associated test tools and/or test data) approved by the Secretary. Certification
criteria are established via notice-and-comment rulemaking, updated, and maintained by ONC. While the ONC Health IT Certification
Program has predominantly focused on electronic health records (EHRs) and other health IT systems used by providers, certification
criteria under the program may also be developed for health IT intended for other types of users.

Such an approach was explored as part of the HTI-2 proposed rule, in which ONC proposed certification criteria in 45 CFR 170.315(g)(30),
(32), (33), (35), and (36) intended for health IT used by payers. These certification criteria corresponded to each of the
interoperability APIs finalized in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior
Authorization final rules (89 FR 63498 and 63582-63590) and were designed to complement and support CMS's interoperability
efforts to improve access to EHI for patients, providers, and payers through FHIR APIs. The proposed certification criteria
would have allowed health IT developers to voluntarily certify their products to standards and specifications in 45 CFR 170.213
and 45 CFR 170.215 (89 FR 63580). In the HTI-4 final rule, ONC finalized three new Prior Authorization API certification criteria
in 45 CFR 170.315 (g)(31), (32), and (33) (90 FR 37175). ONC subsequently withdrew the remaining HTI-2 proposed rule proposals
that had not yet been finalized as part of a notice which appeared in the
Federal Register
on December 29, 2025 (90 FR 60602). While ONC has not finalized those proposals, we are still seeking comment on whether such
an approach could provide value in the future.

2. Request for Information

• Roadmap for Consistent Implementation of Payer API Technology ++ What program components are most important to establishing robust oversight mechanisms for payers' APIs? How can CMS balance testing requirements to ensure interoperability while minimizing burden on payers and health IT developers delivering technology to payers?

++ What aspects of API implementation pose the most significant implementation difficulties, and where do commenters perceive
the potential for lack of conformance with the API technical requirements?

++ What aspects of API implementation should be prioritized for testing? Where would testing requirements have the greatest
impact and benefit?

++ What are current best practices for testing conformance with API technical requirements?

++ What should testing platforms and processes look like?

++ What existing API testing tools (besides the Inferno tool discussed above) could be employed as part of the testing for
payer APIs?

++ What criteria could or should be used to identify new API testing tools?

++ In addition to initial conformance testing, should CMS establish requirements for interoperability testing between and
among multiple systems, that are conformant to identified IGs, to facilitate real-world deployments of such systems?

• Certification of Payer API Technology ++ What value would the certification of payer API technology provide to payers, providers, and patients? What would be the benefits and burdens of requiring certification of payer API technology for payers, providers, and patients?

++ If ONC were to establish criteria for payer API technology, should CMS require certification to meet payer API requirements,
or should such certification be made available solely on a voluntary basis? Would payers or developers of API technology providing
solutions to payers be likely to obtain certification on a voluntary basis?

++ What could a roadmap to certifying payer API technology look like? What are the intermediate steps that may be taken toward
payer API technology certification?

++ If payer API technology certification is not appropriate at this time, how would CMS and ONC know when conditions exist
to propose certification criteria and requirements?

D. Request for Information: Step Therapy

1. Step Therapy Background

Step therapy is a form of utilization management used by some payers to control costs. (388) It is often referred to as a “fail-first” strategy because it requires patients to try various preferred prescription drugs
and find them to be ineffective or contraindicated for patient use before the payer will approve a more expensive or non-preferred
drug option. (389) In some cases, step therapy programs require patients to try one or more generic drugs before brand name drugs are approved
or to try a preferred class of drugs that are less costly before allowing a switch to a more expensive or non-preferred drug
class. (390) Authorization of the non-preferred drug may require attestation by the provider that the patient took the initial drug and
experienced adverse effects or that the initial drug provided inadequate clinical benefit. Legislation requiring payers to
allow providers to exempt patients from step therapy protocols under certain circumstances, such as if the drug was ineffective
in the past or if the drug will likely cause adverse reaction or harm, has been enacted in 29 states. (391) As set forth in the “Modernizing Part D and Medicare Advantage To Lower Drug Prices and Reduce Out-of-Pocket Expenses” final
rule (84 FR 23832), which appeared in the
Federal Register
on May 23, 2019, the Centers for Medicare & Medicaid Services (CMS) allowed Medicare Advantage (MA) plans to apply step therapy
as a utilization management tool for Part B drugs to both prevent overutilization of medically unnecessary health services
and control costs, but only if, starting contract year 2020, the plan uses a Pharmacy and Therapeutic committee to review
and approve the step therapy programs (84 FR 23832).

When developed and implemented appropriately, step therapy can use evidence-based criteria along with clinically-reasonable
provisions for exceptions to encourage more rational prescribing in an effort to control drug costs and ensure that patients
are receiving clinically based data-driven drug regimens. (392) However, if step therapy requirements are based on poor evidence or implemented using an inflexible approach, it can cause
clinical issues for patients forced to return to a drug or class of drugs that were previously ineffective, potentially delaying
access to treatments, hindering adherence to drug regimens, and risking severe side effects and disease progression for patients.
A concerning instance of step therapy interrupting a preferred drug regimen can be observed when a patient changes payers
due to a change in job or employer-provided coverage. In this circumstance, the patient who had previously failed a drug regimen
may unexpectedly be subjected to new step therapy requirements, forcing them to switch from their current drug to whatever
agent is the “first step” in their new plan. In states without laws regulating step therapy practices, this means that providers
are unable to choose what they believe to be the best treatment options for their patients but instead must try alternative
options first that have been mandated by the payer. In the 29 states that require payers to allow exemptions, providers must
either try the drug(s) the payer's step therapy protocol requires or complete paperwork justifying their treatment choice,
which can impose a significant burden on the provider and can negatively impact patients as they wait for effective treatment. (393)

2. Request for Information

While payers should be allowed to implement reasonable evidence-based policies to avoid unnecessary expenses incurred by suboptimal
prescribing practices, CMS is soliciting public comment on whether increased interoperability of information technology (IT)
systems across payers could be used to make utilization management policies, such as step therapy, more transparent.

CMS is interested in how technology and data sharing, such as via the Payer-to-Payer application programming interface (API),
might streamline the step therapy process by giving payers access to historical drug therapies that a patient may have already
tried and automating the utilization management process rather than requiring providers to submit historical records or attest
to prior drug regimens. CMS seeks comment on how technology may facilitate step therapy determinations and improve current
step therapy processes.

• Technology and Step Therapy ++ How could increased interoperability make the criteria for covering a given drug clear to patients and providers; allow providers to obtain permission to override the step therapy protocol for clinically appropriate documented reasons (for example, a patient's intolerance of or poor response to first step treatments); and increase the efficiency of the process for submitting information, ideally as part of electronic prescribing systems?

++ How could technology and data sharing, such as via the Payer-to-Payer API, support streamlined step therapy solutions?
For example, if a patient changes plans, how could technology facilitate honoring step therapy determinations that a prior
payer completed? Additionally, how could data sharing between payers provide automated solutions to evaluating step therapy
requirements?

++ What other technical solutions, in addition to or in lieu of, a Payer-to-Payer API, could facilitate fast, efficient, accurate,
and streamlined step therapy determinations?

• Step Therapy by Previous Payer ++ What are the standard practices for payers applying step therapy criteria to a new patient who is currently stable on a medication? How does the payer obtain documentation to support that a patient has satisfied a previous payer's step therapy requirements or is currently stable on the drug(s)?

++ Given that payers may have different formularies and step therapy requirements, how can payers evaluate step therapy requirements
and formulary options from a previous payer to apply their step therapy requirements to the same medication?

++ If a previous payer has already required step therapy and made a determination, what obligation should a new payer have
to recognize and apply the previous payer's determination, if any, and how could this reduce burden on providers and payers?

++ If a new payer requires step therapy after a patient has satisfied a previous payer's step therapy requirements, what is
the value of requiring the patient to meet step therapy requirements again for the new

  payer? To reduce burden, is there a timeframe during which payers should honor a step therapy determination from a previous
  payer, and, if so, what would be the appropriate timeframe?

++ What information is necessary or beneficial for a new payer to receive to make decisions about accepting a prior payer's
step therapy decisions? Additionally, what challenges could payers face to implement systems to support this transaction,
and would there be a cost impact to payers?

E. Request for Information: Laboratory Tests and Durable Medical Equipment, Prosthetics, Orthotics, and Supplies Items

1. Laboratory Tests and Durable Medical Equipment, Prosthetics, Orthotics, and Supplies Items Background

Prior authorization requirements from health insurers for laboratory tests and Durable Medical Equipment, Prosthetics, Orthotics,
and Supplies (DMEPOS) items have emerged, in some instances, as a potential barrier to care and coverage, impacting both patients
and health care providers. While prior authorization has a role to play for program integrity purposes, such as preventing
fraud and reducing waste on unnecessary medical resources, it may also prevent or delay appropriate care with improper denials
and extended decision periods.

CMS has taken meaningful steps to reduce the burden associated with prior authorization processes across the health care industry.
For instance, the 2024 CMS Interoperability and Prior Authorization final rule included requirements for impacted payers to
improve prior authorization processes through policies and technology (89 FR 8758). Beginning in 2027, impacted payers will
be required to implement and maintain a Prior Authorization application programming interface (API) to improve the electronic
exchange of health care data related to the prior authorization processes (89 FR 8897). Once operational, impacted payers'
Prior Authorization APIs will be populated with a list of non-drug items and services requiring prior authorization, as well
as documentation requirements, which should facilitate the assembly of necessary information for health care providers to
submit a complete prior authorization request. In addition, through the Wasteful and Inappropriate Service Reduction (WISeR)
model, CMS is aiming to leverage advanced technology plus clinician review to assure that Medicare payments for certain high-risk
items/services are timely and appropriate. (394) WISeR will run for 6 performance years from January 1, 2026 to December 31, 2031 in six states: New Jersey, Ohio, Oklahoma,
Texas, Arizona, and Washington. (395)

While CMS has made strides towards streamlining prior authorization processes, such as in the 2024 CMS Interoperability and
Prior Authorization final rule, current prior authorization processes in the private health insurance industry may lead to
unintended negative impacts. While Medicare fee-for-service (FFS) does not require prior authorization for laboratory tests,
recent publications have raised concerns that the length of time it takes for prior authorization requests to be approved
for laboratory tests from private payers may cause delays in care. (396 397 398) Timely access to diagnostic testing is a critical component to manage acute and chronic conditions, and delays may hinder
effective treatment decisions and ultimately patient safety. For example, when a health care provider places an order for
a patient to have laboratory tests drawn, the health care provider often sends the patient to a laboratory that is in the
same facility, or nearby, to have laboratory tests drawn that day. Often, the patient and laboratory do not know that prior
authorization is required or whether a prior authorization request has been submitted until after laboratory tests are drawn
or the claims for the laboratory tests are denied. When a laboratory discovers that prior authorization is missing, it may
not be authorized to start the process itself. We have received anecdotal feedback that some payers do not allow a laboratory
to request prior authorization. (399) Further, if the patient waits for notice of an approved prior authorization decision, it could delay medically necessary testing,
which has the potential to delay diagnosis and treatment, leading to worsened health outcomes.

Additionally, a review of currently published literature indicates that some Medicare Advantage (MA) plans may be misusing
prior authorizations to inappropriately delay or deny services or payment. (400) Some MA plans may improperly rely on the Medicare Part B laboratory “date of service” policy (hereinafter referred to as “DOS”
policy) in 42 CFR 414.510(a), which provides that the DOS is generally the date of specimen collection for purposes of determining
how a laboratory service should be billed to Medicare, as a basis to deny prior authorization. (401) In the MA context, when a health care practitioner does not get prior authorization before ordering a laboratory test or before
the sample is collected, which is often the case, the laboratory will attempt to get prior authorization once it receives
the order. In some cases, the MA plan may deny the laboratory's prior authorization request on the grounds that the DOS has
already occurred, citing the Part B laboratory DOS policy as the basis for this determination. This practice of relying on
the DOS policy to deny prior authorization is not compliant with rules in the MA program. The DOS policy is a Medicare FFS
policy that does not set the scope of basic benefits applicable to the MA program. (402) When

  applying prior authorization for basic benefits, prior authorization processes for MA coordinated care plans may only be used
  to confirm the presence of diagnoses or other medical criteria that are the basis for coverage determinations for the specific
  item or service or to ensure an item or service is medically necessary based on standards specified in 42 CFR 422.101(c)(1). [(403)]() While MA plans could choose to adopt the laboratory DOS policy as a payment or billing rule in their contracts with health
  care providers, it would be wholly inconsistent with 42 CFR 422.138(b) to apply the DOS policy as a basis to deny a request
  for prior authorization of laboratory services that have not yet been performed.

Further, CMS is aware that differences between medical documentation requirements for Medicare Administrative Contractors
(MACs), MA plans, and other payers may lead to health care provider confusion and burden. Specifically, some MACs and MA plans
may not accept a test requisition form (TRF) or a physician attestation as valid medical documentation to establish the medical
necessity of a laboratory test, which can contribute to administrative burden and consume valuable time from health care providers
that could otherwise be spent with patients.

Similar issues may arise with certain prior authorization requests related to DMEPOS items since prior authorization is required
for many types of DMEPOS items. Beginning January 1, 2026, MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed care entities are required to provide notification of prior authorization decisions within
7 calendar days after receiving a standard prior authorization request and 72 hours after receiving an expedited prior authorization
request. (404) While that shortened decision timeframe should alleviate some of the burden associated with prior authorization requests,
industry representatives have reported that differing documentation requirements can lead to denials of prior authorization
requests, resulting in extra time spent by clinicians to complete additional medical evaluations and justifications for DMEPOS
items. (405 406) Another area of concern is length of the prior authorization determination appeals process, which can also take months to
complete, further prolonging patient access to necessary equipment.

Similar to prior authorizations generally, varying payer prior authorization requirements can add complexity and burden for
health care providers and patients to receive prior authorization for DMEPOS items and laboratory tests. In addition, DMEPOS
items face additional coordination challenges, as laboratories and the DMEPOS suppliers are often reliant on the ordering
health care provider to submit a prior authorization request on behalf of the patient; however, because the medical item or
service is not being furnished by the health care provider, communication gaps may occur if not all parties understand the
responsibilities and requirements of the prior authorization process. Moreover, differing prior authorization requirements
across payers may result in confusion and errors in submissions. This could disrupt health care provider workflows and increase
administrative costs, which can lead to denials for procedural reasons and appeals that may take months of additional administrative
costs and efforts.

For example, in a recent scenario provided by a wheelchair supplier to CMS, a health care provider may order a wheelchair
to help a patient regain mobility. In many instances, the DMEPOS supplier is reliant on the health care provider to submit
a prior authorization request on behalf of the patient, including the supporting documentation. If prior authorization was
not submitted by the health care provider or was inadequately supported, then the payer may deny the claim, which could lead
to the wheelchair being taken from the patient, the patient being billed for the DMEPOS item, the DMEPOS supplier not receiving
payment for the wheelchair, or appeals that take time from the payer and health care provider. Similarly, DMEPOS suppliers
have noted that wheelchair repairs sometimes require prior authorization. While waiting for a prior authorization decision,
the patient's mobility may be affected, which can impact their health and quality of life.

In summary, the issues associated with prior authorization for laboratory tests and DMEPOS items are multifaceted, encompassing
potential delays in patient care, administrative burden on health care professionals, and differing requirements across payers.
Addressing prior authorization issues is essential to enhance the efficiency of health care delivery and improve patient outcomes.

2. Request for Information

CMS is soliciting public comment on how prior authorization for laboratory tests and DMEPOS items impacts patient care and
health care provider burden, and if there are opportunities to mitigate burden. CMS is interested in how automation of the
prior authorization process for DMEPOS items and laboratory services could benefit health care providers, payers, and patients,
as well as other opportunities for improving these processes.

• How do prior authorization requirements for laboratory tests and DMEPOS items currently impact patient care and health care provider burden?
• What are possible outcomes of more MACs, MA plans, or non-Medicare payers allowing a TRF to be valid medical documentation to show that a laboratory test is reasonable and necessary?
• How frequently are prior authorizations denied because the request was submitted after the specimen was collected?
• What impacts have laboratory benefit managers (LBMs) had in facilitating prior authorization processes, regulating access, and controlling payment for laboratory services?
• What opportunities for process improvement exist for prior authorization requirements? Are changes needed to make requirements even more effective at containing costs, reducing burden, and improving patient outcomes?

• How could automation of the prior authorization process for laboratory tests and DMEPOS items positively affect patient outcomes
  and potentially reduce both payer and health care provider burden?
  • What other issues exist regarding prior authorization processes for laboratory tests and DMEPOS items that technology is
  not currently addressing?

  What opportunities exist for technology to mitigate those issues?

• How do the issues associated with prior authorization impact the health care workforce and retention of skilled health care
  professionals?

IV. Collection of Information Requirements

Under the Paperwork Reduction Act of 1995 (hereinafter referred to as “PRA”) (Pub. L. 104-13, enacted May 22, 1995), 44 U.S.C.
3501-3520, we are required to provide notice in the
Federal Register
and solicit public comment before a collection of information (COI) requirement is submitted to OMB for review and approval.
To fairly evaluate whether an information collection should be approved by OMB, 44 U.S.C. 3506(c)(2)(A) requires that we solicit
comment on the following issues:

• The need for the information collection and its usefulness in carrying out the proper functions of our agency.
• The accuracy of our estimate of the information collection burden.
• The quality, utility, and clarity of the information to be collected.
• Recommendations to minimize the information collection burden on the affected public, including automated collection techniques. We request public comment on areas of this document that contain information collection requirements (ICRs).

A. Background

In the 2024 CMS Interoperability and Prior Authorization final rule, we included provisions which streamline the prior authorization
process to improve patient care while increasing efficiency (89 FR 8858). In the final rule, CMS characterized the burden
associated with implementing the finalized APIs to support interoperability and prior authorization as collections of information.
To more accurately calculate the burden in this proposed rule, the proposed policies included in this ICR section exclusively
describe the required COI, while the burden and costs associated with implementation of the proposed policies are described
in the Regulatory Impact Analysis (RIA) section under the Detailed Economic Analysis in section V.C. of this proposed rule.
If finalized, the following burden estimates would be described in an updated version of the existing PRA package OMB control
number 0938-1437 and submitted to OMB for approval. Further, CMS is pursuing additional revisions to OMB control number 0938-1437
to remove API implementation burden erroneously included in the original OMB control number 0938-1437 package. These revisions
will align the approach for calculating ICR burden across existing interoperability focused PRA packages and streamline the
content of the package for increased accuracy and fidelity to the requirements of the PRA. These revisions are described in
section IV.D. of this proposed rule and will be submitted for OMB approval along with this proposed rule.

B. Wage Estimates

To derive average costs for this proposed rule, we used data from the U.S. Bureau of Labor Statistics (BLS) National Occupational
Employment and Wage Estimates and aligned our analysis with other CMS regulatory actions. (407) Table 13 presents the median hourly wage, the cost of fringe benefits and overhead (calculated at 100 percent of salary),
and the adjusted hourly wage. We have updated our approach and data sources compared to the 2024 CMS Interoperability and
Prior Authorization final rule to create the wage table and associated calculations for this proposed rule. First, we used
the current wages published on the BLS website based on 2024 data. Second, we used updated occupational titles and codes to
reflect the current occupation listings. For example, the former title, “Database Administrators and Architects” with occupational
code 15-1245, is now “Database and Network Administrators and Architects” with occupational code 15-1240.

Additionally, per OMB's recent recommendation, we utilize the median hourly wages rather than mean hourly wages in our calculations
of labor burden.

BILLING CODE 4150-28-P

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

C. Information Collection Requirements

Consistent with our approach in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization
final rules, we determine ICRs by evaluating cost and

  burden at the payer level (85 FR 25606 and 89 FR 8947). Since the previous CMS interoperability final rules, we have continued
  to develop improvements to our methodology for estimating and describing the reporting burden imposed on impacted payers.
  To determine the number of impacted payers (also referred to as “parent organizations” [(408)]() offering impacted health plans” in the calculations) for each of the information collections in this proposed rule, we used
  information from three official government resources: (1) the 2024 Medicare Advantage Contract Directory to determine the
  number of parent organizations offering MA plans; [(409)]() (2) the Medicaid Managed Care Enrollment Report based on 2021 data to determine the number of parent organizations offering
  Medicaid managed care plans and CHIP managed care plans; [(410)]() and (3) the plan year 2024 QHP Landscape Medical Individual Market file to determine the number of parent organizations offering
  QHPs on the FFEs. [(411)]() These datasets, plus the 56 states and territories (hereinafter referred to as “states”) offering Medicaid and CHIP FFS programs,
  formed the basis for the number of parent organizations offering impacted health plans used in our calculations. [(412)]() Plan types not affected by this proposed rule, such as PACE organizations, Behavioral Health Organizations (BHOs) in Medicaid,
  and QHPs offered only on SBEs or SBE-FPs, were not included in the counts of parent organizations offering impacted health
  plans. The three applicable datasets were merged into one list of unique parent organizations, mapped to the type of health
  plans each parent organization offers.

Table 14 shows the number of parent organizations offering each type of health plan, including different combinations of health
plans.

BILLING CODE 4150-28-C The numbers in Table 14 are used to calculate the cost of compliance across all impacted payers. The estimated burden and
costs for each ICR are included at the end of this section in Table 20.

We have estimated that the total number of burden hours across impacted payers is 218,922 hours. The estimated total cost
associated with information collection burden is $17.25 million in the second year following finalization and $4.32 million
in subsequent years. All estimates will be described in the revised PRA package, OMB control number 0938-1437, which encompasses
the information collections for all CMS interoperability rules—including the proposals outlined in this proposed rule, the
2020 CMS Interoperability and Patient Access final rule, and the 2024 CMS Interoperability and Prior Authorization final rule
(85 FR 25510 and 89 FR 8758).

1. Information Collection Requirements Regarding Proposed Public Reporting of Prior Authorization Metrics for Drugs by Impacted

Payers (42 CFR 422.122, 42 CFR 440.230, 42 CFR 438.210, 42 CFR 457.732, 42 CFR 457.1230, and 45 CFR 156.223)

To increase transparency into payer prior authorization processes and to assist patients in choosing health coverage and evaluating
payer networks, we propose to require MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs to publicly report specific prior authorization metrics for drugs
on their websites. We propose that MA organizations would report at the contract level (applicable integrated plans would
also report drugs covered by MA organizations at the MA contract level), state Medicaid and CHIP FFS programs would report
at the state level, Medicaid managed care plans and CHIP managed care entities would report at the plan and program level
(if drug coverage is included in their contract), and QHP issuers on the FFEs would report at the issuer level. We propose
that MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be required to report data
annually for the previous calendar year no later than March 31, following any calendar year that the payer offers that type
of plan. For MA organizations, reporting would include prior authorizations for all

  drugs payable under Part B, and would exclude covered Part D drugs, and for state Medicaid and CHIP FFS programs and QHP issuers
  on the FFEs, data would include all drugs requiring prior authorization. We are proposing to require those impacted payers
  to publish these reports beginning March 31, 2028. We are also proposing to require Medicaid managed care plans and CHIP managed
  care entities to report data annually no later than 90 days after the end of their rating period. For Medicaid managed care
  plans and CHIP managed care entities, reports would include prior authorizations for all drugs.

To comply with reporting requirements, we estimate that impacted payers would conduct two major work phases: (1) development,
which includes defining requirements; and (2) maintenance, including an annual compilation of reports and public reporting
of metrics on a website. In the first phase, impacted payers would need to define requirements concerning the types and sources
of data that must be compiled regarding prior authorization activities for drugs and then compile the database to capture
this information. In the second phase, impacted payers must create and post the reports to a public website annually.

Table 15 itemizes the estimated activities, hours, and dollar burdens for the first-year implementation and estimated annual
maintenance costs. We assume relevant staff would include a software and web developer with a business operations specialist.

• First-year implementation would impose a total burden of 320 hours for the first year and 120 hours for subsequent years, at a per-entity cost of $33,300 and $9,400 (rounded) for the first and subsequent years, respectively.
• The aggregate burden of the first-year implementation across all 341 impacted payers included in this proposal is 109,000 hours and 41,000 hours (rounded) for the first and subsequent years, respectively, at a cost of $11.36 million and $3.20 million (rounded).

2. Information Collection Requirements for Proposed Reporting of Provider Access, Payer-to-Payer, and Prior Authorization

API Metrics to CMS by Impacted Payers (42 CFR 422.121, 42 CFR 422.122, 42 CFR 431.61, 42 CFR 431.80, 42 CFR 438.242, 42 CFR
457.731, 42 CFR 457.732, 42 CFR 457.1233, 45 CFR 156.222, and 45 CFR 156.223)

Beginning in 2026, CMS will begin collecting data from impacted payers on Patient Access API usage. As well as the finalized
Patient Access API usage metrics, we are proposing to require, beginning in 2028, impacted payers to report metrics to CMS
in the form of aggregated, de-identified data about Provider Access, Payer-to-Payer, and Prior Authorization API usage. We
propose that impacted payers would be required to annually report these data to CMS on dates appropriate to each payer's regular
reporting, contracting, or certification periods, as described earlier in this proposed rule.

We believe these data could provide insight into provider and payer use of the new APIs, the effectiveness of the CMS policies,
and any additional education and outreach in which CMS may need to engage. The annual reports would be submitted to CMS by
impacted payers. Specifically, we propose collecting the metrics outlined in section II.F.2. of this proposed rule for the
Provider Access, Payer-to-Payer, and Prior Authorization APIs. For such reporting efforts, we estimate that the impacted payers
would conduct a gap analysis of existing reports they may have already prepared, followed by appropriate tasks to develop,
produce, and submit such reports to CMS for the metrics outlined in section II.F.2. of this proposed rule.

Table 16 includes our estimates for first-year implementation and ongoing reporting tasks. Total staffing hours would be 160
and 40 hours for the first and subsequent years, respectively, at a total cost per impacted payer of $17,000 and $3,000 (rounded).
The aggregate burden for 341 parent organizations would be 55,000 hours and 14,000 hours (rounded) for the first and subsequent
years at a cost of $5.84 million and $1.07 million (rounded), respectively.

BILLING CODE 4150-28-P

3. Information Collection Requirements for Proposed Reporting of Payer API Endpoints (42 CFR 422.119, 42 CFR 422.120, 42 CFR

422.121, 42 CFR 422.122, 42 CFR 431.60, 42 CFR 431.61, 42 CFR 431.70, 42 CFR 431.80, 42 CFR 438.242, 42 CFR 457.730, 42 CFR
457.731, 42 CFR 457.732, 42 CFR 457.760, 42 CFR 457.1233, 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223)

No later than 60 days after the effective date of the final rule, CMS would require impacted payers to report API endpoints
to CMS for publication in the form of an Endpoint Resource, as defined by an unexpired version of the FHIR® standard adopted
in 45 CFR 170.215(a). New impacted payers would be required to report this information no later than 60 days before they begin
covering patients under the applicable CMS program. Further, CMS proposes to require impacted payers to report to CMS the
direct URL for their interoperability API's FHIR capability statements and one or more URLs with the required documentation
regarding authorization and authentication protocol and implementation details and API registration information. CMS would
require impacted payers to report updated information within 1 week of any changes to the reported information and verify
the reported information at least every 12 months. The proposed policy would require 2 hours of labor by a Business Operations
Specialist at an hourly rate of $78.14 or $156.28 annually. For all impacted payers, this reporting burden would be $53,291
annually, rounded ($156.28 × 341 respondents = $53,291.48).

D. Modifications to Existing OMB Control Number 0938-1437

The existing OMB control number 0938-1437 describes the burden associated with the policies finalized in the 2024 CMS Interoperability
and Prior Authorization final rule (89 FR 8758). As mentioned previously in this section, CMS seeks to streamline PRA packages
corresponding to the CMS interoperability rules.

1. API Implementation Burden

OMB control number 0938-1437 currently includes the burden associated with API implementation requirements finalized in the
2024 CMS Interoperability and Prior Authorization final rule (89 FR 8858). CMS intends to modify the PRA package to remove
the implementation burden of the API policies, as they do not reflect information collection burden as defined by the PRA
and falsely inflate the information collection burden associated with the PRA package and the 2024 CMS Interoperability and
Prior Authorization final rule. Specifically, we are removing the burden estimates associated with developing, implementing,
and maintaining the APIs finalized in the 2024 CMS Interoperability and Prior Authorization final rule and usual and customary
business costs related to prior authorization process requirements, while retaining the following burden estimates: (1) reporting
Patient Access API metrics to CMS (42 CFR 422.119, 42 CFR 431.60, 42 CFR 438.242, 42 CFR 457.730, and 42 CFR 457.1233 and
45 CFR 156.221); and (2) publicly reporting prior authorization metrics (42 CFR 422.122, 42 CFR 438.210, 42 CFR 440.230, 42
CFR 457.732, and 42 CFR 457.1230 and 45 CFR 156.223).

CMS originally calculated the PRA burden by including the cost of finalized requirements to implement and maintain the Provider
Access, Payer-to-Payer, and Prior Authorization APIs. We assumed that to implement these APIs, impacted payers would conduct
three major work phases: initial design, development and testing, and long-term support and maintenance and accounted for
these costs in the PRA package, thus inflating the estimated burden with costs not associated with COI. When updating OMB
control number 0938-1437 to reflect the burden associated with this proposed rule, CMS will remove the following costs as
outlined in Table 18.

This modification would reduce the calculated information collection cost burden by $684 million and by 6,659,425 burden hours.

2. Prior Authorization Decision Timeframe Requirement Burden

In the 2024 CMS Interoperability and Prior Authorization final rule, CMS established timeframe requirements for impacted payers
to provide prior authorization decisions (89 FR 8897). In the ICR section of the 2024 CMS Interoperability and Prior Authorization
final rule, CMS described the final policy as imposing information collection burden on the impacted payers in the form of
up-front costs for impacted payers to update their policies and procedures (89 FR 8952). We estimated that this policy would
result in 8 hours of work by a general and operations manager to update the policies and procedures, reflecting 2 half-days
of work at a per-entity cost of $967. Therefore, the total burden for all 365 impacted payers is 2,920 hours of work at a
cost of $0.35 million. However, the cost of updating internal policies and procedures by a payer is considered by CMS to be
usual and customary and does not necessitate an ICR or corresponding burden in a PRA package. CMS intended to characterize
this burden as usual and customary, which is reflected in the supporting statement for the currently approved PRA package,
but due to a technical error the burden was included in the total cost of the rule and in the burden total of the PRA package.
To correct this oversight and to avoid falsely inflating the estimated burden with costs not associated with COI, CMS would
remove these costs when updating OMB control number 0938-1437, as outlined in Table 19.

This modification would reduce the calculated burden by $0.35 million. In combination, the revisions described in Tables 18
and 19 would reduce the calculated burden from the PRA package approved under OMB control number 0938-1437 by $684.35 million.

E. Summary of Information Collection Burdens

In this section we have explained the estimated costs of individual proposals for purposes of the ICRs. Table 20 summarizes
costs for the first and subsequent years of these proposals and is based on the following assumptions:

• Certain proposals would be effective beginning 2028. However, we assume impacted payers would conduct certain activities before the compliance date to make appropriate operational, procedural, or system changes.
• We are basing our calculations on a 1 year estimate to accommodate all system, process, and reporting activities. The 1 year reflects the period from the expected publication of a proposed rule in [Placeholder Date] until the associated compliance dates.
• Labor costs in the COI are either BLS wages when a single staff member is involved or a weighted average representing a team effort, obtained by dividing the aggregate cost by the aggregate hours.
• Note that while the ICR burden calculations in Table H8 reflect differing amounts of burden in the first and subsequent implementation years, CMS will submit the revised OMB control number 0938-1437 to reflect the average annual burden amount across the first, second, and third implementation year, to align with the 3-year PRA package expiration timeframe. Table 20 provides the 3-year averages in columns “Average Annual Hours” and “Average Annual Cost.”

BILLING CODE 4150-28-C

F. Conclusion

The proposals in this proposed rule, if finalized, should lead to phased improvements of sharing data across impacted payers
and providers by requiring systems that facilitate patient data access, receipt, and exchange. We request comments on our
approaches for estimating cost burden.

We have submitted a copy of this proposed rule to OMB for its review of the rule's information and recordkeeping requirements.
These requirements are not effective until they have been approved by OMB. To obtain copies of the supporting statement and
any related forms for the proposed collections discussed previously, please visit CMS's website at https://www.cms.gov/Regulations-andGuidance/Legislation/PaperworkReductionActof1995/PRAListing.html or call the Report Clearance Office at 410-786-1326.

V. Regulatory Impact Analysis

A. Statement of Need

If finalized, the proposals in this proposed rule would place new requirements on MA organizations, state Medicaid and CHIP
FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs (collectively referred
to as “impacted payers”) (413) to enhance the electronic exchange of health care-related data and improve the prior authorization process for drugs by establishing
technology standards and process requirements. We are proposing to require these payers to publish an enhanced set of metrics
related to the prior authorization process and to report to CMS their digital endpoints to facilitate the electronic exchange
of information. Finally, HHS is proposing to modernize the HIPAA prior authorization transaction standard by replacing the
existing X12N transaction standards with FHIR® based standards. We believe these changes (proposed in 42 CFR parts 422, 431,
438, 440, and 457 and 45 CFR part 156) support CMS's efforts to reduce burden on providers while enabling them to spend more
time with their patients. Additionally, HHS believes that these changes (proposed in 45 CFR part 162) would improve prior
authorization transactions for all HIPAA covered entities. These proposals should increase electronic access to health care
data while keeping that information safe and secure. The proposals build on the foundation laid out in the 2020 CMS Interoperability
and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules to move the health care system toward
increased interoperability by enhancing impacted payers' ability to share data, encouraging health care providers to use new
capabilities, and making health-related data more easily available to patients through health apps.

B. Overall Impact

We are required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on
Improving Regulation and Regulatory Review (January 18, 2011), Executive Order 14192 on Unleashing Prosperity Through Deregulation
(January 31, 2025), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96-354), Executive Order 13272 on Proper
Consideration of Small Entities in Agency Rulemaking (August 13, 2002), section 1102(b) of the Act, section 202 of the Unfunded
Mandates Reform Act of 1995 (UMRA) (March 22, 1995, Pub. L. 104-4), and Executive Order 13132 on Federalism (August 4, 1999)
to examine the impacts of a proposed rule.

Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and,
if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental,
public health, safety effects, and distributive impacts). Section 3(f) of Executive Order 12866 defines a “significant regulatory
action” as any regulatory action that is likely to result in a rule that may: (1) have an annual effect on the economy of
$100 million or more or adversely affect in a material way the economy, a sector of the economy, productivity, competition,
jobs, the environment, public health or safety, or state, local, or tribal governments or communities; (2) create a serious
inconsistency or otherwise interfere with an action taken or planned by another agency; (3) materially alter the budgetary
impact of entitlements, grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise
novel legal or policy issues arising out of legal mandates, or the President's priorities.

Based on our estimates, the Office of Information and Regulatory Affairs (OIRA) has determined this proposed rulemaking to
be significant per section 3(f)(1) of Executive Order 12866, as the initial economic impact estimates presented in this proposed
rule approach the $100 million threshold. We have prepared a RIA that presents the estimated costs, benefits, and transfers
of this proposed rule. We note that the proposed rule impacts two overlapping but regulatorily distinct groups of entities:
impacted payers (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs) which are health plans regulated by CMS; and HIPAA covered entities, which are regulated by HHS,
and defined as “a health plan, health care clearing house, a health care provider who transmits any health information in
electronic form in connection with a transaction covered by this subchapter.” (414) We note that all impacted payers are health plans and therefore are HIPAA covered entities, but not all HIPAA covered entities are impacted payers since the scope of this category is more broad and encompasses many sectors of
the health care industry. To disentangle these two overlapping categories and clearly present the anticipated cost associated
with each policy, we divide the Cost section V.C.2. of this proposed rule, and the Initial Regulatory Flexibility Analysis
(IRFA) sections V.F.2. and V.F.3. of this proposed rule into subsections that describe HHS proposals related to HIPAA covered
entities and separately describe CMS proposals for impacted payers. In section V.C.2.a.(1). of this proposed rule describing
the HIPAA cost estimates, we attempt to isolate the HIPAA covered entities that are also impacted payers such that they are
not double counted in the burden estimates associated with adopting FHIR. Some of the proposals in this proposed rule have
information collection related burdens, and the cost associated with those ICRs is provided in Table 20 in section IV.E. of
this proposed rule. Table 25, Cost of the Proposed Rule to Impacted Payers by Year and Program, provides a summary of the
cost of CMS proposals on impacted payers, broken out by payer program and calendar year. Table 32, Cost of the Proposed Rule
to the Federal Government by Year and Program, provides a summary of the estimated costs to the federal government by payer

  program and calendar year. Specifically, this table reflects the cost of CMS proposals incurred by payers in federally funded
  programs and identifies the portion of that cost which would be covered by payments from the federal government. Finally,
  Table 33, Total Cost of Proposed Policies by Year, summarizes the cost of the entire proposed rule by describing the cost
  of each proposed provision over the next 10 years (including the ICR costs described in Table 20).

C. Detailed Economic Analysis

1. Benefits

Anticipated non-quantified benefits of this proposed rule relate to improving continuity of care and patient outcomes. Prescription
and other drug information is part of a patient's record and giving patients, providers, and payers access to claims data
for prescription and other drugs can offer valuable insights into a patient's health care, provide benefits for care coordination,
and avoid potentially harmful drug interactions. The proposal to incorporate drugs into the existing prior authorization API
requirements has the potential to improve the timeliness of prior authorization decisions for drugs and minimize prior authorization
denials, which could reduce delays in patient access to medication and limit the associated medical risk. The proposal to
align state CHIP FFS programs' and QHP issuers on the FFEs' deadlines for responses to prior authorization requests with other
impacted payers would likely result in operational efficiencies across a health plan's multiple lines of business, as there
would be a consistent expectation and policy across the different products offered by that plan. Further, the proposals to
report prior authorization metrics could benefit patients by allowing them to make better informed decisions regarding their
plan selection.

We believe that many stakeholders could benefit from the proposals in this proposed rule, but do not provide an analysis of
expected savings to impacted payers and HIPAA covered entities arising from proposed prior authorization process improvements,
use of NCPDP standards, or updates to replace current X12N transaction standards with the FHIR standard and applicable IGs
for electronic prior authorization transactions. The estimated savings associated with utilizing APIs to exchange EHI is already
described in detail in the 2024 CMS Interoperability and Prior Authorization final rule. The proposals in this proposed rule
build upon those finalized requirements by expanding the type of information exchanged, but they do not produce the same level
of quantifiable efficiencies as those created by the requirements to transition from manual prior authorization processes
to electronic prior authorization via an API. While we do not make specific assumptions about savings, we believe there could
be cost-reducing benefits associated with these provisions including reduced paperwork, faster response times, and other efficiencies. (415)

Surveys by the AMA cited in section II.C. of this proposed rule describe negative consequences of delayed prior authorizations,
including those for drugs, and stakeholders wrote about the challenges of complicated payer requirements for prior authorization
of drugs and delayed decision-making. However, we have not received specific financial information from commenters or industry
surveys. Nonetheless, we believe savings would accrue due to fewer denials and fewer appeals that would need to be processed
by impacted payers because of these proposals. Denials and appeals sometimes result from errors, missing information, lack
of specificity or clarity in guidelines or instructions. We believe that by requiring impacted payers to incorporate coverage
and documentation requirements for drugs covered under a medical benefit into the Prior Authorization API, as well as to support
the proposed NCPDP standards for electronic prior authorization of drugs covered under a pharmacy benefit, providers would
be better able to collect and submit all necessary information to conduct a prior authorization, which could reduce processing
challenges and increase efficiencies, resulting in cost savings. Further, HHS expects that the proposal to adopt FHIR standards
for HIPAA covered entities (health care providers, health plans, and health care clearinghouses) to conduct electronic prior
authorization transactions could reduce processing challenges, produce administrative efficiencies, and create savings long-term.

2. Costs

a. Rulemaking Costs Related to HHS Proposals

(1) Costs Associated With the Proposal To Adopt FHIR Standards for Electronic Prior Authorization-Related HIPAA-Standard Transactions

(45 CFR 162.103, 45 CFR 162.1202, 45 CFR 162.1203, and 45 CFR 162.1302)

HHS is proposing a modification to two HIPAA Administrative Simplification transactions, the “referral certification and authorization”
transaction in 45 CFR part 162, subpart M, and the “eligibility for a health plan” transaction in 45 CFR part 162, subpart
L. Specifically, HHS proposes adding a new paragraph in 45 CFR 162.1302(g) to adopt the FHIR standard and the US Core, SMART
App Launch, CRD, DTR, PAS, and CDex IGs as the specifications that compose the proposed transaction standard for dental, professional,
and institutional “referral certifications and authorization” transactions. In addition, in a new paragraph in 45 CFR 162.1202(f)(2),
HHS is proposing to adopt the FHIR standard, the US Core, SMART App Launch, and CRD IGs as the specifications that compose
the proposed transaction standard for dental, professional, and institutional “eligibility for a health plan” transactions,
when used to determine whether prior authorization is required. If finalized as proposed, HIPAA covered entities would be
required to comply with these transaction standards no later than 24 months from the effective date of a final rule, except
for small health plans, for which the compliance date would be 36 months from the effective date of a final rule.

The costs associated with the proposal to adopt FHIR standards differ from the other costs described in this proposed rule
because the number of HIPAA covered entities is much larger than the number of impacted payers regulated by CMS and includes
various types of business entities across the health care industry. For the purposes of this impact analysis, HHS assumes
that only the HIPAA covered entities that have not yet implemented FHIR standards or do not use certified health IT that includes
FHIR would incur cost for the technical work of updating systems from the current X12N 278 transaction standard to implement
the proposed FHIR standards for electronic prior authorization. Though the data are severely limited, HHS attempts to provide
reasonable estimates of the number of HIPAA covered entities that already utilize FHIR APIs, or that are already required
to implement FHIR

  APIs per the finalized policies in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8758), and exclude
  them from the estimated cost. HHS assumes the cost and effort of updating health IT systems from using the current X12N 278
  transaction standard to FHIR would vary depending on the type of HIPAA covered entity, so HHS separately examines the burden
  of FHIR standards adoption amongst health plans and health care providers (including hospitals, clinics, and individual providers).
  HHS documents uncertainties related to the impact of transitioning to FHIR amongst EHR or other health IT vendors and health
  care clearinghouses.

For these estimates, HHS uses the adoption of certified EHR technology as a proxy for FHIR API adoption. The ONC Cures Act
final rule adopted an API certification criterion which requires the use of the HL7 FHIR standard and incorporated this criterion
into the 2015 Edition Base EHR definition (85 FR 25646). Therefore, HHS assumes that the use of certified health IT among
certain HIPAA covered entities corresponds to the use of and access to FHIR standards and relies on industry data and research
into the use of certified EHR technology. HHS concludes that if a HIPAA covered entity, such as a hospital, relies on the
X12N transaction standards for prior authorization, but is already using FHIR-enabled certified EHR technology in their workflow,
then they would incur negligible cost in complying with the proposed requirements to transition to the FHIR standard since
they already have technology with the technical capability in place.

HHS uses many of the assumptions and data sources leveraged in the 2022 HIPAA Standards for Health Care Attachments proposed
rule to estimate the number of HIPAA covered entities that would be impacted by the proposed requirements (87 FR 78438). As
in the 2022 HIPAA Standards for Health Care Attachments proposed rule, HHS used the Census Bureau 2022 Statistics of U.S.
Businesses (SUSB) dataset (which is based on the 2017 North American Industry Classification System [NAICS] codes) to identify
NAICS codes corresponding to hospitals, health care providers (using physician NAICS code), and health plans to determine
the total count of firms within each category of impacted HIPAA covered entities, which are listed in Table 21. (416) HHS utilizes the NAICS code for “Office Physicians” to analyze the potential cost to this subset of HIPAA covered entity rather
than include every type of physician in this analysis. The data reflect that other types of office-based providers (for example,
mental health specialists, chiropractors, and dentists) have lower adoption of the X12N 278 transaction standard and certified
EHR in their practice to varying degrees. For the purposes of this analysis, HHS concluded that office physicians were the
providers who were most likely to be impacted by these proposed requirements, and that HHS would focus on this NAICS category.

(a) Hospitals

The Census Bureau 2022 SUSB dataset reflects 3,319 hospital firms nationwide. Of these 3,319 firms, approximately 2,573 are
general hospitals, 419 are psychiatric hospitals, and 327 are specialty hospitals. According to an analysis on the adoption
of EHRs by hospital service type from 2019 through 2021 published by ONC, approximately 96 percent of all non-federal acute
care hospitals adopted a certified EHR, while 40 percent of rehabilitation hospitals and 23 percent of specialty hospitals
adopted a 2015 Edition certified EHR technology. (417) By applying these percentages to the subcategories of hospital described in the Census Bureau 2022 SUSB, HHS estimates that
2,713 hospital firms are already using certified EHR technology enabled with FHIR. In 2021, ONC published retrospective analysis
on their research from 2018, which reflected on the estimated potential adoption of 2015 Edition certified EHR technology
enabled with FHIR compared to the actual adoption they observed in 2019. (418) In addition to those

hospitals and clinicians that adopted technology in 2019, the data suggest that another 7 percent of hospitals could upgrade to 2015 Edition certified EHR technology enabled with FHIR from their current health IT developer. (419) HHS uses 7 percent from this analysis to estimate the number of hospital firms that could adopt the FHIR standard by upgrading
to certified EHR technology enabled with FHIR, offered by their current EHR vendor. Of the remaining 606 hospital firms, HHS
assumes that 7 percent, or 42 firms, (606 × 0.07 = 42.42) would upgrade their EHR product to certified EHR technology to adopt
FHIR standards required by this proposal and may incur cost associated with upgrading their EHR product. Based on industry
research, HHS estimates the one-time cost of upgrading an EHR product to be approximately $10,000, not including the recurring
annual maintenance fees or monthly per-user fees. (420) Therefore, HHS expects these 42 hospitals to incur approximately $424,277 in one-time costs (42.42 × 10,000 = $424,277). HHS
is uncertain what the remaining population of hospital firms would do to remain compliant with the proposed requirements,
if finalized. To avoid conducting many divergent analyses and implying a false sense of precision, HHS assumes that the approximately
563 hospital firms that do not have access to certified EHR technology through their current EHR vendor would not attempt
to undergo the costly process of switching to a different EHR vendor. Industry research indicates that switching EHR vendors
takes multiple years of preparation and can cost at minimum $500,000 for hospitals. (421 422) These hospitals may be smaller or have less resources available, and HHS assumes that they would continue to rely on manual
processes to complete electronic prior authorization transactions and/or wait for their current EHR vendor to offer a certified
technology product that is FHIR enabled.

(b) Physicians

Analysis conducted by ONC suggests that, as of 2021, approximately 78 percent of physicians adopted and utilize certified
EHR technology in their practice. (423) An earlier analysis conducted on 2019 data indicates that while 61 percent of clinicians adopted certified EHR technology,
11 percent of clinicians that did not adopt certified EHR could have done so by upgrading to 2015 Edition certified EHR technology enabled with FHIR from their current health IT developer. (424) Absent more recent data on the population of physicians who could adopt certified EHR technology, HHS uses the ratio of “could adopt but did not adopt” to “did not adopt” from the 2019 data analysis
and applies it to the more recent 2021 statistics (11/39 = X/22, X = 6.21). This yields an estimated 6 percent of clinicians
that could adopt EHR technology. The Census Bureau 2022 SUSB dataset reflects 145,305 physician firms nationwide. (425) For these estimates, HHS assumes that approximately 113,338 physician firms (145,305 × 0.78 = 113,337.90) already use certified
EHR technology. Of the remaining approximately 31,967 physician firms, HHS assumes 6 percent, or approximately 1,985 (31,967.10
× 0.0621 = 1,985.16), would upgrade to a certified EHR product based on HHS's proposals to modify the current X12N 270/271
and 278 transaction standards to FHIR standards for transactions related to prior authorization, as HHS is proposing to define
that term. HHS assumes a one-time cost of $10,000, same as the cost estimate for hospital firms, to upgrade products, resulting
in approximately $19,851,569 among these physician firms (1,985.16 × $10,000 = $19,851,569.10). Under this assumption, HHS
is left with 29,982 physician firms (31,967−1,985.16 = 29,981.84) that do not currently have access to FHIR-enabled certified
EHR technology. As with hospital firms, HHS is uncertain what the remaining population of physician firms might do to remain
in compliance with the new requirements. To avoid conducting many divergent analyses and implying a false sense of precision,
HHS assumes that these remaining 29,982 physician firms without any access to FHIR would not implement FHIR-enabled software.
In the absence of reliable data on FHIR utilization rates among physicians, HHS believes this assumption to be reasonable,
especially due to the costly nature of the process, which can range from $50,000 to $100,000 depending on the number of system
users in the physician's office. (426 427 428)

(c) Health Plans

The Census Bureau 2022 SUSB dataset reflects 1,071 health plan firms nationwide. (429) In estimating the number of health plans that would incur new cost due to the proposed HIPAA transaction standard requirements,
HHS takes into account 341 parent organizations which represent impacted payers subject to the requirements established in
the 2024 CMS Interoperability and Prior Authorization final rule. (430) The definition of NAICS “firms” is approximate to the definition of “parent organization” that CMS used to calculate the number
of impacted payers in the 2024 CMS Interoperability and Prior Authorization final rule. (431) HHS assumes that the 341 parent organizations would incur negligible cost to transition from current X12N 270/271 and 278
transaction standards and implement the proposed FHIR standards for prior authorizations, as they are already required to
implement

  FHIR standards for prior authorization by the 2024 CMS Interoperability and Prior Authorization final rule. Therefore, HHS
  deducts the 341 parent organizations previously accounted for from the count of health plan firms and estimates that 730 health
  plan firms have not adopted FHIR standards or are not required to do so in regulation or both (1,071−341 = 730).

HHS does not anticipate a one hundred percent transition to the proposed FHIR standards for electronic prior authorization
transactions among the remaining 730 health plan firms. Since the adoption of X12N transaction standards among health plans
for prior authorizations remains low (approximately 35 percent), HHS expects that some health plans which have not yet adopted
the X12N transaction standards for prior authorizations will forego the investment in a FHIR API and instead continue to use
manual prior authorization methods or proprietary portals. (432) Therefore, HHS estimates that of the remaining 730 health insurance firms, approximately 35 percent, or 256 (730 × 0.35 =
255.50 rounded), would update their system from current X12N transaction standards to the proposed FHIR API standards for
prior authorization. These 256 health plans may incur cost associated with building and implementing FHIR APIs for the first
time. HHS acknowledges that this methodology to estimate the number of health plans with experience implementing FHIR APIs
does not account for the many commercial health plans that are already leveraging FHIR standards in their workflows or other
business functions but are not captured in the population of impacted payers or certified EHR adopters. Due to the lack of
data on the use of FHIR industry-wide, HHS presents this estimate and requests comment on these assumptions.

HHS estimates that the cost of implementing and maintaining a FHIR API using the proposed FHIR standards would largely align
with the cost to implement and maintain the Prior Authorization APIs described in the 2024 CMS Interoperability and Prior
Authorization final rule. Health plans would conduct three work phases: (1) design; (2) development and testing; and (3) support
and maintenance (85 FR 25605 and 25623, and 89 FR 8948, 8950, and 8953). In the initial design phase, tasks include determining
available resources (for example, personnel, hardware, cloud storage space, etc.); assessing whether to use in-house or contracted
resources to facilitate an API connection; convening a team to scope, build, test, and maintain the API; gap analysis; and
gap mitigation. During the development and testing phase, health plans would map existing data to the FHIR standards, determine
hardware allocation for the necessary environments (development, testing, and production), build a new FHIR server, determine
the frequency and method by which internal data are populated on the FHIR server, build connections between the databases
and the FHIR server, perform capability and security testing, and vet provider requests.

HHS further refines these technical builds and implementation estimates by considering the results of industry exceptions
testing requested by the HL7® Da Vinci Project (HL7 FHIR Exception #202103100) to test FHIR standards. (433) The testing exceptions report from the HL7 Da Vinci Project stated that the design, testing, and deployment of the FHIR API
was accomplished by one health plan for $135,000, which is significantly less costly than the API build estimates included
in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8951). In the 2024 CMS Interoperability and Prior
Authorization final rule, we estimated the cost of implementing the Prior Authorization API to range from $208.9 million to
$626.6 million. Because the cost of the industry exceptions testing was significantly lower, less than half than the median
of the range of per-entity cost estimated in the 2024 CMS Interoperability and Prior Authorization final rule ($417.7 million),
HHS is hesitant to project this rate across all HIPAA covered entities, particularly health plans. To produce a reasonable
estimate that does not drastically depart from the previous estimations in the 2024 CMS Interoperability and Prior Authorization
final rule, but that does acknowledge that many health plans have a degree of familiarity and efficiency with FHIR development
since the previous rulemaking as indicated by the exception testing project, HHS uses the low range of the hourly labor build
estimates (reflected in Table 22 column “Hourly Burden”) presented in the 2024 CMS Interoperability and Prior Authorization
final rule in calculating this burden.

For the estimated 256 health plans, HHS assumes that the one-time cost to develop and implement the FHIR API will require
approximately 2,790 hours of labor for each entity over 2 years, at a total cost of approximately $327,000 dollars. See Table
22 for a breakdown of the total costs. HHS estimates an annual maintenance cost averaging approximately 25 percent of the
estimated one-time API development costs. Total annual maintenance cost for a single health plan would be approximately $78,000
dollars and this cost is included in the 10-year projections in Table 33.

BILLING CODE 4150-28-P

HHS requests public comments on our approach and assumptions for the aggregate maintenance cost of the APIs, including whether
HHS's estimate is reasonable or should be modified.

BILLING CODE 4150-28-C

(d) Uncertainties

While HHS is of the view that the use and accessibility of FHIR-enabled certified EHR technology in the health care industry
is increasing, business practice uncertainties and a paucity of baseline data make it difficult to estimate the cost of adopting
FHIR among certain HIPAA covered entities. In particular, the potential cost incurred by health care clearinghouses and EHR
vendors that supply technologies to health care providers to adopt the proposed FHIR standards for prior authorization-related
transactions into their products and contract offerings is unclear.

EHR vendors provide the technology that many hospitals and physicians use to transmit EHI to and from payers. For the purposes
of this impact analysis, HHS uses “EHR vendor” as a catch-all to represent plan management system vendors and EHR technology
system vendors. Counting the affected entities separately is complicated, in part because they are increasingly integrated.
A health care provider entity's plan management system and EHR systems may be bundled in one product offering, semi-integrated
affiliated systems, or entirely independent systems offered by separate vendors. The 2022 Census Bureau SUSB dataset does
not provide firm-level counts for health care industry-specific technology vendors. (434) For this reason, HHS relies on the same data source used in the 2022 HIPAA Standards for Health Care Attachments proposed
rule impact analysis to count EHR vendors. This industry reporting from 2024 and 2025 suggests that approximately 500 vendors
are offering an EHR product and that several large vendors dominate the EHR market. (435) Epic, Oracle Cerner, and Meditech are the three biggest EHR vendors among hospitals, making up nearly 75 percent of the market
share combined. (436) Epic, Oracle Cerner, and athenahealth, Inc. represent the biggest vendors among clinicians, with approximately 82 percent
of the market share combined. (437 438) These vendors all offer

  certified EHR technology products which are FHIR-enabled, though they are typically priced higher than basic EHR software.
  For vendors who already have FHIR-enabled EHR product offerings, it is unclear if the proposed requirement would spur them
  to develop new products at different price points in anticipation of an increase in hospital and physician demand. For EHR
  vendors that do not currently offer FHIR-enabled EHR products, it is unclear if the proposed requirements would move them
  to begin developing new software. HHS assumes that these vendors may cater to smaller provider markets and may not be able
  to justify the costly process of software development for their client base.

Health care clearinghouses present another set of uncertainties. Clearinghouses provide transaction processing and data translation
services to both providers and health plans. The applicable NAICS category (NAICS 524114) includes many types of financial
transaction processing firms other than those affected by this rule, so the Census business data cannot be used to identify
a nationwide count. Based on the counts used in the 2022 HIPAA Standards for Health Care Attachments proposed rule, HHS assumes
that there are approximately 162 clearinghouse entities nationwide (87 FR 78455). According to industry research, most health
care clearinghouse vendors integrate with or offer features that can be part of health IT systems, including EHR or other
health IT products. (439) A few of their main features include claim submission, payment posting, and denial management, though increasingly, EHR vendors
are offering those same features and services to clients either independently or by contracting with a clearinghouse. Prior
authorization is not one of the main workflows associated with clearinghouse services, but it does come into play for certain
workflows, including denial management. It is unclear what the impact of a hospital or practice adopting FHIR-enabled certified
EHR technology might have on the denial management needs since the aim of the Prior Authorization API is to improve prior
authorization transparency and communication, ultimately reducing denials. Furthermore, it is unclear how many of the roughly
162 clearinghouse firms currently utilize FHIR standards as a part of their business operations or to what extent APIs are
integrated into their workflows. Without a baseline understanding of API utilization among this population of HIPAA covered
entities, it is challenging to predict their future adoption of FHIR standards and the economic impact on their sector of
the health care industry. HHS solicits commenter feedback on the extent to which clearinghouses have experience developing
and implementing FHIR APIs or whether their systems can engage with another party's FHIR API within their workflow. HHS solicits
comment on the level of effort it would require for a health care clearinghouse to update their processing systems to accommodate
these proposals. HHS invites comments on these uncertainties.

(2) Costs Related to ONC's Proposals To Adopt Updated Versions of Standards (45 CFR 170.215 and 45 CFR 170.299)

ONC proposes to adopt new standard versions of a series of IGs which were adopted by the Secretary in the HTI-4 final rule
(90 FR 37130), which appeared in the
Federal Register
on August 4, 2025 as part of the FY 2026 IPPS/LTCH final rule (90 FR 36536). Since the FY 2026 IPPS/LTCH final rule appeared
in the
Federal Register
, newer versions of the standards adopted by the Secretary in the HTI-4 final rule have been released. Therefore, ONC proposes
to adopt the following standards on behalf of the Secretary:

• HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.2.1—STU 2.2 (proposed in 45 CFR 170.215(j)(1)(ii)) (440)

• HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide, Version 2.2.0—STU 2.2 (proposed in 45 CFR 170.215(j)(2)(ii)) (441)

• HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.2.1—STU 2.2 (proposed in 45 CFR 170.215(j)(3)(ii)) (442)

• HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.2.0—STU 2.2 (proposed in 45 CFR 170.215(k)(1)(ii))
• HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.1.0—STU 2.1 (proposed in 45 CFR 170.215(m)(2))
• HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.2.0—STU 1.2 US (proposed in 45 CFR 170.215(n)(2))
• HL7 FHIR® Da Vinci—Clinical Data Exchange (CDex) Implementation Guide, Version 2.1.0—STU 2.1 (proposed in 45 CFR 170.215(k)(3)) As part of the HTI-4 final rule, ONC finalized certification criteria for electronic prior authorization in the ONC Health IT Certification Program that incorporated the CRD, DTR, and PAS IGs. As part of this proposed rulemaking, CMS is proposing to incorporate cross-references to 45 CFR 170.215 where these standards would be adopted as part of proposed technical requirements for payer APIs CMS previously established in the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules.

ONC analysis of these new standard versions finds that the changes between currently adopted standard versions and these new
standard versions are small in scope and would not require significant effort to adopt. Furthermore, ONC adopted the current
standard versions in regulation as part of the HTI-4 final rule, with no required date to adopt the new certification criteria
and the associated standards, lowering any duplication of effort to first adopt the current standard version and the proposed
new standard version (90 FR 36536 through 37308). ONC also finds—aligning with the impact analysis for this proposed CMS rulemaking—that
the proposed updates would not require new adoption of technology by health IT users or adoption of new certification criteria
by developers of certified health

IT, as those requirements are associated with finalized rulemaking. ONC estimates that developers of certified health IT would
face little burden to adopt the updated standard version given these factors. ONC estimates that the effort on developers
of certified health IT to adopt these standard versions would be de minimis. This analysis parallels the ONC HTI-2 proposed rule impact analysis for the proposed update to adopt SMART App Launch IG version
2.2 (89 FR 63498). (443) Similarly here, the proposed update from SMART App Launch IG version 2.0 to 2.2 involved enhancements that would require low
effort on developers of certified health IT to adopt for already adopted certification criteria and associated standards.
Public comments from the HTI-2 proposed rule did not raise any concerns with our impact analysis of the SMART App Launch IG
version update, but we recognize that differing standard maturity levels and implementation challenges for the previously
proposed IG updates may create more burden on developers to update their certified technology. We request comment to that
effect on the expected level of burden to update certified technology to the latest IG versions proposed previously.

b. Rulemaking Costs to Impacted Payers Related to CMS Proposals

(1) Methodology of Attributing Cost Among Impacted Payers

To analyze the cost of the proposals related to prior authorization of drugs, we allocate costs by the three federally funded
programs that would be impacted by this provision—MA; Medicaid and CHIP (including state Medicaid and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed care entities); and QHPs on the FFEs. As the cost is shared by the 341 parent organizations
offering impacted health plans, including state Medicaid and CHIP agencies, there is no readily available way to allocate
costs per parent organization across programs as the percentage of each parent organization's expenditure on the different
programs is not publicly available.

To address this, we use the CMS Medical Loss Ratio (MLR), acknowledging its data limitations as we did in the 2020 CMS Interoperability
and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules (85 FR 25612 through 25616 and 89 FR
8969). Our actuaries use the public CMS MLR files, which break out total premiums among the various programs. (444) Table 24 presents the 2022 MLR data of premiums by program and the resulting percentages by program. We use these percentages
to allocate costs by program in Table 25, which forms a basis for calculating the federal government's cost for the proposals
in this proposed rule described in Table 32.

While most of the CMS proposals in this proposed rule apply to all impacted payers, there are two proposals that do not. For
these proposals, Table 24 shows premium allocation by program. (445) For example, $246 billion of the $549 billion total premium is spent on MA plans ($246 ÷ $549 = 44.81%).

First, as shown in Tables 14 and 20 in sections IV.C. and IV.E. of this proposed rule, the prior authorization decision timeframes
for drugs proposal only applies to the 66 parent organizations offering QHPs on the FFEs. For this proposal, 100 percent of
the cost is allocated to QHPs on the FFEs. Second, as shown in Table 24, the proposed NCPDP SCRIPT standard for prior authorization
of drugs covered under a pharmacy benefit only applies to two programs, those being: (1) Medicaid and CHIP; and (2) QHPs on
the FFEs. For this provision, we allocated 68.91 percent of the total cost to Medicaid and CHIP ($209 ÷ $303 = 68.91%) and
31.09 percent of the total cost to QHP on the FFEs ($94 ÷ $303 = 31.09%). Note, $303 billion is the aggregate amount of premium
costs associated with these two programs: (1) Medicaid and CHIP at $209 billion; and (2) QHPs on the FFEs at $94 billion.
Therefore, 68.91 percent equals the estimated $209 billion in premiums that would be spent by Medicaid and CHIP and 31.09
percent equals the $94 billion in premiums that would be spent by QHPs on the FFEs.

Table 25 reflects the total cost to impacted payers resulting from CMS proposals in this section. This cost is attributed
among: MA organizations; Medicaid and CHIP (including state Medicaid and CHIP FFS programs, Medicaid managed care plans, and
CHIP managed care entities); and QHP issuers on the FFEs using the methodology discussed in section V.C.2.b.(1). of this proposed
rule. In total, the three programs would incur an estimated $141.26 million over 10 years to implement these CMS proposals
described in sections V.C.2.b.(1).(a). through V.C.2.b.(1).(g). of this proposed rule.

(a) Costs Associated With the Proposal To Incorporate Into the Prior Authorization API Coverage and Documentation Requirements

To Support Electronic Prior Authorization for Drugs Covered Under a Medical Benefit for All Impacted Payers (42 CFR 422.122,
42 CFR 431.80, 42 CFR 438.242, 42 CFR 457.732, 42 CFR 457.1233, and 45 CFR 156.223)

In this proposed rule, we would expand upon the Prior Authorization API provisions finalized in the 2024 CMS Interoperability
and Prior Authorization final rule (89 FR 8897) by requiring impacted payers to incorporate prior authorization coverage and
documentation requirements for drugs covered under a medical benefit into the Prior Authorization API beginning in 2027. If
finalized as proposed, CMS anticipates that there would be a 2027 compliance date for this proposal. This should allow for
approximately 1 year of lead time between publication and the compliance date.

To incorporate drug coverage and documentation requirements into the existing Prior Authorization API, we estimate that all
impacted payers would need to conduct similar work phases as for implementation of the API such as design, development testing,
and long-term support and maintenance. For prior authorization of drugs, some, but not all, tasks would be necessary for the
initial development work, such as identifying the relevant drugs, system connections to formularies or PBMs, and programming
the Prior Authorization API to include drugs covered under a medical benefit. Some of the same expertise would be required
to develop and implement prior authorization policies and systems processes for drugs covered under a medical benefit as were
needed to develop a Prior Authorization API for non-drug items and services. Still, it would not require the same level of
effort as for the development of the API itself.

Acknowledging that impacted payers would have the technical infrastructure in place, the deployment of these proposals is
estimated at 127,670 burden hours to calculate the estimated cost, which results in $15,348,797 for all 341 impacted payers
(see costs determination in Table 26). We distributed the cost over approximately 1 calendar year to ensure impacted payers
can identify, analyze, and program their systems to include drugs covered under a medical benefit. Since this rule proposes
a compliance date of October 1, 2027 for this proposal, CMS acknowledges that the development timeframe would likely overlap
with impacted payers' development efforts related to the API requirements finalized in the 2024 CMS Interoperability and Prior
Authorization final rule. Due to this overlap in development activity, we anticipate that the one-time costs incurred in 2026
would double due to the increase in developer labor hours needed to progress both technological builds simultaneously. To
provide an approximate adjustment accounting for this burden, we double the amount of cost estimated to fall in the year 2026
(approximately 25 percent of the total development burden) which results in an additional $3,837,199 across all 341 impacted
payers ($15,348,797.38 × 0.25 = $3,837,199.35) which is reflected in the annual cost associated with each proposal in Table
33. The resulting total is $19,185,997 in one-time implementation cost across all impacted payers. We request comment on these
estimates.

(b) Costs Associated With the Proposed Addition of Prior Authorization Information About Drugs to the Access APIs for Impacted

Payers (42 CFR 422.119, 42 CFR 422.121, 42 CFR 431.60, 42 CFR 431.61, 42 CFR 438.242, 42 CFR 457.730, 42 CFR 457.731, 42 CFR
457.1233, 45 CFR 156.221, and 45 CFR 156.222)

We are proposing that the same policies that require impacted payers to make available—via the Access APIs—information about
prior authorization requests and decisions for non-drug items and services for which an impacted payer has data in the patient's
record would now apply to drugs as well, as described in section II.F.1. of this proposed rule. If finalized as proposed,
CMS anticipates that there will be a 2027 compliance date for this proposal. This should allow for approximately 1 year of
lead time between publication and the compliance date.

As in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules,
we assume that for the technical work, impacted payers would conduct three work phases: (1) design; (2) development and testing;
and (3) support and maintenance (85 FR 25605 and 25623 and 89 FR 8948, 8950, and 8953). In this proposed rule, we assume the
same phases of work would take place for the tasks related to the new proposals related to the APIs, with a different level
of effort during each work phase. In the initial design phase, tasks include determining available resources (for instance,
personnel, hardware, cloud storage space, etc.); assessing whether to use in-house or contracted resources to conduct the
programming; and convening a team to scope, build, test, and maintain work.

Adding prior authorization information to the existing Access APIs upon request should not require substantive technological
changes but could require programming and impact data storage. Additional programing and data storage reflects only a small
part of the total cost of API implementation and, while cost may vary depending on health plan, we chose to use 15 percent
of full API implementation cost to reasonably approximate the burden associated with these activities. We estimate the effect
to be 15 percent of the prior cost for the Access APIs' implementation as a baseline and invite stakeholders to comment on
this 15 percent estimate. We estimate that a parent organization adding this prior authorization information to the Access
APIs would require on average 278 hours, with the corresponding cost obtained by multiplying the estimated hours by the median
wage per hour. Since this rule proposes a compliance date of October 1, 2027 for this proposal, CMS acknowledges that the
development timeframe would likely overlap with impacted payers' development efforts related to the API requirements finalized
in the 2024 CMS Interoperability and Prior Authorization final rule. Due to this overlap in development activity, we anticipate
that the one-time costs incurred in 2026 would double due to the increase in developer labor hours needed to progress both
technological builds simultaneously. To provide an approximate adjustment accounting for this burden, we double the amount
of cost estimated to fall in the year 2026 (approximately 25 percent of the total development burden) which results in an
additional $2,775,755 across all 341 impacted payers ($11,021,098.18 × 0.25 = $ 2,755,274.55) which is reflected in the annual
cost associated with each proposal in Table 33. The resulting total is $13,776,373 in one-time implementation cost across
all impacted payers. We request comment on these estimates.

(c) Costs Associated With the Proposal To Support the NCPDP SCRIPT Standard for the Electronic Prior Authorization of Drugs

Covered Under a Pharmacy Benefit for State Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed
Care Entities, and QHP Issuers on the Federally-facilitated Exchanges (42 CFR 431.80, 42 CFR 438.242, 42 CFR 457.732, 42 CFR
457.1233, and 45 CFR 156.223)

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 a version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b)
when performing electronic prior authorization for drugs covered under a pharmacy benefit. If finalized as proposed, CMS anticipates
that there will be a 2027 compliance date for this proposal. This should allow for approximately 1 year of lead time between
publication and the compliance date.

This proposed rule does not intend to address the prior authorization criteria these impacted payers use to make decisions
about coverage. However, supporting the proposed NCPDP SCRIPT standard should make the prior authorization process less burdensome
for payers and providers and could improve timeliness to approved prescriptions for patients. Specifically, based on stakeholder
feedback, we believe providers already using electronic prescribing software have access to the NCPDP SCRIPT standard for
electronic prior authorization.

We reviewed the 2024 Part D and Health IT Standards final rule (89 FR 51238) and the 2020 Medicare Part D ePA final rule (85
FR 86824) to obtain cost estimates for this proposal. In these rules, CMS indicates that the technical tasks (for instance,
building the infrastructure and logic) to support the proposed NCPDP SCRIPT standard can vary based on how the impacted payer
documents the prior authorization criteria. The average cost per impacted payer is estimated at $6,500, regardless of the
size and expertise of the payer. In the 2020 Medicare Part D ePA final rule, the $6,500 figure included the payer's internal
costs, including labor, initial development and programming, and systems support to transform each of its CMS-approved prior
authorization criteria from a manual process suitable for telephonic or manual efforts. Since the publication of the 2020
Medicare Part D ePA final rule, CMS has not collected new data related to the cost of supporting the NCPDP SCRIPT standard
among impacted payers. In the absence of updated data, we have adjusted the estimated $6,500 for inflation using the BLS Consumer
Price Index Inflation Calculator to obtain a more reasonable estimate of the potential cost. The resulting cost is approximately
$12,500 in inflation-adjusted dollars. Similar to the other proposals implicating systems build for the prior authorization
of drugs, this rule proposes a compliance date of October 1, 2027 for the adoption of the NCPDP SCRIPT standard. CMS acknowledges
that the development timeframe would likely overlap with impacted payers' development efforts related to the API requirements
finalized in the 2024 CMS Interoperability and Prior Authorization final rule. Due to this overlap in development activity,
we anticipate that the one-time costs incurred in 2026 would double due to the increase in developer labor hours needed to
progress both technological builds simultaneously. To provide an approximate adjustment accounting for this burden, we double
the amount of cost estimated to fall in the year 2026 (approximately 25 percent of the total development burden) which results
in an additional $743,750 across all 341 impacted payers ($2,975,000 × 0.25 =$ 743,750) which is reflected in the annual cost
associated with each proposal in Table 33. The resulting total is $3,718,750 in one-time implementation cost across all impacted
payers. We request public comment on these estimates. We solicit comments from impacted payers on this approach and other
sources of data we could use to determine this cost estimate.

(d) Costs Associated With the Proposal To Support the NCPDP Formulary & Benefits Standard and the NCPDP Real-Time Prescription

Benefit Standard Adopted for the Electronic Prior Authorization of Drugs Covered Under a Pharmacy Benefit for State Medicaid
and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and QHP Issuers on the Federally-Facilitated
Exchanges (42 CFR 431.80, 42 CFR 438.242, 42 CFR 457.732, 42 CFR 457.1233, and 45 CFR 156.223)

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 the NCPDP F&B standard version 60 adopted by the Secretary in 45 CFR 170.205(u), for
transmitting formulary and benefit information between providers and impacted payers, and NCPDP RTPB standard version 13 adopted
by the Secretary in 45 CFR 170.205(c), to enable real-time, patient-specific prescription benefit information to be delivered
to providers at the point of prescribing. If finalized as proposed, CMS anticipates that there will be a 2027 compliance date
for this proposal. This should allow for approximately a year of lead time between publication and the compliance date. Consistent
with the initial adoption of these standards in the 2020 Medicare Part D ePA final rule, we are advancing these proposals
with unclear costs for these impacted payers, but a clear vision that it is important to invest in these programs due to the
increasing costs of drugs and potential savings that could be realized through the proposed NCPDP F&B and NCPDP RTPB standards.
Cost associated with the adoption of these standards remain unclear due to a lack of robust public data on the implementation
of the proposed NCPDP F&B and NCPDP RTPB standards among Medicare PDPs. An understanding of the adoption rate in Medicare
Part D and the cost of implementation among those plans could support the development of a cost analysis in this proposed
rule. CMS solicits comment on the cost of the proposed NCPDP F&B and NCPDP RTPB standards among impacted payers who have already
implemented them in their Medicare Part D lines of business and specifically requests comment on the type of implementation
activities associated with cost, such as software development and testing. Further, CMS solicits comments from impacted payers
who would be adopting these standards for the first time with respect to their anticipated implementation activities and anticipated
costs for expenses such as software licensing, system integration, API development, and testing. CMS requests comment comparing
the cost of implementing these standards for the first time with the estimated one-time cost of implementing the NCPDP SCRIPT
standard of $12,500 per entity, plus the additional markup for the cost of labor in the year 2026.

(e) Costs Associated With the API Proposals for the Small Group Market Qualified Health Plan Issuers on the Federally-facilitated

Small Business Health Options Program Exchanges (45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223)

In this proposed rule we are proposing to apply existing requirements to small group market QHP issuers on the FF-SHOPs as
described in section II.D. of this proposed rule. Consistent with the provisions of the 2020 CMS Interoperability and Patient
Access final rule (85 FR 25522), we are proposing the development and implementation of a standards-based Patient Access API
that permits third-party apps to retrieve standardized data for adjudicated claims, encounters with capitated providers, provider
remittances, enrollee cost sharing, reports of lab test results, and preferred drug lists at the request of the patient. We
are proposing to apply this requirement to small group market QHP issuers on the FF-SHOPs for plan years beginning on or after
January 1, 2028.

We are also proposing that small group market QHP issuers on the FF-SHOPs implement and maintain standards-based Provider
Access, Payer-to-Payer, and Prior Authorization APIs, consistent with requirements in the 2024 CMS Interoperability and Prior
Authorization final rule (89 FR 8817, 8855, and 8897). We are proposing compliance dates for the Provider Access and Payer-to-Payer
API requirements of plan years beginning on or after January 1, 2028, and an October 1, 2027 compliance date for the Prior
Authorization API requirements. In that final rule, we finalized another set of requirements for impacted payers (excluding
small group market QHP issuers on the FF-SHOPs) to report on the Patient Access API and publicly report prior authorization
metrics (89 FR 8784 and 8897). We do not anticipate that there would be added burden for the parent organizations that offer
individual market QHPs on the FFEs to implement these proposals for their small group market QHPs on the FF-SHOPs, because
the parent organizations are already required to implement these same policies for their individual market QHPs on the FFEs.

(f) Costs Associated With the Proposal To Report Usage Metrics for Provider Access, Payer-to-Payer, and Prior Authorization

APIs (42 CFR 422.121, 42 CFR 422.122, 42 CFR 431.61, 42 CFR 431.80, 42 CFR 438.242, 42 CFR 457.731, 42 CFR 457.732, 42 CFR
457.1233, 45 CFR 156.222, and 45 CFR 156.223)

CMS proposes to require impacted payers to report metrics about the usage of the Provider Access, Payer-to-Payer, and Prior
Authorization APIs in the form of aggregated, de-identified data. We estimate that this proposal will require 100 hours of
labor by a Software

  and Web Developer at $124.34 ($12,434 annually) per impacted payer for the first year, with no maintenance burden. We also
  estimate 60 hours of labor by a Business Operations Specialist at $78.14 ($4,688 annually) per impacted payer for the first
  year and 40 hours for maintenance burden ($3,126 annual cost). The aggregate burden for 341 parent organizations would be
  55,000 hours and 14,000 hours (rounded) for the first and subsequent years at a cost of $5.8 million and $1.1 million. For
  additional information on this burden estimate, see section IV.C.2. of this proposed rule.

(g) Costs Associated With the Proposal To Report Payer API Endpoints and Associated Information for CMS To Publish (42 CFR

422.119, 42 CFR 422.120, 42 CFR 422.121, 42 CFR 422.122, 42 CFR 431.60, 42 CFR 431.61, 42 CFR 431.70, 42 CFR 431.80, 42 CFR
438.242, 42 CFR 457.730, 42 CFR 457.731, 42 CFR 457.732, 42 CFR 457.760, 42 CFR 457.1233, 45 CFR 156.221, 45 CFR 156.222,
and 45 CFR 156.223)

CMS proposes to require impacted payers to report all API endpoints in the form of an Endpoint Resource, a direct URL for
their API's FHIR capability statements, and required documentation such as authorization and authentication protocols, implementation
details, and API registration information to CMS within 1 week of any changes and to verify this every 12 months. We estimate
that this proposal would require 2 hours of labor by a Business Operations Specialist at $78.14 ($156.28 annually) per impacted
payer and for all impacted payers we estimate that the reporting burden would be $53,291 annually. For additional information
on this burden estimate, see section IV.C.3. of this proposed rule.

3. Transfers

a. Rulemaking Costs Related To the Proposal To Define “Failure To Report” in Open Payment Non-Compliance (42 CFR 403.902)

We propose in section II.G. of this proposed rule to create a new definition of “failure to report” that includes the failure
to provide requested documentation during an audit. CMS has both CMP authority in 42 CFR 403.912(a) and audit authority in
42 CFR 403.912(e)(2). CMS began implementing the Open Payments audit program in 2022 and conducted the first full audit during
the 2023 cycle. Over this 2-year period CMS audited 16 total entities. Due to the relatively short implementation period of
the Open Payments audit program, we have limited historical data to use in estimating the amount of CMPs that would be imposed
as a result of the proposed “failure to report” definition as it relates to audit findings. In the absence of robust audit
data, we are relying on information from the 2022 to 2023 audits and the statutorily mandated knowing “failure to report”
CMP methodology (section 1128G(b)(2) of the Act) to calculate the estimated cost associated with this proposal.

Based on previous audit sample sizes, CMS estimates an average of 10 reporting entities will be audited (out of approximately
1,700 reporting entities) annually. During the 2022 to 2023 audit cycles, approximately 25 percent of sampled entities failed
to fully or partially comply with audit requests. CMS anticipates that the proposed definition of “failure to report” would
compel entities to fully comply with audit requests. Without implementation experience to draw from, CMS can only estimate
how the change in definition would impact compliance with audit requirements. CMS assumes that the non-compliance rate would
drop to approximately 10 percent of sampled entities if the definition is finalized. CMS invites comment on this assumption.
Based on an expected sample size of 10 entities, CMS anticipates imposing CMPs for one reporting entity per year (10 × 10
percent). As knowing “failure to report” CMP amounts are determined by the Act on a per-record basis between $10,000 and $100,000
for each failure, with a program year ceiling of $1,000,000 (adjusted annually in 45 CFR part 102), the amount of CMPs imposed
on a single entity could vary depending on how many instances of non-compliance CMS identifies and the duration of the non-compliance.
CMS uses the median per-record knowing “failure to report” CMP amount of $77,371 (considering a range of $14,067 and $140,674
for 2024, per 45 CFR part 102) to calculate the total amount of anticipated CMPs for a non-compliant entity. Based on the
results of previous audits, we assume a non-compliant entity would fail to report a total of five records per program year,
but we invite comment on this assumption.

Therefore, CMS estimates that on average one entity per audit cycle would be found non-compliant in the reporting of approximately
five records per program year, at an average rate of $77,371 per record, or $386,855 ($77,371 × 5). Open Payments program
audits evaluate a 3-year lookback period, which would result in a total of $1,160,565 ($386,855 × 3 years) in estimated CMPs
during the annual audit cycle. This information can be seen in Table 29. CMS invites comments on these assumptions and calculations.

BILLING CODE 4150-28-P

b. Costs to the Government

CMS estimates that the federal government would incur transfer costs from the three federally funded programs that would be
impacted by the proposed requirements to expand the prior authorization provisions finalized in the 2024 CMS Interoperability
and Prior Authorization final rule to include drugs and the proposed requirements associated with reporting API metrics, those
being MA; Medicaid and CHIP (including state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed
care entities); and QHPs on the FFEs. We use the CMS internal data from the CMS Trustees' Report and the “Fiscal Year 2025
Budget in Brief” to calculate federal costs for MA organizations. (446 447) Our

  calculations, shown in Table 30, indicate that the Trust Fund would pay about 34 percent of impacted payers' costs over the
  next 10 years. The remaining costs, for the approximately 99 percent of plans bidding below the benchmark, are borne by the
  impacted payers.

Similarly, we calculate the federal Medicaid payments using the Medicaid managed care plan share of benefits and Federal Medical
Assistance Percentages (FMAPs) in Table 31. Refer to section IV.I. in the 2024 CMS Interoperability and Prior Authorization
final rule for further information on how this table is applied to calculations (89 FR 8970).

Tables 25, 30, and 31 form a basis for Table 32, the Cost of the Proposed Rule to the Federal Government by Year and Program,
which presents the costs of this proposed rule by year and by federal government payments to each program. The total cost
in Table 32 is $74.21 million.

For Table 32, the 10-year total cost to the government assumptions include the following:

• The three columns in Table 32 list the cost incurred by the federal government as a result of the proposals in this rule.
  We applied the proportions of Tables 31 and 30 for MA and Medicaid. For the cost associated with QHPs on the FFEs, although
  the federal government does not subsidize QHPs on the FFEs it does provide PTC subsidies to eligible enrollees. We provide
  a PTC cost estimate that reflects a global premium increase across all QHPs on the FFEs of the projected expense burden.
  • PTC Payments: The government offers QHP eligible enrollees PTCs to help cover the enrollees' plan premiums. The PTCs are
  only available

  to enrollees of individual market QHPs purchased through an SBE, SBE-FP, or FFE. Enrollees of small group market QHPs purchased
  through the FF-SHOP are not eligible for PTCs. There would be federal PTC impacts to the extent that issuers increase premiums
  for individual market QHPs on the FFEs.

The PTC estimate reflects a global premium increase across all QHPs on the FFEs of the projected expense burden. The methodology
to estimate the PTC impact of the projected expense burden is consistent with that used to estimate the PTC impact in the
2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules (85 FR
25612 and 89 FR 8972). Within the FFE states, the estimated expense burden would impact premium rates in the individual and
small group markets. PTCs are only available for the individual plans sold on the Marketplace and are calculated as a function
of the second lowest-cost silver plan and the eligible individual's household income. The estimate of these impacts uses the
global assumption that the industry would increase the second lowest-cost silver plan premium rate in the same amount as the
overall projected premium rate increase as a result of the RIA cost estimate. The overall rate increase, determined by internal
estimates produced by the CMS Office of the Actuary (OACT), is applied to the projected PTC payments in the FFE states to
estimate the proposed rule's impact on PTC payments.

Table 33 provides the total cost of the rule over 10 years, broken out by proposal. This table only reflects proposed policies
determined to have a non-negligible cost impact. Tables 21 through 30 form a basis for Table 33, the Total Cost of Proposed
Policies by Year, which presents the costs of this proposed rule by year, in the aggregate, by program, and with allocations
to plans and the government. The total 10-year cost in Table 33 (excluding PTC payments and savings from prior authorization)
is $396.91 million.

BILLING CODE 4150-28-C

4. Regulatory Review Cost Estimation

Due to the uncertainty involved with accurately quantifying the number of entities that will review the rule, we assume that
the total number of unique commenters on the 2022 CMS Interoperability and Prior Authorization proposed rule will be the number
of reviewers of this proposed rule. We acknowledge that this assumption may understate or overstate the costs of reviewing
this rule. It is possible that not all commenters reviewed the 2022 CMS Interoperability and Prior Authorization proposed
rule in detail, and it is also possible that some reviewers chose not to comment on the proposed rule. For these reasons we
thought that the number of past commenters (900) would be a fair estimate of the number of reviewers of this rule. We welcome
any comments on the approach in estimating the number of entities which will review this proposed rule. We also recognize
that different types of entities are in many cases affected by mutually exclusive sections of this proposed rule; therefore,
for the purposes of our estimate we assume that each reviewer reads approximately 50 percent of the rule. We seek comments
on this assumption.

Using the wage information from the BLS for medical and health service managers (Code 11-9111), we estimate that the cost
of reviewing this rule is $113.42 per hour, including overhead and fringe benefits. (448) In the 2024 CMS Interoperability and Prior Authorization proposed rule, we estimated that it would take a manager-level reviewer
10 hours to read the entire rule (87 FR 76343). Based on our prior assumption assigning each reviewer 50 percent of the rule
content and feedback from industry stakeholders, we estimate that it would take 10 hours total for staff to review. We estimate
this amount of time because, while the majority of the prior authorization and API-related proposals build on the familiar
framework of policies finalized in the 2024 CMS Interoperability and Prior Authorization final rule, we acknowledge that the
addition of drugs to these policies and the systems associated with the prior authorization of drugs under a medical and pharmacy
benefit add new complexity to concepts which may already be familiar to reviewers. Further, the proposal to adopt the FHIR
standard and applicable IGs as the transaction standard for HIPAA Administrative Simplification “referral certification and
authorization” and “eligibility for a health plan” transactions related to prior authorization may require reviewers to conduct
additional research cross-referencing existing HIPAA regulations to achieve understanding. Therefore, we estimate that the
amount of time needed to review the rule would not decrease. For each entity that reviews the rule, the estimated cost is
$1,134.20 (10 hours × $113.42) and we estimate that the total cost of reviewing this regulation is $1,020,780 ($1,134.20 ×
900). In addition, we anticipate that certain reviewers will incur familiarizations costs that reflect the time and effort
taken to seek answers to policy questions and to synthesize and disseminate the information on the proposed requirements to
the relevant decision-makers within their organization. We estimate that approximately one quarter of all anticipated reviewers,
or 225 (900/4 = 225), will engage in familiarization activities based on the proportion of comments submitted by professional
associations of impacted payers, providers, and patient advocacy organizations on our previous rules. We expect it would take
these medical and health service managers (Code 11-9111) approximately 20 hours at a rate of $113.42 to familiarize themselves
with the provisions in this proposed rulemaking. This would result in a burden of $2,268 (20 hours × $113.42 = $2,268.40)
for a single reviewer and $510,390 for all 225 reviewers to familiarize themselves and their organizations with the content
of this proposed rule. In total, we estimate the one-time cost of review and familiarization activities would be $1,531,170
($1,020,780 + $510,390 = $1,531,170). We seek comment on these assumptions.

D. Alternatives Considered

After considering the alternatives to the proposals in this rule, we concluded that the proposed policies in this rulemaking
represent the best options to mitigate ongoing burdens identified in public comments about prior authorization of drugs. Those
public comments and engagements with industry experts over the past 2 years support our conclusions that none of the alternatives
would address remaining critical issues related to patient, provider, or payer burden and interoperability. A key alternative
across all policies in this proposed rule is the proposed compliance timeline. We considered proposing earlier compliance
deadlines in 2027, which would accelerate the important outcomes we aim to achieve by improving the transfer of electronic
health data for patients, providers, and plans. For example, we considered providing less time, such as 6 months, for impacted
payers to implement the proposed technical standards. However, CMS believes that an implementation timeline of less than one
year would be more likely to result in inoperative or deficient technical builds. If developers have inadequate development
and testing time, we risk dysfunctional systems that do not achieve the policy goals stated in this proposed rule. Based on
anecdotal industry feedback, we estimate that the additional labor needed to accelerate technical development timelines to
less than a year could double the costs estimated in this rule. For example, the one-time implementation cost of incorporating
information on drugs into the Prior Authorization API would increase for a single entity to approximately $90,000 (45,000
× 2 = $90,000). (449) CMS seeks to support industry partners in their efforts to achieve interoperability and has determined that an accelerated
timeline would significantly increase the cost to impacted payers, while jeopardizing the effectiveness of the proposed standards,
and that the proposed compliance deadlines are most appropriate.

1. Alternatives Considered for the Proposal To Incorporate Drugs Covered Under a Medical Benefit Into the Prior Authorization

API for Impacted Payers

We considered encouraging impacted payers to voluntarily update their prior authorization processes for drugs under a medical
benefit, rather than proposing it as a requirement. A voluntary approach could allow plans the flexibility to tailor their
incorporation of drugs covered under a medical benefit to their specific systems. Encouraging voluntary incorporation might
create space for industry leaders to coalesce around best practices and develop consensus. We also considered proposing to
expand the Prior Authorization API provisions to drugs covered under a medical benefit at a later date to allow impacted payers
additional time to comply with the requirements finalized in the 2024 CMS Interoperability and Prior Authorization final rule.
However, this would cause a delay in addressing a well-known

  industry issue. In considering these alternatives, we assume that some industry leaders would likely volunteer to adopt this
  policy based on their voluntary participation in other HHS initiatives like the prior authorization pledge. [(450)]() The roughly 60 health plan firms [(451)]() would incur a one-time implementation cost of approximately $45,000 to incorporate drugs into their existing Prior Authorization
  APIs and approximately $11,200 in maintenance cost annually thereafter per the estimates in this proposed rule. The remaining
  non-volunteer health plans would incur no burden associated with this policy in the short term by deferring implementation.
  Based on stakeholder feedback, CMS is confident that industry is heading in the direction of prior authorization of drugs
  via API and that eventually these costs to integrate drugs would be incurred regardless. At the same time, the administrative
  cost to providers from inefficient manual drug prior authorization processes would persist as some plans delayed incorporating
  drugs into their Prior Authorization APIs. Based on these factors, we concluded that a voluntary and potentially inconsistent
  application of this policy does not adequately further CMS's health care and public health objectives. Therefore, we are proceeding
  with our proposal to expand the Prior Authorization API provisions to include drugs covered under a medical benefit and solicit
  public feedback.

2. Alternatives Considered for the Proposal To Support the Proposed NCPDP Standards for State Medicaid and CHIP Fee-for-Service

Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-Facilitated
Exchanges

We considered an alternative standard to the NCPDP SCRIPT standard, such as the NCPDP Telecommunication Standard, Version
D, Release 0 (Version D.0), used by pharmacies as mandated under HIPAA. The cost to implement the Telecommunications Standard,
which is already mandated for use under HIPAA and has been widely adopted, would likely be negligible, since impacted payers
already use this standard in pharmacy claims billing. However, this standard does not support data exchange between payers
and providers, nor does it support access to formulary or medication history. Despite this alternative's low-cost burden,
this standard would not achieve the desired electronic data exchange and CMS concluded that it would not be effective for
the prior authorization of drugs. Additionally, this standard cannot be used with the widely used NCPDP SCRIPT standard. We
also considered the X12N 278 Health Care Services Review—Request for Review and Response transaction standard. This standard
is currently used by providers to submit prior authorization, referral, and certification requests to payers. The cost of
requiring this X12N 278 standard would likely be minimal considering it is already an established HIPAA standard and would
be considered an usual and customary business expense. However, this standard is not intended or designed to be used for drugs
covered under a pharmacy benefit. Furthermore, these standards were evaluated by the Medicare Part D program and NCPDP, and
they determined that the NCPDP SCRIPT standard better supports electronic prior authorization of drugs covered under a pharmacy
benefit than the alternatives (85 FR 86827 through 86830). When considering the functionalities of these standards and Medicare
Part D and NCPDP's evaluations, we determined that the NCPDP Telecommunication and X12N 278 transaction standards do not support
the intent of this proposal. This led us to conclude that the NCPDP SCRIPT standard's technical advantages, combined with
the supporting NCPDP F&B and NCPDP RTPB standards, could maximize benefits to patients, providers, and payers, and align with
other regulatory requirements. These factors made these three proposed NCPDP standards the most appropriate option for this
proposed rule and justify the estimated cost of implementation. Therefore, 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 the proposed
NCPDP standards for electronic prior authorization of drugs covered under a pharmacy benefit.

3. Alternatives Considered for the Proposals for Prior Authorization Decision Timeframes for State Medicaid and CHIP Fee-for-Service

Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities and Qualified Health Plan Issuers on the Federally-Facilitated
Exchanges

For the prior authorization decision timeframes for non-drug items and services, we considered retaining the current prior
authorization decision timeframe of 15 days for standard requests for QHP issuers on the FFEs. However, we believe that aligning
the standard prior authorization request decision timeframe across all impacted payers is essential in achieving the agency's
goal of patient-centered care and ensuring continuity of care for patients transitioning between payers. While we do not estimate
a cost associated with the time to respond to prior authorization requests since they are considered usual and customary business
practices, CMS believes that the alignment of these timeframes could ultimately result in operational efficiencies across
a health plan's multiple lines of business, as there would be a consistent expectation and policy across the different products
offered by that plan. Therefore, we are proposing to require QHP issuers on the FFEs to make prior authorization decisions
for non-drug items and services as expeditiously as the enrollee's health condition requires, but no later than 7 calendar
days after receiving a standard request and no later than 72 hours after receiving an expedited request.

For the prior authorization timeframes for drugs, we considered not taking any action. However, MA organizations require payers
to respond to a prior authorization request no later than 72 hours for Part B drugs, and state Medicaid FFS programs are required
to respond to prior authorization requests for covered outpatient drugs no later than 24 hours. Therefore, we are proposing
to require QHP issuers on the FFEs to make prior authorization decisions no later than 72 hours for standard requests and
24 hours for expedited requests for all drugs. We are proposing to require state Medicaid FFS programs, Medicaid managed care
plans, and CHIP managed care entities to make prior authorization decisions for drugs within a timeframe that aligns with
applicable existing decision timeframe requirements. We are also proposing to require state CHIP FFS programs to make prior
authorization decisions no later than 24 hours for

  prescription drugs for which FFP is available

4. Alternatives Considered for the Proposal To Adopt FHIR Standards for Prior Authorization-Related HIPAA Standard Transactions

As an alternative to this proposal, HHS considered not taking any action and maintaining the X12N 270/271 and 278 transaction
standards, respectively “eligibility for a health plan” transactions (when used to determine whether prior authorization is
required) and “referral certification and authorization” transactions, currently required in regulation. Maintaining the status
quo would avoid placing a new burden on sectors of the health care industry such as hospitals and physicians who have not
yet implemented a FHIR API in their practice. These HIPAA covered entities would avoid the direct cost associated with adopting
new health IT standards and implementing a FHIR API or upgrading their EHR or other health IT to support FHIR, which we describe
in the cost section of this preamble. Maintaining the use of X12N 279/271 and 278 transaction standards for prior authorization
would also ensure continued alignment with other core operational uses of X12N standards, like eligibility verification and
claims submission. While X12N standards are widely used across the industry, we note that there is a very low adoption rate
of these X12N 278 transaction standards specifically for electronic prior authorization transactions, and this indicates to
HHS that the standards are not serving the payers or providers as intended. Industry feedback indicates that the bi-directional
and real-time responses enabled by FHIR would reduce administrative burden associated with the batch-oriented X12N transaction
standards, particularly in the “back and forth” communication between providers and payers. Based on the overwhelming movement
of the health care industry towards FHIR standards, HHS concludes that proposing the adoption of the FHIR standard and applicable
IGs for electronic prior authorization-related HIPAA transactions is the best option to support the long-term goal of interoperability.

E. Accounting Statement

Consistent with OMB Circular A-4, we have prepared an accounting statement in Table 24 showing the classification of the impact
associated with the provisions of this rule. (452) Monetary annualized benefits and non-budgetary costs are presented using 3 percent and 7 percent discount rates.

Note, as described in Table 33, the undiscounted cost estimated in the first year is $16,260,000, in the second year $75,070,000,
in the third year $64,030,000, in the fourth year $49,350,000, and the 5th through 10th years are $32,030,000.

F. Initial Regulatory Flexibility Analysis

The IRFA requires agencies to analyze options for regulatory relief of small entities. For purposes of the IRFA, HHS estimates
that many impacted payers and HIPAA covered entities are small entities, as that term is used in the IRFA, either by being
nonprofit organizations or by meeting the Small Business Administration (SBA) definition of a small business. Small entities
include small businesses, nonprofit organizations, and small governmental jurisdictions. Individuals and states are not included
in the definition of a small entity. Executive Order 13272 requires that HHS thoroughly review rules to assess and take account
of their potential impact on small businesses, small governmental jurisdictions, and small organizations (as mandated by the
IRFA). If a proposed rule may have a significant economic impact on a substantial number of small entities, then the proposed
rule must discuss steps taken, including alternatives considered, to minimize the burden on small entities. The IRFA does
not define the terms “significant economic impact” or “substantial number.” The SBA advises that this absence of statutory
specificity

  allows what is “significant” or “substantial” to vary, depending on the problem that is to be addressed in rulemaking, the
  rule's requirements, and the preliminary assessment of the rule's impact. Nevertheless, HHS typically considers a “significant”
  impact to be 3 to 5 percent or more of the affected entities' costs or revenues and a “substantial number” to be greater than
  5 percent of impacted entities.

1. Objectives and Legal Basis

In the 2024 CMS Interoperability and Prior Authorization final rule, we did not propose or finalize policies that apply to
drugs of any type because, as we discussed in the 2022 CMS Interoperability and Prior Authorization proposed rule and in the
final rule, the processes and electronic standards for prior authorization of drugs differ from those for non-drug items and
services. We also acknowledged that there are existing laws and regulations about prior authorization of certain 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-76241 and 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, the health care industry would benefit from consistent
requirements to ensure patients' timely access to drugs and a streamlined electronic prior authorization process that alleviates
burden for providers and payers.

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
(including associated FHIR IGs) as one set and three NCPDP standards (the NCPDP SCRIPT, NCPDP F&B, and NCPDP RTPB standards)
as the other set. 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 8897), to incorporate drugs covered under a medical benefit.
We are also proposing to require impacted payers (other than MA organizations) to support the proposed NCPDP standards for
the electronic prior authorization of drugs covered under a pharmacy benefit.

To fully incorporate drug coverage into the prior authorization policies finalized in the 2024 CMS Interoperability and Prior
Authorization final 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 respond to the provider with a specific reason for denying a prior authorization
request for all drugs, regardless of whether they are covered under a medical or pharmacy benefit. We propose several timeframe
modifications to align across programs. 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. We propose to require QHP issuers on the FFEs to make decisions on prior authorization requests for non-drug items
and services no later than 7 calendar days for standard requests and 72 hours for expedited requests. We are also proposing
to require QHP issuers on the FFEs to make decisions on prior authorization requests for drugs no later than 72 hours for
standard requests and no later than 24 hours for expedited requests. 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).

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 (89 FR 8889 and 8890). We are now proposing
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. 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 support implementation of the policies 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).

Under the Administrative Simplification provisions of HIPAA, in Title XI, Part C 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 for all
HIPAA covered entities. Specifically, in addition to the FHIR standard, HHS is proposing to adopt the US Core, SMART App Launch,
CRD, DTR, and PAS IGs in place of the adopted versions of the X12N 278 transaction standard in 45 CFR 162.1302 and the existing
X12N 270/271 transaction standard in 45 CFR 162.1202 for transactions related to prior authorization. Additionally, HHS is
proposing to adopt the CDex IG in 45 CFR 162.1302(g)(2)(vii) as the attachment standard for prior authorization transactions.
We seek comment on these proposals and their impact on small entities.

2. Impacted Payers

We refer to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs as “impacted payers,” as we did in the 2024 CMS Interoperability and Prior Authorization final
rule (89 FR 8758). In this proposed rule, the 341 impacted payers (also referred to as parent organizations offering impacted
health plans when discussing calculations) would perform system updates to expand the capability of the required APIs. (453) Specifically, the rule proposes to require that impacted payers add certain information for prior authorizations or expand
the capabilities of the Prior Authorization API to accommodate prior authorizations for drugs covered under a medical benefit.
Additionally, we propose that the impacted payers would be responsible for developing and submitting reports regarding API
usage or making data about prior authorization decisions for drugs available on public websites. Furthermore, if this proposed
rule is finalized, the 341 impacted payers would be required to implement and maintain APIs that conform to standards adopted
by the Secretary in 45 CFR 170.215. We refer to Table 3 in section II.A. of this proposed rule, where we list the standards
and specifications required for each API.

  Impacted payers would also be required to implement the FHIR IGs that were previously recommended in the 2024 CMS Interoperability
  and Prior Authorization final rule. A subset of impacted payers would have to create or update policies and procedures for
  prior authorization decisions to meet the timeframe proposals and to support electronic prior authorization for drugs using
  the proposed NCPDP standards adopted by the Secretary in 45 CFR 170.205(b), (c), and (u). Lastly, we propose that all impacted
  payers would be required to annually report their API endpoint information to CMS. Impacted payers described in this proposed
  rule would be classified under the NAICS code 524114 (Direct Health and Medical Insurance Carriers), which has a $47 million
  threshold for “small size” per the SBA. [(454)]()

a. Medicare Advantage

Each year, MA organizations estimate costs for the upcoming plan year and then submit bids and proposed PBPs to CMS. These
bids project payments to hospitals, providers, and staff for covered benefits, as well as the cost of plan administration
and profits. Because the API requirements proposed in this rule would apply to every MA plan and each MA plan must furnish
at least the Medicare Part A and Part B benefits, we assume that the cost of the API would be built into the administrative
component of the basic benefit bid. These bids in turn determine one component of the payments of the Medicare Trust Fund
to the MA organizations who reimburse providers and subcontractors for their services. A second component of the Trust Fund
payment to MA organizations are the rebates, which are a portion of the difference between the basic benefit bid compared
to an administratively-set benchmark for the MA plan's service area (currently, based on our past and projected experience,
rebates vary by plan and are approximately 66 percent). If the bid is below the benchmark, CMS pays an amount equal to the
standard bid of the MA organization. However, if the bid is above the benchmark, CMS pays the portion of the cost up to the
benchmark and the MA organization bears the extra cost and must charge enrollees a premium for the remaining amount, as set
forth in section 1854 of the Act. As the cost of providing services by these payers is covered by a combination of government
funding and in some cases by enrollee premiums, MA and PDPs are not expected to incur burdens or losses because the private
companies' costs are being supported by the government and enrolled beneficiaries. This lack of expected burden applies to
both large and small MA health plans. Any MA health plans that are considered “small” would be expected to include the costs
of compliance with the proposed regulations in their bids, thus avoiding additional burden, since the cost of complying with
any regulation is funded by payments from the government and, if applicable, enrollee premiums. Historically, at most 2 percent
of plans bid above the benchmark, and they contain roughly 1 percent of all plan enrollees.

Table 35 reports the percentage of MA organizations bidding above the benchmark and the percentage of affected enrollees in
recent years. This table reports aggregates of proprietary bid data collected by OACT. As shown in Table 35, the percentage
of plans incurring additional costs by bidding above the benchmark is 0.11 percent in 2024 and 0.07 percent in 2025, while
the CMS threshold for what constitutes a significant impact for purposes of the IRFA is 3 to 5 percent. Since at least 99
percent of MA organizations bid below the benchmark in recent years, we estimate that the federal government fully pays these
MA organizations their projected costs for providing services to enrollees for the coming year. The preceding analysis shows
that MA plans, whether small or large entities, are not significantly affected by this proposed rule since the vast majority
(all but at most 1 percent) will have their costs subsidized by the federal government and would not be materially impacted.
Consequently, we conclude that, among MA plans, the impact of the cost of these proposals would not be significant for the
purposes of the IRFA.

b. Medicaid and CHIP

Title XIX of the Act established the Medicaid program as a federal-state partnership to provide and finance medical assistance
to specified groups of eligible individuals. States claim federal matching funds quarterly based on their program expenditures.
Medicaid managed care plans and CHIP managed care entities reflect a somewhat consolidated market with a mix of for-profit,
non-profit, and government plans. 2022 survey data suggest that 16 managed care firms (including Aetna, Centene, United Health
Care, and others) were responsible for approximately 63 percent of the market. The remaining 36 percent of managed care enrollment
reflects local/regional managed care companies, (455) which are more likely to be considered small, though data on their size distribution by annual receipt size is limited. However,
since Medicaid

  managed care plans and CHIP managed care entities receive 100 percent capitation from the state, we expect that the projected
  costs associated with the provisions of this proposed rule, if finalized, will be included in their capitation rates. Consequently,
  we assert that there will be no substantial impact on a significant number of these entities for the purposes of this IRFA.

c. QHP Issuers on the Federally-Facilitated Exchanges

For the purposes of this IRFA, CMS evaluated health insurance issuers categorized under NAICs code 524114 (Direct Health and
Medical Insurance Carriers). Based on the latest available SUSB data, 1,071 total firms fall under code 524114. According
to SBA size standards, entities with average annual receipts of $47 million or less would be considered small entities in
this category. (456) Consistent with the analysis published in the “Patient Protection and Affordable Care Act, HHS Notice of Benefit and Payment
Parameters for 2027; and Basic Health Program” proposed rule (91 FR 6292), which appeared in the
Federal Register
on February 11, 2026, we assume that few, if any, insurance companies underwriting comprehensive health insurance policies
available on the FFE (in contrast, for example, to travel insurance policies or dental discount policies) fall below these
SBA size thresholds. CMS examined the premium revenue data from the MLR annual report submissions for the 2023 MLR reporting
year and approximately 84 out of 479 issuers of health insurance coverage nationwide have a total premium revenue of $47 million
or less. (457) Furthermore, approximately 80 percent of these small issuers belong to non-small holding groups based on the total premium
revenue of all associated subsidiaries available in the MLR data. Many, if not all, of these holding group companies are likely
to have other non-health lines of business in addition to health plan premium revenue that likely result in their total revenues
exceeding $47 million. (458) Therefore, CMS concludes that the QHP issuer on the FFEs population impacted by these proposed policies is unlikely to include
small entities and can be excluded from this IRFA.

3. HIPAA Covered Entities

In addition to proposed requirements for “impacted payers,” which largely comprise of government health plans within NAICS
category 524114, this proposed rule would also impose direct requirements on HIPAA covered entities to replace their existing
X12N 278 transaction standard with FHIR standards to build a FHIR API. Such covered entities include health care providers
(including individual providers and clinics who transmit information in an electronic form), hospitals, all health plans,
and health care clearinghouses. NAICS is used in the United States, Canada, and Mexico to classify businesses by industry.
While there is no distinction between small and large businesses among the NAICS categories, the SBA develops size standards
for each NAICS category. For the purposes of HHS's analysis, HHS relies on a combination of NAICS codes (hospitals NAICS code
622 and physicians NAICS code 6211) to approximate data on the health care providers that are small entities. HHS used the
methodology described in the 2022 HIPAA Standards for Health Care Attachments proposed rule RIA to evaluate the impact on
hospitals (NAICS code 622), clearinghouses (NAICS code 522320), physicians (NAICS code 6211), health plans (NAICS code 524114),
and all other support services (NAICS code 561990) which encompasses EHR vendors. The SBA Standard size entity threshold for
each category is described in Table 36. We used the most recent revenue data available from the 2022 SUSB from the Census
Bureau to determine the number of small entities and their revenue. HHS considered including the 2023 Nonemployer Statistics
(NES) data from the Census Bureau to supplement the SUSB data on small providers in particular. However, considering the industries
impacted by this proposal and the nature of the health care services which most frequently require prior authorization, HHS
is hesitant to include data on provider businesses with no employees in the total count of small provider entities. It is
unclear to HHS what proportion of providers (Physicians) have no employees and would also provide items and services subject
to prior authorization and manage those prior authorization requests themselves. HHS requests comment from providers on the
inclusion of NES data in this IRFA analysis and if self-employed providers with no employees could be expected to be impacted
by the proposed policy. As noted in the cost analysis section of this preamble, HHS is hesitant to project that all small
providers would make the business and financial decision to upgrade their EHR product to support the FHIR standards for prior
authorization. The decision to adopt FHIR would vary depending on the volume of prior authorization each business requests
among other factors.

HHS also encountered uncertainties in measuring the potential impact of this proposal on clearinghouses (NAICS code 522320)
and all other support services (NAICS code 561990), which encompasses EHR vendors, that could fall under the small entity
threshold. HHS notes that in 2020, the national clearinghouse association, Cooperative Exchange, indicated its 23 member companies
represent over 90 percent of the clearinghouse industry. (459) HHS is uncertain if this proposal would materially impact any small clearinghouse entities and seeks comment from the clearinghouse
industry on the potential impacts of this proposal on small clearinghouses. Finally, approximately 10,484 other support service
entities qualify as small entities, which equate to about 6.65 percent of the regulated small businesses across the 5 industries
in this analysis. The “other support service” category is used by HHS to represent plan management system vendors and EHR
technology system vendors, though it includes many types of technology vendors outside of the healthcare industry. Counting
the affected plan management system and EHR vendor entities separately is complicated, in part because they are increasingly
integrated. A health care provider entity's plan management system and EHR systems may be bundled into one product offering,
semi-integrated affiliated systems, or entirely independent systems offered by separate vendors. The 2022 Census Bureau SUSB
dataset does not provide firm-level counts for health care industry-specific technology vendors. (460) For this reason, HHS relies on industry reporting from 2024 and 2025, which suggests that approximately 500 vendors are offering
an EHR product and that several large vendors dominate the EHR market. (461) Epic, Oracle Cerner, and Meditech are the three biggest EHR vendors among hospitals, making up nearly 75 percent of the market
share combined. (462) Epic, Oracle Cerner, and athenahealth, Inc. represent the biggest vendors among clinicians, with approximately 82 percent
of the market share combined. (463 464) Due to the lack of specific detail on how many entities within the other support service category are EHR vendors and given
that the majority of providers using an EHR contract with a large entity, as explained in the Uncertainties analysis in section
V.C.2.a.(1).(d). of this proposed rule, HHS is uncertain if small EHR entities will be materially impacted by the proposals
in this proposed rule. HHS invites comment on this assumption and requests feedback from EHR vendors, particularly those considered
small, on the potential impacts of these policies on small EHR vendor companies.

Based on the SBA size threshold described in Table 36, HHS analyzed the revenue for hospitals, physicians, and direct health
insurance plans which met the SBA criteria for small entities and their anticipated change in revenue, illustrated in Table
37. To conduct this revenue test, HHS used the total count of firms considered small based on the latest 2022 SUSB data (143,743).
Then, HHS calculated the percentage of these small firms that fall into size ranges by receipt (“% of Small Firms” column
in Table 37). These percentages are applied to the average revenue for all small entities, which yields the average revenue
for each firm size. The average revenue for each firm size is then divided by the annualized cost of the proposed rule per
firm and reflected as a percentage. When the annualized net primary cost estimates were determined, there were $40.88 million
net annualized costs for the industries overall. (465) The net annualized costs for this proposed rule are $40.88 million, meaning each of the 143,743 small businesses incur a net
annualized cost of $284.40, regardless of their size by receipts. This resulting percentage (“Revenue Test” column in Table
37) is the anticipated change in revenue for small firms due to the proposed rule. As a measure of significant economic

  impact on a substantial number of small entities, HHS uses a change in revenue of more than 3 percent and presents this analysis
  in Table 37.

HHS calculated the percentage of revenue represented by the primary estimates of small entities earning less than $50,000,000
in receipts annually. None of the included buckets exceeded the 3 percent of the revenue threshold, and all of the revenue
test results reflect less than 1 percent revenue impact.

4. Alternatives for Small Entities

In an effort to anticipate the needs of small entities, CMS considered options for viable alternatives that adapt the proposed
policies in this proposed rule and tailor them to small businesses. These alternatives attempt to balance the need for broad
adoption of the proposals to achieve improved interoperability and an acknowledgement that small businesses are typically
less resourced. The alternative options fall into two main categories: delayed compliance and exemption criteria. Some of
these alternatives are already incorporated into the proposals of this rule but could be expanded to other provisions to better
accommodate small businesses, while others are novel and have not yet been introduced.

a. Delayed Compliance

HHS is proposing to adopt a modified standard for two HIPAA Administrative Simplification transactions, the “referral certification
and authorization” transaction in 45 CFR part 162, subpart M and the “eligibility for a health plan” transaction in 45 CFR
part 162, subpart L. HHS proposes to adopt, in 45 CFR 162.1302(g), the FHIR standard, US Core IG, SMART App Launch IG, CRD,
DTR, PAS, and CDex IGs as the specifications that compose the proposed transaction standard. In addition, in 45 CFR 162.1202(f)(2),
HHS is proposing to adopt the FHIR standard, the US Core IG, SMART App Launch IG, and CRD IG as the specifications that compose
the proposed transaction standard for “eligibility for a health plan” transactions, when used to determine whether prior authorization
is required. If finalized as proposed, HIPAA covered entities would be required to comply with these transaction standards
no later than 24 months from the effective date of a final rule, except for small health plans, defined in 45 CFR 160.103
as those with annual receipts of $5 million or less, for which the compliance date would be 36 months from the effective date
of a final rule. The proposed delayed compliance date for small health plans would allow these health plans an additional
year to prepare to use the FHIR standards for those transactions. This same principle could be applied to entities considered
“small” for other provisions in this proposed rule, including the proposal for impacted payers to expand their Prior Authorization
API to incorporate drugs covered under a medical benefit and that impacted payers (other than MA organizations) support the
NCPDP standards for the electronic prior authorization of drugs covered under a pharmacy benefit. An additional 12 months
of implementation time could support small entities in preparing for the technical requirements of these proposals and distribute
the estimated per-entity cost of $12,500 associated with adopting the standard over 1 year. This redistribution of cost over
2 years could result in small entities saving approximately $6,250 in the first year of implementation. However, as discussed
in section V.F.2. of this proposed rule, the majority of impacted payers likely do not qualify as small, so the impact of
this alternative is uncertain.

b. Extensions and Exceptions

CMS is proposing a process for state Medicaid and CHIP FFS programs to request from CMS extensions to allow additional time
to implement the Prior Authorization API, meet the proposed requirement to incorporate drugs covered under a medical benefit
into the Prior Authorization API, and/or to support the NCPDP standards for electronic prior authorization of drugs covered
under a pharmacy benefit. The updated proposals would replace the existing process by which states can request an exemption
from the requirement to implement the Prior Authorization API finalized in the 2024 CMS Interoperability and Prior

  Authorization final rule. CMS is also proposing a process to allow QHP issuers on the FFEs to apply for an exception from
  the proposed requirement to support the NCPDP standards for electronic prior authorization of drugs covered under a pharmacy
  benefit in limited circumstances. A similar exception process, wherein an impacted payer provides justification based on certain
  criteria for not being able to meet the requirement and submits a plan to come into compliance, might be adapted and provided
  specifically to small entities that participate in any CMS program. If granted an exception, this alternative could save small
  entities between $12,500-$57,511 in first-year implementation costs based on the estimated burden for each of these proposals.
  However, this process would still generate administrative and reporting burden for the small entities as they would need to
  justify their exception. Furthermore, patients that have coverage through those small entities and providers in their networks
  would not be able to benefit from the burden reduction we expect our proposals to catalyze.

5. Identifying Duplication

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to improve
the electronic exchange of health care information, not just with patients, but also with their providers and other payers.
We finalized requirements for impacted payers to implement and maintain a Prior Authorization API that streamlines the prior
authorization process between providers and payers. (466) We additionally 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. Many of the policies proposed in this rule build upon
and align with those finalized in the 2024 CMS Interoperability and Prior Authorization final rule particularly because they
apply to the same population of impacted payers and reference the same electronic data transmission standards. However, CMS
confirms that the proposed requirements in this rule do not duplicate efforts of this previous rulemaking, but rather, they
build upon and refine them to ensure that drugs are accounted for in the improvements being made to the prior authorization
process, standards, and data reporting.

In addition, HHS reiterates that there is no redundancy in these proposals and the provisions finalized in the HIPAA Standards
for Health Care Attachments final rule (91 FR 14350). In the HIPAA Standards for Health Care Attachments proposed rule, HHS
proposed standards for “health care attachments” transactions, which would support both health care claims and prior authorization
transactions, and a standard for electronic signatures to be used in conjunction with health care attachments transactions.
However, in the HIPAA Standards for Health Care Attachments final rule, HHS adopted an attachment standard only for claims
transactions and did not finalize an attachment standard for prior authorization transactions. Specifically, the HIPAA Standards
for Health Care Attachments final rule does not adopt any modifications to prior authorization transactions or finalize any
conflicting prior authorization transaction requirements that would overlap with this proposed rule. HHS concludes that there
is no duplication or conflict of the requirements in this proposed rule and other recent rulemakings impacting similar populations
and sectors of the industry.

6. Conclusion and Request for Comment

CMS concludes that the proposals relevant to impacted payers do not produce a significant economic impact on a substantial
number of impacted payers that are small entities. CMS seeks comment on the assumptions related to the number of MA organizations,
state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs
that could be considered small businesses, small governmental jurisdictions, or small organizations. HHS assumes that only
a subset of small HIPAA covered entities would be economically impacted by the proposed policy and assumes that only those
represented in the SUSB dataset, that is, those with employees, would be impacted by these proposals. CMS and HHS solicit
comment specifically from HIPAA covered entities and small businesses associates in the health care and health technology
industries on the impacts of the various proposals in this proposed rule. We request comment specifically on how the proposals
increase or decrease administrative burden for small HIPAA covered entities and business associates, as well as feedback on
mitigation strategies.

For the purposes of the IRFA analysis, HHS concludes that there is not a significant impact on small entities. As a measure
of significant economic impact on a substantial number of small entities, HHS uses a change in revenue of more than 3 percent.
As illustrated by the revenue test in Table 37, none of the small firm sizes approached the 3 percent threshold.

In addition, section 1102(b) of the Act requires HHS to prepare an RIA if a rule may have a significant impact on the operations
of a substantial number of small rural hospitals. This analysis must conform to the provisions of section 603 of the IRFA
for proposed rules. For purposes of section 1102(b) of the Act, HHS defines a small rural hospital as a hospital that is located
outside of a Metropolitan Statistical Area for Medicare payment regulations and has fewer than 100 beds. HHS is not preparing
an analysis for section 1102(b) of the Act because HHS has determined that the Secretary may certify that this proposed rule
would not have a significant impact on the operations of a substantial number of small rural hospitals.

G. Unfunded Mandates Reform Act

Section 202 of UMRA also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates
will require spending more in any one year than threshold amounts in 1995 dollars, updated annually for inflation. In 2026,
this threshold is approximately $193 million. This proposed rule will not impose mandates that will result in the expenditure
by state, local, and tribal governments, in the aggregate, or by the private sector, of more than $193 million in any one
year.

H. Federalism

Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule that imposes
substantial direct requirement costs on state and local governments, preempts state law, or otherwise has federalism implications.
This proposed rule will not have a substantial direct effect on state or local governments, preempt state law, or otherwise
have a federalism implication.

I. Executive Order 14192, “Unleashing Prosperity Through Deregulation”

Executive Order 14192, entitled “Unleashing Prosperity Through Deregulation,” was issued on January 31, 2025 and requires
that “any new incremental costs associated with new regulations shall, to the extent permitted by law, be offset by the elimination
of existing costs associated with at least 10 prior regulations.” This proposed rule, if finalized as proposed, is expected
to be considered an Executive Order 14192 regulatory action. We estimate that this final rule will generate $31.78 million
in annualized cost at a 7 percent discount rate, over a perpetual time horizon.

By the provisions of Executive Order 12866, this proposed rule has been reviewed by OMB.

VI. Response to Comments

Because of the large number of public comments we usually receive on
Federal Register
documents, we cannot acknowledge or respond to them individually. We will consider all comments we receive by the date and
time specified in the
DATES
section of the preamble, and when we proceed with a subsequent document, we will respond to the comments in the preamble to
that document.

Dr. Mehmet Oz, Administrator of the Centers for Medicare & Medicaid Services, approved this document on April 3, 2026.

List of Subjects

Grant programs-health, Health insurance, Hospitals, Intergovernmental relations, Medicare, Reporting and recordkeeping requirements.

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

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

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

Grant programs-health, Medicaid.

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

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

Administrative practice and procedures, Electronic transactions, Health facilities, Health insurance, Hospitals, Incorporation
by reference, Medicaid, Medicare, Reporting and recordkeeping requirements.

Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Healthcare,
Health information technology, Health insurance, Health records, Hospitals, Incorporation by reference, Laboratories, Medicaid,
Medicare, Privacy, Reporting and record keeping requirements, Public health, Security.

For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services proposes to amend 42 CFR chapter IV
and the Department of Health and Human Services proposes to amend 45 CFR subtitle A, subchapters B, C, and D as set forth
below:

Title 42—Public Health

PART 403—SPECIAL PROGRAMS AND PROJECTS

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

Authority:

42 U.S.C. 1302, and 1395hh.

1. Section 403.902 is amended by adding the definition of “Failure to report” in alphabetical order.

§ 403.902 Definitions. * * * * *

Failure to report means either of the following:

(1) A failure, including a knowing failure, to timely, accurately, and completely provide to HHS, CMS, OIG, or their designees
the information pertaining to the requirements outlined in this subpart.

(2) A failure to timely, accurately, and completely provide to HHS, CMS, OIG, or their designees any books, contracts, records,
documents, and other evidence sufficient to enable the audit, evaluation, and inspection of the records maintained by the
applicable manufacturer or applicable group purchasing organization as required in § 403.912(e)(2). An untimely failure under
this paragraph is defined as beginning 30 calendar days after notification of the information request and ending upon provision
of the requested information to HHS, CMS, OIG, or the designee.

---

PART 422—MEDICARE ADVANTAGE PROGRAM

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

Authority:

42 U.S.C. 1302 and 1395hh.

1. Section 422.119 is amended by—

a. Revising paragraphs (a), (b)(1) introductory text, and (b)(1)(iv) introductory text;

b. Removing paragraph (b)(1)(iv)(A)(4);

c. Redesignating paragraphs (b)(1)(iv)(A)(5) and (6) as paragraphs (b)(1)(iv)(A)(4) and (5);

d. Revising paragraphs (b)(1)(v) and (c)(1);

e. Redesignating paragraphs (c)(2) through (4) and paragraphs (c)(3) through (5);

f. Adding new paragraph (c)(2); and

g. Revising newly redesignated paragraph (c)(5) and paragraph (h).

The revisions and addition read as follows:

§ 422.119 Access to and exchange of health data and plan information. (a) Application Programming Interface to support MA enrollees. Beginning January 1, 2021, an MA organization must implement and maintain a standards-based Application Programming Interface
(API) that permits third-party applications to retrieve, with the approval and at the direction of a current MA enrollee or
their personal representative, data specified in paragraph (b) of this section through the use of common technologies and
without special effort from the enrollee.

(b) * * *

(1) An MA organization must make all of the following information maintained by the MA organization with a date of service
on or after January 1, 2016 accessible to its current enrollees or their personal representatives through

  the API described in paragraph (a) of this section:

---

(iv) Beginning January 1, 2027, information about prior authorizations for items and services (excluding drugs), including
the items and services approved and the information in paragraph (b)(1)(iv)(A) of this section, according to the timelines
in paragraph (b)(1)(iv)(B) of this section.

---

(v) Beginning October 1, 2027, information about prior authorizations for drugs, including the drugs and dosage approved and
the information in paragraph (b)(1)(iv)(A) of this section, according to the timelines in paragraph (b)(1)(iv)(B) of this
section.

---

(c) * * *

(1) Must implement and maintain API technology conformant with the standards in 45 CFR 170.215(a), (b)(1), (c), and (e);

(2) Beginning October 1, 2027, must implement and maintain API technology conformant with the standards in 45 CFR 170.215(k)(1),
(k)(2), and (m);

---

(5) An MA organization may use an updated version of any standard or all standards required under paragraph (c)(1), (c)(2)
or (c)(4) of this section, where—

---

(h) Reporting Patient Access API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before any calendar year for which it expects to offer an MA plan, an MA
organization must report to CMS the information specified in paragraphs (h)(1) and (2) of this section about its Patient Access
API to be published by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS
within 1 week of any changes:

(1) All API endpoints in the form of an Endpoint Resource, as defined by a version of the FHIR standard adopted in 45 CFR
170.215(a), including, if multiple, appropriate use cases for each.

(2) URLs with the documentation required in paragraph (d) of this section, including all of the following, if applicable:

(i) A direct URL to the API FHIR capability statement.

(ii) Authorization and authentication protocols and implementation details.

(iii) API registration information.

1. Section 422.120 is amended by revising paragraphs (a) and (c) to read as follows:

§ 422.120 Access to published provider directory information. (a) Beginning January 1, 2021, unless otherwise specified, an MA organization must implement and maintain a publicly accessible,
standards-based Application Programming Interface (API) that meets all the following:

(1) Is conformant with the standards in 45 CFR 170.215(a), (b)(1), and (n)(1) or an updated version of any such standards
in conformance with § 422.119(c)(5).

(2) Beginning October 1, 2027, is conformant with the standards in 45 CFR 170.215(n)(2), or an updated version of any such
standards in conformance with § 422.119(c)(5).

(3) Does not restrict the availability of this information to particular persons or organizations.

(4) Is conformant with the documentation requirements in § 422.119(d).

(5) Is conformant with the denial and discontinuation policies in § 422.119(e).

(6) Is accessible via a public-facing digital endpoint.

---

(c) Reporting Provider Directory API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before any calendar year for which it expects to offer an MA plan, an MA
organization must report to CMS the information in § 422.119(h)(1) and (2) about its Provider Directory API to be published
by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any
changes.

1. Section 422.121 is amended by—

a. Revising paragraphs (a) introductory text, (a)(1)(i), and (ii), and (a)(2) introductory text;

b. Adding paragraphs (a)(1)(iii), c. Revising paragraph (a)(2) introductory text;

d. Adding paragraphs (a)(6), and (7);

e. Revising paragraphs (b) introductory text, and (b)(1)(i) and (ii); and

f. Adding paragraphs (b)(1)(iii), (b)(4)(ii)(A)(3), (b)(8), and (b)(9).

The revisions and additions read as follows:

§ 422.121 Access to and exchange of health data for providers and payers. (a) Application programming interface to support data exchange from payers to providers—Provider Access API. Beginning January 1, 2027, unless otherwise specified, an MA organization must do the following:

(1) * * *

(i) The requirements in § 422.119(c)(3), (c)(4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), (c), and (d), or an updated version of any such standards in conformance
with § 422.119(c)(5).

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(k)(1) and (k)(2), or an updated version of any such standards
in conformance with § 422.119(c)(5).

(2) Provider access. Make the data specified in § 422.119(b)(1) and (b)(2)(i) with a date of service on or after January 1, 2016, excluding provider
remittances and enrollee cost-sharing information, that are maintained by the MA organization available to in-network providers
via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such
a provider, if all the following conditions are met:

---

(6) Reporting on Provider Access API usage. Beginning in 2028, by March 31 of each year, an MA organization must report to CMS the metrics specified in paragraphs (a)(6)(i)
through (iii) of this section, in the form of aggregated, de-identified data, for the previous calendar year at the contract
level in the form and manner specified by the Secretary:

(i) The total number of unique providers who requested patient data via the MA organization's Provider Access API.

(ii) The total number of unique patients whose data were transferred via the MA organization's Provider Access API to a provider's
health IT system.

(iii) The total number of patient data transfers via the MA organization's Provider Access API.

(7) Reporting Provider Access API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before any calendar year for which it expects to offer an MA plan, an MA
organization must report to CMS the information in § 422.119(h)(1) and (2) about its Provider Access API to be published by
CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any changes.

(b) Application programming interface to support data exchange between payers—Payer-to-Payer API. Beginning January 1, 2027, unless otherwise specified, an MA organization must do the following:

(1) * * *

(i) The requirements in § 422.119(c)(3), (c)(4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), and (d), or an updated

  version of any such standards in conformance with § 422.119(c)(5).

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(k)(1), and (k)(2), or an updated version of any such standards
in conformance with § 422.119(c)(5).

---

(4) * * *

(ii) * * *

(A) * * *

(3) The information in § 422.119(b)(2)(ii).

---

(8) Reporting on Payer-to-Payer API usage. Beginning in 2028, by March 31 of each year, an MA organization must report to CMS the metrics specified in paragraphs (b)(8)(i)
through (iii), in the form of aggregated, de-identified data, for the previous calendar year at the contract level in the
form and manner specified by the Secretary:

(i) The percent of patients who have opted in to the payer to payer data exchange.

(ii) The total number of unique patients whose data have been sent to other payers via the MA plan's Payer-to-Payer API.

(iii) The total number of unique patients whose data have been received from other payers via the MA plan's Payer-to-Payer
API.

(9) Reporting Payer-to-Payer API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before any calendar year for which it expects to offer an MA plan, an MA
organization must report to CMS the information in § 422.119(h)(1) and (2) about its Payer-to-Payer API to be published by
CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any changes.

1. Section 422.122 is amended by—

a. In paragraph (a) by removing the phrase “as defined in § 422.119(b)(1)(v), in accordance with” and adding in its place
the phrase “in accordance with”;

b. Revising paragraph (b) introductory text;

c. Redesignating paragraphs (b)(1) through (5) as paragraphs (b)(2) through (6);

d. Adding new paragraph (b)(1);

e. Revising newly redesignated paragraph (b)(2);

f. In newly redesignated paragraph (b)(3) by—

i. Removing the phrase “items or services” and adding in its place the phrase “items, services, or drugs”;

ii. Removing the “;” and adding in its place “.”;

g. In newly redesignated paragraph (b)(4), by removing the “; and” and adding in its place “.”;

h. Revising paragraph (c); and

i. Adding paragraphs (d), (e), and (f).

The revisions and additions read as follows:

§ 422.122 Prior authorization requirements. * * * * *

(b) Prior Authorization API. Beginning January 1, 2027, unless otherwise specified, an MA organization must implement and maintain an API that meets all
of the following:

(1) Is conformant with all the following:

(i) The requirements in § 422.119(c)(3), (c)(4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), and (c), or an updated version of any such standards in conformance with
§ 422.119(c)(5).

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(j)(1), (j)(2), and (j)(3), or an updated version of any such
standards in conformance with § 422.119(c)(5).

(2) Is populated with the following:

(i) Beginning January 1, 2027, the MA organization's list of covered items and services (excluding drugs) that require prior
authorization.

(ii) Beginning October 1, 2027, the MA organization's list of drugs payable under Part B that require prior authorization.

---

(c) Publicly reporting prior authorization metrics. Beginning in 2026, following each calendar year that it offers an MA plan, an MA organization must annually report prior authorization
metrics, excluding data on drugs, at the MA contract level no later than March 31. The MA organization must make all of the
following metrics from the previous calendar year publicly accessible by posting them on its website:

(1) A list of all items and services that require prior authorization.

(2) For standard prior authorization requests for items and services, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage that were approved after appeal.

(iv) The total number and percentage that remain denied after appeal.

(v) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(vi) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(vii) The average and median time that elapsed between the submission of a request and a decision by the MA plan.

(3) For expedited prior authorization requests for items and services, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage that were approved after appeal.

(iv) The total number and percentage that remain denied after appeal.

(v) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(vi) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(vii) The average and median time that elapsed between the submission of a request and a decision by the MA plan.

(d) Publicly reporting prior authorization for drugs metrics. Beginning in 2028, following each calendar year that it offers an MA plan, an MA organization must annually report prior authorization
metrics on all drugs payable under Part B, at the MA contract level no later than March 31. The MA organization must make
all of the following metrics from the previous calendar year publicly accessible by posting them on its website:

(1) A list of all drugs payable under Part B that require prior authorization.

(2) For standard prior authorization requests for all drugs payable under Part B, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(iv) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(v) The total number and percentage approved after appeal.

(vi) The total number and percentage that remain denied after appeal.

(vii) The average and median time that elapsed between the submission of requests and decisions.

(3) For expedited prior authorization requests for all drugs payable under Part B, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(iv) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(v) The total number and percentage approved after appeal.

(vi) The total number and percentage that remain denied after appeal.

(vii) The average and median time that elapsed between the submission of requests and decisions.

(e) Reporting on Prior Authorization API usage. Beginning in 2028, by March 31of each year, an MA organization must report to CMS the metrics specified in paragraphs (e)(1)
through (3) of this section, in the form of aggregated, de-identified data, for the previous calendar year at the contract
level in the form and manner specified by the Secretary:

(1) The total number of unique providers who requested a prior authorization for items, services, or drugs through the MA
organization's Prior Authorization API.

(2) The number of unique prior authorization requests for items, services, or drugs received through the MA organization's
Prior Authorization API.

(3) The percentage of all prior authorization requests that were received through the MA organization's Prior Authorization
API.

(f) Reporting Prior Authorization API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before any calendar year for which it expects to offer an MA plan, an MA
organization must report to CMS the information in § 422.119(h)(1) and (2) about its Prior Authorization API to be published
by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any
changes.

PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION

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

Authority:

42 U.S.C. 1302.

1. Section 431.60 is amended by—

a. Revising paragraphs (a), (b) introductory text, (b)(5) introductory text;

b. Removing paragraph (b)(5)(i)(D);

c. Redesignating paragraphs (b)(5)(i)(E) and (F) as paragraphs (b)(5)(i)(D) and (E);

d. Revising paragraphs (b)(6) and (c)(1);

e. Redesignating paragraphs (c)(2) through (4) as paragraphs (c)(3) through (5);

f. Adding new paragraph (c)(2); and

g. Revising newly redesignated paragraph (c)(5) introductory text and paragraph (h). The revisions and addition read as follows:

§ 431.60 Beneficiary access to and exchange of data. (a) Application Programming Interface to support Medicaid beneficiaries. Beginning January 1, 2021, a State must implement and maintain a standards-based Application Programming Interface (API) that
permits third-party applications to retrieve, with the approval and at the direction of a current beneficiary or their personal
representative, data specified in paragraph (b) of this section through the use of common technologies and without special
effort from the beneficiary.

(b) Accessible content. A State must make all of the following information maintained by the State with a date of service on or after January 1, 2016
accessible to its current beneficiaries or their personal representatives through the API described in paragraph (a) of this
section:

---

(5) Beginning January 1, 2027, information about prior authorizations for items and services (excluding covered outpatient
drugs defined in section 1927(k)(2) of the Act), including the items and services approved and the information in paragraph
(b)(5)(i) of this section, according to the timelines in paragraph (b)(5)(ii) of this section.

---

(6) Beginning October 1, 2027, information about prior authorizations for covered outpatient drugs defined in section 1927(k)(2)
of the Act, including the drugs and dosage approved and the information in paragraph (b)(5)(i) of this section, according
to the timelines in paragraph (b)(5)(ii) of this section.

(c) * * *

(1) Beginning January 1, 2021, must implement and maintain API technology conformant with the standards in 45 CFR 170.215(a),
(b)(1), (c), and (e);

(2) Beginning October 1, 2027, must implement and maintain API technology conformant with the standards in 45 CFR 170.215(k)(1),
(k)(2), and (m);

---

(5) A State may use an updated version of any standard or all standards required under paragraph (c)(1), (c)(2), or (c)(4)
of this section where:

---

(h) Reporting Patient Access API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information specified in paragraphs (h)(1) and (2) about its Patient Access API to be published
by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any
changes:

(1) All API endpoints in the form of an Endpoint Resource, as defined by a version of the FHIR standard adopted in 45 CFR
170.215(a), including, if multiple, appropriate use cases for each.

(2) URLs with the documentation required in paragraph (d) of this section, including all of the following, if applicable:

(i) A direct URL to the API FHIR capability statement.

(ii) Authorization and authentication protocols and implementation details.

(iii) API registration information.

1. Section 431.61 is amended by—

a. Revising paragraphs (a) introductory text, (a)(1)(i), and (ii), and (a)(2) introductory text;

b. Adding paragraphs (a)(1)(iii);

c. Revising paragraph (a)(2) introductory text;

d. Adding paragraphs (a)(6) and (7);

e. Revising paragraphs (b) introductory text, and (b)(1)(i) and (ii); and

f. Adding paragraphs (b)(1)(iii), (b)(4)(ii)(A)(3), (b)(8), and (b)(9).

The revisions and additions read as follows:

§ 431.61 Access to and exchange of health data for providers and payers. (a) Application programming interface to support data exchange from payers to providers—Provider Access API. Beginning January 1, 2027, unless otherwise specified or granted an extension or exemption under paragraph (c) of this section,
a State must do the following:

(1) * * *

(i) The requirements in § 431.60(c)(3), (c)(4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), (c), and (d), or an updated version of any such standards in conformance
with § 431.60(c)(5).

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(k)(1), and (k)(2), or an updated version of any such standards
in conformance with § 431.60(c)(5).

(2) Provider access. Make the data specified in § 431.60(b)(1) through (3) and (b)(5) and (6) with a date of service

  on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information, that are maintained
  by the State available to enrolled Medicaid providers via the API required in paragraph (a)(1) of this section no later than
  1 business day after receiving a request from such a provider, if all the following conditions are met:

---

(6) Reporting on Provider Access API usage. Beginning in 2028, by March 31 of each year, a State must report to CMS the metrics specified in paragraphs (a)(6)(i) through
(iii) of this section, in the form of aggregated, de-identified data, for the previous calendar year at the State level in
the form and manner specified by the Secretary:

(i) The total number of unique providers who requested patient data via the State's Provider Access API.

(ii) The total number of unique patients whose data were transferred via the State's Provider Access API to a provider's health
IT system.

(iii) The total number of patient data transfers via the State's Provider Access API.

(7) Reporting Provider Access API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information in § 431.60(h)(1) and (2) about its Provider Access API to be published by CMS.
Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any changes.

(b) Application programming interface to support data exchange between payers—Payer-to-Payer API. Beginning January 1, 2027, unless otherwise specified or granted an extension or exemption under paragraph (c) of this section,
a State must do the following:

(1) * * *

(i) The requirements in § 431.60(c)(3), (c)(4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), and (d), or an updated version of any such standards in conformance with
§ 431.60(c)(5).

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(k)(1) and (k)(2), or an updated version of any such standards
in conformance with § 431.60(c)(5).

---

(4) * * *

(ii) * * *

(A) * * *

(3) The information in § 431.60(b)(4).

---

(8) Reporting on Payer-to-Payer API usage. Beginning in 2028, by March 31 of each year, a State must report to CMS the metrics specified in paragraphs (b)(8)(i) through
(iii) of this section, in the form of aggregated, de-identified data, for the previous calendar year at the State level in
the form and manner specified by the Secretary:

(i) The percent of patients who have opted in to the payer to payer data exchange.

(ii) The total number of unique patients whose data have been sent to other payers via the State's Payer-to-Payer API.

(iii) The total number of unique patients whose data have been received from other payers via the State's Payer-to-Payer API.

(9) Reporting Payer-to-Payer API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information in § 431.60(h)(1) and (2) about its Payer-to-Payer API to be published by CMS.
Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any changes.

---

1. Section 431.70 is amended by revising paragraphs (a) and (c) to read as follows:

§ 431.70 Access to published provider directory information. (a) Beginning January 1, 2021, unless otherwise specified, the State must implement and maintain a publicly accessible, standards-based
Application Programming Interface (API) that meets all the following:

(1) Is conformant with the standards in 45 CFR 170.215(a), (b)(1), and (n)(1) or an updated version of any such standards
in conformance with § 431.60(c)(5).

(2) Beginning October 1, 2027, is conformant with the standards in 45 CFR 170.215(n)(2), or an updated version of any such
standards in conformance with § 431.60(c)(5).

(3) Does not restrict the availability of this information to particular persons or organizations.

(4) Is conformant with the documentation requirements in § 431.60(d).

(5) Is conformant with the denial and discontinuation policies in § 431.60(e).

(6) Is accessible via a public-facing digital endpoint.

---

(c) Reporting Provider Directory API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information in § 431.60(h)(1) and (2) about its Provider Directory API to be published by
CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any changes.

1. Section 431.80 is amended by—

a. Revising paragraphs (a) and (b) introductory text;

b. Redesignating paragraphs (b)(1) through (4) as paragraphs (b)(2) through (5);

c. Adding a new paragraph (b)(1);;

d. Revising newly redesignated paragraph (b)(2);

e. In newly redesignated paragraph (b)(3) by—

i. Removing the phrase “items or services” and adding in its place the phrase “items, services, or drugs”;

ii. Removing the “;” and adding in its place “.”;

f. In newly redesignated paragraph (b)(4), removing the “;” and adding a “.” in its place;

g. Redesignating paragraph (c)(1) as (f)(1);

h. Removing paragraph (c)(2);

i. Adding new paragraph (c) and paragraphs (d) and (e);

j. Revising newly redesignated paragraph (f)(1); and

k. Adding paragraph (f)(2).The revisions and additions read as follows:

§ 431.80 Prior authorization requirements. (a) Communicating a reason for denial.

(1) Beginning January 1, 2026, if the State denies a prior authorization request (excluding a request for coverage of covered
outpatient drugs defined in section 1927(k)(2) of the Act), the response to the provider must be sent in accordance with the
timeframes established in § 440.230(e)(1) of this chapter, and must include a specific reason for the denial, regardless of
the method used to communicate that information.

(2) Beginning October 1, 2027, if the State denies a prior authorization request for any covered outpatient drugs defined
in section 1927(k)(2) of the Act, the response to the provider must be sent in accordance with the timeframes established
in section 1927(d)(5)(A) of the Act, and must include a specific reason for the denial, regardless of the method used to communicate
that information.

(b) Prior Authorization API. Beginning January 1, 2027, unless otherwise specified or granted an extension under paragraph (f) of this section, a State
must implement and maintain an API that meets all of the following:

(1) Is conformant with all of the following:

(i) The requirements in § 431.60(c)(3), (c)(4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), and (c), or an updated

  version of any such standards in conformance with § 431.60(c)(5).

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(j)(1), (j)(2), and (j)(3), or an updated version of any such
standards in conformance with § 431.60(c)(5).

(2) Is populated with the following:

(i) Beginning January 1, 2027, the State's list of covered items and services (excluding prescribed drugs described in section
1905(a)(12) of the Act) that require prior authorization.

(ii) Beginning October 1, 2027, the State's list of prescribed drugs described in section 1905(a)(12) of the Act processed
in a claims adjudication system that is not at the point of sale that require prior authorization.

---

(c) Reporting on Prior Authorization API usage. Beginning in 2028, by March 31 of each year, a State must report to CMS the metrics specified in paragraphs (c)(1) through
(3) of this section, in the form of aggregated, de-identified data, for the previous calendar year at the State level in the
form and manner specified by the Secretary:

(1) The total number of unique providers who requested a prior authorization for items, services, or drugs through the State's
Prior Authorization API.

(2) The number of unique prior authorization requests for items, services, or drugs received through the State's Prior Authorization
API.

(3) The percentage of all prior authorization requests that were received through the State's Prior Authorization API.

(d) Reporting Prior Authorization API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information in § 431.60(h)(1) and (2) about its Prior Authorization API to be published
by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any
changes.

(e) Electronic prior authorization for prescription drugs. Beginning October 1, 2027, unless granted an extension under paragraph (f) of this section, a State must support an electronic
prior authorization process using all of the following standards for any prescribed drugs described in section 1905(a)(12)
of the Act that are processed in a point of sale or real-time claims adjudication system that require prior authorization:

(1) An unexpired version of the NCPDP SCRIPT Standard adopted in 45 CFR 170.205(b) to communicate drug-related information
between providers and the State with the following transactions:

(i) PAInitiationRequest and PAInitiationResponse.

(ii) PARequest and PAResponse.

(iii) PAAppealRequest and PAAppealResponse.

(iv) PACancelRequest and PACancelResponse.

(v) PA Notification.

(2) An unexpired version of the NCPDP Real-Time Prescription Benefit Standard adopted in 45 CFR 170.205(c).

(3) An unexpired version of the NCPDP Formulary and Benefit Standard adopted in 45 CFR 170.205(u).

(f) Extensions

(1) A State may submit a request for an extension to the compliance date for the requirements in paragraphs (b) and (e), of
this section for its Medicaid FFS program. The request(s) must be submitted as part of an APD described in part 433, subpart
C, of this chapter; and approved before the compliance date. It must include all the following:

(i) A narrative justification describing the specific reasons why the State cannot satisfy the requirement(s) by the compliance
date and why those reasons result from circumstances that are unique to the agency operating the Medicaid FFS program.

(ii) A report on completed and ongoing State activities that evidence a good faith effort towards compliance.

(iii) A comprehensive plan to meet the requirements.

(2) CMS would grant the State's request if it determines, based on the information provided, that—

(i) The request adequately establishes a need to delay implementation; and

(ii) The State has a comprehensive plan to meet the requirements.

---

PART 438—MANAGED CARE

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

Authority:

42 U.S.C. 1302.

1. Section 438.210 is amended by revising paragraphs (c), (f), and (g) to read as follows:

§ 438.210 Coverage and authorization of services. * * * * *

(c) Notice of adverse benefit determination. Each contract must require the MCO, PIHP, or PAHP to notify the requesting provider, and give the enrollee written notice
of any decision by the MCO, PIHP, or PAHP to deny a service authorization request, or to authorize a service in an amount,
duration, or scope that is less than requested.

(1) The enrollee's notice must meet the requirements of § 438.404.

(2) For rating periods beginning on or after January 1, 2026, the provider's notice for any items and services must include
a specific reason for the denial, regardless of the method used to communicate that information.

(3) Beginning October 1, 2027, the provider's notice for any drugs must include a specific reason for the denial, regardless
of the method used to communicate that information.

(4) For contracts with an applicable integrated plan, as defined in § 422.561 of this chapter, in lieu of the provisions in
this paragraph governing notices of adverse benefit determinations, the provisions set forth in §§ 422.629 through 422.634
of this chapter apply to determinations affecting dually eligible individuals who are also enrolled in a dual eligible special
needs plan with exclusively aligned enrollment, as defined in § 422.2 of this chapter.

---

(f) Publicly reporting prior authorization metrics. For rating periods beginning on or after January 1, 2026, each contract must require the MCO, PIHP, or PAHP to annually report
prior authorization metrics, excluding data on all drugs covered by the MCO, PIHP, or PAHP, at the plan and program level,
no later than 90 days after the end of each rating period. The MCO, PIHP, or PAHP must make all of the following metrics from
the previous rating period publicly accessible by posting them on its website:

(1) * * *

(2) For standard prior authorization requests for items and services, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage that were approved after appeal.

(iv) The total number and percentage that remain denied after appeal.

(v) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(vi) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(vii) The average and median time that elapsed between the submission of a request and a decision by the MCO, PIHP, or PAHP.

(3) For expedited prior authorization requests for items and services and services, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage that were approved after appeal.

(iv) The total number and percentage that remain denied after appeal.

(v) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(vi) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(vii) The average and median time that elapsed between the submission of a request and a decision by the MCO, PIHP, or PAHP.

(g) Publicly reporting prior authorization for drugs metrics. For rating periods beginning on or after January 1, 2028, each contract must require the MCO, PIHP, or PAHP to annually report
prior authorization metrics on all drugs at the plan and program level, no later than 90 days after the end of each rating
period. The MCO, PIHP, or PAHP must make the following metrics from the previous rating period publicly accessible by posting
them on its website:

(1) A list of all drugs that require prior authorization.

(2) The total number and percentage of prior authorization requests that were approved.

(3) The total number and percentage of prior authorization requests that were denied.

(4) The total number and percentage of prior authorization requests approved after appeal.

(5) The total number and percentage of prior authorization requests that remain denied after appeal.

(6) The average and median time that elapsed between the submission of requests and decisions for prior authorizations.

1. Section 438.242 is amended by revising paragraphs (b)(5) through (8) and removing paragraph (b)(9) to read as follows:

§ 438.242 Health information systems. * * * * *

(b) * * *

(5) Implement and maintain a Patient Access Application Programming Interface (API) described in § 431.60 of this chapter
as if such requirements applied directly to the MCO, PIHP, or PAHP and:

(i) Include all encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating
based on capitation payments and adjudicated claims and encounter data from any subcontractors.

(ii) Comply with the requirements of § 431.60 of this chapter by January 1, 2021, except as follows:

(A) Comply with the content requirements in § 431.60(b)(5) of this chapter for rating periods beginning on or after January
1, 2027.

(B) Comply with the content requirements in § 431.60(b)(6) and the API standards requirements in § 431.60(c)(2) of this chapter
beginning October 1, 2027.

(C) Comply with the API usage metrics reporting requirements in § 431.60(f) of this chapter for rating periods beginning January
1, 2026 by reporting data to the State, in the form of aggregated, de-identified metrics, from the previous rating period,
at the plan and program level, no later than 90 days after the end of each rating period.

(D) Comply with the API endpoint reporting requirements in § 431.60(h) of this chapter no later than [60 days after the effective
date of a final rule in the
Federal Register
].

(6) Implement and maintain a Provider Directory API described in § 431.70, except § 431.70(a)(2), as if such requirements
applied directly to the MCO, PIHP, or PAHP, by January 1, 2021, that includes all information specified in § 438.10(h)(1)
and (2) of this chapter. The MCO, PIHP, or PAHP must comply with the API standards requirements in § 431.70(a)(2) by October
1, 2027.

(7) Implement and maintain a Provider Access API as described in § 431.61(a) and Payer-to-Payer API as described in § 431.61(b)
of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP, and include all encounter data, including
encounter data from any network providers the MCO, PIHP, or PAHP is compensating based on capitation payments and adjudicated
claims and encounter data from any subcontractors by the following dates:

(i) For the requirements in § 431.61(a)(1) through (5) except § 431.61(a)(1)(iii); 431.61(b)(1) except § 431.61(b)(1)(iii);
§ 431.61(a)(2) and (b)(4) through (6) except § 431.61(b)(4)(ii); and (b)(7)(ii) and (iii), of this chapter, for rating periods
beginning on or after January 1, 2027. The MCO, PIHP, or PAHP must comply with the requirements in § 431.61(a)(1)(iii), § 431.61(b)(1)(iii),
and § 431.61(b)(4)(ii) of this chapter beginning October 1, 2027.

(ii) For the API usage metrics reporting requirements in § 431.61(a)(6) and (b)(8) of this chapter, for rating periods beginning
on or after January 1, 2027, by reporting data to the State, no later than 90 days after the end of each rating period, for
the previous rating period, in the form of aggregated, de-identified metrics, at the plan and program level.

(iii) For the API endpoint reporting requirements in §§ 431.61(a)(7) and (b)(9) of this chapter, no later than [60 days after
the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before the start of the next rating period.

(8) Prior Authorization Requirements. Comply with all of the following requirements, as if such requirements applied directly to the MCO, PIHP, or PAHP:

(i) For the Prior Authorization API items and services requirements in § 431.80(b)(1)(i) and (ii) and (b)(2)(i) of this chapter,
for rating periods beginning on or after January 1, 2027.

(ii) For the API standards requirement in § 431.80(b)(1)(iii) of this chapter, beginning October 1, 2027.

(iii) For the Prior Authorization API drug requirements in § 431.80(b)(2)(ii) of this chapter, beginning October 1, 2027.

(iv) For the API usage metrics reporting requirements in § 431.80(c) of this chapter, for rating periods beginning on or after
January 1, 2027, by reporting data to the State, no later 90 days after the end of each rating period, in the form of aggregated,
de-identified metrics, at the plan and program level.

(v) For the API endpoints reporting requirement in § 431.80(d) of this chapter, no later than [60 days after the effective
date of a final rule in the
Federal Register
].

(vi) For the electronic prior authorization for drugs requirements at § 431.80(e) of this chapter, beginning October 1, 2027.

---

PART 440—SERVICES: GENERAL PROVISIONS

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

Authority:

42 U.S.C. 1302.

1. Section 440.230 is amended by—

a. Revising paragraphs (e) introductory text, (e)(1)(i) and (ii), and (e)(3); and

b. Adding paragraph (f).

The revisions and addition read as follows:

§ 440.230 Sufficiency of amount, duration, and scope. * * * * *

(e) For prior authorization requests for items and services (excluding prescribed drugs described in section 1905(a)(12) of
the Act), the State Medicaid agency must—

(1) * * *

(i) For a standard determination, as expeditiously as a beneficiary's health

  condition requires, but no later than 7 calendar days after receiving the request, unless a shorter timeframe is established
  by the State. The timeframe for standard authorization decisions can be extended by up to 14 calendar days if the beneficiary
  or provider requests an extension, or if the State agency determines that additional information from the provider is needed
  to make a decision.

(ii) For an expedited determination, as expeditiously as a beneficiary's health condition requires, but no later than 72 hours
after receiving the request, unless a shorter timeframe is established by the State.

---

(3) Publicly reporting prior authorization metrics. Beginning in 2026, a State must annually report prior authorization metrics, excluding data on prescribed drugs described
in section 1905(a)(12) of the Act, at the State level no later than March 31. The State must make all of the following metrics
from the previous calendar year publicly accessible by posting them on its website:

(i) * * *

(ii) For standard prior authorization requests for items and services, all of the following:

(A) The total number and percentage that were approved.

(B) The total number and percentage that were denied.

(C) The total number and percentage that were approved after appeal.

(D) The total number and percentage that remain denied after appeal.

(E) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(F) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(G) The average and median time that elapsed between the submission of a request and a decision by the State.

(iii) For expedited prior authorization requests for items and services, all of the following:

(A) The total number and percentage that were approved.

(B) The total number and percentage that were denied.

(C) The total number and percentage that were approved after appeal.

(D) The total number and percentage that remain denied after appeal.

(E) The average and median time that elapsed between the submission of a request and a decision by the State.

(f) Publicly reporting prior authorization for drugs metrics. Beginning in 2028, annually report prior authorization metrics on all covered outpatient drugs defined in section 1927(k)(2)
of the Act, at the State level no later than March 31. The State must make all of the following metrics from the previous
calendar year publicly accessible by posting them on its website:

(i) A list of all drugs that require prior authorization.

(ii) The total number and percentage of prior authorization requests that were approved.

(iii) The total number and percentage of prior authorization requests that were denied.

(iv) The total number and percentage of prior authorization requests approved after appeal.

(v) The total number and percentage of prior authorization requests that remain denied after appeal.

(vi) The average and median time that elapsed between the submission of requests and decisions for prior authorizations.

PART 457—ALLOTMENTS AND GRANTS TO STATES

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

Authority:

42 U.S.C. 1302.

1. Section 457.495 is amended by revising paragraph (d)(2)(ii) and adding paragraph (f) to read as follows:

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

(d) * * *

(2) * * *

(ii) In accordance with a shorter prior authorization timeframe established by the State.

---

(f) Beginning October 1, 2027, compliance with the requirements as described in section 1927(d)(5)(A) of the Act, as if such
requirements applied to all prescription drugs described in section 2110(a)(6) of the Act.

1. Section 457.730 is amended by—

a. Revising paragraphs (a), (b) introductory text and (b)(5);

b. Removing paragraph (b)(5)(i)(D);

c. Redesignating paragraphs (b)(5)(i)(E) and (F) as paragraphs (b)(5)(i)(D) and (E);

d. Revising paragraphs (b)(6); and (c)(1);

e. Redesignating paragraphs (c)(2) through (4) as paragraphs (c)(3) through (5);

f. Adding new paragraph (c)(2); and

g. Revising newly redesignated paragraph (c)(5) and paragraph (h).

The revisions and addition read as follows:

§ 457.730 Beneficiary access to and exchange of data. (a) Application Programming Interface to support CHIP beneficiaries. Beginning January 1, 2021, a State must implement and maintain a standards-based Application Programming Interface (API) that
permits third-party applications to retrieve, with the approval and at the direction of the current individual beneficiary
or their personal representative, data specified in paragraph (b) of this section through the use of common technologies and
without special effort from the beneficiary.

(b) Accessible content. A State must make all of the following information maintained by the State with a date of service on or after January 1, 2016
accessible to its current beneficiaries or their personal representatives through the API described in paragraph (a) of this
section:

---

(5) Beginning January 1, 2027, information about prior authorizations for items and services (excluding prescription drugs
described in section 2110(a)(6) of the Act), including the items and services approved and the information in paragraph (b)(5)(i)
of this section, according to the timelines in paragraph (b)(5)(ii) of this section.

---

(6) Beginning October 1, 2027, information about prior authorizations for prescription drugs described in section 2110(a)(6)
of the Act, including the drugs and dosage approved and the information in paragraph (b)(5)(i) of this section, according
to the timelines in paragraph (b)(5)(ii) of this section.

(c) * * *

(1) Beginning January 1, 2021, must implement and maintain API technology conformant with the standards in 45 CFR 170.215(a),
(b)(1), (c), and (e);

(2) Beginning October 1, 2027, must implement and maintain API technology conformant with the standards in 45 CFR 170.215
(k)(1), (k)(2), and (m);

---

(5) A State may use an updated version of any standard or all standards required under paragraphs (c)(1), (c)(2), or (c)(4)
of this section, where:

---

(h) Reporting Patient Access API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
] a State must report to CMS the information specified in paragraphs (h)(1) and (2) of this section about its Patient Access
API to be published by CMS. Thereafter, this

  information must be verified at least once every 12 months and updated to CMS within 1 week of any changes:

(1) All API endpoints in the form of an Endpoint Resource, as defined by aversion of the FHIR standard adopted in 45 CFR 170.215(a),
including, if multiple, appropriate use cases for each.

(2) URLs with the documentation required in paragraph (d) of this section, including all of the following, if applicable:

(i) A direct URL to the API FHIR capability statement.

(ii) Authorization and authentication protocols and implementation details.

(iii) API registration information.

1. Section 457.731 is amended by—

a. Revising paragraphs (a) introductory text and (a)(1)(i) and (ii);

b. Adding paragraphs (a)(1)(iii);

c. Revising paragraph (a)(2) introductory text;

d. Adding paragraphs (a)(6) and (7);

e. Revising paragraphs (b) introductory text, and (b)(1)(i) and (ii); and

f. Adding paragraphs (b)(1)(iii), (b)(4)(ii)(A)(3), (b)(8), and (b)(9).

The revisions and additions read as follows:

§ 457.731 Access to and exchange of health data for providers and payers. (a) Application programming interface to support data exchange from payers to providers—Provider Access API. Beginning January 1, 2027, unless otherwise specified or granted an extension or exemption under paragraph (c) of this section,
a State must do the following:

(1) * * *

(i) The requirements in § 457.730(c)(3), (c)(4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), (c), and (d), or an updated version of any such standards in conformance
with § 457.730(c)(5);

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(k)(1), and (k)(2), or an updated version of any such standards
in conformance with § 457.730(c)(5).

(2) Provider access. Make the data specified in § 457.730(b)(1) through (3) and (b)(5) and (6) with a date of service on or after January 1, 2016,
excluding provider remittances and beneficiary cost-sharing information, that are maintained by the State, available to enrolled
CHIP providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request
from such a provider, if all the following conditions are met:

---

(6) Reporting on Provider Access API usage. Beginning in 2028, by March 31 of each year, a State must report to CMS the metrics specified in paragraphs (a)(6)(i) through
(iii) of this section in the form of aggregated, de-identified data, for the previous calendar year at the State level in
the form and manner specified by the Secretary:

(i) The total number of unique providers who requested patient data via the State's Provider Access API.

(ii) The total number of unique patients whose data were transferred via the State's Provider Access API to a provider's health
IT system.

(iii) The total number of patient data transfers via the State's Provider Access API.

(7) Reporting Provider Access API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information in § 457.730(h)(1) and (2) about its Provider Access API to be published by
CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any changes.

(b) Application programming interface to support data exchange between payers—Payer-to-Payer API. Beginning January 1, 2027 unless otherwise specified or granted an extension or exemption under paragraph (c) of this section,
a State must do the following:

(1) * * *

(i) The requirements in § 457.730(c)(3), (c)(4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), and (d), or an updated version of any such standards in conformance with
§ 457.730(c)(5);

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(k)(1), and (k)(2), or an updated version of any such standards
in conformance with § 457.730(c)(5).

---

(4) * * *

(ii) * * *

(A) * * *

(3) The information in § 457.730(b)(4).

---

(8) Reporting on Payer-to-Payer API usage. Beginning in 2028, by March 31 of each year, a State must report to CMS the metrics specified in paragraphs (b)(8)(i) through
(iii) of this section, in the form of aggregated, de-identified data, for the previous calendar year at the State level in
the form and manner specified by the Secretary:

(i) The percent of patients who have opted in to the payer to payer data exchange.

(ii) The total number of unique patients whose data have been sent to other payers via the State's Payer-to-Payer API.

(iii) The total number of unique patients whose data have been received from other payers via the State's Payer-to-Payer API.

(9) Reporting Payer-to-Payer API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information in § 457.730(h)(1) and (2) about its Payer-to-Payer API to be published by CMS.
Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any changes.

---

1. Section 457.732 is amended—

a. Revising paragraphs (a) and (b) introductory text;

b. Redesignating paragraphs (b)(1) through (4) as paragraphs (b)(2) through (5);

c. Adding a new paragraph (b)(1);

d. Revising newly redesignated paragraph (b)(2);

e. In newly redesignated paragraph (b)(3) by—

i. Removing the phrase “items or services” and adding in its place the phrase “items, services, or drugs”;

ii. Removing the “;” and adding in its place “.”;

f. In newly redesignated paragraph (b)(4), removing the “;” and adding a “.” in its place;

g. Redesignating paragraph (c)(1) as (f)(1);

h. Removing paragraph (c)(2);

i. Revising paragraphs (c), (d)(1)(i), and (d)(2)(i);

j. Redesignating paragraph (d) as (h);

k. Adding new paragraph (d);

l. Revising newly redesignated paragraph (h); and

m. By adding paragraphs (e) through (g).

The revisions and additions read as follows:

§ 457.732 Prior authorization requirements. (a) Communicating a reason for denial.

(1) Beginning January 1, 2026, if the State denies a prior authorization request (excluding a request for coverage of prescription
drugs described in section 2110(a)(6) of the Act), the response to the provider must be sent in accordance with the timeframes
established in § 457.495(d) of this chapter, and must include a specific reason for the denial, regardless of the method used
to communicate that information.

(2) Beginning October 1, 2027, if the State denies a prior authorization request for any prescription drugs described in section
2110(a)(6) of the Act, the response to the provider must

  be sent in accordance with the timeframes established in § 457.495(f) of this chapter, and must include a specific reason
  for the denial, regardless of the method used to communicate that information.

(b) Prior Authorization API. Beginning January 1, 2027, unless otherwise specified or granted an extension under paragraph (h) of this section, a State
must implement and maintain an API that meets all of the following:

(1) Is conformant with all the following:

(i) The requirements in § 457.730(c)(3) (4), (d), and (e).

(ii) The standards in 45 CFR 170.215(a), (b)(1), and (c), or an updated version of any such standards in conformance with
§ 457.730(c)(5).

(iii) Beginning October 1, 2027, the standards in 45 CFR 170.215(j)(1), (j)(2), and (j)(3). or an updated version of any such
standards in conformance with § 457.730(c)(5).

(2) Is populated with the following:

(i) Beginning January 1, 2027, the State's list of covered items and services (excluding prescription drugs described in section
2110(a)(6) of the Act) that require prior authorization.

(ii) Beginning October 1, 2027, the State's list of prescription drugs described in section 2110(a)(6) of the Act processed
in a claims adjudication system that is not at the point of sale that require prior authorization.

---

(c) Publicly reporting prior authorization metrics. Beginning in 2026, a State must annually report prior authorization metrics, excluding data on prescription drugs described
in section 2110(a)(6) of the Act, at the State level no later than March 31. The State must make all of the following metrics
from the previous calendar year publicly accessible by posting them on its website:

(1) * * *

(2) For standard prior authorization requests for items and services, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage that were approved after appeal.

(iv) The total number and percentage that remain denied after appeal.

(v) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(vi) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(vii) The average and median time that elapsed between the submission of a request and a decision by the State.

(3) For expedited prior authorization requests for items and services, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage that were approved after appeal.

(iv) The total number and percentage that remain denied after appeal.

(v) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(vi) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(vii) The average and median time that elapsed between the submission of a request and a decision by the State.

(d) Publicly reporting prior authorization for drugs metrics. Beginning in 2028, a State must annually report prior authorization metrics on all prescription drugs described in section
2110(a)(6) of the Act, at the State level no later than March 31. The State must make all of the following metrics from the
previous calendar year publicly accessible by posting them on its website:

(1) A list of all drugs that require prior authorization.

(2) The total number and percentage of prior authorization requests that were approved.

(3) The total number and percentage of prior authorization requests that were denied.

(4) The total number and percentage of prior authorization requests approved after appeal.

(5) The total number and percentage of prior authorization requests that remain denied after appeal.

(6) The average and median time that elapsed between the submission of requests and decisions for prior authorizations.

(e) Reporting on Prior Authorization API usage. Beginning in 2028, by March 31 of each year, a State must report to CMS the metrics specified in paragraphs (e)(1) through
(3) of this section, in the form of aggregated, de-identified data, for the previous calendar year at the State level in the
form and manner specified by the Secretary:

(1) The total number of unique providers who requested a prior authorization for items, services, or drugs through the State's
Prior Authorization API.

(2) The number of unique prior authorization requests for items, services, or drugs received through the State's Prior Authorization
API.

(3) The percentage of all prior authorization requests that were received through the State's Prior Authorization API.

(f) Reporting Prior Authorization API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information in § 457.730(h)(1) and (2) about its Prior Authorization API to be published
by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any
changes.

(g) Electronic prior authorization for prescription drugs. Beginning October 1, 2027, unless granted an extension under paragraph (h) of this section, a State must support an electronic
prior authorization process using all of the following standards for any prescription drugs described in section 2110(a)(6)
of the Act that are processed in a point of sale or real-time claims adjudication system that require prior authorization:

(1) An unexpired version of the NCPDP SCRIPT Standard adopted in 45 CFR 170.205(b) to communicate drug-related information
between providers and the State with the following transactions:

(i) PAInitiationRequest and PAInitiationResponse.

(ii) PARequest and PAResponse.

(iii) PAAppealRequest and PAAppealResponse.

(iv) PACancelRequest and PACancelResponse.

(v) PA Notification.

(2) An unexpired version of the NCPDP Real-Time Prescription Benefit Standard adopted in 45 CFR 170.205(c).

(3) An unexpired version of the NCPDP Formulary and Benefit Standard adopted in 45 CFR 170.205(u).

(h) Extensions.

(1) A State may submit a request for an extension to the compliance date for the requirements in paragraphs (b) and (g) of
this section for its CHIP fee-for-service program. The request(s) must be submitted and approved as part of the State's Advance
Planning Document (APD) described in part 433, subpart C, of this chapter, and approved before the applicable compliance date.
It must include all the following:

(i) A narrative justification describing the specific reasons why the State cannot satisfy the requirement(s) by the compliance
date and why those reasons result from circumstances that are unique to the agency operating the CHIP fee-for service program;

(ii) A report on completed and ongoing State activities that evidence a good faith effort toward compliance.

(iii) A comprehensive plan to meet the requirements.

(2) CMS would grant the State's request if it determines, based on the information provided, that—

(i) The request adequately establishes a need to delay implementation; and

(ii) The State has a comprehensive plan to meet the requirements.

---

1. Section 457.760 is amended by revising paragraphs (a) and (c) to read as follows:

§ 457.760 Access to published provider directory information. (a) Beginning January 1, 2021, unless otherwise specified, the State must implement and maintain a publicly accessible, standards-based
Application Programming Interface (API) that meets all the following:

(1) Is conformant with the standards in 45 CFR 170.215(a), (b)(1), and (n)(1) or an updated version of any such standards
in conformance with § 457.730(c)(5).

(2) Beginning October 1, 2027, is conformant with the standards in 45 CFR 170.215(n)(2), or an updated version of any such
standards in conformance with § 457.730(c)(5).

(3) Does not restrict the availability of this information to particular persons or organizations.

(4) Is conformant with the documentation requirements in § 457.730(d).

(5) Is conformant with the denial and discontinuation policies in § 457.730(e).

(6) Is accessible via a public-facing digital endpoint.

---

(d) Reporting Provider Directory API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], a State must report to CMS the information in § 457.730(h)(1) and (2) about its Provider Directory API to be published
by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any
changes.

Title 45—Public Welfare

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

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

Authority:

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

1. Section 156.221 is amended by—

a. Revising paragraphs (a), (b)(1) introductory text, and (b)(1)(iv) introductory text;

b. Removing paragraph (b)(1)(iv)(A) (4);

c. Redesignating paragraphs (b)(1)(iv)(A) (5) and (6) as paragraphs (b)(1)(iv)(A) (4) and (5);

d. Revising paragraphs (b)(1)(v) and (c)(1);

f. Redesignating paragraphs (c)(2) through (4) as paragraphs (c)(3) through (5);

e. Adding new paragraph (c)(2);

g. Revising newly redesignated paragraph (c)(5) and paragraph (f);

h. Removing paragraph (i)

i. Redesignating paragraph (h) as (i);

j. Adding new paragraph (h);

k. Revising newly redesignated paragraphs (i)(1) and (i)(2)

The revisions and additions read as follows:

§ 156.221 Access to and exchange of health data and plan information. (a) Application Programming Interface to support enrollees. For plan years beginning on or after January 1, 2021, unless otherwise specified or granted an exception under paragraph (i)
of this section, a QHP issuer on a Federally-facilitated Exchange, not including on a Federally-facilitated SHOP, must implement
and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve,
with the approval and at the direction of a current enrollee or their personal representative, data specified in paragraph
(b) of this section through the use of common technologies and without special effort from the enrollee. For plan years beginning
on or after January 1, 2028, unless otherwise specified or granted an exception under paragraph (i) of this section, a QHP
issuer on a Federally-facilitated SHOP must implement and maintain such an API.

(b) * * *

(1) A QHP issuer on a Federally-facilitated Exchange must make all of the following information maintained by the QHP issuer
with a date of service during a plan year beginning on or after January 1, 2016 accessible to its current enrollees or their
personal representatives through the API described in paragraph (a) of this section:

---

(iv) For plan years beginning on or after January 1, 2027, information about prior authorizations for items and services (excluding
drugs), including the items and services approved and the information in paragraph (b)(1)(iv)(A) of this section, according
to the timelines in paragraph (b)(1)(iv)(B) of this section.

---

(v) Beginning October 1, 2027, information about prior authorizations for drugs, including the drugs and dosage approved and
the information in paragraph (b)(1)(iv)(A) of this section, according to the timelines in paragraph (b)(1)(iv)(B) of this
section.

---

(c) * * *

(1) Must implement and maintain API technology conformant with the standards in § 170.215(a), (b)(1), (c), and (e);

(2) Beginning October 1, 2027, must implement and maintain API technology conformant with the standards at § 170.215(k)(1),
(k)(2), and (m);

---

(5) A QHP issuer on a Federally-facilitated Exchange may use an updated version of any standard or all standards required
under paragraphs (c)(1), (c)(2), or (c)(4) of this section, where:

---

(f) Reporting on Patient Access API usage. Following each year it offers a QHP on Federally-facilitated Exchange, a QHP issuer on a Federally-facilitated Exchange must
report to CMS the metrics specified in paragraph (f)(2) of this section as aggregated, de-identified data at the issuer level
in the form and manner and within the timeframes specified by the Secretary.

(1) QHP issuers on a Federally-facilitated Exchange, not including QHPs on a Federally-facilitated SHOP, must report data
from plan years beginning on or after January 1, 2025. QHP issuers on a Federally-facilitated SHOP must report data from plan
years beginning on or after January 1, 2028.

(2) The metrics that must be reported are the following:

(i) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated
by the enrollee.

(ii) The total number of unique enrollees whose data are transferred more than once via the Patient Access API to a health
app designated by the enrollee.

---

(h) Reporting Patient Access API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before the first day of any plan year for which it expects to offer a QHP,
a QHP issuer on the FFE must report to CMS the information specified in paragraphs

  (h)(1) and (2) about its Patient Access API to be published by CMS. Thereafter, this information must be verified at least
  once every 12 months and updated to CMS within 1 week of any changes.

(1) All API endpoints in the form of an Endpoint Resource, as defined by aversion of the FHIR standard adopted in § 170.215(a),
including, if multiple, appropriate use cases for each.

(2) URLs with the documentation required in paragraph (d) of this section, including all of the following, if applicable:

(i) A direct URL to the API FHIR capability statement.

(ii) Authorization and authentication protocols and implementation details.

(iii) API registration information.

---

(i) Exception.

(1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy
the requirements in paragraphs (a) through (h) of this section, the issuer must include as part of its QHP certification application
a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable
plan year, the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees,
and solutions and a timeline to achieve compliance with the requirements of this section.

(2) The Federally-facilitated Exchange may grant an exception to the requirements in this section if the Exchange determines
that making such health plan available through such Exchange is in the interests of qualified individuals and qualified employers
in the State or States in which such Exchange operates.

1. Section 156.222 is amended by—

a. Revising paragraphs (a) introductory text, and (a)(1)(i), and (ii);

b. Adding paragraphs (a)(1)(iii) and (iv);

c. Revising paragraph (a)(2) introductory text;

d. Adding paragraphs (a)(6) and (7);

e. Revising paragraphs (b) introductory text, and (b)(1)(i) and (ii);

f. Adding paragraphs (b)(1)(iii), (b)(8), and (b)(9); and

g. Revising paragraphs (c)(1)(ii) and (iii) and (c)(2).

The revisions and additions read as follows:

§ 156.222 Access to and exchange of health data for providers and payers. (a) Application programming interface to support data exchange from payers to providers—Provider Access API. For plan years beginning on or after January 1, 2027, unless otherwise specified or granted an exception under paragraph (c)
of this section, QHP issuers on a Federally-facilitated Exchange, not including on a Federally-facilitated SHOP, must meet
the requirements in paragraphs (a)(1) though (5). For plan years beginning on or after January 1, 2028, QHP issuers on a Federally-facilitated
SHOP must also meet these requirements.

(1) * * *

(i) The requirements in § 156.221(c)(3), (c)(4), (d), and (e).

(ii) The standards in § 170.215(a), (b)(1), (c), and (d), or an updated version of any such standards in conformance with
§ 156.221(c)(5).

(iii) Beginning October 1, 2027, the standards in § 170.215(k)(1) and (k)(2), or an updated version of any such standards
in conformance with § 156.221(c)(5).

---

(6) Reporting on Provider Access API usage. Unless granted an exception under paragraph (c) of this section, for plan years beginning on or after January 1, 2028, following
each year it offers a QHP on a Federally-facilitated Exchange, a QHP issuer on a Federally-facilitated Exchange must report
to CMS the metrics specified in paragraphs (a)(6)(i) through (iii), in the form of aggregated, de-identified data, for the
previous calendar year at the issuer level in the form and manner and within the timeframes specified by the Secretary.

(i) The total number of unique providers who requested patient data via the QHP issuer's Provider Access API.

(ii) The total number of unique patients whose data were transferred via the QHP issuer's Provider Access API to a provider's
health IT system.

(iii) The total number of patient data transfers via the QHP issuer's Provider Access API.

(7) Reporting Provider Access API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before the first day of any plan year for which it expects to offer a QHP,
a QHP issuer on the FFE must report to CMS the information in § 156.221(h)(1) and (2) about its Provider Access API to be
published by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1
week of any changes.

---

(b) Application programming interface to support data exchange between payers—Payer-to-Payer API. For plan years beginning on or after January 1, 2027, unless otherwise specified or granted an exception under paragraph (c)
of this section, QHP issuers on a Federally-facilitated Exchange, not including on a Federally-facilitated SHOP, must meet
the requirements of paragraphs (b)(1) through (9). For plan years beginning on or after January 1, 2028, QHP issuers on a
Federally-facilitated SHOP must also meet these requirements.

(1) * * *

(i) The requirements in § 156.221(c)(3), (c)(4), (d), and (e).

(ii) The standards in § 170.215(a), (b)(1), and (d), or an updated version of any such standards in conformance with § 156.221(c)(5).

(iii) Beginning October 1, 2027, the standards in § 170.215(k)(1), and (k)(2), or an updated version of any such standards
in conformance with § 156.221(c)(5).

---

(8) Reporting on Payer-to-Payer API usage. Unless granted an exception under paragraph (c) of this section, for plan years beginning on or after January 1, 2028, following
each year it offers a QHP on a Federally-facilitated Exchange, a QHP issuer on a Federally-facilitated Exchange must report
to CMS the metrics specified in paragraphs (b)(8)(i) through (iii), in the form of aggregated, de-identified data, for the
previous calendar year at the issuer level in the form and manner and within the timeframes specified by the Secretary:

(i) The percent of patients who have opted in to the payer to payer data exchange.

(ii) The total number of unique patients whose data have been sent to other payers via the QHP issuer's Payer-to-Payer API.

(iii) The total number of unique patients whose data have been received from other payers via the QHP issuer's Payer-to-Payer
API.

(9) Reporting Payer-to-Payer API endpoints. No later than [60 days after the effective date of a final rule in the
Federal Register
], and in subsequent years no later than 60 days before the first day of any plan year for which it expects to offer a QHP,
a QHP issuer on the FFE must report to CMS the information in § 156.221(h)(1) and (2) about its Payer-to-Payer API to be published
by CMS. Thereafter, this information must be verified at least once every 12 months and updated to CMS within 1 week of any
changes.

(c) * * *

(1) * * *

(ii) The impact of non-compliance upon enrollees and providers if the

  exception request pertains to the requirements in paragraph (a) of this section, or upon enrollees and payers if the exception
  request pertains to the requirements in paragraph (b) of this section.

(iii) The current or proposed means of providing health information to providers if the exception pertains to the requirements
in paragraph (a) of this section or to payers if the exception pertains to the requirements in paragraph (b) of this section.

---

(2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraph (a) or (b) (or paragraphs (a)
and (b)) of this section if the Exchange determines that making QHPs of such issuer available through such Exchange is in
the interests of qualified individuals and qualified employers in the State or States in which such Exchange operates and
an exception is warranted to permit the issuer to offer QHPs through the FFE.

---

1. Section 156.223 is amended by—

a. Revising paragraphs (a) and (b) introductory text;

b. Redesignating paragraphs (b)(1) through (4) as paragraphs (b)(2) through (5);

c. Adding a new paragraph (b)(1);

d. Revising newly redesignated paragraph (b)(2);

e. In newly redesignated paragraph (b)(3) by—

i. Removing the phrase “items or services” and adding in its place the phrase “items, services, or drugs”;

ii. Removing the “;” and adding in its place “.”;

f. In newly redesignated paragraph (b)(4), removing the “;” and adding a “.” in its place;

g. Revising paragraph (c);

j. Redesignating paragraph (d) as (h); and

k. Adding a new paragraph (d) and paragraphs (e) through (g) and (i).

The revisions and additions read as follows:

§ 156.223 Prior authorization requirements. (a) Communicating a reason for denial.

(1) For plan years beginning on or after January 1, 2026, if a QHP issuer on a Federally-facilitated Exchange, not including
a Federally-facilitated SHOP, denies a prior authorization request (excluding a request for coverage of drugs), the response
to the provider must include a specific reason for the denial, regardless of the method used to communicate that information.

(2) Beginning on October 1, 2027, if a QHP issuer on a Federally-facilitated Exchange, not including a Federally-facilitated
SHOP, denies a prior authorization, including a request for coverage of drugs, the response to the provider must include a
specific reason for the denial, regardless of the method used to communicate that information.

(3) For plan years beginning on or after January 1, 2028, QHP issuers on a Federally-facilitated SHOP must meet the requirements
in paragraphs (a)(1) and (2) of this section.

(b) Prior Authorization API. For plan years beginning on or after January 1, 2027, unless otherwise specified or granted an exception under paragraph (h)
of this section, a QHP issuer on a Federally-facilitated Exchange, not including on a Federally-facilitated SHOP, must implement
and maintain an API that meets all of the requirements of paragraphs (b)(1) through (4). Beginning on October 1, 2027, QHP
issuers on a Federally-facilitated SHOP must also implement and maintain an API that meets all such requirements.

(1) The API must be conformant with all the following:

(i) The requirements in § 156.221(c)(3), (4), (d), and (e).

(ii) The standards in § 170.215(a), (b)(1), and (c), or an updated version of any such standard in conformance with § 156.221(c)(5).

(iii) Beginning October 1, 2027, the standards in § 170.215(j)(1), (j)(2), and (j)(3), or an updated version of any such standard
in conformance with § 156.221(c)(5).

(2) The API must be populated with all of the following:

(i) For plan years beginning on or after January 1, 2027, the issuer's list of covered items and services (excluding drugs)
that require prior authorization.

(ii) Beginning October 1, 2027, the issuer's list of drugs covered under a medical benefit, as described by the applicable
standards, that require prior authorization.

---

(c) Publicly reporting prior authorization metrics. Beginning in 2026, following each calendar year it offers a QHP on a Federally-facilitated Exchange, not including a Federally-facilitated
SHOP, a QHP issuer must annually report prior authorization metrics, excluding data on all drugs covered by the issuer, at
the issuer level no later than March 31. Beginning in 2028, following each year it offers a QHP on a Federally-facilitated
SHOP, a QHP issuer must annually report these metrics in the same manner no later than March 31. To make such a report, the
QHP issuer must make all of the following metrics from the previous calendar year publicly accessible by posting them on its
website:

(1) * * *

(2) For standard prior authorization requests for items and services, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage that were approved after appeal.

(iv) The total number and percentage that remain denied after appeal.

(v) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(vi) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(vii) The average and median time that elapsed between the submission of a request and a decision by the QHP issuer.

(3) For expedited prior authorization requests for items and services, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage that were approved after appeal.

(iv) The total number and percentage that remain denied after appeal.

(v) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(vi) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(vii) The average and median time that elapsed between the submission of a request and a decision by the QHP issuer.

(d) Publicly reporting prior authorization for drugs metrics. Beginning in 2028, following each year it offers a QHP on a Federally-facilitated Exchange, a QHP issuer must annually report
prior authorization metrics on all drugs covered by the issuer, at the issuer level no later than March 31. To make such a
report, the QHP issuer must make all of the following metrics from the previous calendar year publicly accessible by posting
them on its website:

(1) A list of all drugs that require prior authorization.

(2) For standard prior authorization requests for all drugs, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(iv) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(v) The total number and percentage approved after appeal.

(vi) The total number and percentage that remain denied after appeal.

(vii) The average and median time that elapsed between the submission of requests and decisions.

(2) For expedited prior authorization requests for all drugs, all of the following:

(i) The total number and percentage that were approved.

(ii) The total number and percentage that were denied.

(iii) The total number and percentage for which the timeframe for review was extended, and the request was approved.

(iv) The total number and percentage for which the timeframe for review was extended, and the request was denied.

(v) The total number and percentage approved after appeal.

(vi) The total number and percentage that remain denied after appeal.

(vii) The average and median time that elapsed between the submission of requests and decisions.

(e) Reporting on Prior Authorization API usage. Unless granted an exception under paragraph (h) of this section, for plan years beginning on or after January 1, 2028, following
each year it offers a QHP on a Federally-facilitated Exchange, a QHP issuer on a Federally-facilitated Exchange must report
to CMS the metrics specified in paragraphs (e)(1) through (3) of this section, in the form of aggregated, de-identified data,
for the previous calendar year at the issuer level in the form and manner and within the timeframes specified by the Secretary:

(1) The total number of unique providers who requested a prior authorization for items, services, or drugs through the QHP
issuer's Prior Authorization API.

(2) The number of unique prior authorization requests for items, services, or drugs received through the QHP issuer's Prior
Authorization API.

(3) The percentage of all prior authorization requests that were received through the QHP issuer's Prior Authorization API.

(f) Reporting Prior Authorization API endpoints. Unless granted an exception under paragraph (h) of this section, no later than [60 days after the effective date of a final
rule in the
Federal Register
], and in subsequent years no later than 60 days before the first day of any plan year for which it expects to offer a QHP,
a QHP issuer on the Federally-facilitated Exchange must report to CMS the information in § 156.221(h)(1) and (2) about its
Prior Authorization API to be published by CMS. Thereafter, this information must be verified at least once every 12 months
and updated to CMS within 1 week of any changes.

(g) Electronic prior authorization for drugs covered under a pharmacy benefit. Beginning October 1, 2027, unless granted an exception under paragraph (h) of this section, a QHP issuer on a Federally-facilitated
Exchange must support an electronic prior authorization process using all of the following standards for any drugs that require
prior authorization and are covered under a pharmacy benefit, as described by the applicable standards:

(1) An unexpired version of the NCPDP SCRIPT Standard adopted in § 170.205(b) to communicate drug-related information between
providers and the QHP issuer with the following transactions:

(i) PAInitiationRequest and PAInitiationResponse.

(ii) PARequest and PAResponse.

(iii) PAAppealRequest and PAAppealResponse.

(iv) PACancelRequest and PACancelResponse.

(v) PA Notification.

(2) An unexpired version of the NCPDP Real-Time Prescription Benefit Standard adopted in § 170.205(c).

(3) An unexpired version of the NCPDP Formulary and Benefit Standard adopted in § 170.205(u).

(h) Exception

(1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy
the requirements in paragraph (b), (e), (f), and/or (g) of this section, the issuer must include a narrative justification
in its QHP application that describes all of the following:

(i) The reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year.

(ii) The impact of non-compliance upon providers and enrollees.

(iii) Their current or proposed means of providing prior authorization coverage and documentation requirements and facilitating
prior authorization requests and decisions.

(iv) Solutions and a timeline to achieve compliance with the requirements in paragraphs (b), (e), and (f), or (g) of this
section.

(2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraphs (b), (e), and (f), or (g)
of this section if the Exchange determines that making QHPs of such issuer available through such Exchange is in the interests
of qualified individuals and qualified employers in the State or States in which such Exchange operates and an exception is
warranted to permit the issuer to offer QHPs through the FFE.

(i) Timeframes. Beginning October 1, 2027—

(1) In response to a request for prior authorization, a QHP issuer must notify the requesting provider of its determination
as expeditiously as the enrollee's health condition requires but no later than the following:

(i) For all items and services, other than drugs—

(A) No later than 7 calendar days after receiving a standard prior authorization request; or

(B) No later than 72 hours after receiving an expedited prior authorization request.

(ii) For all drugs—

(A) No later than 72 hours after receiving a standard prior authorization request; or

(B) No later than 24 hours after receiving an expedited prior authorization request.

(2) For purposes of this paragraph (i)(1)—

(i) A standard prior authorization request has the meaning given to a “pre-service claim” in 29 CFR 2560.503-1(m)(2); and

(ii) An expedited prior authorization request has the meaning given to a “claim involving urgent care” in 29 CFR 2560.503-1(m)(1).

(3) Extensions on requests for items or services—

(i) The issuer may extend the timeframes in paragraphs (i)(1) by up to 14 calendar days under any of the following circumstances:

(A) The provider requests the extension.

(B) The extension is justified and in the provider's or enrollee's interest because the QHP issuer needs additional medical
evidence from another provider or from the enrollee in order to issue a decision.

(C) The extension is justified due to extraordinary, exigent, or other non-routine circumstances and is in the provider's
or enrollee's interest.

(ii) Notice of extension.

(A) When the QHP issuer extends a timeframe as described in paragraph (i)(3)(i), it must—

(1) Notify the requesting provider in writing of the reasons for the extension; and

(2) Inform the provider of the right to file an expedited grievance if they

  disagree with the QHP issuer's decision to grant an extension.

(B) The issuer must notify the provider of its determination as expeditiously as the enrollee's health condition requires,
but no later than upon expiration of the extension.

PART 162—ADMINISTRATIVE REQUIREMENTS

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

Authority:

42 U.S.C. 1320d-1320d-9 and secs. 1104 and 10109 of Pub. L. 111-148, 124 Stat. 146-154 and 915-917.

1. Section 162.103 is amended by adding a definition of “prior authorization” as follows:

§ 162.103 Definitions. * * * * *

Prior authorization means transmissions described in § 162.1301(a) used by health care providers to obtain authorization for health care, and
transmissions described in § 162.1301(c) used by health plans to respond to such requests.

1. Section 162.1202 is amended by—

a. Revising paragraphs (b)(2) and (e); and

b. Adding paragraph (f).

The revisions and addition read as follows:

§ 162.1202 Standards for eligibility for a health plan transaction. * * * * *

(b) * * *

(2) The following standards:

---

(e) For the period from April 14, 2028 through [24 months after the effective date of the final rule in the
Federal Register
], except for small health plans from February 11, 2028 through [36 months after the effective date of the final rule in the

  Federal Register
  ], the standards identified in paragraph (d)(2) of this section or the standards identified in paragraph (f) of this section.

(f) Beginning [24 months after the effective date of the final rule in the
Federal Register
], except for small health plans beginning [36 months after the effective date of the final rule in the
Federal Register
]:

(1) Retail pharmacy drugs. The NCPDP Telecommunication Standard Implementation Guide Version F6, January 2020 and equivalent
NCPDP Batch Standard Implementation Guide, Version 15, October 2017 (both incorporated by reference in § 162.920).

(2) Dental, professional, and institutional health care eligibility benefit inquiry and response.

(i) For transactions used to determine whether prior authorization, as defined in § 162.103, is required, all of the following:

(A) HL7® Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 (incorporated by reference, see § 170.299).

(B) The HL7® FHIR® US Core Implementation Guide STU 6.1.0 (incorporated by reference, see § 170.299).

(C) The HL7® SMART App Launch Implementation Guide Release 2.0.0 (incorporated by reference, see § 170.299).

(D) HL7® FHIR® Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.2.1—STU 2.2 (incorporated by
reference in § 170.299).

(ii) For all other transactions, the ASC X12 Standards for Electronic Data Interchange Technical Report Type 3—Health Care
Eligibility Benefit Inquiry and Response (270/271), April 2008, ASC X12N/005010X279 (incorporated by reference in § 162.920).

1. Section 162.1203 is amended by—

a. Revising paragraph (a) and

b. Adding paragraph (c).

The revision and addition read as follows:

§ 162.1203 Operating rules for eligibility for a health plan transaction. (a) Except as specified in paragraphs (b) and (c) of this section, the following CAQH CORE Phase I and Phase II operating
rules (updated for Version 5010) for the eligibility for a health plan transaction:

---

(c) Excluding transactions where an adopted Fast Healthcare Interoperability Resources (FHIR®)-based standard transaction
is used to determine whether prior authorization, as defined in § 162.103, is required.

1. Section 162.1302 is amended by—

a. Revising paragraphs (b)(2) and (f); and

b. Adding paragraph (g).

The revisions and additions read as follows:

§ 162.1302 Standards for referral certification and authorization transaction. * * * * *

(b) * * *

(2) The following standards:

---

(f) For the period from April 14, 2028 through [24 months after the effective date of the final rule in the
Federal Register
], except for small health plans from February 11, 2028 through [36 months after the effective date of the final rule in the

  Federal Register
  ], the standards identified in paragraph (e)(2) of this section or the standards identified in paragraph (g).

(g) Beginning [24 months after the effective date of the final rule in the
Federal Register
], except for small health plans beginning [36 months after the effective date of the final rule in the
Federal Register
]:

(1) Retail pharmacy drugs. The NCPDP Telecommunication Standard Implementation Guide Version F6, January 2020 and equivalent
NCPDP Batch Standard Implementation Guide, Version 15, October 2017 (both incorporated by reference in § 162.920).

(2) Dental, professional, and institutional request for review and response. For prior authorization transactions, as defined
at 162.103, all of the following:

(i) HL7® Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 (incorporated by reference, see § 170.299).

(ii) HL7® FHIR® US Core Implementation Guide STU 6.1.0 (incorporated by reference, see § 170.299).

(iii) HL7® SMART App Launch Implementation Guide Release 2.0.0 (incorporated by reference, see § 170.299).

(iv) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.2.1—STU 2.2 (incorporated by
reference in § 170.299).

(v) HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide, Version 2.2.0—STU 2.2 (incorporated by
reference in § 170.299).

(vi) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) Implementation Guide, Version 2.2.1—STU 2.2 (incorporated by reference
in § 170.299).

(vii) HL7 FHIR® Da Vinci—Clinical Data Exchange (CDex) Implementation Guide, Version 2.1.0—STU 2.1 (incorporated by reference
in § 170.299).

PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION

PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

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

Authority:

42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C. 552.

1. Section 170.215 is amended by revising paragraphs (j) through (n) to read as follows:

§  170.215 Application Programming Interface Standards. * * * * *

(j) * * *

(1) * * *

(i) Implementation specification. HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1—STU 2 (incorporated by reference
in § 170.299). The adoption of this standard expires on January 1, 2028.

(ii) Implementation specification. HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.2.1—STU 2.2 (incorporated by reference
in § 170.299).

(iii) [Reserved]

(2) * * *

(i) Implementation specification. HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide, Version 2.0.1—STU 2 (incorporated by reference
in § 170.299). The adoption of this standard expires on January 1, 2028.

(ii) Implementation specification. HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide, Version 2.2.0—STU 2.2 (incorporated by reference
in § 170.299).

(iii) [Reserved]

(3) * * *

(i) Implementation specification. HL7 FHIR Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.0.1—STU 2 (incorporated by reference
in § 170.299). The adoption of this standard expires on January 1, 2028.

(ii) Implementation specification. HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.2.1—STU 2.2 (incorporated by reference
in § 170.299).

(iii) [Reserved]

(k) * * *

(1) * * *

(i) Implementation specification. HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.0.0—STU
2 US (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2028.

(ii) Implementation specification. HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.1.2—STU
2.2 (incorporated by reference in § 170.299).

(iii) [Reserved]

---

(3) Clinical data exchange

(i) Implementation specification. HL7 FHIR® Da Vinci—Clinical Data Exchange (CDex) Implementation Guide, Version 2.1.0—STU 2.1 (incorporated by reference in
§ 170.299).

---

(m) * * *

(1) Implementation specification. HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1—STU 2 (incorporated by
reference in § 170.299). The adoption of this standard expires on January 1, 2028.

(2) Implementation specification. HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.1.0—STU 2.1 (incorporated
by reference in § 170.299).

(3) [Reserved]

(n) * * *

(1) Implementation specification. HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0—STU 1.1 US (incorporated by reference
in §  170.299). The adoption of this standard expires on January 1, 2028.

(2) Implementation specification. HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.2.0—STU 1.2 (incorporated by reference
in §  170.299).

(3) [Reserved]

1. Section 170.299 is amended by revising paragraphs (g)(50) through (56) to read as follows:

§  170.299 Incorporation by reference. * * * * *

(g) * * *

(50) HL7 FHIR® Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.2.1—STU 2.2, March 27, 2026,
IBR approved for § 170.215(j).

(51) HL7 FHIR® Da Vinci Documentation Templates and Rules (DTR) Implementation Guide, Version 2.2.0—STU 2.2, March 27 2026,
IBR approved for § 170.215(j).

(52) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.2.1—STU 2.2, March 27, 2026,
IBR approved for § 170.215(j).

(53) HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.2.0—STU
2.2, March 27, 2026, IBR approved for § 170.215(k).

(54) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.1.0—STU 2.1, February
26, 2025, IBR approved for § 170.215(m).

(55) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.2.0—STU 1.2, February 5, 2025,
IBR approved for § 170.215(n).

(56) HL7 FHIR® Da Vinci Clinical Data Exchange (CDex) Implementation Guide, Version 2.1.0—STU 2.1, February 11, 2025, IBR
approved for § 170.215(k).

---

Robert F. Kennedy, Jr., Secretary, Department of Health and Human Services. [FR Doc. 2026-07205 Filed 4-10-26; 4:15 pm] BILLING CODE 4150-28-P

Footnotes

(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.

(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.

(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.

(4) NOTE: This document contains links to non-United States Government websites. We are providing these links because they contain
additional information relevant to the topic(s) discussed in this document or that otherwise may be useful to the reader.
We cannot attest to the accuracy of information provided on the cited third-party websites or any other linked third-party
site. We are providing these links for reference only; linking to a non-United States Government website does not constitute
an endorsement by CMS, HHS, or any of their employees of the sponsors or the information and any products presented on the
website. Also, please be aware that the privacy protections generally provided by United States Government websites do not
apply to third-party sites.

Health Level Seven International. (2026, March 27). Da Vinci Prior Authorization Support (PAS) FHIR: Use Cases and Overview.
Retrieved from https://hl7.org/fhir/us/davinci-pas/2.2.1/en/usecases.html.

(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.

(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.

(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.

(9) Information about QHP certification, including deadlines can be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline.

(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.

(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.

(12) For more information on interoperability and QHP certification, including further detail on the exceptions process, see https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability. Discussion of this topic is also available in the 2024 CMS Interoperability and Prior Authorization final rule preamble: 89
FR 8906.

(13) Centers for Medicare & Medicaid Services. (2026, April 7). Exceptions Process. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process.

(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.

(15) See 45 CFR parts 160 and 164, subparts A and E.

(16) United States Department of Health and Human Services. (2020, January 31). Health Information and Privacy. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html and https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html.

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

(18) The Office of the National Coordinator for Health Information Technology. (n.d.). What Is HL7® FHIR®? Retrieved from https://www.healthit.gov/sites/default/files/page/2021-04/What%20Is%20FHIR%20Fact%20Sheet.pdf.

(19) See 89 FR 51262.

(20) As announced in the
Federal Register
in 65 FR 50373.

(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.

(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.

(23) NCPDP SCRIPT Standard IG, Versions 2017071 and 2023011. NCPDP SCRIPT IGs are available to NCPDP members for free and to non-members
for a fee at https://standards.ncpdp.org/Access-to-Standards.aspx.

(24) NCPDP (2015, August). NCPDP SCRIPT Standard Supports Electronic Prior Authorization (ePA) Fact Sheet. Retrieved from https://ncpdp.org/NCPDP/media/pdf/NCPDP_ePA_Fact_Sheet.doc.

(25) See 45 CFR 170.215(a)(1).

(26) See section II.A.4.a.6. of this proposed rule for a description of the CRD, DTR, and PAS IGs and section II.A.4.b.4. of this proposed
rule regarding CMS's proposal to require use of these IGs for the Prior Authorization API.

(27) Health Level Seven International (2024, December 20). Da Vinci Prior Authorization Support (PAS) FHIR: Use Cases and Overview.
Retrieved from https://hl7.org/fhir/us/davinci-pas/usecases.html.

(28) NCPDP. (2022, January 14). Re: Next version of SCRIPT Standard Recommendations. Retrieved from https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2022/202201NCPDP-SCRIPTNextVersionLetter.pdf.

(29) NCPDP. (2023, February 13). Re: Proposed Rule CMS-4201-P. Retrieved from https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2023/20230213_To_CMS_CMS_4201_P_NPRM.pdf.

(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).

(32) National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit Standard IG, Version 13. NCPDP RTPB
IGs are available to NCPDP members for free and to non-members for a fee at https://standards.ncpdp.org/Access-to-Standards.aspx.

(33) Journal of American Pharmacists Association. (2023, February 2). Formulary & Benefit and Real-time Pharmacy Benefit: Electronic
Standards Delivering Value to Prescribers and Pharmacists.

  Retrieved from *https://www.japha.org/article/S1544-3191(23)00016-X/abstractqq.*

(34) See 45 CFR 170.215(d)(1).

(35) Health Level Seven International. (n.d.). CARIN IG for Blue Button. Retrieved from http://hl7.org/fhir/us/carin-bb/ImplementationGuide/hl7.fhir.us.carin-bb.

(36) Health Level Seven International. (n.d.). Da Vinci PDex IG. Retrieved from http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex.

(37) Health Level Seven International. (n.d.). Da Vinci PDex US Drug Formulary IG. Retrieved from http://hl7.org/fhir/us/davinci-drug-formulary/ImplementationGuide/hl7.fhir.us.davinci-drug-formulary.

(38) Health Level Seven International. (n.d.). Da Vinci PDex Plan Net IG. Retrieved from http://hl7.org/fhir/us/davinci-pdex-plan-net/ImplementationGuide/hl7.fhir.us.davinci-pdex-plan-net.

(39) Health Level Seven International. (n.d.). FHIR Bulk Data Access IG. Retrieved from http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/hl7.fhir.uv.bulkdata.

(40) Health Level Seven International. (n.d.). Da Vinci CRD IG. Retrieved from http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd.

(41) Health Level Seven International. (2026, March 27). Da Vinci CRD IG, Version 2.2.1—STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-crd/2.2.1/en/.

(42) Health Level Seven International. (n.d.). Da Vinci DTR IG. Retrieved from http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr.

(43) Health Level Seven International. (2026, March 27). Da Vinci DTR IG, Version 2.2.0—STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/.

(44) Health Level Seven International. (n.d.). Da Vinci PAS IG. Retrieved from http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas.

(45) Health Level Seven International. (2026, March 27). Da Vinci PAS IG, Version 2.2.1—STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-pas/2.2.1/en/.

(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.

(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.

(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.

(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.

(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.

(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).

(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.

(57) Health Level Seven International. (n.d.). Da Vinci CRD IG. Retrieved from http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd.

(58) Health Level Seven International. (n.d.). Da Vinci DTR IG. Retrieved from http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr.

(59) Health Level Seven International. (n.d.). Da Vinci PAS IG. Retrieved from http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas.

(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.

(61) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov.
Retrieved from https://inferno.healthit.gov/.

(62) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov
Test Kits. Retrieved from https://inferno.healthit.gov/test-kits/.

(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.

(64) Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology. (n.d.).
SVAP. Retrieved from https://www.healthit.gov/isa/standards-version-advancement-process.

(65) Health Level Seven International. (n.d.). Da Vinci ATR List IG. Retrieved from http://hl7.org/fhir/us/davinci-atr/ImplementationGuide/hl7.fhir.us.davinci-atr.

(66) Health Level Seven International. (n.d.). Da Vinci CDex IG. Retrieved from http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex.

(67) Health Level Seven International. (n.d.). FAST Security IG. Retrieved from https://build.fhir.org/ig/HL7/fhir-udap-security-ig/.

(68) UDAP Unified Data Access Profiles. (n.d.) UDAP Tiered OAuth for User Authentication. Retrieved from https://www.udap.org/udap-user-auth-stu1.html.

(69) Health Level Seven International. (n.d.). FAST Security IG. Retrieved from https://build.fhir.org/ig/HL7/fhir-udap-security-ig/.

(70) Health Level Seven International. (n.d.). Consumer Real-Time Pharmacy Benefit Check IG. Retrieved from https://hl7.org/fhir/us/carin-rtpbc/.

(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.

(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.

(98) See 45 CFR 162.1302.

(99) Department of Health and Human Services. (2024, February 28). Statement of Enforcement Discretion for Referral Certification
and Authorization Transaction Standard at 45 CFR 162.1302 for HIPAA Covered Entities Subject to the 2024 CMS Interoperability
and Prior Authorization Final Rule (CMS-0057-F) that Implement an All-FHIR-Based Prior Authorization API. Retrieved from https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf.

(100) See 45 CFR 162.1302.

(101) Health Level Seven International. (2026, March 27). Da Vinci Prior Authorization Support (PAS) FHIR IG. Retrieved from https://hl7.org/fhir/us/davinci-pas/usecases.html#scope-of-work-flow.

(102) Per section 1927(k)(3) of the Act and 42 CFR 447.502, drugs that are provided as part of, or as incident to and in the same
setting as a service, and for which payment is made in Medicaid as payment for part of the service, and not as direct reimbursement
are not “covered outpatient drugs.” Accordingly, the prior authorization requirements in section 1927(d)(5) of the Act do
not apply to such drugs.

(103) See 42 CFR 438.3(s)(6).

(104) See 42 CFR 431.80(b) for state Medicaid FFS programs and 42 CFR 457.732(b) for state CHIP FFS programs.

(105) American Medical Association. (2024). 2024 Prior Authorization (PA) State Law Chart. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-state-law-chart.pdf.

(106) National Council for Prescription Drug Programs. NCPDP Formulary and Benefit Standard Implementation Guide, Version 60. Retrieved
from https://standards.ncpdp.org/Access-to-Standards.aspx. NCPDP F&B standard IGs are available to NCPDP members for free and to non-members for a fee at this website.

(107) National Council for Prescription Drug Programs. NCPDP Real-Time Prescription Benefit Standard, Implementation Guide, Version
13. Retrieved from https://standards.ncpdp.org/Access-to-Standards.aspx. NCPDP RTPB standard IGs are available to NCPDP members for free and to non-members for a fee at this website.

(108) For the Provider Access and Payer-to-Payer APIs, see 42 CFR 431.61(c) for state Medicaid FFS programs and 42 CFR 457.731(c)
for state CHIP FFS programs. For the Prior Authorization API, see 42 CFR 431.80(c) for state Medicaid FFS programs and 42
CFR 457.732(d) for state CHIP FFS programs.

(109) For the Provider Access and Payer-to-Payer APIs, see 45 CFR 156.222(c). For the Prior Authorization API, see 45 CFR 156.223(d).

(110) See 42 CFR 431.80(c)(2)(ii)(B)(2).

(111) See discussion in 65 FR 82579 that clarifies that “pure premiums” can be substituted for “annual receipts,” as appropriate.

(112) For the Patient Access API, see 45 CFR 156.221(h). For the Provider Access and Payer-to-Payer APIs, see 45 CFR 156.222(c).
For the Prior Authorization API, see 45 CFR 156.223(d).

(113) For additional discussion of considerations related to granting an exception, please see 2024 CMS Interoperability and Prior
Authorization final rule preamble (89 FR 8905-8906).

(114) American Medical Association. (2025). 2024 AMA prior authorization physician survey. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.

(115) American Medical Association. (2023, March 13). Toll from prior authorization exceeds alleged benefits, say physicians. Retrieved
from https://www.ama-assn.org/press-center/press-releases/toll-prior-authorization-exceeds-alleged-benefits-say-physicians.

(116) See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs,
42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through existing cross reference
to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers
on the FFEs.

(117) See 42 CFR 422.122(a) for MA organizations and applicable integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs,
42 CFR 457.732(a) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8) for Medicaid
managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45
CFR 156.223(a) for individual market QHP issuers on the FFEs.

(118) See 42 CFR 422.568(b)(3) and 42 CFR 422.572(a)(2).

(119) See 42 CFR 422.568(e) and 42 CFR 422.572(e).

(120) See 42 CFR 422.2267(e)(16); See Integrated Denial Notice Form 10003-NDMCP, which has the instructions, form, and Spanish translation. See Centers for Medicare & Medicaid Services. (2024, September 10). MA Denial Notice. Retrieved from https://www.cms.gov/medicare/forms-notices/beneficiary-notices-initiative/ma-denial-notice.

(121) Centers for Medicare & Medicaid Services. (2024, November 18). Parts C & D Enrollee Grievances, Organization/Coverage Determinations,
and Appeals Guidance. Retrieved from https://www.cms.gov/medicare/appeals-and-grievances/mmcag/downloads/parts-c-and-d-enrollee-grievances-organization-coverage-determinations-and-appeals-guidance.pdf.

(122) See Integrated Denial Notice Form 10003-NDMCP Eff Jan 2025 available at: Centers for Medicare & Medicaid Services. (2024, September
10). MA Denial Notice. Retrieved from https://www.cms.gov/medicare/forms-notices/beneficiary-notices-initiative/ma-denial-notice.

(123) See 42 CFR 438.210(c) and 438.242(b)(8) for Medicaid managed care plans and 42 CFR 457.1230(d) for CHIP managed care entities.

(124) As specified in 42 CFR 438.242(b)(8) by cross-reference to 42 CFR 431.80(a).

(125) See 42 CFR 457.1233(d).

(126) See 42 CFR 422.122(a) for MA organizations and applicable integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs,
42 CFR 457.732(a) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8) for Medicaid
managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45
CFR 156.223(a) for individual market QHP issuers on the FFEs.

(127) See 42 CFR 435.917(a) for state Medicaid FFS programs and 42 CFR 457.1180 for state CHIP FFS programs.

(128) See 29 CFR 2560.503-1(g), 45 CFR 147.136(b)(2)(i), and 45 CFR 147.136(b)(3)(ii)(E)(3).

(129) As noted above, effective in 2026, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and
CHIP managed care entities must notify claimants and providers of prior authorization decisions on non-drug items and services
no later than 7 calendar days for standard requests and no later than 72 hours for expedited requests

(130) See 42 CFR 422.568(b)(3) and 42 CFR 422.572(a)(2).

(131) See 42 CFR 423.568(b) and 42 CFR 423.572(a).

(132) See section 1927(d)(5)(A) of the Act for state Medicaid FFS programs, 42 CFR 438.210(d)(3) and 42 CFR 438.3(s)(6) for Medicaid
managed care plans, and through cross reference to 42 CFR 438.210(d)(3) in 42 CFR 457.1230(d) for CHIP managed care entities.

(133) See 42 CFR 457.495(d).

(134) American Medical Association. (2024). 2024 Prior Authorization (PA) State Law Chart. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-state-law-chart.pdf.

(135) Pollitz, K., Pestaina, K., Lopes, L., Wallace, R., & Lo, J. (2023, September 29). Consumer Problems with Prior Authorization:
Evidence from KFF Survey. Retrieved from https://www.kff.org/affordable-care-act/issue-brief/consumer-problems-with-prior-authorization-evidence-from-kff-survey/.

(136) Consistent with the treatment of the requirement that payers provide the specific reason for denying a prior authorization
request in the payer's response to the provider established in the 2024 CMS Interoperability and Prior Authorization final
rule, the burden associated with notifying the requesting provider of the health plan's prior authorization determination
is considered usual and customary as the disclosure is integral to the business practice and function of the health plan.
Therefore, we have identified the burden associated with communicating a prior authorization decision as a usual and customary
business practice that does not require a burden calculation pursuant to 5 CFR 1320.3(b)(2).

(137) See 42 CFR 422.568(b)(1) and 42 CFR 422.568(b)(3).

(138) See 42 CFR 423.568(b) and 42 CFR 423.572(a).

(139) See 42 CFR 440.230(e)(1).

(140) See 42 CFR 457.495(d), using the phrase “In accordance with the medical needs of the patient . . . .”

(141) The services listed in section 1927(k)(3) of the Act are: inpatient hospital services; hospice services; dental services,
except that drugs for which the State plan authorizes direct reimbursement to the dispensing dentist are covered outpatient
drugs; physicians' services; outpatient hospital services; nursing facility services and services provided by an intermediate
care facility for the mentally retarded; other laboratory and x-ray services; and renal dialysis.

(142) See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs,
42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through existing cross reference
to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers
on the FFEs.

(143) See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs,
42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through cross reference
to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 1562.223(c) for individual market QHP issuers
on the FFEs.

(144) Appeals for MA organizations are described in 42 CFR 422 Subpart M. Appeals for state Medicaid FFS programs (known as fair
hearings) are described in 42 CFR 431 Subpart E and for Medicaid managed care plans in 42 CFR 438 Subpart F. Appeals for state
CHIP FFS programs are described in 42 CFR 457 Subpart K and for CHIP managed care entities in 42 CFR 457.1260. Appeals for
QHP issuers on the FFEs are described in 45 CFR 147.136.

(145) Existing reporting requirements for PDPs may be found at: Centers for Medicare & Medicaid Services. (2024). Part D Reporting
Requirements. Retrieved from https://www.cms.gov/medicare/coverage/prescription-drug-coverage-contracting/part-d-reporting-requirements.

(146) See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs,
42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through existing cross reference
to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers
on the FFEs.

(147) Centers for Medicare & Medicaid Services. (2023, September 15). Prior Authorization and Pre-Claim Review Program Stats. Retrieved
from https://www.cms.gov/files/document/prior-authorization-and-pre-claim-review-program-statistics.pdf.

(148) Appeals for MA organizations are described in 42 CFR 422 Subpart M.

(149) Appeals for state Medicaid FFS programs (known as fair hearings) are described in 42 CFR 431 Subpart E and for Medicaid managed
care plans in 42 CFR 438 Subpart F. Appeals for state CHIP FFS programs are described in 42 CFR 457 Subpart K and for CHIP
managed care entities in 42 CFR 457.1260.

(150) Appeals for QHP issuers on the FFEs are described in 45 CFR 147.136.

(151) See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs,
42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through existing cross reference
to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers
on the FFEs.

(152) Qualified Health Plan Certification. (2024, August 8). Application Instructions. Retrieved from https://www.qhpcertification.cms.gov/s/Application%20Instructions.

(153) See the following sections for these proposals: II.A.2.a. through II.A.2.c., II.A.3., II.A.4.b.(1). and II.A.4.b.(2)., II.A.4.b.(4).
and II.A.4.b.(5)., II.B.3. through II.B.7., II.C.2.c., II.C.3.b. and II.C.3.d., II.C.6. and II.C.7., II.E.1. through II.E.4.,
II.F.1.b., II.F.2.b., II.F.2.c., II.F.5.a., and II.F.5.b. of this proposed rule.

(154) For more information on interoperability and QHP certification, including further detail on the exceptions process, see https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability. Discussion of this topic is also available in the 2024 CMS Interoperability and Prior Authorization final rule preamble: 89
FR 8906.

(155) We discuss final requirements in the 2020 CMS Interoperability and Patient Access final rule and the 2024 CMS Interoperability
and Prior Authorization final rule for all impacted payers, but for ease of reference, we are only providing citations to
these requirements for individual market QHP issuers on the FFEs. See 45 CFR 156.221(a) for the Patient Access API, 45 CFR 156.222(a) for the Provider Access API, 45 CFR

  156.222(b) for the Payer-to-Payer API, and 45 CFR 156.223(b) for the Prior Authorization API for individual market QHP issuers
  on the FFEs.

(156) See 45 CFR 156.221(c) for the Patient Access API, 45 CFR 156.222(a)(1)(ii) for the Provider Access API, 45 CFR 156.222(b)(1)(ii)
for the Payer-to-Payer API, and 45 CFR 156.223(b) for the Prior Authorization API.

(157) See 45 CFR 156.221(c)(4).

(158) See 45 CFR 156.221(c)(2).

(159) See 45 CFR 156.221(d).

(160) See 45 CFR 156.221(e)(1).

(161) See 45 CFR 156.221(e)(2).

(162) See 45 CFR 156.221(a).

(163) See 45 CFR 156.221(b)(1)(iii).

(164) See 45 CFR 156.221(i)(1).

(165) See 45 CFR 156.221(b)(1)(iii).

(166) See 45 CFR 156.221(b)(1)(iv).

(167) See 45 CFR 156.221(b)(1)(iv)(A).

(168) See 45 CFR 156.221(b)(1)(iv)(B).

(169) See 45 CFR 156.221(g).

(170) See 45 CFR 156.221(f).

(171) Information about QHP certification, including deadlines can be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline.

(172) See 45 CFR 156.222(a)(1).

(173) See 45 CFR 156.222(a)(2).

(174) See 45 CFR 156.222(a)(2).

(175) See 45 CFR 156.222(a)(3).

(176) See 45 CFR 156.222(a)(5).

(177) See 45 CFR 156.222(a)(4)(i).

(178) See 45 CFR 156.222(a)(4)(i).

(179) See 45 CFR 156.222(a)(4)(ii).

(180) See 45 CFR 156.222(a)(4)(ii).

(181) As discussed in the 2024 CMS Interoperability and Prior Authorization final rule, where coverage starts prospectively, the
deadline would be based on the coverage start date (also known as the coverage effective date). In the case of retroactive
coverage, to avoid a deadline in the past, the deadline for the payer to provide the required information about the Payer-to-Payer
API, request identifying information about previous/concurrent payer(s), and an opt in would be based on the date that the
payer gets patient information and makes the patient's coverage effective (89 FR 8833).

(182) See 45 CFR 156.222(a)(4)(ii).

(183) See 45 CFR 156.222(a)(4)(ii)(D).

(184) See 45 CFR 156.222(b).

(185) See 45 CFR 156.222(b)(5).

(186) See 45 CFR 156.222(b)(4).

(187) See 45 CFR 156.222(b)(2).

(188) See 45 CFR 156.222(b).

(189) See 45 CFR 156.222(b)(2).

(190) See 45 CFR 156.222(b)(2)(ii).

(191) See 45 CFR 156.222(b)(7).

(192) See 45 CFR 156.222(b)(7).

(193) See 45 CFR 156.222(b)(7)(i)-(ii).

(194) See 45 CFR 156.222(b)(7)(iii).

(195) See 45 CFR 156.222(b)(4)(iv)(A). In the 2024 CMS Interoperability and Prior Authorization final rule, in which this requirement
was finalized for impacted payers including individual market QHP issuers on the FFEs, CMS noted that “sufficient information”
refers to information about patients' previous/concurrent payer(s) that would allow them [the payer] to identify and request
data from those other payers. CMS left the process of gathering this information open for payers to implement in the least
burdensome, most practical way, and noted payers often have established points of contact and existing processes that can
apply here; for example, that they use to identify concurrent payers to facilitate coordination of coverage and Medicare Secondary
Payer/Third Party Liability administration (89 FR 8834-8835).

(196) See 45 CFR 156.222(b)(4)(iv)(B).

(197) See 45 CFR 156.222(b)(4)(v).

(198) See 45 CFR 156.222(b)(6).

(199) See 45 CFR 156.223(b).

(200) See 45 CFR 156.223(a).

(201) See 45 CFR 156.223(c).

(202) See 45 CFR 156.223(b).

(203) See 45 CFR 156.223(b).

(204) See 45 CFR 156.223(a).

(205) See 45 CFR 156.223(c).

(206) See 156.221(h) for the Patient Access API, 45 CFR 156.222(c) for the Provider Access and Payer-to-Payer APIs, and 45 CFR 156.223(d)
for the Prior Authorization API.

(207) For the Patient Access API, see 45 CFR 156.221(h) for QHP issuers on the FFEs. For the Provider Access and Payer-to-Payer
APIs, see 42 CFR 431.61(c)(1)-(2) for state Medicaid FFS programs, 42 CFR 457.731(c)(1) and (2) for state CHIP FFS programs,
and 45 CFR 156.222(c) for QHP issuers on the FFEs. For the Prior Authorization API, see 42 CFR 431.80(c)(1) for state Medicaid
FFS programs, 42 CFR 457.732(d)(1) for state CHIP FFS programs, and 45 CFR 156.223(d) for QHP issuers on the FFEs.

(208) See, for instance, cross-references to SMART Launch IG in 45 CFR 170.215(c) and OpenID Connect Core in 45 CFR 170.215(e),
for the Patient Access API in 42 CFR 422.119(c)(1) for MA organizations, 42 CFR 431.60(c)(1) for state Medicaid FFS programs,
through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(c)(1) for
CHIP FFS programs, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45
CFR 156.221(c)(1) for individual market QHP issuers on the FFEs.

(209) For the Patient Access API, see 45 CFR 156.221(h) for QHP issuers on the FFEs. For the Provider Access and Payer-to-Payer
APIs, see 42 CFR 431.61(c)(1)-(2) for state Medicaid FFS programs, 42 CFR 457.731(c)(1) and (2) for state CHIP FFS programs,
and 45 CFR 156.222(c) for QHP issuers on the FFEs. For the Prior Authorization API, see 42 CFR 431.80(c)(1) for state Medicaid
FFS programs, 42 CFR 457.732(d)(1) for state CHIP FFS programs, and 45 CFR 156.223(d) for QHP issuers on the FFEs.

(210) See 42 CFR 422.119(d) for MA organizations, 42 CFR 431.60(d) for state Medicaid FFS programs, 42 CFR 457.730(d) for state CHIP
FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d) for QHP issuers on
the FFEs.

(211) See 42 CFR 422.119(d) for MA organizations, 42 CFR 431.60(d) for state Medicaid FFS programs, 42 CFR 457.730(d) for state CHIP
FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d) for QHP issuers on
the FFEs.

(212) See 42 CFR 422.119(d)(1) for MA organizations, 42 CFR 431.60(d)(1) for state Medicaid FFS programs, 42 CFR 457.730(d)(1) for state
CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(1) for QHP issuers
on the FFEs.

(213) See 42 CFR 422.119(d)(3) for MA organizations, 42 CFR 431.60(d)(3) for state Medicaid FFS programs, 42 CFR 457.730(d)(3) for state
CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(3) for QHP issuers
on the FFEs.

(214) See 42 CFR 422.119(d)(2) for MA organizations, 42 CFR 431.60(d)(2) for state Medicaid FFS programs, 42 CFR 457.730(d)(2) for state
CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(2) for QHP issuers
on the FFEs.

(215) See sections 1852(d)(1)(A), 1852(g)(1)(A), 1852(h), 1856(b), and 1857(e)(1) of the Act for MA organizations; see sections 1902(a)(4),
1902(a)(6), 1902(a)(8), 1902(a)(19), 1903(m)(2)(A)(xi), and 1932(d)(1) of the Act for state Medicaid FFS programs and Medicaid
managed care plans; see sections 2101 and 2102 of the Act for state CHIP FFS programs and CHIP managed care entities; see
sections 1311(c) and 1321(a) of the Affordable Care Act for QHP issuers on the FFEs (42 U.S.C. 18031(c), 18041(a)). See section
II.E.7. of this proposed rule for a detailed discussion of statutory authorities.

(216) Health Level Seven International. (2023, March 26). Resource Capability Statement—Content. Retrieved from https://hl7.org/fhir/capabilitystatement.html.

(217) See 42 CFR 422.119(d)(1) for MA organizations, 42 CFR 431.60(d)(1) for state Medicaid FFS programs, 42 CFR 457.730(d)(1) for state
CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(1) for QHP issuers
on the FFEs.

(218) Authorization and authentication protocols are “software components and configurations an application must use in order to
successfully interact with the API” and are specifically required to be publicly posted in 42 CFR 422.119(d)(2) for MA organizations,
42 CFR 431.60(d)(2) for state Medicaid FFS programs, 42 CFR 457.730(d)(2) for state CHIP FFS programs, through cross reference
to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42
CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(2) for QHP issuers on the FFEs.

(219) Authorization protocols (such as OAuth 2.0 and SMART App Launch) define the software components and configurations that apps
must implement to obtain permission to access data from the API server, including authorization clients, token handlers, and
redirect URI configurations. Authentication protocols (such as OpenID Connect Core) define the software components and configurations
that apps must implement to verify the identity of the requesting entity, including authentication flows, identity token processors,
and user credential validation modules.

(220) Health Level Seven International. (2023, March 26). FHIR Security. Retrieved from https://hl7.org/fhir/security.html#binding.

(221) See, for example, the Certified Health IT Product Listing API maintained by ONC at https://chpl.healthit.gov/#/resources/api and the ONC Certification (g)(10) Standardized API Test Kit at https://github.com/onc-healthit/onc-certification-g10-test-kit?tab=readme-ov-file#terminology-prerequisites.

(222) Health Level Seven International. (2025, April 10). National Directory of Healthcare Providers & Services (NDH) IG. Retrieved
from https://hl7.org/fhir/us/ndh/STU1/index.html.

(223) Health Level Seven International. (2025, April 10). Resource Profile: NDH Base Endpoint Profile. Retrieved from https://hl7.org/fhir/us/ndh/STU1/StructureDefinition-ndh-Endpoint.html.

(224) See 89 FR 8784.

(225) See 89 FR 8818.

(226) See 89 FR 8840 and 8841.

(227) See 85 FR 25526.

(228) See 89 FR 8785.

(229) See 89 FR 8840 and 8841.

(230) See 89 FR 8899.

(231) See 89 FR 8786.

(232) See 89 FR 8819.

(233) See 89 FR 8840 and 8841.

(234) See 89 FR 8900.

(235) See 89 FR 8840 and 8841.

(236) See 42 CFR 422.119(b)(1)(iv)(A) for MA organizations, 42 CFR 431.60(b)(5)(i) for state Medicaid FFS programs, 42 CFR 457.730(b)(5)(i)
for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans,
through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(b)(1)(iv)(A)
for individual market QHP issuers on the FFEs.

(237) See 42 CFR 422.121(b)(4)(ii)(A) for MA organizations, 42 CFR 431.61(b)(4)(ii)(A) for state Medicaid FFS programs, 42 CFR 457.731(b)(4)(ii)(A)
for state CHIP FFS programs, through cross reference to 42 CFR 431.61(b)(4) in 42 CFR 438.242(b)(7) for Medicaid managed care
plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(b)(4)(ii)(A)
for individual market QHP issuers on the FFEs.

(238) See 42 CFR 422.121(b)(4)(ii) for MA organizations, 42 CFR 431.61(b)(4)(ii) for state Medicaid FFS programs, 42 CFR 457.731(b)(4)(ii)
for state CHIP FFS programs, through cross reference to 42 CFR 431.61(b)(4) in 42 CFR 438.242(b)(7) for Medicaid managed care
plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(b)(4)(ii)
for individual market QHP issuers on the FFEs.

(239) See 42 CFR 422.119(f) for MA organizations, 42 CFR 431.60(f) for state Medicaid FFS programs, 42 CFR 457.730(f) for state CHIP
FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5)(iii) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities.

(240) See Section 16. Interoperability. Center for Consumer Information and Insurance Oversight. (2026, February 25). FFEs 2027 Draft
Letter to Issuers in the Federally-facilitated Exchanges. Retrieved from https://www.cms.gov/files/document/draft-2027-letter-issuers.pdf.

(241) See 42 CFR 422.119(f) for MA organizations, 42 CFR 431.60(f) for state Medicaid FFS programs, 42 CFR 457.730(f) for state CHIP
FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5)(iii) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(f) for individual
market QHP issuers on the FFEs.

(242) See FAQ #3 citing the requirements in 42 CFR 438.66(e)(1). (2024, March). Medicaid Managed Care Program Annual Report (MCPAR)
Technical Assistance Resource for States. Retrieved from https://www.medicaid.gov/sites/default/files/2024-04/mcpar-faq-march-2024v.2.pdf.

(243) For example, 45 CFR 156.220(b) provides that a QHP issuer on the FFEs must submit transparency in coverage metrics described
in paragraph (a) of that section in an accurate and timely manner, to be determined by HHS.

(244) Information about QHP certification, including deadlines, can be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline.

(245) See Section 16. Interoperability. Center for Consumer Information and Insurance Oversight. (2026, February 25). FFEs 2027 Draft
Letter to Issuers in the Federally-facilitated Exchanges. Retrieved from https://www.cms.gov/files/document/draft-2027-letter-issuers.pdf.

(246) 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.

(247) The applicable regulations used a cross reference to the regulatory provision for the scope of information available through
the Patient Access API to accomplish this. For example, the regulation in 42 CFR 422.121(a)(2) requires MA organizations to
include in their Provider Access APIs information that is listed in 42 CFR 422.119(b), a provision from the regulation that
requires MA organizations to make certain information available through the Patient Access API. For MA organizations, the
obligation to include drug formulary information is limited to MA-PD plans and their covered Part D drug formularies. See through cross reference to 42 CFR 422.119(b) in 42 CFR 422.121(a)(2) (Provider Access API) and in 42 CFR 422.121(b)(4)(ii)(A)
(Payer-to-Payer API) for MA organizations, through cross reference to 42 CFR 431.60(b) in 42 CFR 431.61(a)(2) (Provider Access
API) and in 42 CFR 431.61(b)(4)(ii)(A) (Payer-to-Payer API) for state Medicaid FFS programs, through cross reference to 42
CFR 457.730(b) in 42 CFR 457.731(a)(2) (Provider Access API) and in 42 CFR 457.731(b)(4)(ii)(A) (Payer-to-Payer API) for state
CHIP FFS programs, through cross reference to 42 CFR 431.61 in 42 CFR 438.242(b)(7) (Provider Access and Payer-to-Payer APIs),
and through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) (Provider Access and Payer-to-Payer APIs).

(248) Qualified Health Plan Certification Information and Guidance. Machine-Readable Data. Retrieved from https://www.qhpcertification.cms.gov/s/Machine-Readable%20Data.

(249) See 42 CFR 422.120 for MA organizations, 42 CFR 431.70 for state Medicaid FFS programs, 42 CFR 457.760 for state CHIP FFS programs,
42 CFR 438.242(b)(6) for Medicaid managed care plans, and 42 CFR 457.1233(d) for CHIP managed care entities.

(250) See 42 CFR 422.119(e) for MA organizations, 42 CFR 431.60(e) for state Medicaid FFS programs, 42 CFR 457.730(e) 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, and through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities.

(251) See 45 CFR 156.230(c).

(252) See 42 CFR 422.112(b)(8)(i)(B).

(253) Section 1902(a)(7) of the Act uses the term “recipients.” For clarity, we have modified the term to “beneficiaries” to be
consistent with the terminology used in this proposed rule.

(254) The regulation in 42 CFR 431.306(d) generally requires a state Medicaid agency to obtain permission from the beneficiary
or their authorized representative, whenever possible, before responding to a request for information from an outside source.

(255) See 42 CFR 431.61(a)(4).

(256) Churning occurs when people lose Medicaid coverage and then re-enroll within a short period of time. Medicaid beneficiaries
frequently experience churning. Sugar, S., Peters, C., Lew, N. D., & Sommers, B. D. (2021, April 12). Medicaid Churning and
Continuity of Care: Evidence and Policy Considerations Before and After the COVID-19 Pandemic. ASPE. Assistant Secretary For
Planning And Evaluation. Retrieved from https://aspe.hhs.gov/sites/default/files/documents/5f6e4d78d867b6691df12d1512787470/medicaid-churning-ib.pdf.

(257) See 42 U.S.C. 1320a.

(258) See 42 CFR 403.902.

(259) See 42 CFR 403.904(e)(2).

(260) See 42 CFR 403.904 (c).

(261) See 42 CFR 403.904(c)(8).

(262) Despite the language of section 1128G(e)(10)(B)(i) of the Act that says “[f]or calendar years after 2012,” we explained in
the rulemaking that, “[g]iven the timing of this final rule, we have decided to begin increasing the de minimis thresholds
for reporting in CY 2014, and retain the statutory de minimis thresholds ($10 and $100) for reporting in CY 2013.”

(263) See 42 CFR 403.904(h)(2)(iii).

(264) For example, per the Open Payments final rule, “in order to facilitate audits and enforcement, applicable manufacturers and
applicable GPOs must maintain all books, records, documents, and other materials sufficient to enable an audit, evaluation
or inspection of the applicable manufacturer's or applicable GPO's compliance with the requirements in section 1128G of the
Act and the implementing regulations.” (78 FR 9506-78 FR 9507).

(265) See 42 CFR 403.912(e)(1)(ii).

(266) This includes our authority to audit books, contracts, records, documents, ledgers, and other evidence of compliance with
reporting requirements that reporting entities must maintain. See 42 CFR 403.912(e)(2).

(267) See 45 CFR 102.3 for annual calculation. For 2025, the non-compliance per-record minimum is $1,406 and the maximum is $14,067,
with a per-year cap of $211,008. The knowing minimum per-record is $14,067 and the maximum is $140,674, with a per-year cap
of $1,406,728.

(268) See 45 CFR 160.103 for the definition of a HIPAA covered entity.

(269) See, for example, sections 1173(i) and 1174(b) of the Act.

(270) American Medical Association. (2025). 2024 AMA prior authorization physician survey. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.

(271) Reginfo.gov. (2002, October). Addenda: EDI Transaction Set IG, Health Care Services Review—Request for Review and Response,
ASC X12N 278 (004010X094A1). Retrieved from https://www.reginfo.gov/public/do/DownloadDocument?objectID=6139801.

(272) X12. (n.d.). Health Care Transaction Flow, Step 11: Health Care Services Review Request. Retrieved from https://x12.org/flow/health-care.

(273) “Health care” means care, services, or supplies related to the health of an individual. Health care includes, but is not
limited to, the following: (1) Preventive, diagnostic, therapeutic, rehabilitative, maintenance, or palliative care, and counseling,
service, assessment, or procedure with respect to the physical or mental condition, or functional status, of an individual
or that affects the structure or function of the body; and (2) Sale or dispensing of a drug, device, equipment, or other item
in accordance with a prescription (see 45 CFR 160.103).

(274) Nothing precludes such transactions from being intermediated by clearinghouses, though traditionally they have not largely
engaged in that role for prior authorization.

(275) The FHIR standard, adopted by the Secretary as the “API base standard” in 45 CFR 170.215(a), is a base set of modular components
called “resources” that serve as the foundation to the FHIR framework, and is commonly referred to as the FHIR base standard.

(276) Health Level Seven International. (2023, March 26.). Introduction to HL7 FHIR. Retrieved from https://hl7.org/fhir/summary.html.

(277) Health Level Seven International. (2025, December 10). US Core Implementation Guide. Retrieved from https://hl7.org/fhir/us/core/.

(278) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (n.d.). United States Core Data
for Interoperability. Retrieved from https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi.

(279) Health Level Seven International. (2023, March 1). SMART App Launch IG. Retrieved from https://hl7.org/fhir/smart-app-launch/.

(280) SMART. (n.d.). SMART on FHIR API. Retrieved from https://smarthealthit.org/smart-on-fhir-api/.

(281) Health Level Seven International. (n.d.). Da Vinci CRD IG. Retrieved from http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd.

(282) Health Level Seven International. (n.d.). Da Vinci DTR IG. Retrieved from http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr.

(283) Health Level Seven International. (n.d.). Da Vinci PAS IG. Retrieved from http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas.

(284) HL7 FHIR Exception #202103100. Health Level Seven International. (2024, November 12). Da Vinci Project Confluence: Da Vinci
HIPAA/HL7 FHIR Exception Approval Letter. Retrieved from https://confluence.hl7.org/spaces/DVP/pages/113675673/Da+Vinci+HIPAA+Exception?preview=/113675673/113675685/Approval%20%232021031001.pdf.

(285) Centers for Medicare & Medicaid Services. (2026, April 7). Da Vinci Exception Testing Materials. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process.

(286) HL7 Da Vinci Project Steering Committee. (2024, June 25). HIPAA Exception Report. Retrieved from https://confluence.hl7.org/download/attachments/113675673/HL7%20Da%20Vinci%20Exception%20Report_Final%20%28June%2025%2C%202024%29.pdf?version=1&modificationDate=1731382945836&api=v2.

(287) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (2023, April 17). Intersection
of Clinical and Administrative Data Task Force. Retrieved from https://www.healthit.gov/hitac/committees/intersection-clinical-and-administrative-data-task-force.

(288) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (2020, November 17). A Path Toward
Future Clinical and Administrative Data Integration Final Report. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-11/2020-11-17_ICAD_TF_FINAL_Report_HITAC.pdf.

(289) The Health Information Technology Advisory Committee & The Clinical and Administrative Data Task Force to the National Coordinator
for Health Information Technology Policy. (2020, November 17). A Path Toward Further Clinical and Administrative Data Integration.
Retrieved from https://www.healthit.gov/sites/default/files/page/2020-11/2020-11-17_ICAD_TF_FINAL_Report_HITAC.pdf.

(290) Health Level Seven International. (n.d.). Da Vinci CDex IG. Retrieved from http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex.

(291) National Committee on Vital and Health Statistics. (2022, July 28). Recommendations to Modernize Adoption of HIPAA Transaction
Standards. Retrieved from https://ncvhs.hhs.gov/wp-content/uploads/2022/08/Recommendation-Letter-Modernize-Adoption-of-HIPAA-Transaction-Standards-508.pdf.

(292) National Committee on Vital and Health Statistics. (2022, June 9). Subcommittee on Standards Listening Session on Standardization
of Information for Burden Reduction and Post-Pandemic America Meeting Summary. Retrieved from https://ncvhs.hhs.gov/wp-content/uploads/2022/10/NCVHS-Standards-Subcommittee-Meeting-Summary-June-9-2022-final-508.pdf.

(293) National Committee on Vital and Health Statistics Subcommittee on Standards. (2021 November 8). Comments Received in Response
to Request for Comment
Federal Register
Notice: 86 FR 33318. Retrieved from https://ncvhs.hhs.gov/wp-content/uploads/2021/11/Public-Comments-Standards-Subcommittee-Listening-Session-August-25-2021.pdf.

(294) Appendix, Part II of National Committee on Vital and Health Statistics. (2022, July 28). Recommendations to Modernize Adoption
of HIPAA Transaction Standards. Retrieved from https://ncvhs.hhs.gov/wp-content/uploads/2022/08/Recommendation-Letter-Modernize-Adoption-of-HIPAA-Transaction-Standards-508.pdf.

(295) See, for example, 89 FR 100763 (Version D.0/Version 1.2 to Version F6/Version 15 8 months transition period).

(296) CMS explained that the approach of recommending, but not requiring, the specific IGs and versions provided directional guidance
with flexibility to the industry in order to allow for additional improvements to be made without locking implementers into
versions of the IGs available at the time of the proposed rule. (89 FR 8938)

(297) Centers for Medicare & Medicaid Services. (2024, February 28). HIPAA Transaction Enforcement Discretion Announcement. Retrieved
from https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf.

(298) CAQH. (n.d.). 2024 CAQH Index Report. Retrieved from https://www.caqh.org/hubfs/Index/2024%20Index%20Report/CAQH_IndexReport_2024_FINAL.pdf.

(299) The CAQH also identified low adoption of the available standard supporting health care claims attachments, for which a standard
had been proposed in the 2022 HIPAA Standards for Health Care Attachments proposed rule (the X12N 275 transaction standard),
but not finalized in the 2026 HIPAA Standards for Health Care Attachments final rule which appears elsewhere in this issue
of the
Federal Register
. See the proposal at https://www.federalregister.gov/d/2022-27437/p-141 and the CDex IG proposal in subsequent pages of this section.

(300) American Medical Association. (2024). 2024 AMA Prior Authorization Physician Survey. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.

(301) Council for Affordable Quality Healthcare. (2025, February 12). 2024 CAQH Index Report: From Transactions to Trust: Building
Better Care Through Healthcare Automation. Retrieved from https://www.caqh.org/hubfs/Index/2024%20Index%20Report/CAQH_IndexReport_2024_FINAL.pdf.

(302) HL7 Da Vinci Project Steering Committee. (2024, June 25). HIPAA Exception Report. Retrieved from https://confluence.hl7.org/download/attachments/113675673/HL7%20Da%20Vinci%20Exception%20Report_Final%20%28June%2025%2C%202024%29.pdf?version=1&modificationDate=1731382945836&api=v2.

(303) American Medical Association. (2024). 2024 AMA Prior Authorization Physician Survey. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.

(304) HL7 Da Vinci Project Steering Committee. (2024, June 25). HIPAA Exception Report. Retrieved from https://confluence.hl7.org/download/attachments/113675673/HL7%20Da%20Vinci%20Exception%20Report_Final%20%28June%2025%2C%202024%29.pdf?version=1&modificationDate=1731382945836&api=v2.

(305) Those operating rules are available at https://www.caqh.org/core/operating-rules.

(306) HL7 Da Vinci Project Steering Committee. (2024, June 25). HIPAA Exception Report. Retrieved from https://confluence.hl7.org/download/attachments/113675673/HL7%20Da%20Vinci%20Exception%20Report_Final%20%28June%2025%2C%202024%29.pdf?version=1&modificationDate=1731382945836&api=v2.

(307) HL7 Da Vinci Project Steering Committee. (2024, June 25). HIPAA Exception Report. Retrieved from https://confluence.hl7.org/download/attachments/113675673/HL7%20Da%20Vinci%20Exception%20Report_Final%20%28June%2025%2C%202024%29.pdf?version=1&modificationDate=1731382945836&api=v2.

(308) HIPAA § 261 as amended by § 1104 of the Patient Protection and Affordable Care Act (Public Law 111-148 as amended by Public
Law 111-152).

(309) Health Level Seven International. (n.d.). Da Vinci Clinical Data Exchange (CDex) IG. Retrieved from https://hl7.org/fhir/us/davinci-cdex/.

(310) Appendix, Part II of National Committee on Vital and Health Statistics. (2022, July 28). Recommendations to Modernize Adoption
of HIPAA Transaction Standards. Retrieved from https://ncvhs.hhs.gov/wp-content/uploads/2022/08/Recommendation-Letter-Modernize-Adoption-of-HIPAA-Transaction-Standards-508.pdf.

(311) Centers for Medicare & Medicaid Services. (2026, April 7). Da Vinci Exception Testing Materials. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process.

(312) As defined in 45 CFR 160.103, small health plans are those with annual receipts of $5 million or less.

(313) 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 432 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(b) for QHP issuers
on the FFEs.

(314) Centers for Medicare & Medicaid Services. (2024, February 28). HIPAA Transaction Enforcement Discretion Announcement. Retrieved
from https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf.

(315) American National Standards Institute. (n.d.). ANSI Accredited Standards Developers (ASD)—Health Level Seven International.
Retrieved from https://www.ansi.org/american-national-standards/info-for-standards-developers/accredited-standards-developers#q=Health%20Level%20Seven%20International&sort=%40titlecomputed%20ascending.

(316) Health Level Seven International. (n.d.). American National Standards Institute (ANSI) Approved Standards. Retrieved from https://www.hl7.org/implement/standards/ansiapproved.cfm?ref=nav.

(317) Centers for Medicare & Medicaid Services. (2026, April 7). DSMO Listening Session. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/events-latest-news.

(318) Council for Affordable Quality Healthcare. (2025, February 12). 2024 CAQH Index Report: From Transactions to Trust: Building
Better Care Through Healthcare Automation. Retrieved from https://www.caqh.org/hubfs/Index/2024%20Index%20Report/CAQH_IndexReport_2024_FINAL.pdf.

(319) Health Information Technology Advisory Committee. (2018, February 21). HITAC Policy Framework. Retrieved from https://www.healthit.gov/sites/default/files/page/2019-07/2018-02-21_HITAC_Policy-Framework_FINAL_508-signed.pdf.

(320) Health Information Technology Advisory Committee. (2020, March 2). Health Information Technology Advisory Committee (HITAC)
Annual Report for Fiscal Year 2019. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-03/HITAC%20Annual%20Report%20for%20FY19_508.pdf.

(321) Interoperability Standards Priorities Task Force. (2019, October 16). Interoperability Standards Priorities Task Force 2018
Report. Retrieved from https://www.healthit.gov/sites/default/files/page/2019-12/2019-10-16_ISP_TF_Final_Report_signed_508.pdf.

(322) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology. (n.d.). Interoperability
Standards Platform. Retrieved from https://www.healthit.gov/isp/.

(323) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology. (2025, January
30). About the ISA. Retrieved from https://www.healthit.gov/isp/about-isa.

(324) Health Leven Seven International. (2026, March 27). Da Vinci Coverage Requirements Discovery IG. Retrieved from https://hl7.org/fhir/us/davinci-crd/2.2.1/en/.

(325) Health Level Seven International. (2026, March 27). Da Vinci Documentation Templates and Rules IG. Retrieved from https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/.

(326) Health Leven Seven International. (2026, March 27). Da Vinci Prior Authorization Support (PAS) FHIR IG. Retrieved from https://hl7.org/fhir/us/davinci-pas/2.2.1/en/.

(327) Health Leven Seven International. (2026, March 27). CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button).
Retrieved from https://build.fhir.org/ig/HL7/carin-bb/en/

(328) Health Leven Seven International. (n.d.). Da Vinci PDex IG. Retrieved from http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex.

(329) Health Leven Seven International. (2025, February 25). Da Vinci PDex Plan Net IG. Retrieved from https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.2/.

(330) Health Leven Seven International. (2025, February 11). Da Vinci CDex IG. Retrieved from https://build.fhir.org/ig/HL7/davinci-ecdx/.

(331) Office of the National Coordinator for Health IT. (n.d.) Hospital Routine Electronic Notification. Retrieved from https://www.healthit.gov/data/quickstats/hospital-routine-electronic-notification.

(332) The Office of the Assistant Secretary for Planning and Evaluation. (2023, December). Health Information Technology Adoption
and Utilization in Long-Term and Post-Acute Care Settings. Retrieved at https://www.ncbi.nlm.nih.gov/books/NBK606653/pdf/Bookshelf_NBK606653.pdf.

(333) Gabriel, M.H., Richwine, C., Strawley, C., Barker, W., & Everson, J. (2024, May). Interoperable Exchange of Patient Health
Information Among U.S. Hospitals: 2023. ASTP Health IT Data Brief [internet], 71. Retrieved from https://www.ncbi.nlm.nih.gov/books/NBK606033/.

(334) Center for Clinical Standards and Quality. (2021, May 7). Advance Copy—Interoperability and Patient Access Rule—Admission,
Discharge, and Transfer Notifications for Hospitals, Psychiatric Hospitals, and Critical Access Hospitals (CAHs) Interpretive
Guidance. Retrieved from https://www.cms.gov/files/document/qso-21-18-hospitals-cahs.pdf.

(335) The Mass HIway. (n.d.). Circle Health uses the Mass HIway to Facilitate Sharing of Patient Information with Atrius Health.
Retrieved from https://ehs-hie-dru.ehs.mass.gov/Resources/HIE_Spotlight_Stories/Circle_Health.

(336) Health Gorilla. (n.d.). ADT Network. Retrieved from https://developer.healthgorilla.com/docs/adt-network.

(337) Office of the National Coordinator for Health IT. (2024, October). Standards Adoption Among Health Information Exchange Organizations.
Retrieved from https://www.healthit.gov/data/data-briefs/standards-adoption-among-health-information-exchange-organizations.

(338) Office of the National Coordinator for Health IT. (2026, February 11). TEFCA. Retrieved from https://healthit.gov/policy/tefca/.

(339) Health Level Seven International FHIR. (2024, October 2). Topic-Based Subscriptions Framework. Retrieved from https://build.fhir.org/subscriptions.html.

(340) See section 2.14.6.6. Health Level Seven International FHIR. (2024, October 2). Resource SubscriptionTopic—Content. Retrieved
from https://build.fhir.org/subscriptiontopic.html.

(341) Health Level Seven International FHIR. (2025, April 8). Da Vinci Unsolicited Notification IG Version 1.0.0. Retrieved from https://build.fhir.org/ig/HL7/davinci-alerts/usecases.html.

(342) Office of the National Coordinator for Health IT. (2026, February 11). TEFCA. Retrieved from https://healthit.gov/policy/tefca/.

(343) Health Level Seven International. (n.d.). Da Vinci ATR List IG. Retrieved from http://hl7.org/fhir/us/davinci-atr/ImplementationGuide/hl7.fhir.us.davinci-atr.

(344) U.S. Department of Health and Human Services. (2023, October 23). How the HIPAA Security Rule Can Help Defend Against Cyber-Attacks
[Webinar]. YouTube. Retrieved from https://www.youtube.com/watch?v=VnbBxxyZLc8.

(345) International Business Machines Corporation (IBM), p.12-13 (2025). Cost of a Data Breach Report 2025. Retrieved from https://www.ibm.com/reports/data-breach.

(346) See sections 262(aa) and 264(c) of Public Law 104-191.

(347) See 45 CFR part 160 and 45 CFR part 164, subparts A and C.

(348) See 45 CFR 164.306(a).

(349) See 45 CFR 164.306(b)-(d).

(350) See 45 CFR 164.306(e).

(351) Text—S.2521—113th Congress (2013-2014): Federal Information Security Modernization Act of 2014. (2014, December 18). Retrieved
from https://www.congress.gov/bill/113th-congress/senate-bill/2521/text.

(352) Federal Information Security Modernization Act of 2014. (Pub. L. 113-283, 3554, Dec. 18, 2014, 128 Stat. 2751).

(353) Centers for Medicare & Medicaid Services. (2024, September 10). What's a MAC. Retrieved from https://www.cms.gov/medicare/coding-billing/medicare-administrative-contractors-macs/whats-mac.

(354) Office of Inspector General. (n.d.). Review of Medicare Administrative Contractor Information Security Program Evaluations
for FY 2023 (MMA 912). Retrieved from https://oig.hhs.gov/reports-and-publications/workplan/summary/wp-summary-0000665_2.asp#:~:text=and%20transmitted%20securely.-,Review%20of%20Medicare%20Administrative%20Contractor%20Information%20Security%20Program%20Evaluations%20for,of%20their%20Section%20912%20evaluations.

(355) Text—S.912(b)—108th Congress (2003-2004): Medicare Prescription Drug, Improvement, and Modernization Act of 2003. (2003,
December 18). Retrieved from https://www.congress.gov/bill/108th-congress/house-bill/1.

(356) Public Law 111-5, 123 Stat. 226 (Feb. 17, 2009).

(357) Sec. 13401(a) and (b) of Public Law 111-5, 123 Stat. 260 (codified in 42 U.S.C. 17931(a) and (b)).

(358) Sec. 13401(c) of Public Law 111-5, 123 Stat. 260 (codified in 42 U.S.C. 17931(c)).

(359) See Public Law 116-321, 134 Stat. 5072, adding sec. 13412 (Jan. 5, 2021) (codified in 42 U.S.C. 17941); see also 42 U.S.C. 17931 et seq.

(360) The White House. (2024, April 30). National Security Memorandum on Critical Infrastructure Security and Resilience. Retrieved
from https://bidenwhitehouse.archives.gov/briefing-room/presidential-actions/2024/04/30/national-security-memorandum-on-critical-infrastructure-security-and-resilience/.

(361) Centers for Medicare & Medicaid Services. (2025, July 31). CMS Interoperability Framework. Retrieved from https://www.cms.gov/health-technology-ecosystem/interoperability-framework.

(362) Centers for Medicare & Medicaid Services. (2025, July 30). White House, Tech Leaders Commit to Create Patient-Centric Healthcare
Ecosystem. Retrieved from https://www.cms.gov/newsroom/press-releases/white-house-tech-leaders-commit-create-patient-centric-healthcare-ecosystem.

(363) Office of the National Coordinator for Health Information Technology. (2018, November). SAFER Guides. Retrieved from https://www.healthit.gov/topic/safety/safer-guides.

(364) Centers for Medicare & Medicaid Services. (n.d.). SAFER Guides Requirements. Retrieved from https://www.cms.gov/files/document/cms-safer-guides-infographic-2023.pdf.

(365) Office of the National Coordinator for Health IT. (2025, February 21). SAFER Guides. Retrieved from https://www.healthit.gov/topic/safety/safer-guides.

(366) See U.S. Department of Health and Human Services. (2024, October 24). Security Rule Guidance Material, OCR Cyber Awareness Newsletters.
Retrieved from https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html (newsletters published from 2019-present) and U.S. Department of Health and Human Services. (2019, April 2). Cybersecurity
Newsletter Archive. Retrieved from https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity/cybersecurity-newsletter-archive/index.html (newsletters published from 2016-2019).

(367) The Office for Civil Rights of the U.S. Department of Health and Human Services. (n.d.). USGovHHSOCR. Retrieved from https://www.youtube.com/usgovhhsocr.

(368) Office of the National Coordinator for Health Information Technology. (2025, September 30). Security Risk Assessment Tool.
Retrieved from https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool.

(369) U.S. Department of Health and Human Services. (2023, December). Healthcare Sector Cybersecurity: Introduction to the Strategy
of the U.S. Department of Health and Human Services. Retrieved from https://aspr.hhs.gov/cyber/Documents/Health-Care-Sector-Cybersecurity-Dec2023-508.pdf.

(370) The White House. (2023, March). National Cybersecurity Strategy. Retrieved from https://bidenwhitehouse.archives.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf.

(371) U.S. Department of Health and Human Services. (2023). Healthcare and Public Health (HPH) Cybersecurity Performance Goals.
Retrieved from https://hhscyber.hhs.gov/performance-goals.html.

(372) Administration for Strategic Preparedness & Response. (2023, March). HPH Sector Cybersecurity Framework Implementation Guide.
Retrieved from https://aspr.hhs.gov/cip/hph-cybersecurity-framework-implementation-guide/Pages/default.aspx.

(373) U.S. Department of Health and Human Services and the Healthcare & Public Health Sector Coordinating Council. (2023). Health
Industry Cybersecurity Practices: Managing Threats and Protecting Patients. Retrieved from https://405d.hhs.gov/Documents/HICP-Main-508.pdf.

(374) Federal Trade Commission. (2023, August). Start with Security: A Guide for Business. Retrieved from https://www.ftc.gov/system/files/ftc_gov/pdf/920a_start_with_security_en_aug2023_508_final_0.pdf.

(375) National Institute of Standards and Technology. (2024, February). Implementing the Health Insurance Portability and Accountability
Act (HIPAA) Security Rule: A Cybersecurity Resource Guide. Retrieved from https://csrc.nist.gov/pubs/sp/800/66/r2/final.

(376) McGlave, C., Neprash, H., & Nikpay, S., (2023, August 19). Hacked to Pieces? The Effects of Ransomware Attacks on Hospitals
and Patients. SSRN. Retrieved from https://dx.doi.org/10.2139/ssrn.4579292.

(377) Health Care Industry Cybersecurity Task Force. (2017, June). Report on Improving Cybersecurity In The Health Care Industry.
Retrieved from https://nsarchive.gwu.edu/document/15310-health-care-industry-cybersecurity-task-force.

(378) Ghayoomi H, Laskey K, Miller-Hooks E, Hooks C, & Tariverdi M. (2021, November 29). Assessing resilience of hospitals to cyberattack.
DIGITAL HEALTH. doi:10.1177/20552076211059366.

(379) Cybersecurity and Infrastructure Security Agency. (2021, September). Provide Medical Care is in Critical Condition: Analysis
and Stakeholder Decision Support to Minimize Further Harm. Retrieved from https://www.cisa.gov/sites/default/files/publications/CISA_Insight_Provide_Medical_Care_Sep2021.pdf.

(380) See for example, Collier, K. (2023, June 12). An Illinois hospital is the first health care facility to link its closing to a
ransomware attack. Retrieved from https://www.nbcnews.com/tech/security/illinoishospital-links-closure-ransomware-attackrcna85983.

(381) Health Care Industry Cybersecurity Task Force. (2017, June). Report on Improving Cybersecurity In The Health Care Industry.
Retrieved from https://nsarchive.gwu.edu/document/15310-health-care-industry-cybersecurity-task-force.

(382) U.S. Government Accountability Office. (2022, July 19). Rising Cyberthreats Increase Cyber Insurance Premiums While Reducing
Availability. Retrieved from https://www.gao.gov/blog/rising-cyberthreats-increase-cyber-insurance-premiums-while-reducing-availability#:~:text=In%20our%202021%20report%2C%20we,instead%20offering%20cyber%20coverage%20separately.

(383) Under section 3000(5) of the PHSA, health IT is defined as “hardware, software, integrated technologies or related licenses,
intellectual property, upgrades, or packaged solutions sold as services that are designed for or support the use by health
care entities or patients for the electronic creation, maintenance, access, or exchange of health information.” ONC has adopted
this definition of health IT in 45 CFR 170.102.

(384) Centers for Medicare & Medicaid Services (2024). CMS Interoperability. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/interoperability/cms-interoperability.

(385) Standardized APIs enable one software applicable to access the services or data of another, securely and efficiently, without
human intervention.

(386) Office of the National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov Test Kits. Retrieved from https://inferno.healthit.gov/test-kits/.

(387) Office of the National Coordinator for Health IT. (2021, October 18). ONC-Approved Testing Partners. Retrieved from https://www.healthit.gov/topic/certification-ehrs/onc-approved-testing-partners.

(388) Tharp, L., & Rothblatt, Z. (2022). Do patients benefit from legislation regulating step therapy? Health Economics, Policy
and Law, 17(3), 282-297. doi:10.1017/S1744133121000153.

(389) Sachs, R. E., & Kyle, M. A. (2022). Step Therapy's Balancing Act—Protecting Patients while Addressing High Drug Prices. The
New England Journal of Medicine, 386(10), 901-904. doi.org/10.1056/NEJMp2117582.

(390) Hoffman, S. (2018). Step Therapy: Legal, Ethical, and Policy Implications of a Cost-Cutting Measure. Food and Drug Law Journal,
73(1), 38-65. Retrieved from https://www.jstor.org/stable/26661167.

(391) Tharp, L., & Rothblatt, Z. (2022). Do patients benefit from legislation regulating step therapy? Health Economics, Policy
and Law, 17(3), 282-297. doi:10.1017/S1744133121000153.

(392) Fischer, M. A., Kesselheim, A. S., Lu, Z., Ross, K. M., Tessema, F. A., & Avorn, J. (2019). Physician Perceptions of Step
Therapy Prescribing Requirements. Journal of Managed Care & Specialty Pharmacy, 25(11), 1210-1224. doi.org/10.18553/jmcp.2019.25.11.1210.

(393) Tharp, L., & Rothblatt, Z. (2022). Do patients benefit from legislation regulating step therapy? Health Economics, Policy
and Law, 17(3), 282-297. doi:10.1017/S1744133121000153.

(394) Centers for Medicare & Medicaid Services. (n.d.). WISeR (Wasteful and Inappropriate Service Reduction) Model. Retrieved from https://www.cms.gov/priorities/innovation/innovation-models/wiser.

(395) Centers for Medicare & Medicaid Services. (2025, June 2). Voluntary vs. Mandatory Participation. Retrieved from https://www.cms.gov/priorities/innovation/key-concepts/voluntary-vs-mandatory-participation.

(396) Henry, T.A. (2025, April 24). Fixing prior auth: First, speed up payers' response times. American Medical Association. Retrieved
from https://www.ama-assn.org/practice-management/prior-authorization/fixing-prior-auth-first-speed-payers-response-times#:~:text=Survey%20data%20from%202024%20has,a%20week%20for%20an%20answer.

(397) Careviso. (2025, February 24). How Long Does Prior Authorization Take? Retrieved from https://www.careviso.com/news-events/how-long-does-prior-authorization-take#:~:text=How%20Long%20Does%20Prior%20Authorization,potential%20for%20delays%20in%20care.

(398) Sparks, G., Montalvo III, J., Schumacher, S., Kirzinger, A., & Hamel, L. (2025, July 25). KFF Health Tracking Poll: Public
Finds Prior Authorization Process Difficult to Manage. KFF. Retrieved from https://www.kff.org/patient-consumer-protections/poll-finding/kff-health-tracking-poll-public-finds-prior-authorization-process-difficult-to-manage/.

(399) In the MA context, MA plans must allow laboratories to initiate prior authorization requests because a laboratory is a “provider”
that furnishes, or intends to furnish, services to the enrollee. See 42 CFR 422.566(c)(1)(ii).

(400) Office of Inspector General. (2022, April 27). Some Medicare Advantage Organization Denials of Prior Authorization Requests
Raise Concerns About Beneficiary Access to Medically Necessary Care. Retrieved from https://oig.hhs.gov/reports/all/2022/some-medicare-advantage-organization-denials-of-prior-authorization-requests-raise-concerns-about-beneficiary-access-to-medically-necessary-care/.

(401) Centers for Medicare & Medicaid Services. (2024, September 10). Laboratory Date of Service Policy. Retrieved from https://www.cms.gov/medicare/payment/fee-schedules/clinical-laboratory-fee-schedule-clfs/date-service-policy.

(402) The DOS policy was established in the “Medicare Program; Revisions to Payment Policies, Five-Year Review of Work Relative
Value Units, Changes to the Practice Expense Methodology Under the Physician Fee Schedule, and Other Changes to Payment Under
Part B; Revisions to the Payment Policies of Ambulance Services Under the Fee Schedule for Ambulance Services; and Ambulance
Inflation Factor Update for CY 2007” final rule (71 FR 69624), which appeared in the
Federal Register
on December 1, 2006, and is set forth in 42 CFR 414.510.

(403) See 42 CFR 422.138(b)(1) and (2).

(404) See 42 CFR 422.568(b)(1)(ii) for MA organizations, 42 CFR 422.631(d)(2)(i)(B) (2) for applicable integrated plans, 42 CFR 440.230(e)(1)(i) for state Medicaid FFS programs, 42 CFR 457.495(d)(2)(i) for state
CHIP FFS programs, 42 CFR 438.210(d)(1)(i)(B) for Medicaid managed care plans, and through cross reference to 42 CFR 438.210
in 42 CFR 457.1230(d) for CHIP managed care entities.

(405) Clinician Task Force and National Coalition for Assistive and Rehab Technology. (2021, July). Evidence‐Based Response to
Insurance Denials of Standing Devices, Medical Benefits, Evidence, and Coverage Guidelines. Retrieved from https://www.ncart.us/uploads/userfiles/files/documents/Evidence%20and%20Guidance%20Supporting%20Coverage%20of%20Standing%20Devices-%20July%202021%20(2).pdf.

(406) Mock, J.V., National Seating & Mobility. (2022, May 3). Tips to Overcome Documentation Burnout. Retrieved from https://www.nsm-seating.com/journal/tips-to-overcome-documentation-burnout/.

(407) U.S. Bureau of Labor Statistics. (2024, May). National Occupational Employment and Wage Estimates. Retrieved from https://data.bls.gov/oes/#/industry/000000.

(408) A parent organization, also known as a parent company or parent corporation, is an organization that has a controlling interest
in another company, giving it control of its operations. Specifically, a parent organization is any corporation (other than
the employer corporation) in an unbroken chain of corporations ending with the employer corporation if, at the time of granting
of the option, each of the corporation's other employer corporation owns stock possessing 50 percent or more of the total
combined voting power of all classes of stock in one of the other corporations in such chain (see 26 U.S.C. 424(e)).

(409) Centers for Medicare & Medicaid Services. (2024). MA Plan Directory. Retrieved from https://www.cms.gov/files/zip/ma-plan-directory-march-2024.zip.

(410) Centers for Medicare & Medicaid Services. (2023, July 21). Managed Care Enrollment by Program and Plan. Retrieved from https://data.medicaid.gov/dataset/0bef7b8a-c663-5b14-9a46-0b5c2b86b0fe/data?conditions%5b0%5d%5bproperty%5d=year&conditions%5b0%5d%5bvalue%5d=2021&conditions%5b0%5d%5boperator%5d=%3D.

(411) Centers for Medicare & Medicaid Services. (2024, May 08). QHP Landscape PY2024 Individual Medical. Retrieved from https://data.healthcare.gov/dataset/2cfb30f4-7c65-42bd-bc4c-a3fbcf1cb2cd.

(412) The term “state” means the 50 states, the District of Columbia, Puerto Rico, the Virgin Islands, Guam, American Samoa, and
the Northern Mariana Islands (see 42 U.S.C. 11151(13)).

(413) We provide a detailed rationale for how we determined the number of impacted payers in the CMS Interoperability and Patient
Access final rule (85 FR 25622-25623). In that analysis we determined that 288 issuers and 56 states, territories, and U.S.
commonwealths, which operate state Medicaid and CHIP FFS programs, will be subject to the API provisions for Medicare, Medicaid,
and the individual market. To this, we added the one state that operates its CHIP and Medicaid separately. Thus, we have 345
total impacted payers (288 + 56 + 1). This number has been updated to 341 to reflect a consolidation of impacted payers in
the impacted programs.

(414) See 45 CFR 160.103.

(415) See the 2024 CMS Interoperability and Prior Authorization final rule for detailed discussion on how API availability would yield
efficiency benefits for providers and impacted payer (89 FR 8758).

(416) United States Census Bureau. (2025, August 4). 2022 SUSB Annual Data Tables by Establishment Industry. Retrieved from https://www.census.gov/data/tables/2022/econ/susb/2022-susb-annual.html; SUSB data include number of firms, number of establishments, employment, annual payroll, and receipts for most U.S. business
establishments. The data are tabulated by geographic area, industry, and enterprise employment or receipts size. The industry
classification is based on 2017 NAICS codes.

(417) Office of the National Coordinator for Health Information Technology. (2022, April). Adoption of Electronic Health Records
by Hospital Service Type 2019-2021, Health IT Quick Stat #60. Retrieved from https://www.healthit.gov/data/quickstats/adoption-electronic-health-records-hospital-service-type-2019-2021.

(418) Office of the National Coordinator for Health Information Technology. (2021, July 29). The Heat is On: US Caught FHIR in
2019. Retrieved from https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019.

(419) Office of the National Coordinator for Health Information Technology. (2021, July 29). The Heat is On: US Caught FHIR in
2019. Retrieved from https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019.

(420) Bendersky, A. (2025, July 11). Guide to the Cost of EHR Implementation for Healthcare Providers. Sprypt. Retrieved from https://www.sprypt.com/blog/guide-to-the-cost-of-ehr-implementation-for-healthcare-providers.

(421) Office of the National Coordinator for Health Information Technology. (2025, August 11). Section 2: Certified Health IT.
ASTP Health IT Playbook. (2025, August 11). Retrieved from https://www.healthit.gov/playbook/certified-health-it/.

(422) Kalinin, K. (2025, May 8). EHR Implementation Cost Breakdown: Factors Affecting the Price in 2025. Topflight. Retrieved from https://topflightapps.com/ideas/cost-of-ehr-implementation/.

(423) Office of the National Coordinator for Health Information Technology. (2022, April). Adoption of Electronic Health Records
by Hospital Service Type 2019-2021. Health IT Quick Stat #60. Retrieved from https://www.healthit.gov/data/quickstats/adoption-electronic-health-records-hospital-service-type-2019-2021.

(424) Office of the National Coordinator for Health Information Technology. (2021, July 29). The Heat is On: US Caught FHIR in
2019. Retrieved from https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019.

(425) United States Census Bureau. (2025, April). 2022 SUSB Annual Data Tables by Establishment Industry. Retrieved from https://www.census.gov/data/tables/2022/econ/susb/2022-susb-annual.html.

(426) Office of the National Coordinator for Health Information Technology. (2025, August 11). Section 2: Certified Health IT.
ASTP Health IT Playbook. Retrieved from https://www.healthit.gov/playbook/certified-health-it/.

(427) Bendersky, A. (2025, July 11). Guide to the Cost of EHR Implementation for Healthcare Providers. Sprypt. Retrieved from https://www.sprypt.com/blog/guide-to-the-cost-of-ehr-implementation-for-healthcare-providers.

(428) Kalinin, K. (2025, May 8). EHR Implementation Cost Breakdown: Factors Affecting the Price in 2025. Topflight. Retrieved from https://topflightapps.com/ideas/cost-of-ehr-implementation/.

(429) United States Census Bureau. (2025, April). 2022 SUSB Annual Data Tables by Establishment Industry. Retrieved from https://www.census.gov/data/tables/2022/econ/susb/2022-susb-annual.html.

(430) These impacted payers include MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed
care entities, and QHP issuers on the FFEs.

(431) See the 2020 CMS Interoperability and Patient Access final rule (85 FR 25623) for information on the methodology used to define
and identify parent organizations.

(432) Council for Affordable Quality Healthcare. (2024). 2024 CAQH Index Report. Retrieved from https://www.caqh.org/hubfs/Index/2024%20Index%20Report/CAQH_IndexReport_2024_FINAL.pdf.

(433) Health Level Seven International. (2024, November 12). Da Vinci Project Confluence: Da Vinci HIPAA/HL7 FHIR Exception Approval
Letter. Retrieved from https://confluence.hl7.org/spaces/DVP/pages/113675673/Da+Vinci+HIPAA+Exception?preview=/113675673/113675685/Approval%20%232021031001.pdf.

(434) NAICS Codes for Plan Management System Vendors (541611) and All Other Support Services (561990) reflect the entire industry
of establishments engaged in providing operating and administrative support but is not limited to health care industry specific
firms.

(435) Smith, T. (2025, January 22). Who are the largest EHR vendors? EHR In Practice. Retrieved from https://www.ehrinpractice.com/largest-ehr-vendors.html.

(436) Newman, D. (2024, December 9). Top EHR Vendors 2025-Epic, Cerner/Oracle, Meditech, Allscripts. Healthcare IT Skills. Retrieved
from https://healthcareitskills.com/top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/.

(437) Newman, D. (2024, December 9). Top EHR Vendors 2025-Epic, Cerner/Oracle, Meditech, Allscripts. Healthcare IT Skills. Retrieved
from https://healthcareitskills.com/top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/.

(438) Office of the National Coordinator for Health Information Technology. (2025, August). Certified Health IT Developers Reported
by Clinicians Reporting for Promoting Interoperability Health IT

  Quick Stat #30. Retrieved from *https://www.healthit.gov/data/quickstats/health-care-professional-certified-health-it-developers.*

(439) MediBill RCM LLC. (2025, April 23). How Medical Billing Clearinghouses Work? A Deep Dive into Claim Submission & Processing.
MediBill RCM LLC. Retrieved from https://www.medibillrcm.com/blog/how-medical-billing-clearinghouses-work/.

(440) Health Level Seven International. (2026, March 27). Da Vinci—Coverage Requirements Discovery (CRD) IG. Retrieved from https://hl7.org/fhir/us/davinci-crd/2.2.1/en/.

(441) Health Level Seven International. (2026, March 27). Da Vinci—Documentation Templates and Rules (DTR) IG. Retrieved from https://hl7.org/fhir/us/davinci-dtr/2.2./en/0.

(442) Health Level Seven International. (2026, March 27). Da Vinci—Prior Authorization Support (PAS) IG. Retrieved from https://hl7.org/fhir/us/davinci-pas/2.2.1/en/.

(443) See section III.B.2. on the SMART App Launch 2.2 in the HTI-2 proposed rule at https://www.federalregister.gov/d/2024-14975/p-2093.

(444) Centers for Medicare & Medicaid Services. (2024). Public Use File for 2022. Retrieved from https://www.cms.gov/files/zip/mlr-public-use-file-2022.zip.

(445) Medicaid and CHIP patients may pay premiums under certain circumstances.

(446) Centers for Medicare & Medicaid Services. (2025, August 04). Trustees Report & Trust Funds. Retrieved from https://www.cms.gov/data-research/

(447) U.S. Department of Health and Human Services. (2024, August 21). Fiscal Year 2025 Budget in Brief. Retrieved from https://us.pagefreezer.com/en-US/wa/browse/0a7f82bb-be6e-448a-ae11-373d22c37842?url=https:%2F%2Fwww.hhs.gov%2Fabout%2Fbudget%2Ffy2025%2Findex.html&timestamp=2025-02-24T07:03:59Z.

(448) U.S. Bureau of Labor Statistics. (2025, July 23). Occupational Employment and Wage Statistics. Retrieved from https://www.bls.gov/oes/current/oes_nat.htm.

(449) Cost associated with the proposal to incorporate into the Prior Authorization API coverage and documentation requirements
to support electronic prior authorization for drugs covered under a medical benefit are estimated to be approximately $45,011.14
per impacted payer for a one-time implementation cost.

(450) Centers for Medicare & Medicaid Services. (2025, June 23). HHS Secretary Kennedy, CMS Administrator Oz Secure Industry Pledge
to Fix Broken Prior Authorization System. Retrieved from https://www.cms.gov/newsroom/press-releases/hhs-secretary-kennedy-cms-administrator-oz-secure-industry-pledge-fix-broken-prior-authorization.

(451) AHIP. (2026). Health plans are making voluntary commitments to support patients and providers. Retrieved from https://www.ahip.org/health-plans-are-making-voluntary-commitments-to-support-patients-and-providers.

(452) Office of Management and Budget. (2003). Circular A-4. Retrieved from https://www.reginfo.gov/public/jsp/Utilities/a-4.pdf.

(453) A parent organization, also referred to as a parent company or parent corporation, is an organization that has a controlling
interest in another company, giving it control of its operations (see 26 U.S.C. 424(e)).

(454) U.S. Small Business Administration. (2024, October 15). Size Standards Tool. Retrieved from https://www.sba.gov/federal-contracting/contracting-guide/size-standards/size-standards-tool.

(455) Centers for Medicare & Medicaid Services. (2026). Medicaid Managed Care Enrollment and Program Characteristics 2024. Retrieved
from https://www.medicaid.gov/medicaid/managed-care/downloads/2024-medicaid-managed-care-enrollment-report.pdf.

(456) U.S. Small Business Administration. (2024, October 15). Size Standards Tool. Retrieved from https://www.sba.gov/federal-contracting/contracting-guide/size-standards/size-standards-tool.

(457) Centers for Medicare & Medicaid Services. (n.d.). Medical Loss Ratio Data and System Resources. Retrieved from https://www.cms.gov/CCIIO/Resources/Data-Resources/mlr.html.

(458) Based on internal calculations. Source: Centers for Medicare & Medicaid Services. (2025, November 21). Medical Loss Ratio
Data and System Resources. Retrieved from https://www.cms.gov/CCIIO/Resources/Data-Resources/mlr.html.

(459) The National Committee on Vital and Health Statistics. (2020, August 20). NCVHS Subcommittee on Standards Comments Received
in Response to Request for Comment on the on Proposed CAQH CORE Operating Rules. Retrieved from https://ncvhs.hhs.gov/wp-content/uploads/2020/08/Comments-CAQH%20CORE%20Proposed%20Operating%20Rules%20for%20Federal%20Adoption%20508.pdf.

(460) NAICS Codes for Plan Management System Vendors (541611) and All Other Support Services (561990) reflect the entire industry
of establishments engaged in providing operating and administrative support but is not limited to health care industry specific
firms.

(461) Smith, T. (2025, January 22). Who are the largest EHR vendors? EHR In Practice. Retrieved from https://www.ehrinpractice.com/largest-ehr-vendors.html.

(462) Newman, D. (2024, December 9). Top EHR Vendors 2025-Epic, Cerner/Oracle, Meditech, Allscripts. Healthcare IT Skills. Retrieved
from https://healthcareitskills.com/top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/.

(463) Newman, D. (2024, December 9). Top EHR Vendors 2025-Epic, Cerner/Oracle, Meditech, Allscripts. Healthcare IT Skills. Retrieved
from https://healthcareitskills.com/top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/.

(464) Office of the National Coordinator for Health Information Technology. (2025, August). Certified Health IT Developers Reported
by Clinicians Reporting for Promoting Interoperability Health IT Quick Stat #30. Retrieved from https://www.healthit.gov/data/quickstats/health-care-professional-certified-health-it-developers.

(465) The total cost $40.88 million includes the total annualized cost of the proposed policies and the annualized regulatory review
cost ($40.68 + $0.20 = $40.88).

(466) 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.

Download File

Download