Medicare and Medicaid Interoperability Standards and Prior Authorization for Drugs

Proposed Rule

Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability Standards and Prior Authorization for Drugs for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges

A Proposed Rule by the Centers for Medicare & Medicaid Services on 04/14/2026

• This document has a comment period that ends in 62 days.
  (06/15/2026) Submit a public comment

• PDF

• Document Details

• Document Dates

- Table of Contents

• Public Comments
• Regulations.gov Data

- Sharing

• Print
• Other Formats
• Public Inspection Published Document: 2026-07205 (91 FR 19890) Document Headings ###### Department of Health and Human Services

Centers for Medicare & Medicaid Services

Office of the Secretary

1. 42 CFR Parts 403, 422, 431, 438, 440, and 457
2. 45 CFR Parts 156, 162, and 170
3. [CMS-0062-P]
4. RIN 0938-AV44 ( printed page 19890) # AGENCY:

Centers for Medicare & Medicaid Services (CMS) and Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS).

ACTION:

Proposed rule.

SUMMARY:

These proposals are intended to improve the electronic exchange of health care data and streamline processes related to prior authorization by increasing the interoperability of systems used across the health care industry. We are proposing new requirements for Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs), including issuers that offer small group market QHPs on the Federally-facilitated Small Business Health Options Program (FF-SHOP) Exchanges (hereinafter referred to as “small group market QHP issuers on the FF-SHOPs”) (collectively “impacted payers”), to make available electronic prior authorization for drugs. We are also proposing to extend many existing interoperability requirements for the prior authorization of non-drug items and services to include prior authorizations for drugs to further reduce patient and provider burden.

We are also proposing to require impacted payers to report their application programming interfaces (API) endpoints and related information for the Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization APIs to CMS. To help assess the impact of our policies, we are proposing to collect API usage metrics. In addition, we are proposing to apply the existing interoperability requirements to small group market QHP issuers on the FF-SHOPs as impacted payers. To improve impacted payers' ability to exchange health information while continuing CMS's drive toward interoperability, we are proposing to require certain Health Level Seven (HL7®) 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 ( printed page 19891)

C. Specific Terms Used in this Proposed Rule

D. Severability

II. Provisions of the Proposed Rule

A. Interoperability Standards for APIs

B. Electronic Prior Authorization for Drugs

C. Improving Communications and Decision Timeframes for Prior Authorizations

D. Requirements for Issuers That Offer Small Group Market Qualified Health Plans on the Federally-facilitated Small Business Health Options Program Exchanges

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

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

G. Open Payments Civil Monetary Penalties

H. Modifications to HIPAA Standards Related to Prior Authorization

J. Adoption of Health Information Technology Standards and Incorporation by Reference

III. Requests for Information

A. Electronic Event Notifications for Value-Based Care and Care Coordination

B. Increasing Health Care Resiliency

C. Improving Implementation of Payer Application Programming Interface Technology

D. Step Therapy

E. Laboratory Tests and Durable Medical Equipment, Prosthetics, Orthotics, and Supplies Items

IV. Collection of Information Requirements

V. Regulatory Impact Analysis

VI. Response to Comments

Regulation Text

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

A. Purpose and Background

The “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for MA Organizations and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers” final rule (85 FR 25510) (hereinafter referred to as the “2020 CMS Interoperability and Patient Access final rule”) appeared in the Federal Register on May 1, 2020. That rule was the first phase of CMS's interoperability rulemaking and focused on giving patients access to their health data maintained by their payer through a Patient Access API. In that rule, we required MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and issuers that offer individual market QHPs on the FFEs (hereinafter referred to as “individual market QHP issuers on the FFEs”) to implement a Patient Access API that allows patients, through health apps with the necessary functionality, to easily access their claims and encounter information, provider remittances, patient cost-sharing information, and clinical data, including laboratory results, maintained by the impacted payer. [1 ]

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 ( printed page 19892) commenters suggested modeling requirements for the other types of impacted payers on the existing Part D requirements in 42 CFR 423.160, as established in the “Medicare Program; Secure Electronic Prior Authorization for Medicare Part D” final rule (85 FR 86824) (hereinafter referred to as the “2020 Medicare Part D ePA final rule”), which appeared in the Federal Register on December 31, 2020.

The 2024 CMS Interoperability and Prior Authorization final rule also established, improved, or shortened prior authorization timeframes for impacted payers other than QHP issuers on the FFEs (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities) to respond to prior authorization requests for non-drug items and services. Specifically, we finalized timeframes of 7 calendar days for standard requests and 72 hours for expedited requests, with the possibility of an extension of up to 14 days in certain circumstances (89 FR 8878). For Medicaid and CHIP, state law may establish a shorter timeframe. [3 ] Some of the payers affected by those requirements had existing timeframes for prior authorization decisions, notices, and appeals that differed, so we aligned the prior authorization decision timeframes across impacted payers, except for QHP issuers on the FFEs (89 FR 8878). As discussed in the 2022 CMS Interoperability and Prior Authorization proposed rule and the 2024 CMS Interoperability and Prior Authorization final rule, we did not propose prior authorization decision timeframes for QHP issuers on the FFEs, in part because existing regulations in 45 CFR 147.136 already establish internal claims and appeals processes, external review processes, and pre-service claims (prior authorization) requirements for all non-grandfathered group and individual market plans or coverage (87 FR 76297 and 89 FR 8879). Specifically, 45 CFR 147.136(b)(3) specifies that individual market QHP issuers on the FFEs are generally subject to requirements of the Employee Retirement Income Security Act of 1974 (hereinafter referred to as “ERISA”) (Pub. L. 93-406, enacted September 2, 1974) and internal claims and appeals procedures applicable to group health plans under 29 CFR 2560.503-1 as if the issuer were a group health plan. Thus, QHP issuers on the FFEs are required to provide notification of a plan's benefit determination for pre-service claims to enrollees within a reasonable period of time appropriate to the medical circumstances, but not later than 15 days for standard prior authorization decisions, and as soon as possible, taking into account the medical exigencies, but not later than 72 hours for expedited requests. The latter is a similar timeframe for notices to enrollees for expedited authorization decisions as finalized for other impacted payers (89 FR 8880).

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 ( printed page 19893) under a pharmacy benefit. Therefore, these sets of FHIR and NCPDP standards are mutually exclusive and, when used in conjunction, encompass the full scope of drugs that are covered by any particular payer. We propose that impacted payers be required to support electronic prior authorization for all drugs through the Prior Authorization API and NCPDP standards beginning on October 1, 2027.

Our proposals regarding the prior authorization of drugs are similar to the provisions finalized for non-drug items and services in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8897) but with special consideration to existing policies, operational processes, and standards for the electronic prior authorizations of drugs. The proposals would require impacted payers to support electronic prior authorization for all drugs, which should improve the process for impacted payers' patients and providers. In section II.A. of this proposed rule, we describe each of these standards and how they would be used. In section II.B. of this proposed rule, we describe our proposals as they apply to each category of impacted payer, including program specifics as to distinction of drugs covered under medical benefits versus drugs covered under pharmacy benefits.

For the proposed requirement to incorporate drugs covered under a medical benefit into the Prior Authorization API, we are proposing an October 1, 2027 compliance date. As discussed in section II.B.3. of this proposed rule, incorporating drugs into Prior Authorization APIs means that, using the proposed standards, information is available through the API as to whether prior authorization is required for drugs covered under a medical benefit, the coverage and documentation requirements for prior authorization are available, and that the API can transmit prior authorization requests and decisions between providers and the payer.

Medicare Part D sponsors (including MA organizations that offer a Medicare Advantage Prescription Drug [MA-PD] plan) are already required, in 42 CFR 423.160(b)(1), to use an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) as part of their electronic prescription drug programs. Prescribers and dispensers are also required to use an adopted version of the NCPDP SCRIPT standard when electronically transmitting prescriptions and prescription-related information for covered Part D drugs for Part D-eligible individuals. Similarly, beginning January 1, 2027, Part D sponsors are required, in 42 CFR 423.160(b)(3) and (b)(5), to implement for uses described in those paragraphs unexpired versions of the NCPDP F&B and RTPB standards adopted by the Secretary in 45 CFR 170.205(u) and 45 CFR 170.205(c), respectively.

We propose that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, including small group market QHP issuers on the FF-SHOPs, similarly could use any unexpired version of the NCPDP standards adopted by the Secretary in 45 CFR 170.205(b), (c), and (u) to support electronic prior authorization of drugs covered under a pharmacy benefit. We are proposing an October 1, 2027 compliance date to support the proposed NCPDP standards to facilitate electronic prior authorization of drugs covered under a pharmacy benefit.

Consistent with section 3004(b)(3) of the PHSA, the Secretary adopts standards for HHS use, including those adopted in 45 CFR 170.215. We are proposing to require impacted payers to implement and maintain their required FHIR APIs in conformance with certain applicable standards adopted in 45 CFR 170.215, without specifying versions of each required standard, which would allow impacted payers to use unexpired versions of the required standards, as the Secretary adopts updated versions in 45 CFR 170.215. Where more than one unexpired version of a standard is adopted in 45 CFR 170.215, impacted payers would be able to use any of the unexpired standards, allowing for transition periods as updated versions are adopted by the Secretary and older versions expire. To support interoperability, these proposals require impacted payers to implement and maintain API technology conformant with certain IGs that were recommended in the 2024 CMS Interoperability and Prior Authorization final rule, as applicable to each interoperability API (89 FR 8945). We are proposing an October 1, 2027 compliance date to implement the proposed standards. We are also recommending additional IGs for some of the APIs that could be used to support certain use cases.

We are proposing to replace the policy finalized in the 2024 CMS Interoperability and Prior Authorization final rule that allows states with small FFS populations to request an exemption from CMS for the non-drug items and services Prior Authorization API requirements with a policy that would allow all state Medicaid and CHIP FFS programs to request extensions to the compliance date for that requirement. We are proposing that those extensions would only be available until the compliance date for the HIPAA Administrative Simplification proposals in this rule, if the proposals are finalized. In addition, we are proposing a process for state Medicaid and CHIP FFS programs to request from CMS extensions to allow additional time to meet the proposed requirement to incorporate drugs covered under a medical benefit into the Prior Authorization API and the proposed requirement to support the NCPDP standards for electronic prior authorization of drugs covered under a pharmacy benefit, if they meet certain criteria. We are also proposing that QHP issuers on the FFEs be permitted to request an exception from the requirement to support electronic prior authorization of drugs covered under a pharmacy benefit through the proposed NCPDP standards, as part of the annual QHP certification process. Issuers could seek an exception by submitting a narrative justification with information specified in 45 CFR 156.223(h), including why the QHP issuer on the FFEs cannot reasonably satisfy the requirements for the applicable plan year. [5 ] Those proposals are similar to the exception policies finalized in the 2024 CMS Interoperability and Prior Authorization final rule and are discussed in section II.B.7. of this proposed rule. [6 ]

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 ]

( printed page 19894) For state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities, the timeframes for making decisions on prior authorization requests for covered outpatient drugs is 24 hours. [8 ] However, the term “covered outpatient drugs” does not apply to all drugs that are covered by states for which states receive Federal Financial Participation (FFP) from CMS. Therefore, we are requesting comment to identify whether there are drugs for which a prior authorization timeframe does not currently exist and needs to be established. If there are gaps identified in the prior authorization decision timeframe requirements for drugs, in order to align patient protections and create consistent requirements across the Medicaid and CHIP programs, we propose to require state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities to provide notice of prior authorization decisions for drugs within a timeframe that aligns with applicable existing decision timeframe requirements. We are proposing an October 1, 2027 compliance date. In addition, we are proposing to require state CHIP FFS programs to make decisions on prior authorization requests for prescription drugs for which the state receives FFP no later than 24 hours after receiving a prior authorization request, rather than the current requirements that cover both drugs and non-drug items and services. We are proposing an October 1, 2027 compliance date.

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 ( printed page 19895) each rating period no later than 90 days after the end of each rating period. We are proposing that QHP issuers on the FFEs report their API usage metrics as aggregated, de-identified data at the issuer level in the form and manner and within the timeframes specified by the Secretary, as we are proposing to amend the deadline for Patient Access API usage metrics. For these proposals, we propose compliance dates beginning in 2028.

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 ( printed page 19896) to meet the requirements proposed in section II.D. of this proposed rule (requirements for small group market QHP issuers on the FF-SHOPs), and vice versa?

To support implementation of the policies finalized in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules, we propose to require impacted payers to report their API endpoints for each of the required APIs to CMS. In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, we received numerous comments from the public indicating that a centralized directory of API endpoints would be necessary to unlock the full potential of our electronic data exchange policies and reduce administrative burden (89 FR 8932). For instance, a centralized directory of API endpoints could help providers locate a payer's Provider Access API to request patient data or Prior Authorization API to submit a prior authorization request. In addition, payers will need to discover each other's API endpoints to exchange data via the Payer-to-Payer API. Commenters emphasized that there would be a significant burden if payers' API endpoints had to be found individually rather than being listed in a centralized directory. Therefore, we are proposing to require impacted payers to report their Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization API endpoints and related information to CMS no later than 60 days after the effective date of a final rule, in a manner to be determined. We are also proposing that new impacted payers be required to report this information no later than 60 days before they begin covering patients under the applicable CMS program.

To ensure that patients, providers, and other payers can have complete and appropriate access to information about prior authorizations, we are proposing to require impacted payers to make information about prior authorization requests and decisions for all drugs available to patients via the Patient Access, Provider Access, and Payer-to-Payer APIs (collectively “Access APIs”). For the Patient Access and Provider Access APIs, this includes, as applicable, the status of the prior authorization; the date the prior authorization was approved or denied; the date or circumstance under which the authorization ends; the drug or drugs approved (including the dosage); if the prior authorization was denied, a specific reason why the request was denied; and related structured administrative and clinical documentation submitted by a provider. For the Payer-to-Payer API, that includes, as applicable, the status of the prior authorization; the date the prior authorization was approved; the date or circumstance under which the authorization ends; the drugs or drugs approved (including the dosage); and related structured and unstructured administrative and clinical documentation submitted by a provider, excluding denied prior authorization requests. We are proposing an October 1, 2027 compliance date for these proposals.

In addition, we are proposing to add a definition for “failure to report” in 42 CFR 403.902 to support the Open Payments program. The Open Payments program, mandated by section 1128G of the Social Security Act (hereinafter referred to as “the Act”) and codified in 42 CFR 403.900 through 403.914, requires the pharmaceutical and medical device industry to submit information about certain payments or other transfers of value made to certain types of health care providers. This proposal would allow CMS to impose a CMP on applicable manufacturers or applicable GPOs if those entities fail to grant CMS timely access to documents for the purposes of an audit authorized by 42 CFR 402.912(e)(2). We propose this definition be effective beginning on the effective date of the final rule.

Under the Administrative Simplification provisions of HIPAA (Part C of Title XI of the Act), HHS is proposing to adopt the FHIR standard and certain associated IGs as the standards for dental, professional, and institutional “referral certification and authorization” transactions and “eligibility for a health plan” transactions associated with prior authorization. Specifically, in addition to the FHIR standard, HHS is proposing to adopt the HL7 FHIR US Core (US Core), HL7 Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Framework (SMART App Lauch), CRD, DTR, and PAS IGs in place of the adopted versions of the X12N 278 Health Care Services Review—Request for Review and Response transaction standard (X12N 278 transaction standard) in 45 CFR 162.1302 and the existing X12N 270/271 Health Care Eligibility Benefit Inquiry and Response transaction standard (X12N 270/271 transaction standard) in 45 CFR 162.1202 for transactions related to prior authorization. Additionally, HHS is proposing to adopt the HL7 FHIR Da Vinci Clinical Data Exchange (CDex) IG in 45 CFR 162.1302(g)(2)(vii) as the attachment standard for prior authorization transactions. The proposals to adopt the FHIR standards would only apply to dental, professional, and institutional transactions, not to those for retail pharmacy drugs, which are currently required to be conducted using NCPDP standards. HHS proposes a compliance date for these HIPAA Administrative Simplification proposals 24 months after the effective date of a final rule, except for small health plans, for which HHS proposes a compliance date 36 months after the effective date of a final rule. HHS is making these proposals after evaluating the results of the exception from the currently adopted standards granted to the HL7 Da Vinci Project, as provided in 45 CFR 162.940, to test FHIR standards. [13 ]

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 ( printed page 19897) certification, using technology to manage step therapy, and prior authorization requirements for laboratory tests and durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS) items.

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

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

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

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

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

C. Specific Terms Used in This Proposed Rule

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

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

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

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

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

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

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

Many of the existing and proposed interoperability standards are based on API technology. An API is a set of rules that lets different software systems communicate with each other. It defines how one program (a client, often an app) can request data or services from another system (a server), and how the response should be structured. APIs are commonly used to connect apps. For example, a health app can use an API implemented within a payer's system to request and receive a specific patient's data. This allows developers to build on and communicate with existing systems without needing to understand their internal workings. APIs are essential for building modern, integrated digital experiences in a variety of industries, including health care, banking, and e-commerce. [17 ]

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 ( printed page 19900) propose that the provision would be severable from the other provisions of this rulemaking and would not affect the remainder thereof or the application of the provision to persons not similarly situated or to dissimilar circumstances.

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

II. Provisions of the Proposed Rule

A. Interoperability Standards for APIs

1. Background

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

• Health Level Seven (HL7®) 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 ( printed page 19901) updated version if required by other applicable law. [22 ] Under these provisions, impacted payers may upgrade to newer versions of the required standards, subject to the specified limiting conditions (85 FR 25532 and 89 FR 8946).

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 ( printed page 19902) example, NCPDP SCRIPT).” [26 27 ] That directive is intended to differentiate the scope of the FHIR IGs for prior authorization from the scope of the NCPDP SCRIPT standard, which is used for prior authorization of drugs under a pharmacy benefit.

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:

( printed page 19903)

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 ( printed page 19904) has been certified to certain ONC health IT certification criteria, adopted in 45 CFR 170.315, as necessary to report on objectives and measures in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. To complete the measures under the Electronic Prescribing objectives in those programs, eligible hospitals, CAHs, and MIPS eligible clinicians must use CEHRT certified to the “electronic prescribing” criterion in 45 CFR 170.315(b)(3). [31 ] Once their Health IT Module is certified to the “electronic prescribing” criterion finalized in the HTI-4 final rule, to complete the relevant measure requirements, participants in these programs are required to meaningfully use certified health IT capable of electronic prior authorization for prescription drugs using the NCPDP SCRIPT standard version 2023011 by January 1, 2028.

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 ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Required Standards for FHIR APIs

a. Modification to Required Standards for FHIR APIs

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Requiring Additional Implementation Guides to Support Interoperability APIs

a. Description of the Implementation Guides

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

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

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

( printed page 19907)

(2) HL7 FHIR Da Vinci PDex Implementation Guide

The HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG [36 ] facilitates the creation and exchange of a patient's health history using clinical data (based on US Core Profiles established from FHIR R4) in a manner that allows providers to integrate the data received into their EHRs. The PDex IG supports sharing of payer data through a more clinical perspective, in line with the United States Core Data for Interoperability (USCDI) and US Core IG, than a financial perspective as is done with the CARIN IG for Blue Button. However, the PDex IG does include information about prior authorizations that impacted payers are required to make available by the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8758). The PDex IG can support all the required data elements for prior authorization data exchange, though we note that the PDex IG enhancements to support payer to payer bulk data exchange, payer to provider exchange, and explanation of benefits are currently in draft form and have not appeared in ballot, but have been tested at multiple Connectathons. The PDex IG has been updated to support newer versions of the US Core IG, including versions 6.1.0 and 7.0.0. As of the date this proposed rule appears in the Federal Register, the most recently published and adopted version is the PDex IG, Version 2.1.0—STU 2.1.

(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 ( printed page 19908) 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 ( printed page 19909) Interoperability and Prior Authorization final rule, we finalized a requirement that, beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must include certain information about prior authorizations for non-drug items and services in the data that are available through the Patient Access API (89 FR 8768). [48 ] In that 2024 final rule, we also finalized a requirement that impacted payers must implement and maintain their Patient Access APIs conformant with standards in 45 CFR 170.215, including FHIR, US Core IG, SMART App Launch IG, and the OpenID Connect Core 1.0.

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 ( printed page 19910) exchange requirement includes adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard (USCDI) in 45 CFR 170.213, and certain information about prior authorizations for non-drug items and services. [54 ]

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 ( printed page 19911) PDex IG adopted by the Secretary for their Payer-to-Payer API.
• The proposal to require impacted payers to use an unexpired version of the CRD, DTR, and PAS IGs adopted by the Secretary for their Prior Authorization API.
• The alternative proposal to require impacted payers to use an unexpired version of the PDex US Drug Formulary IG adopted by the Secretary, if the drug formulary data requirement is retained, for impacted payers' Provider Access and Payer-to-Payer API.
• The proposed October 1, 2027 compliance date for the proposed requirements for impacted payers.

c. Using Testing Tools To Ensure Conformance With Implementation Guides

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

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

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 ( printed page 19913) IG provides for client registration, authentication, and authorization, the entity that performs the registration must have a “trust relationship” established.

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

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

( printed page 19914)

( printed page 19915)

( printed page 19916)

( printed page 19917)

( printed page 19918)

( printed page 19919)

( printed page 19920)

( printed page 19921)

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). ( printed page 19922)

In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, we received numerous comments requesting that we reconsider the exclusion of drugs from the proposed requirements. Those comments stated that providers face similar challenges with prior authorizations for drugs as with non-drug items and services, and that the current prior authorization processes sometimes delay access to medically necessary drug treatments. Commenters noted that the inconsistent use of technology and standards can create barriers to care and burden both providers and payers. For example, providers are sometimes unaware that a prior authorization is required until a payer rejects a prescription claim presented to a pharmacy, which causes delays for patients to receive necessary medication and affects the provider's ability to timely identify and prescribe an alternative medication. In many cases, providers still have to use fax, telephone, or payer-specific web portals for drug prior authorizations. While portals are used for data entry, they typically do not provide immediate feedback to providers about prior authorization requirements or accept supporting documentation, nor do they provide real time responses. Thus, current methods can be inefficient and create additional process challenges (89 FR 8765-8766).

Many commenters, including payers and providers, advocated that prior authorization for drugs could and should be incorporated into the Prior Authorization API. Commenters specifically emphasized the need for more streamlined electronic prior authorization processes for drugs administered in a medical setting, such as infusions, oral cancer drugs, oral antiemetics, and drugs for terminal or chronic conditions, such as cancer or multiple sclerosis. Other commenters pointed to existing rules that require Medicare Part D sponsors to offer electronic prior authorization for covered Part D drugs via a standard adopted by the Secretary, which includes NCPDP SCRIPT standard versions 2017071 and 2023011, adopted in 45 CFR 170.205(b)(1) and 45 CFR 170.205(b)(2) (89 FR 8765-8766).

In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that we would gather additional information and consider opportunities for future rulemaking (89 FR 8765). After considering stakeholder comments, our goals for interoperability, and the technical standards available to support electronic prior authorization for drugs, we are now proposing to require impacted payers to support electronic prior authorization for all drugs using a combination of standards, including the HL7® 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 ( printed page 19923) January 1, 2021 and were required to do so beginning January 1, 2022.

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

d. Other HIPAA Standards for Pharmacy Transactions

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

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

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

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

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

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

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

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

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

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 ( printed page 19925) in either category. However, we understand that most QHP issuers on the FFEs structure benefits into medical and pharmacy categories and therefore should follow their own distinctions for drug coverage.

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

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

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

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

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

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

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

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

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

4. Proposed Requirement To Support the NCPDP SCRIPT Standard for Prior Authorization for State Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated Exchanges

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

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

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

• PAInitiationRequest and PAInitiationResponse
• PARequest and PAResponse
• PAAppealRequest and PAAppealResponse
• PACancelRequest and PACancelResponse
• PANotification (NCPDP SCRIPT standard version 2023011 only) We are not proposing to require providers to use electronic prior authorization in this proposed rule. Rather, we are proposing that an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary must be available for providers to use for prior authorization, and that the payer must send the response to the prior authorization request using the same standard. If ONC establishes an expiration date for an adopted version of the NCPDP SCRIPT standard in 45 CFR 170.205(b), upon the specified expiration date, that version would no longer be eligible for use by impacted payers to meet the interoperability requirements. State Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs may continue to make non-electronic means of conducting prior authorization (for example, fax, phone call, or direct data entry through a payer portal) available to providers. However, should these proposals be finalized, an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary would be the only electronic method these payers would be ( printed page 19926) permitted to use for the prior authorization of drugs covered under a pharmacy benefit as that term is described by the implementation guidance of the NCPDP SCRIPT standard, as discussed in sections II.A.2. and II.A.3. of this proposed rule.

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

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. ( printed page 19927)

6. Proposed Requirement To Support the NCPDP Real-Time Prescription Benefit Standard for State Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated Exchanges

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

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

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 ( printed page 19928) ability to request an exemption for these standards would not be affected and we are proposing no changes to the extensions and exemptions policies finalized in the 2024 CMS Interoperability and Prior Authorization final rule for those APIs.

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

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

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

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

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.
  ( printed page 19930)

( printed page 19931)

8. Statutory Authorities

a. Medicare Advantage

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

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

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

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

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

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

b. State Medicaid and CHIP

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

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

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

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

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

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

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

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

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

C. Improving Communications and Decision Timeframes for Prior Authorizations

1. Background for Improving Prior Authorization Process

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

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 ( printed page 19933) their commitment to improving services. Beyond information about which services require prior authorization and the requirements for approval, greater transparency about payer performance on denials, timeframes, and volumes could be helpful for the public. Such reporting improves accountability and can identify opportunities for improvement.

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

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 ( printed page 19936) requests and 24 hours for expedited requests.

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

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

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

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

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

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

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

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

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

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

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

c. Prior Authorization Decision Timeframes for Drugs That Are Not Covered Outpatient Drugs for State Medicaid Fee-for-Service Programs, Medicaid Managed Care Plans, and CHIP Managed Care Entities

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

Section 1927(k)(3) of the Act limits the term “covered outpatient drug” to exclude any drug, biological product, or insulin provided as part of, or as incident to and in the same setting as, certain services (and for which payment may be made under that subchapter as part of payment for those services and not as direct reimbursement for the drug). [141 ] To the extent that state Medicaid and CHIP programs cover and impose prior authorization requirements on these drugs that are not covered outpatient drugs, we believe the same decision timeframe requirements that ( printed page 19938) apply to prior authorization for the non-drug items and services should apply to a drug that is provided incident to those services. Therefore, non-covered outpatient drugs that meet the limiting definition in section 1927(k)(3) of the Act should align with the timeframe requirements for non-drug items and services, which is 7 calendar days for standard requests and 72 hours for expedited requests. We believe it is most appropriate to align the prior authorization decision timeframe for a drug that meets the limiting definition in section 1927(k)(3) of the Act with the services it is provided as part of, or incident to. We believe this will ensure a prior authorization decision is rendered for the drug and non-drug items and services within the same timeframe as opposed to having the drug reviewed under a different timeframe than the remainder of the service with which it is bundled with.

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 ( printed page 19939) Medicaid agency would have to comply. The regulation refers to this as a “shorter minimum timeframe,” but the intent of this requirement is to establish a maximum period of time for a state to make a decision on a prior authorization request. We are therefore proposing to remove the word “minimum” to explain that states may establish timeframes that are shorter, but not longer, than those we finalized.

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

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

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

5. Proposed Changes to Reporting Deadlines and Reporting Levels for Publicly Reported Prior Authorization Metrics for Non-Drug Items and Services for Medicaid Managed Care Plans and CHIP Managed Care Entities

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

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. ( printed page 19940)

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

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

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

• The total number and percentage of standard prior authorization requests for non-drug items and services that remain denied after appeal during the reporting period. [144 ] ++ 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 ( printed page 19941) reporting period. A percentage, on the other hand, provides an easy-to-understand metric to compare payers. Both of those numbers are important to provide context to individuals reviewing the reported data. Percentages and absolute numbers also allow for comparison across impacted payers and could highlight differences between payers, both in the number of prior authorization requests that they receive, as well as the approval rates at each stage of the process. Furthermore, using both the absolute number and percentage of prior authorizations in these metrics may avoid misinterpretation of the data. For instance, a small percentage of denied prior authorizations may seem insignificant until one understands that it represents thousands of prior authorizations. Conversely, for a payer that requires few prior authorizations, a large percentage of denials may be misinterpreted. Therefore, reporting both the number and percentage of prior authorization decisions by payers over the previous reporting period provides more comprehensive and useful information of these data while ensuring that the interpretation of these data is accurate and properly contextualized.

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

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, ( printed page 19942) 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. ( printed page 19943)

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

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

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

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

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

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

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

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

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

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

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

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

• A list of all drugs that require prior authorization.

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

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

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

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

• The total number and percentage of prior authorization requests for all drugs approved after appeal during the reporting period. [149 ] ++ 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. ( printed page 19944)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. ( printed page 19945)
• The proposal to require Medicaid managed care plans and CHIP managed care entities to annually report the previous rating period's metrics on their public websites no later than 90 days after the end of their rating period.
• The proposal to require MA organizations to report at the contract level (applicable integrated plans would report drugs covered by MA organizations at the MA contract level), state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans and CHIP managed care entities to report at the plan and program level (if coverage of drugs is included in their contract), and QHP issuers on the FFEs to report at the issuer level.

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

• Whether there are drugs payable under Part A that require prior authorization separate from other non-drug items and services that should be included in the scope of the proposed metrics for MA organizations.
  ( printed page 19946)

( printed page 19947)

( printed page 19948)

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

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

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

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

1. Introduction

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

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 ( printed page 19950) require small group market QHP issuers on the FF-SHOPs to implement these requirements, which already apply to individual market QHP issuers on the FFEs.

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, ( printed page 19951) and must continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change. [168 ]

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 ( printed page 19952) status change, and must continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change. [174 ]

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

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 ( printed page 19954) issuers on the FF-SHOPs, in this rule. For discussion of those proposals please see section II.C.3. of this proposed rule.

b. Proposals

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

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

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

( printed page 19956)

( printed page 19957)

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 ( printed page 19958) interoperability APIs. [207 ] To ensure the standardization of payer endpoints, we are proposing to require impacted payers to report their API endpoints as an Endpoint Resource, as defined by an unexpired version of the Health Level Seven (HL7®) 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, ( printed page 19959) 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 ( printed page 19960) the file within a site reported by the payer.

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

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

4. Reporting Timelines

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

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

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

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

5. Publication

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

6. Summary

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

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

++ Authorization and authentication protocols and implementation details.

++ API registration information.

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

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

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

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

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

• Would aligning the reporting requirements with the NDH Endpoint Profile resource reduce payer burden to report the proposed information and/or developer burden to use a centralized registry?

• If the alternative proposal is finalized, would it negate the need for impacted payers to report URLs to documentation related to authorization and authentication protocols and implementation details and API registration information? ( printed page 19962)

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

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

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

( printed page 19963)

( printed page 19964)

( printed page 19965)

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

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

b. Medicaid

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

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

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

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

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

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

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

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

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

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 ( printed page 19970) provisions that require impacted payers to make available information about prior authorizations for non-drug items and services and drugs. Consistent with our policies for non-drug items and services, the information about prior authorizations for drugs that we are proposing be made available via the Patient Access and Provider Access APIs is the following:

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

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

• The prior authorization status.

• The date the prior authorization was approved.

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

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

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

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

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

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

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

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

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

a. Background

Beginning in 2026, impacted payers are required to annually report to CMS certain metrics about patient data requests made via the Patient Access API. Impacted payers must annually report Patient Access API metrics to CMS in the form of aggregated, de-identified data following any year that the payer was subject to the requirement to make the Patient Access API available. Specifically, by March 31, 2026, MA organizations at the contract level, state Medicaid and CHIP FFS programs at the state level, and Medicaid managed care plans and CHIP managed care entities at the plan level must report the following metrics: (1) the total number of unique patients whose data are transferred via the ( printed page 19971) Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. [239 ] The current regulation in 45 CFR 156.221(f) provides that individual market QHP issuers on the FFEs at the issuer level also report these data by March 31, 2026, but CMS has specified to plans in sub-regulatory guidance that we will collect Patient Access API usage metrics during the QHP certification process. [240 ]

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

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. ( printed page 19973) However, at this time, we continue to believe that the burden of requiring MA organizations to report at the plan level, especially given the small sample sizes of some plans, outweighs the benefits of obtaining that information.

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

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

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

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

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

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

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

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

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

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

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

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

• The total number of unique providers who request a prior authorization for items, services, or drugs through their Prior Authorization API.
• The number of unique prior authorization requests for items, services, and drugs received through their Prior Authorization API.
• 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 ( printed page 19974) 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 ( printed page 19975) 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 ( printed page 19976) 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 ( printed page 19977) would apply to administrative claims for complying with the proposals in this proposed rule, if finalized.

( printed page 19978)

( printed page 19979)

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 ( printed page 19980) 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. ( printed page 19981)

(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 ( printed page 19982) 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. ( printed page 19983)

(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. ( printed page 19984)

(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 ( printed page 19985) 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 ( printed page 19986) 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) ( printed page 19987) (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 ( printed page 19988) 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 ( printed page 19989) 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 ( printed page 19990) 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 ( printed page 19991) 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 ( printed page 19992) 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, ( printed page 19993) 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 ( printed page 19994) 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. ( printed page 19995)

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. ( printed page 19996)

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 ( printed page 19997) 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 ( printed page 19998) 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. ( printed page 19999)

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? ( printed page 20000)

( printed page 20001)

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 ( printed page 20002) 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 ( printed page 20003) 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: ( printed page 20004)

• 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. ( printed page 20005) 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 ( printed page 20006) 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 ( printed page 20007) (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/ ( printed page 20008) 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 (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 ( printed page 20009) 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 ( printed page 20010) 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 ( printed page 20011) 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) ( printed page 20012) 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? ( printed page 20013)

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 ( printed page 20014) 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 ( printed page 20015) 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? ( printed page 20016) 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.

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 ( printed page 20017) 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 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.

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 ( printed page 20018) 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.

( printed page 20019)

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.

( printed page 20020)

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.” ( printed page 20021)

( printed page 20022)

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 ( printed page 20023) 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 ( printed page 20024) 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

( printed page 20025) 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 ( printed page 20026) 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.

( printed page 20027)

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.

(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 ( printed page 20028) 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

( printed page 20029) 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.

( printed page 20030)

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

( printed page 20031)

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

( printed page 20032)

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

( printed page 20033)

(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 ( printed page 20034) 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.

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 ( printed page 20035) 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 ( printed page 20036) 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.

( printed page 20037)

( printed page 20038)

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 ( printed page 20039) 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 ( printed page 20040) 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 ( printed page 20041) 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. ( printed page 20042) 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 ( printed page 20043) 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.

( printed page 20044)

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 ( printed page 20045) 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 ( printed page 20046) 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. ( printed page 20047)

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

42 CFR Part 403

• Grant programs-health
• Health insurance
• Hospitals
• Intergovernmental relations
• Medicare
• Reporting and recordkeeping requirements

42 CFR Part 422

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

42 CFR Part 431

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

42 CFR Part 438

• Grant programs-health
• Medicaid
• Reporting and recordkeeping requirements

42 CFR Part 440

• Grant programs-health
• Medicaid

42 CFR Part 457

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

45 CFR Part 156

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

45 CFR Part 162

• Administrative practice and procedures
• Electronic transactions
• Health facilities
• Health insurance
• Hospitals
• Incorporation by reference
• Medicaid
• Medicare
• Reporting and recordkeeping requirements

45 CFR Part 170

• 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 ( printed page 20048) 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 ( printed page 20049) 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. ( printed page 20050)

(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 ( printed page 20051) 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.

• * * * * 11. 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 ( printed page 20052) 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. ( printed page 20053)

(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 ( printed page 20054) 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 ( printed page 20055) 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.

• * * * * 22. 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 ( printed page 20056) 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. ( printed page 20057)

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

• * * * * 23. 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 ( printed page 20058) (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 ( printed page 20059) 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.
• • * * * 27. 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. ( printed page 20060)

(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 ( printed page 20061) 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:

( printed page 20062) §  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.

Footnotes

1.

                         
                        See [42 CFR 422.119(b)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(b)) for MA organizations, [42 CFR 431.60(b)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(b)) for state Medicaid FFS programs, [42 CFR 457.730(b)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(b)) for state CHIP FFS programs, cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(b)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)) for individual market QHP issuers on the FFEs.

Back to Citation 2.

                         
                        See [42 CFR 422.122(b)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(b)) for MA organizations, [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) for state Medicaid FFS programs, [42 CFR 457.732(b)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(b)) for state CHIP FFS programs, through cross reference to [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for individual market QHP issuers on the FFEs.

Back to Citation 3.

                         
                        See [42 CFR 440.230(e)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)) for state Medicaid FFS programs, [42 CFR 457.495(d)(2)](https://www.ecfr.gov/current/title-42/section-457.495#p-457.495(d)(2)) for state CHIP FFS programs, [42 CFR 438.210(d)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(d)) for Medicaid managed care plans, and [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-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](https://www.ecfr.gov/current/title-42/section-422.402).

Back to Citation 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.

Back to Citation 5.

                         We note that existing language in [45 CFR 156.223(d)(1)(i)](https://www.ecfr.gov/current/title-45/section-156.223#p-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.

Back to Citation 6.

                         For exceptions, see [45 CFR 156.222(c)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(c)) and [45 CFR 156.223(d)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(d)) for individual market QHP issuers on the FFEs.

Back to Citation 7.

                         
                        See [42 CFR 422.122(a)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(a)) for MA organizations and applicable integrated plans, [42 CFR 431.80(a)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(a)) for state Medicaid FFS programs, through cross 

                        reference to [42 CFR 431.80(a)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(a)) in [42 CFR 438.242(b)(8)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(8)) for Medicaid managed care plans, [42 CFR 457.732(a)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(a)) for state CHIP FFS programs, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.223(a)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(a)) for individual market QHP issuers on the FFEs.

Back to Citation 8.

                         
                        See 
                         section 1927(d)(5)(A) of the Act for state Medicaid FFS programs, [42 CFR 438.3(s)(6)](https://www.ecfr.gov/current/title-42/section-438.3#p-438.3(s)(6)) for Medicaid managed care plans, and [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities.

Back to Citation 9.

                         Information about QHP certification, including deadlines can be found at *[https://www.qhpcertification.cms.gov/​QHP/​aboutthemarketplace/​Timeline](https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline).*

Back to Citation 10.

                         
                        See [42 CFR 422.119(f)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(f)) for MA organizations, [42 CFR 431.60(f)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(f)) for state Medicaid FFS programs, through cross reference to 431.60 in [42 CFR 438.242(b)(5)(iii)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)(iii)) for Medicaid managed care plans, [42 CFR 457.730(f)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(f)) for CHIP FFS programs, through existing cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in existing [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(f)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(f)) for individual market QHP issuers on the FFEs.

Back to Citation 11.

                         
                        See [42 CFR 422.122(c)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(c)) for MA organizations and applicable integrated plans, [42 CFR 440.230(e)(3)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)(3)) for state Medicaid FFS programs, [42 CFR 457.732(c)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(c)) for state CHIP FFS programs, [42 CFR 438.210(f)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(f)) for Medicaid managed care plans, through cross reference to [42 CFR 438.210](https://www.ecfr.gov/current/title-42/section-438.210) in [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities, and [45 CFR 156.223(c)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(c)) for individual market QHP issuers on the FFEs.

Back to Citation 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](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](https://www.federalregister.gov/citation/89-FR-8906).

Back to Citation 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](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process).*

Back to Citation 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](https://www.federalregister.gov/citation/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.

Back to Citation 15.

                         
                        See [45 CFR parts 160](https://www.ecfr.gov/current/title-45/part-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](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](https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html).*

Back to Citation 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](https://www.healthit.gov/api-education-module/story_html5.html).*

Back to Citation 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](https://www.healthit.gov/sites/default/files/page/2021-04/What%2520Is%2520FHIR%2520Fact%2520Sheet.pdf).*

Back to Citation 19.

                         
                        See [89 FR 51262](https://www.federalregister.gov/citation/89-FR-51262).

Back to Citation 20.

                         As announced in the **Federal Register** in [65 FR 50373](https://www.federalregister.gov/citation/65-FR-50373).

Back to Citation 21.

                         
                        See [42 CFR 422.119(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(c)(4)(ii)) for MA organizations, [42 CFR 431.60(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(c)(4)(ii)) for state Medicaid FFS programs; through cross references to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)), [42 CFR 431.61(a)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(a)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)), [42 CFR 431.61(b)(1)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(1)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)), [42 CFR 431.70](https://www.ecfr.gov/current/title-42/section-431.70) in [42 CFR 438.242(b)(6)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(6)), [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans; [42 CFR 457.730(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(c)(4)(ii)) for state CHIP FFS programs; through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities; and [45 CFR 156.221(c)(4)(ii)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(c)(4)(ii)) for individual market QHP issuers.

Back to Citation 22.

                         
                        See [42 CFR 422.119(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(c)(4)(ii)) for MA organizations, [42 CFR 431.60(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(c)(4)(ii)) for state Medicaid FFS programs; through cross references to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)), [42 CFR 431.61(a)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(a)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)), [42 CFR 431.61(b)(1)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(1)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)), [42 CFR 431.70](https://www.ecfr.gov/current/title-42/section-431.70) in [42 CFR 438.242(b)(6)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(6)), [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans; [42 CFR 457.730(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(c)(4)(ii)) for state CHIP FFS programs; through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities; and [45 CFR 156.221(c)(4)(ii)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(c)(4)(ii)) for individual market QHP issuers.

Back to Citation 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](https://standards.ncpdp.org/Access-to-Standards.aspx).*

Back to Citation 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](https://ncpdp.org/NCPDP/media/pdf/NCPDP_ePA_Fact_Sheet.doc).*

Back to Citation 25.

                         
                        See [45 CFR 170.215(a)(1)](https://www.ecfr.gov/current/title-45/section-170.215#p-170.215(a)(1)).

Back to Citation 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](https://hl7.org/fhir/us/davinci-pas/usecases.html).*

Back to Citation 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](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](https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2023/20230213_To_CMS_CMS_4201_P_NPRM.pdf).*

Back to Citation 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](https://www.ecfr.gov/current/title-45/section-170.102)).

Back to Citation 31.

                         For eligible hospitals and CAHs, *see* the FY 2026 IPPS/LTCH final rule ([89 FR 69615](https://www.federalregister.gov/citation/89-FR-69615)); for MIPS eligible clinicians, *see* the CY 2025 Medicare Physician Fee Schedule final rule ([89 FR 98417-98427](https://www.federalregister.gov/citation/89-FR-98417)).

Back to Citation 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](https://standards.ncpdp.org/Access-to-Standards.aspx).*

Back to Citation 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](https://www.japha.org/article/S1544-3191(23)00016-X/abstractqq).*

Back to Citation 34.

                         
                        See [45 CFR 170.215(d)(1)](https://www.ecfr.gov/current/title-45/section-170.215#p-170.215(d)(1)).

Back to Citation 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](http://hl7.org/fhir/us/carin-bb/ImplementationGuide/hl7.fhir.us.carin-bb).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-drug-formulary/ImplementationGuide/hl7.fhir.us.davinci-drug-formulary).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-pdex-plan-net/ImplementationGuide/hl7.fhir.us.davinci-pdex-plan-net).*

Back to Citation 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](http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/hl7.fhir.uv.bulkdata).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd).*

Back to Citation 41.

                         Health Level Seven International. (2026, March 27). Da Vinci CRD IG, Version 2.2.1—STU 2.2. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-crd/2.2.1/en/">https://hl7.org/​fhir/​us/​davinci-crd/​2.2.1/​en/</a>.*

Back to Citation 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](http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr).*

Back to Citation 43.

                         Health Level Seven International. (2026, March 27). Da Vinci DTR IG, Version 2.2.0—STU 2.2. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/">https://hl7.org/​fhir/​us/​davinci-dtr/​2.2.0/​en/</a>.*

Back to Citation 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](http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas).*

Back to Citation 45.

                         Health Level Seven International. (2026, March 27). Da Vinci PAS IG, Version 2.2.1—STU 2.2. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-pas/2.2.1/en/">https://hl7.org/​fhir/​us/​davinci-pas/​2.2.1/​en/</a>.*

Back to Citation 46.

                         
                        See [42 CFR 422.119(a)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(a)) for MA organizations, [42 CFR 431.60(a)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(a)) for state Medicaid FFS programs, [42 CFR 457.730(a)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(a)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 457.730](https://www.ecfr.gov/current/title-42/section-457.730) in [42 CFR 457.1233(d)(2)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)(2)) for CHIP managed care entities, and [45 CFR 156.221(a)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(a)) for individual market QHPs.

Back to Citation 47.

                         
                        See [42 CFR 422.119(b)(1)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(b)(1)) for MA organizations, [42 CFR 431.60(b)(3)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(b)(3)) for state Medicaid FFS programs, cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, [42 CFR 457.730](https://www.ecfr.gov/current/title-42/section-457.730) for state CHIP FFS programs, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in existing [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(b)(1)(iii)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)(1)(iii)) for individual market QHP issuers.

Back to Citation 48.

                         
                        See [42 CFR 422.119(b)(1)(iv)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(b)(1)(iv)) for MA organizations, [42 CFR 431.60(b)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(b)) for state Medicaid FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, [42 CFR 457.730(b)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(b)) for state CHIP FFS programs, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(b)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)) for individual market QHP issuers.

Back to Citation 49.

                         
                        See [42 CFR 422.121(a)(2)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(a)(2)) for MA organizations, [42 CFR 431.61(a)(2)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(a)(2)) for state Medicaid FFS programs, [42 CFR 457.731(a)(2)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(a)(2)) for CHIP FFS programs, through cross reference to [42 CFR 431.61](https://www.ecfr.gov/current/title-42/section-431.61) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.222(a)(2)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(2)) for individual market QHP issuers.

Back to Citation 50.

                         
                        See 
                         cross reference to [42 CFR 422.119(b)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(b)) in [42 CFR 422.121(a)(2)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(a)(2)) for MA organizations, through cross reference to [42 CFR 431.60(b)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(b)) in [42 CFR 431.61(a)(2)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(a)(2)) for state Medicaid FFS programs, through cross reference to [42 CFR 457.730(b)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(b)) in [42 CFR 457.731(a)(2)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(a)(2)) for state CHIP FFS programs, through cross reference to [42 CFR 431.61](https://www.ecfr.gov/current/title-42/section-431.61) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.222(a)(1)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(1)) for individual market QHP issuers.

Back to Citation 51.

                         
                        See [42 CFR 422.120(a)](https://www.ecfr.gov/current/title-42/section-422.120#p-422.120(a)) for MA organizations, [42 CFR 431.70(a)](https://www.ecfr.gov/current/title-42/section-431.70#p-431.70(a)) for state Medicaid FFS programs, [42 CFR 457.760(a)](https://www.ecfr.gov/current/title-42/section-457.760#p-457.760(a)) for state CHIP FFS programs, through cross reference to [42 CFR 431.70](https://www.ecfr.gov/current/title-42/section-431.70) in [42 CFR 438.242(b)(6)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(6)) for Medicaid managed care plans, and through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities.

Back to Citation 52.

                         
                        See [42 CFR 422.120(c)](https://www.ecfr.gov/current/title-42/section-422.120#p-422.120(c)) for MA organizations, [42 CFR 431.70(c)](https://www.ecfr.gov/current/title-42/section-431.70#p-431.70(c)) for state Medicaid FFS programs, [42 CFR 457.760(c)](https://www.ecfr.gov/current/title-42/section-457.760#p-457.760(c)) for state CHIP FFS programs, through cross reference to [42 CFR 431.70(c)](https://www.ecfr.gov/current/title-42/section-431.70#p-431.70(c)) in [42 CFR 438.242(b)(6)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(6)) for Medicaid managed care plans, and through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities.

Back to Citation 53.

                         
                        See [42 CFR 422.121(b)(1)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(b)(1)) for MA organizations, [42 CFR 431.61(b)(1)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(1)) for state Medicaid FFS 

                        programs, through cross reference to [42 CFR 431.61(b)(1)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(1)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, [42 CFR 457.731(b)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(b)) for state CHIP FFS programs, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.222(b)(1)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(1)) for individual market QHPs.

Back to Citation 54.

                         
                        See [42 CFR 422.121(b)(4)(ii)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(b)(4)(ii)) for MA organizations, [42 CFR 431.61(b)(4)(ii)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(4)(ii)) for state Medicaid FFS programs, through cross reference to [42 CFR 431.61(b)(4)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(4)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, [42 CFR 457.731(b)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(b)) for state CHIP FFS programs, [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.222(b)(4)(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(4)(ii)) for individual market QHPs.

Back to Citation 55.

                         
                        See 
                         cross reference to [42 CFR 422.119(b)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(b)) in [42 CFR 422.121(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(b)(4)(ii)(A)) for MA organizations, through cross reference to [42 CFR 431.60(b)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(b)) in [42 CFR 431.61(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(4)(ii)(A)) for state Medicaid FFS programs, through cross reference to [42 CFR 457.730(b)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(b)) in [42 CFR 457.731(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(b)(4)(ii)(A)) for state CHIP FFS programs, through cross reference to [42 CFR 431.61](https://www.ecfr.gov/current/title-42/section-431.61) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)), and through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)).

Back to Citation 56.

                         
                        See [42 CFR 422.122(b)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(b)) for MA organizations, [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) for state Medicaid FFS programs, through cross reference to [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, [42 CFR 457.732(b)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(b)) for state CHIP FFS programs, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)), and [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for individual market QHPs.

Back to Citation 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](http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas).*

Back to Citation 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](https://www.federalregister.gov/citation/89-FR-8943) and [8944](https://www.federalregister.gov/citation/89-FR-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.

Back to Citation 61.

                         Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov. Retrieved from *<a href="https://inferno.healthit.gov/">https://inferno.healthit.gov/</a>.*

Back to Citation 62.

                         Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov Test Kits. Retrieved from *<a href="https://inferno.healthit.gov/test-kits/">https://inferno.healthit.gov/​test-kits/</a>.*

Back to Citation 63.

                         
                        See [42 CFR 422.119(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(c)(4)(ii)) for MA organizations, [42 CFR 431.60(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(c)(4)(ii)) for state Medicaid FFS programs; through cross references to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)), [431.61(a)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(a)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)), [42 CFR 431.61(b)(1)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(1)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)), [42 CFR 431.70](https://www.ecfr.gov/current/title-42/section-431.70) in [42 CFR 438.242(b)(6)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(6)), [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans; [42 CFR 457.730(c)(4)(ii)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(c)(4)(ii)) for state CHIP FFS programs; through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities; and [45 CFR 156.221(c)(4)(ii)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(c)(4)(ii)) for individual market QHP issuers.

Back to Citation 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](https://www.healthit.gov/isa/standards-version-advancement-process).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-atr/ImplementationGuide/hl7.fhir.us.davinci-atr).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex).*

Back to Citation 67.

                         Health Level Seven International. (n.d.). FAST Security IG. Retrieved from *<a href="https://build.fhir.org/ig/HL7/fhir-udap-security-ig/">https://build.fhir.org/​ig/​HL7/​fhir-udap-security-ig/</a>.*

Back to Citation 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](https://www.udap.org/udap-user-auth-stu1.html).*

69.

                         Health Level Seven International. (n.d.). FAST Security IG. Retrieved from *<a href="https://build.fhir.org/ig/HL7/fhir-udap-security-ig/">https://build.fhir.org/​ig/​HL7/​fhir-udap-security-ig/</a>.*

Back to Citation 70.

                         Health Level Seven International. (n.d.). Consumer Real-Time Pharmacy Benefit Check IG. Retrieved from *<a href="https://hl7.org/fhir/us/carin-rtpbc/">https://hl7.org/​fhir/​us/​carin-rtpbc/</a>.*

Back to Citation 96.

                         
                        See [42 CFR 422.122(b)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(b)) for MA organizations, [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) for state Medicaid FFS programs, [42 CFR 457.732(b)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(b)) for state CHIP FFS programs, through cross reference to [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for individual market QHP issuers on the FFEs.

Back to Citation 97.

                         
                        See [42 CFR 422.122(b)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(b)) for MA organizations, [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) for state Medicaid FFS programs, [42 CFR 457.732(b)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(b)) for state CHIP FFS programs, through cross reference to [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for individual market QHP issuers on the FFEs.

Back to Citation 98.

                         
                        See [45 CFR 162.1302](https://www.ecfr.gov/current/title-45/section-162.1302).

Back to Citation 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](https://www.ecfr.gov/current/title-45/section-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](https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf).*

Back to Citation 100.

                         
                        See [45 CFR 162.1302](https://www.ecfr.gov/current/title-45/section-162.1302).

Back to Citation 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](https://hl7.org/fhir/us/davinci-pas/usecases.html#scope-of-work-flow).*

Back to Citation 102.

                         Per section 1927(k)(3) of the Act and [42 CFR 447.502](https://www.ecfr.gov/current/title-42/section-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.

Back to Citation 103.

                         
                        See [42 CFR 438.3(s)(6)](https://www.ecfr.gov/current/title-42/section-438.3#p-438.3(s)(6)).

Back to Citation 104.

                         
                        See [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) for state Medicaid FFS programs and [42 CFR 457.732(b)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(b)) for state CHIP FFS programs.

Back to Citation 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](https://www.ama-assn.org/system/files/prior-authorization-state-law-chart.pdf).*

Back to Citation 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](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.

Back to Citation 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](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.

Back to Citation 108.

                         For the Provider Access and Payer-to-Payer APIs, see [42 CFR 431.61(c)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(c)) for state Medicaid FFS programs and [42 CFR 457.731(c)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(c)) for state CHIP FFS programs. For the Prior Authorization API, see [42 CFR 431.80(c)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(c)) for state Medicaid FFS programs and [42 CFR 457.732(d)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(d)) for state CHIP FFS programs.

Back to Citation 109.

                         For the Provider Access and Payer-to-Payer APIs, see [45 CFR 156.222(c)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(c)). For the Prior Authorization API, see [45 CFR 156.223(d)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(d)).

Back to Citation 110.

                         
                        See [42 CFR 431.80(c)(2)(ii)(B)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(c)(2)(ii)(B)) (*2*).

Back to Citation 111.

                         
                        See 
                         discussion in [65 FR 82579](https://www.federalregister.gov/citation/65-FR-82579) that clarifies that “pure premiums” can be substituted for “annual receipts,” as appropriate.

Back to Citation 112.

                         For the Patient Access API, see [45 CFR 156.221(h)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(h)). For the Provider Access and Payer-to-Payer APIs, see [45 CFR 156.222(c)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(c)). For the Prior Authorization API, see [45 CFR 156.223(d)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(d)).

Back to Citation 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](https://www.federalregister.gov/citation/89-FR-8905)).

Back to Citation 114.

                         American Medical Association. (2025). 2024 AMA prior authorization physician survey. Retrieved from *[https://www.ama-assn.org/​system/​files/​prior-authorization-survey.pdf](https://www.ama-assn.org/system/files/prior-authorization-survey.pdf).*

Back to Citation 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](https://www.ama-assn.org/press-center/press-releases/toll-prior-authorization-exceeds-alleged-benefits-say-physicians).*

Back to Citation 116.

                         
                        See [42 CFR 422.122(c)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(c)) for MA organizations and applicable integrated plans, [42 CFR 440.230(e)(3)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)(3)) for state Medicaid FFS programs, [42 CFR 457.732(c)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(c)) for state CHIP FFS programs, [42 CFR 438.210(f)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(f)) for Medicaid managed care plans, through existing cross reference to [42 CFR 438.210](https://www.ecfr.gov/current/title-42/section-438.210) in [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities, and [45 CFR 156.223(c)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(c)) for individual market QHP issuers on the FFEs.

Back to Citation 117.

                         
                        See [42 CFR 422.122(a)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(a)) for MA organizations and applicable integrated plans, [42 CFR 431.80(a)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(a)) for state Medicaid FFS programs, [42 CFR 457.732(a)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(a)) for state CHIP FFS programs, through cross reference to [42 CFR 431.80(a)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(a)) in [42 CFR 438.242(b)(8)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(8)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.223(a)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(a)) for individual market QHP issuers on the FFEs.

Back to Citation 118.

                         
                        See [42 CFR 422.568(b)(3)](https://www.ecfr.gov/current/title-42/section-422.568#p-422.568(b)(3)) and [42 CFR 422.572(a)(2)](https://www.ecfr.gov/current/title-42/section-422.572#p-422.572(a)(2)).

Back to Citation 119.

                         
                        See [42 CFR 422.568(e)](https://www.ecfr.gov/current/title-42/section-422.568#p-422.568(e)) and [42 CFR 422.572(e)](https://www.ecfr.gov/current/title-42/section-422.572#p-422.572(e)).

Back to Citation 120.

                         
                        See [42 CFR 422.2267(e)(16)](https://www.ecfr.gov/current/title-42/section-422.2267#p-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](https://www.cms.gov/medicare/forms-notices/beneficiary-notices-initiative/ma-denial-notice).*

Back to Citation 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](https://www.cms.gov/medicare/appeals-and-grievances/mmcag/downloads/parts-c-and-d-enrollee-grievances-organization-coverage-determinations-and-appeals-guidance.pdf).*

Back to Citation 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](https://www.cms.gov/medicare/forms-notices/beneficiary-notices-initiative/ma-denial-notice).*

Back to Citation 123.

                         
                        See [42 CFR 438.210(c)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(c)) and [438.242(b)(8)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(8)) for Medicaid managed care plans and [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities.

Back to Citation 124.

                         As specified in [42 CFR 438.242(b)(8)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(8)) by cross-reference to [42 CFR 431.80(a)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(a)).

Back to Citation 125.

                         
                        See [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)).

Back to Citation 126.

                         
                        See [42 CFR 422.122(a)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(a)) for MA organizations and applicable integrated plans, [42 CFR 431.80(a)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(a)) for state Medicaid FFS programs, [42 CFR 457.732(a)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(a)) for state CHIP FFS programs, through cross reference to [42 CFR 431.80(a)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(a)) in [42 CFR 438.242(b)(8)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(8)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.223(a)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(a)) for individual market QHP issuers on the FFEs.

Back to Citation 127.

                         
                        See [42 CFR 435.917(a)](https://www.ecfr.gov/current/title-42/section-435.917#p-435.917(a)) for state Medicaid FFS programs and [42 CFR 457.1180](https://www.ecfr.gov/current/title-42/section-457.1180) for state CHIP FFS programs.

Back to Citation 128.

                         
                        See [29 CFR 2560.503-1(g)](https://www.ecfr.gov/current/title-29/section-2560.503-1#p-2560.503-1(g)), [45 CFR 147.136(b)(2)(i)](https://www.ecfr.gov/current/title-45/section-147.136#p-147.136(b)(2)(i)), and [45 CFR 147.136(b)(3)(ii)(E)](https://www.ecfr.gov/current/title-45/section-147.136#p-147.136(b)(3)(ii)(E)) (*3*).

Back to Citation 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

Back to Citation 130.

                         
                        See [42 CFR 422.568(b)(3)](https://www.ecfr.gov/current/title-42/section-422.568#p-422.568(b)(3)) and [42 CFR 422.572(a)(2)](https://www.ecfr.gov/current/title-42/section-422.572#p-422.572(a)(2)).

Back to Citation 131.

                         
                        See [42 CFR 423.568(b)](https://www.ecfr.gov/current/title-42/section-423.568#p-423.568(b)) and [42 CFR 423.572(a)](https://www.ecfr.gov/current/title-42/section-423.572#p-423.572(a)).

Back to Citation 132.

                         
                        See 
                         section 1927(d)(5)(A) of the Act for state Medicaid FFS programs, [42 CFR 438.210(d)(3)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(d)(3)) and [42 CFR 438.3(s)(6)](https://www.ecfr.gov/current/title-42/section-438.3#p-438.3(s)(6)) for Medicaid managed care plans, and through cross reference to [42 CFR 438.210(d)(3)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(d)(3)) in [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities.

Back to Citation 133.

                         
                        See [42 CFR 457.495(d)](https://www.ecfr.gov/current/title-42/section-457.495#p-457.495(d)).

Back to Citation 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](https://www.ama-assn.org/system/files/prior-authorization-state-law-chart.pdf).*

Back to Citation 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 *<a href="https://www.kff.org/affordable-care-act/issue-brief/consumer-problems-with-prior-authorization-evidence-from-kff-survey/">https://www.kff.org/​affordable-care-act/​issue-brief/​consumer-problems-with-prior-authorization-evidence-from-kff-survey/</a>.*

Back to Citation 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)](https://www.ecfr.gov/current/title-5/section-1320.3#p-1320.3(b)(2)).

Back to Citation 137.

                         
                        See [42 CFR 422.568(b)(1)](https://www.ecfr.gov/current/title-42/section-422.568#p-422.568(b)(1)) and [42 CFR 422.568(b)(3)](https://www.ecfr.gov/current/title-42/section-422.568#p-422.568(b)(3)).

Back to Citation 138.

                         
                        See [42 CFR 423.568(b)](https://www.ecfr.gov/current/title-42/section-423.568#p-423.568(b)) and [42 CFR 423.572(a)](https://www.ecfr.gov/current/title-42/section-423.572#p-423.572(a)).

Back to Citation 139.

                         
                        See [42 CFR 440.230(e)(1)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)(1)).

Back to Citation 140.

                         
                        See [42 CFR 457.495(d)](https://www.ecfr.gov/current/title-42/section-457.495#p-457.495(d)), using the phrase “In accordance with the medical needs of the patient . . . .”

Back to Citation 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.

Back to Citation 142.

                         
                        See [42 CFR 422.122(c)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(c)) for MA organizations and applicable integrated plans, [42 CFR 440.230(e)(3)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)(3)) for state Medicaid FFS programs, [42 CFR 457.732(c)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(c)) for state CHIP FFS programs, [42 CFR 438.210(f)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(f)) for Medicaid managed care plans, through existing cross reference to [42 CFR 438.210](https://www.ecfr.gov/current/title-42/section-438.210) in [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities, and [45 CFR 156.223(c)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(c)) for individual market QHP issuers on the FFEs.

Back to Citation 143.

                         
                        See [42 CFR 422.122(c)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(c)) for MA organizations and applicable integrated plans, [42 CFR 440.230(e)(3)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)(3)) for state Medicaid FFS programs, [42 CFR 457.732(c)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(c)) for state CHIP FFS programs, [42 CFR 438.210(f)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(f)) for Medicaid managed care plans, through cross reference to [42 CFR 438.210](https://www.ecfr.gov/current/title-42/section-438.210) in [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities, and [45 CFR 1562.223(c)](https://www.ecfr.gov/current/title-45/section-1562.223#p-1562.223(c)) for individual market QHP issuers on the FFEs.

Back to Citation 144.

                         Appeals for MA organizations are described in [42 CFR 422 Subpart M](https://www.ecfr.gov/current/title-42/part-422/subpart-M). Appeals for state Medicaid FFS programs (known as fair hearings) are described in [42 CFR 431 Subpart E](https://www.ecfr.gov/current/title-42/part-431/subpart-E) and [f](https://www.ecfr.gov/current/title-42/part-431/subpart-f) or Medicaid managed care plans in [42 CFR 438 Subpart F](https://www.ecfr.gov/current/title-42/part-438/subpart-F). Appeals for state CHIP FFS programs are described in [42 CFR 457 Subpart K](https://www.ecfr.gov/current/title-42/part-457/subpart-K) and [f](https://www.ecfr.gov/current/title-42/part-457/subpart-f) or CHIP managed care entities in [42 CFR 457.1260](https://www.ecfr.gov/current/title-42/section-457.1260). Appeals for QHP issuers on the FFEs are described in [45 CFR 147.136](https://www.ecfr.gov/current/title-45/section-147.136).

Back to Citation 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](https://www.cms.gov/medicare/coverage/prescription-drug-coverage-contracting/part-d-reporting-requirements).*

Back to Citation 146.

                         
                        See [42 CFR 422.122(c)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(c)) for MA organizations and applicable integrated plans, [42 CFR 440.230(e)(3)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)(3)) for state Medicaid FFS programs, [42 CFR 457.732(c)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(c)) for state CHIP FFS programs, [42 CFR 438.210(f)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(f)) for Medicaid managed care plans, through existing cross reference to [42 CFR 438.210](https://www.ecfr.gov/current/title-42/section-438.210) in [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities, and [45 CFR 156.223(c)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(c)) for individual market QHP issuers on the FFEs.

Back to Citation 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](https://www.cms.gov/files/document/prior-authorization-and-pre-claim-review-program-statistics.pdf).*

Back to Citation 148.

                         Appeals for MA organizations are described in [42 CFR 422 Subpart M](https://www.ecfr.gov/current/title-42/part-422/subpart-M).

Back to Citation 149.

                         Appeals for state Medicaid FFS programs (known as fair hearings) are described in [42 CFR 431 Subpart E](https://www.ecfr.gov/current/title-42/part-431/subpart-E) and [f](https://www.ecfr.gov/current/title-42/part-431/subpart-f) or Medicaid managed care plans in [42 CFR 438 Subpart F](https://www.ecfr.gov/current/title-42/part-438/subpart-F). Appeals for state CHIP FFS programs are described in [42 CFR 457 Subpart K](https://www.ecfr.gov/current/title-42/part-457/subpart-K) and [f](https://www.ecfr.gov/current/title-42/part-457/subpart-f) or CHIP managed care entities in [42 CFR 457.1260](https://www.ecfr.gov/current/title-42/section-457.1260).

Back to Citation 150.

                         Appeals for QHP issuers on the FFEs are described in [45 CFR 147.136](https://www.ecfr.gov/current/title-45/section-147.136).

Back to Citation 151.

                         
                        See [42 CFR 422.122(c)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(c)) for MA organizations and applicable integrated plans, [42 CFR 440.230(e)(3)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)(3)) for state Medicaid FFS programs, [42 CFR 457.732(c)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(c)) for state CHIP FFS programs, [42 CFR 438.210(f)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(f)) for Medicaid managed care plans, through existing cross reference to [42 CFR 438.210](https://www.ecfr.gov/current/title-42/section-438.210) in [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities, and [45 CFR 156.223(c)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(c)) for individual market QHP issuers on the FFEs.

Back to Citation 152.

                         Qualified Health Plan Certification. (2024, August 8). Application Instructions. Retrieved from *[https://www.qhpcertification.cms.gov/​s/​Application%20Instructions](https://www.qhpcertification.cms.gov/s/Application%2520Instructions).*

Back to Citation 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.

Back to Citation 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](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](https://www.federalregister.gov/citation/89-FR-8906).

Back to Citation 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)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(a)) for the Patient Access API, [45 CFR 156.222(a)](https://www.ecfr.gov/current/title-45/section-156.222#p-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)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for the Prior Authorization API for individual market QHP issuers on the FFEs.

Back to Citation 156.

                         
                        See [45 CFR 156.221(c)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(c)) for the Patient Access API, [45 CFR 156.222(a)(1)(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(1)(ii)) for the Provider Access API, [45 CFR 156.222(b)(1)(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(1)(ii)) for the Payer-to-Payer API, and [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for the Prior Authorization API.

Back to Citation 157.

                         
                        See [45 CFR 156.221(c)(4)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(c)(4)).

Back to Citation 158.

                         
                        See [45 CFR 156.221(c)(2)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(c)(2)).

Back to Citation 159.

                         
                        See [45 CFR 156.221(d)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(d)).

Back to Citation 160.

                         
                        See [45 CFR 156.221(e)(1)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(e)(1)).

Back to Citation 161.

                         
                        See [45 CFR 156.221(e)(2)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(e)(2)).

Back to Citation 162.

                         
                        See [45 CFR 156.221(a)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(a)).

Back to Citation 163.

                         
                        See [45 CFR 156.221(b)(1)(iii)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)(1)(iii)).

Back to Citation 164.

                         
                        See [45 CFR 156.221(i)(1)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(i)(1)).

Back to Citation 165.

                         
                        See [45 CFR 156.221(b)(1)(iii)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)(1)(iii)).

Back to Citation 166.

                         
                        See [45 CFR 156.221(b)(1)(iv)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)(1)(iv)).

Back to Citation 167.

                         
                        See [45 CFR 156.221(b)(1)(iv)(A)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)(1)(iv)(A)).

Back to Citation 168.

                         
                        See [45 CFR 156.221(b)(1)(iv)(B)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)(1)(iv)(B)).

Back to Citation 169.

                         
                        See [45 CFR 156.221(g)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(g)).

Back to Citation 170.

                         
                        See [45 CFR 156.221(f)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(f)).

Back to Citation 171.

                         Information about QHP certification, including deadlines can be found at *[https://www.qhpcertification.cms.gov/​QHP/​aboutthemarketplace/​Timeline](https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline).*

Back to Citation 172.

                         
                        See [45 CFR 156.222(a)(1)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(1)).

Back to Citation 173.

                         
                        See [45 CFR 156.222(a)(2)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(2)).

Back to Citation 174.

                         
                        See [45 CFR 156.222(a)(2)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(2)).

Back to Citation 175.

                         
                        See [45 CFR 156.222(a)(3)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(3)).

Back to Citation 176.

                         
                        See [45 CFR 156.222(a)(5)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(5)).

Back to Citation 177.

                         
                        See [45 CFR 156.222(a)(4)(i)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(4)(i)).

Back to Citation 178.

                         
                        See [45 CFR 156.222(a)(4)(i)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(4)(i)).

Back to Citation 179.

                         
                        See [45 CFR 156.222(a)(4)(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(4)(ii)).

Back to Citation 180.

                         
                        See [45 CFR 156.222(a)(4)(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(4)(ii)).

Back to Citation 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](https://www.federalregister.gov/citation/89-FR-8833)).

182.

                         
                        See [45 CFR 156.222(a)(4)(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(4)(ii)).

Back to Citation 183.

                         
                        See [45 CFR 156.222(a)(4)(ii)(D)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(a)(4)(ii)(D)).

Back to Citation 184.

                         
                        See [45 CFR 156.222(b)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)).

Back to Citation 185.

                         
                        See [45 CFR 156.222(b)(5)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(5)).

Back to Citation 186.

                         
                        See [45 CFR 156.222(b)(4)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(4)).

Back to Citation 187.

                         
                        See [45 CFR 156.222(b)(2)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(2)).

Back to Citation 188.

                         
                        See [45 CFR 156.222(b)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)).

Back to Citation 189.

                         
                        See [45 CFR 156.222(b)(2)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(2)).

Back to Citation 190.

                         
                        See [45 CFR 156.222(b)(2)(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(2)(ii)).

Back to Citation 191.

                         
                        See [45 CFR 156.222(b)(7)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(7)).

Back to Citation 192.

                         
                        See [45 CFR 156.222(b)(7)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(7)).

Back to Citation 193.

                         
                        See [45 CFR 156.222(b)(7)(i)-(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(7)(i)).

Back to Citation 194.

                         
                        See [45 CFR 156.222(b)(7)(iii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(7)(iii)).

Back to Citation 195.

                         
                        See [45 CFR 156.222(b)(4)(iv)(A)](https://www.ecfr.gov/current/title-45/section-156.222#p-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](https://www.federalregister.gov/citation/89-FR-8834)).

Back to Citation 196.

                         
                        See [45 CFR 156.222(b)(4)(iv)(B)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(4)(iv)(B)).

Back to Citation 197.

                         
                        See [45 CFR 156.222(b)(4)(v)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(4)(v)).

Back to Citation 198.

                         
                        See [45 CFR 156.222(b)(6)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(6)).

Back to Citation 199.

                         
                        See [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)).

Back to Citation 200.

                         
                        See [45 CFR 156.223(a)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(a)).

Back to Citation 201.

                         
                        See [45 CFR 156.223(c)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(c)).

Back to Citation 202.

                         See [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)).

Back to Citation 203.

                         
                        See [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)).

Back to Citation 204.

                         
                        See [45 CFR 156.223(a)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(a)).

Back to Citation 205.

                         
                        See [45 CFR 156.223(c)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(c)).

Back to Citation 206.

                         
                        See 
                         156.221(h) for the Patient Access API, [45 CFR 156.222(c)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(c)) for the Provider Access and Payer-to-Payer APIs, and [45 CFR 156.223(d)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(d)) for the Prior Authorization API.

Back to Citation 207.

                         For the Patient Access API, see [45 CFR 156.221(h)](https://www.ecfr.gov/current/title-45/section-156.221#p-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)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(c)(1)) for state Medicaid FFS programs, [42 CFR 457.731(c)(1)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(c)(1)) and [(2)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(c)(2)) for state CHIP FFS programs, and [45 CFR 156.222(c)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(c)) for QHP issuers on the FFEs. For the Prior Authorization API, see [42 CFR 431.80(c)(1)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(c)(1)) for state Medicaid FFS programs, [42 CFR 457.732(d)(1)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(d)(1)) for state CHIP FFS programs, and [45 CFR 156.223(d)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(d)) for QHP issuers on the FFEs.

Back to Citation 208.

                         See, for instance, cross-references to SMART Launch IG in [45 CFR 170.215(c)](https://www.ecfr.gov/current/title-45/section-170.215#p-170.215(c)) and OpenID Connect Core in [45 CFR 170.215(e)](https://www.ecfr.gov/current/title-45/section-170.215#p-170.215(e)), for the Patient Access API in [42 CFR 422.119(c)(1)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(c)(1)) for MA organizations, [42 CFR 431.60(c)(1)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(c)(1)) for state Medicaid FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, [42 CFR 457.730(c)(1)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(c)(1)) for CHIP FFS programs, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(c)(1)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(c)(1)) for individual market QHP issuers on the FFEs.

Back to Citation 209.

                         For the Patient Access API, see [45 CFR 156.221(h)](https://www.ecfr.gov/current/title-45/section-156.221#p-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)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(c)(1)) for state Medicaid FFS programs, [42 CFR 457.731(c)(1)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(c)(1)) and [(2)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(c)(2)) for state CHIP FFS programs, and [45 CFR 156.222(c)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(c)) for QHP issuers on the FFEs. For the Prior Authorization API, see [42 CFR 431.80(c)(1)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(c)(1)) for state Medicaid FFS programs, [42 CFR 457.732(d)(1)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(d)(1)) for state CHIP FFS programs, and [45 CFR 156.223(d)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(d)) for QHP issuers on the FFEs.

Back to Citation 210.

                         
                        See [42 CFR 422.119(d)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(d)) for MA organizations, [42 CFR 431.60(d)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(d)) for state Medicaid FFS programs, [42 CFR 457.730(d)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(d)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(d)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(d)) for QHP issuers on the FFEs.

Back to Citation 211.

                         
                        See [42 CFR 422.119(d)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(d)) for MA organizations, [42 CFR 431.60(d)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(d)) for state Medicaid FFS programs, [42 CFR 457.730(d)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(d)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(d)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(d)) for QHP issuers on the FFEs.

Back to Citation 212.

                         
                        See [42 CFR 422.119(d)(1)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(d)(1)) for MA organizations, [42 CFR 431.60(d)(1)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(d)(1)) for state Medicaid FFS programs, [42 CFR 457.730(d)(1)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(d)(1)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(d)(1)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(d)(1)) for QHP issuers on the FFEs.

Back to Citation 213.

                         
                        See [42 CFR 422.119(d)(3)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(d)(3)) for MA organizations, [42 CFR 431.60(d)(3)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(d)(3)) for state Medicaid FFS programs, [42 CFR 457.730(d)(3)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(d)(3)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(d)(3)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(d)(3)) for QHP issuers on the FFEs.

Back to Citation 214.

                         
                        See [42 CFR 422.119(d)(2)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(d)(2)) for MA organizations, [42 CFR 431.60(d)(2)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(d)(2)) for state Medicaid FFS programs, [42 CFR 457.730(d)(2)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(d)(2)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(d)(2)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(d)(2)) for QHP issuers on the FFEs.

Back to Citation 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)](https://www.govinfo.gov/link/uscode/42/18031), [18041(a)](https://www.govinfo.gov/link/uscode/42/18041)). See section II.E.7. of this proposed rule for a detailed discussion of statutory authorities.

Back to Citation 216.

                         Health Level Seven International. (2023, March 26). Resource Capability Statement—Content. Retrieved from *[https://hl7.org/​fhir/​capabilitystatement.html](https://hl7.org/fhir/capabilitystatement.html).*

Back to Citation 217.

                         
                        See [42 CFR 422.119(d)(1)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(d)(1)) for MA organizations, [42 CFR 431.60(d)(1)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(d)(1)) for state Medicaid FFS programs, [42 CFR 457.730(d)(1)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(d)(1)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(d)(1)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(d)(1)) for QHP issuers on the FFEs.

Back to Citation 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)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(d)(2)) for MA organizations, [42 CFR 431.60(d)(2)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(d)(2)) for state Medicaid FFS programs, [42 CFR 457.730(d)(2)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(d)(2)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(d)(2)](https://www.ecfr.gov/current/title-45/section-156.221#p-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.

Back to Citation 220.

                         Health Level Seven International. (2023, March 26). FHIR Security. Retrieved from *[https://hl7.org/​fhir/​security.html#binding](https://hl7.org/fhir/security.html#binding).*

Back to Citation 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.

Back to Citation 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](https://hl7.org/fhir/us/ndh/STU1/index.html).*

Back to Citation 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](https://hl7.org/fhir/us/ndh/STU1/StructureDefinition-ndh-Endpoint.html).*

Back to Citation 224.

                         
                        See [89 FR 8784](https://www.federalregister.gov/citation/89-FR-8784).

Back to Citation 225.

                         
                        See [89 FR 8818](https://www.federalregister.gov/citation/89-FR-8818).

Back to Citation 226.

                         
                        See [89 FR 8840](https://www.federalregister.gov/citation/89-FR-8840) and [8841](https://www.federalregister.gov/citation/89-FR-8841).

Back to Citation 227.

                         
                        See [85 FR 25526](https://www.federalregister.gov/citation/85-FR-25526).

Back to Citation 228.

                         
                        See [89 FR 8785](https://www.federalregister.gov/citation/89-FR-8785).

Back to Citation 229.

                         
                        See [89 FR 8840](https://www.federalregister.gov/citation/89-FR-8840) and [8841](https://www.federalregister.gov/citation/89-FR-8841).

Back to Citation 230.

                         
                        See [89 FR 8899](https://www.federalregister.gov/citation/89-FR-8899).

Back to Citation 231.

                         
                        See [89 FR 8786](https://www.federalregister.gov/citation/89-FR-8786).

Back to Citation 232.

                         
                        See [89 FR 8819](https://www.federalregister.gov/citation/89-FR-8819).

Back to Citation 233.

                         
                        See [89 FR 8840](https://www.federalregister.gov/citation/89-FR-8840) and [8841](https://www.federalregister.gov/citation/89-FR-8841).

Back to Citation 234.

                         
                        See [89 FR 8900](https://www.federalregister.gov/citation/89-FR-8900).

Back to Citation 235.

                         
                        See [89 FR 8840](https://www.federalregister.gov/citation/89-FR-8840) and [8841](https://www.federalregister.gov/citation/89-FR-8841).

Back to Citation 236.

                         
                        See [42 CFR 422.119(b)(1)(iv)(A)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(b)(1)(iv)(A)) for MA organizations, [42 CFR 431.60(b)(5)(i)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(b)(5)(i)) for state Medicaid FFS programs, [42 CFR 457.730(b)(5)(i)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(b)(5)(i)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(b)(1)(iv)(A)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(b)(1)(iv)(A)) for individual market QHP issuers on the FFEs.

Back to Citation 237.

                         
                        See [42 CFR 422.121(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(b)(4)(ii)(A)) for MA organizations, [42 CFR 431.61(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(4)(ii)(A)) for state Medicaid FFS programs, [42 CFR 457.731(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(b)(4)(ii)(A)) for state CHIP FFS programs, through cross reference to [42 CFR 431.61(b)(4)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(4)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.222(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(4)(ii)(A)) for individual market QHP issuers on the FFEs.

Back to Citation 238.

                         
                        See [42 CFR 422.121(b)(4)(ii)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(b)(4)(ii)) for MA organizations, [42 CFR 431.61(b)(4)(ii)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(4)(ii)) for state Medicaid FFS programs, [42 CFR 457.731(b)(4)(ii)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(b)(4)(ii)) for state CHIP FFS programs, through cross reference to [42 CFR 431.61(b)(4)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(4)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.222(b)(4)(ii)](https://www.ecfr.gov/current/title-45/section-156.222#p-156.222(b)(4)(ii)) for individual market QHP issuers on the FFEs.

Back to Citation 239.

                         
                        See [42 CFR 422.119(f)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(f)) for MA organizations, [42 CFR 431.60(f)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(f)) for state Medicaid FFS programs, [42 CFR 457.730(f)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(f)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)(iii)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)(iii)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities.

Back to Citation 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](https://www.cms.gov/files/document/draft-2027-letter-issuers.pdf).*

Back to Citation 241.

                         
                        See [42 CFR 422.119(f)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(f)) for MA organizations, [42 CFR 431.60(f)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(f)) for state Medicaid FFS programs, [42 CFR 457.730(f)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(f)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)(iii)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)(iii)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.221(f)](https://www.ecfr.gov/current/title-45/section-156.221#p-156.221(f)) for individual market QHP issuers on the FFEs.

Back to Citation 242.

                         
                        See 
                         FAQ #3 citing the requirements in [42 CFR 438.66(e)(1)](https://www.ecfr.gov/current/title-42/section-438.66#p-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](https://www.medicaid.gov/sites/default/files/2024-04/mcpar-faq-march-2024v.2.pdf).*

Back to Citation 243.

                         For example, [45 CFR 156.220(b)](https://www.ecfr.gov/current/title-45/section-156.220#p-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.

Back to Citation 244.

                         Information about QHP certification, including deadlines, can be found at *[https://www.qhpcertification.cms.gov/​QHP/​aboutthemarketplace/​Timeline](https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline).*

Back to Citation 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](https://www.cms.gov/files/document/draft-2027-letter-issuers.pdf).*

Back to Citation 246.

                         
                        See [42 CFR 422.122(b)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(b)) for MA organizations, [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) for state Medicaid FFS programs, [42 CFR 457.732(b)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(b)) for state CHIP FFS programs, through cross reference to [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care 

                        plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for individual market QHP issuers on the FFEs.

Back to Citation 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)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(a)(2)) requires MA organizations to include in their Provider Access APIs information that is listed in [42 CFR 422.119(b)](https://www.ecfr.gov/current/title-42/section-422.119#p-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)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(b)) in [42 CFR 422.121(a)(2)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(a)(2)) (Provider Access API) and in [42 CFR 422.121(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-422.121#p-422.121(b)(4)(ii)(A)) (Payer-to-Payer API) for MA organizations, through cross reference to [42 CFR 431.60(b)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(b)) in [42 CFR 431.61(a)(2)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(a)(2)) (Provider Access API) and in [42 CFR 431.61(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(b)(4)(ii)(A)) (Payer-to-Payer API) for state Medicaid FFS programs, through cross reference to [42 CFR 457.730(b)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(b)) in [42 CFR 457.731(a)(2)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(a)(2)) (Provider Access API) and in [42 CFR 457.731(b)(4)(ii)(A)](https://www.ecfr.gov/current/title-42/section-457.731#p-457.731(b)(4)(ii)(A)) (Payer-to-Payer API) for state CHIP FFS programs, through cross reference to [42 CFR 431.61](https://www.ecfr.gov/current/title-42/section-431.61) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) (Provider Access and Payer-to-Payer APIs), and through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) (Provider Access and Payer-to-Payer APIs).

Back to Citation 248.

                         Qualified Health Plan Certification Information and Guidance. Machine-Readable Data. Retrieved from *[https://www.qhpcertification.cms.gov/​s/​Machine-Readable%20Data](https://www.qhpcertification.cms.gov/s/Machine-Readable%2520Data).*

Back to Citation 249.

                         
                        See [42 CFR 422.120](https://www.ecfr.gov/current/title-42/section-422.120) for MA organizations, [42 CFR 431.70](https://www.ecfr.gov/current/title-42/section-431.70) for state Medicaid FFS programs, [42 CFR 457.760](https://www.ecfr.gov/current/title-42/section-457.760) for state CHIP FFS programs, [42 CFR 438.242(b)(6)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(6)) for Medicaid managed care plans, and [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities.

Back to Citation 250.

                         
                        See [42 CFR 422.119(e)](https://www.ecfr.gov/current/title-42/section-422.119#p-422.119(e)) for MA organizations, [42 CFR 431.60(e)](https://www.ecfr.gov/current/title-42/section-431.60#p-431.60(e)) for state Medicaid FFS programs, [42 CFR 457.730(e)](https://www.ecfr.gov/current/title-42/section-457.730#p-457.730(e)) for state CHIP FFS programs, through cross reference to [42 CFR 431.60](https://www.ecfr.gov/current/title-42/section-431.60) in [42 CFR 438.242(b)(5)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(5)) for Medicaid managed care plans, and through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities.

Back to Citation 251.

                         
                        See [45 CFR 156.230(c)](https://www.ecfr.gov/current/title-45/section-156.230#p-156.230(c)).

Back to Citation 252.

                         
                        See [42 CFR 422.112(b)(8)(i)(B)](https://www.ecfr.gov/current/title-42/section-422.112#p-422.112(b)(8)(i)(B)).

Back to Citation 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.

Back to Citation 254.

                         The regulation in [42 CFR 431.306(d)](https://www.ecfr.gov/current/title-42/section-431.306#p-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.

Back to Citation 255.

                         
                        See [42 CFR 431.61(a)(4)](https://www.ecfr.gov/current/title-42/section-431.61#p-431.61(a)(4)).

Back to Citation 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](https://aspe.hhs.gov/sites/default/files/documents/5f6e4d78d867b6691df12d1512787470/medicaid-churning-ib.pdf).*

Back to Citation 257.

                         
                        See [42 U.S.C. 1320a](https://www.govinfo.gov/link/uscode/42/1320a).

Back to Citation 258.

                         
                        See [42 CFR 403.902](https://www.ecfr.gov/current/title-42/section-403.902).

Back to Citation 259.

                         
                        See [42 CFR 403.904(e)(2)](https://www.ecfr.gov/current/title-42/section-403.904#p-403.904(e)(2)).

Back to Citation 260.

                         
                        See [42 CFR 403.904 (c)](https://www.ecfr.gov/current/title-42/section-403.904#p-403.904(c)).

Back to Citation 261.

                         
                        See [42 CFR 403.904(c)(8)](https://www.ecfr.gov/current/title-42/section-403.904#p-403.904(c)(8)).

Back to Citation 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.”

Back to Citation 263.

                         
                        See [42 CFR 403.904(h)(2)(iii)](https://www.ecfr.gov/current/title-42/section-403.904#p-403.904(h)(2)(iii)).

Back to Citation 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](https://www.federalregister.gov/citation/78-FR-9506) - [78 FR 9507](https://www.federalregister.gov/citation/78-FR-9507)).

Back to Citation 265.

                         
                        See [42 CFR 403.912(e)(1)(ii)](https://www.ecfr.gov/current/title-42/section-403.912#p-403.912(e)(1)(ii)).

Back to Citation 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)](https://www.ecfr.gov/current/title-42/section-403.912#p-403.912(e)(2)).

Back to Citation 267.

                         
                        See [45 CFR 102.3](https://www.ecfr.gov/current/title-45/section-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.

Back to Citation 268.

                         
                        See [45 CFR 160.103](https://www.ecfr.gov/current/title-45/section-160.103) for the definition of a HIPAA covered entity.

Back to Citation 269. See, for example, sections 1173(i) and 1174(b) of the Act.

Back to Citation 270.

                         American Medical Association. (2025). 2024 AMA prior authorization physician survey. Retrieved from *[https://www.ama-assn.org/​system/​files/​prior-authorization-survey.pdf](https://www.ama-assn.org/system/files/prior-authorization-survey.pdf).*

Back to Citation 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](https://www.reginfo.gov/public/do/DownloadDocument?objectID=6139801).*

Back to Citation 272.

                         X12. (n.d.). Health Care Transaction Flow, Step 11: Health Care Services Review Request. Retrieved from *[https://x12.org/​flow/​health-care](https://x12.org/flow/health-care).*

Back to Citation 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](https://www.ecfr.gov/current/title-45/section-160.103)).

Back to Citation 274.

                         Nothing precludes such transactions from being intermediated by clearinghouses, though traditionally they have not largely engaged in that role for prior authorization.

Back to Citation 275.

                         The FHIR standard, adopted by the Secretary as the “API base standard” in [45 CFR 170.215(a)](https://www.ecfr.gov/current/title-45/section-170.215#p-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.

Back to Citation 276.

                         Health Level Seven International. (2023, March 26.). Introduction to HL7 FHIR. Retrieved from *[https://hl7.org/​fhir/​summary.html](https://hl7.org/fhir/summary.html).*

Back to Citation 277.

                         Health Level Seven International. (2025, December 10). US Core Implementation Guide. Retrieved from *<a href="https://hl7.org/fhir/us/core/">https://hl7.org/​fhir/​us/​core/</a>.*

Back to Citation 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](https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi).*

Back to Citation 279.

                         Health Level Seven International. (2023, March 1). SMART App Launch IG. Retrieved from *<a href="https://hl7.org/fhir/smart-app-launch/">https://hl7.org/​fhir/​smart-app-launch/</a>.*

Back to Citation 280.

                         SMART. (n.d.). SMART on FHIR API. Retrieved from *<a href="https://smarthealthit.org/smart-on-fhir-api/">https://smarthealthit.org/​smart-on-fhir-api/</a>.*

Back to Citation 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](http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr).*

Back to Citation 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](http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas).*

Back to Citation 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](https://confluence.hl7.org/spaces/DVP/pages/113675673/Da+Vinci+HIPAA+Exception?preview=/113675673/113675685/Approval%2520%25232021031001.pdf).*

Back to Citation 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](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process).*

Back to Citation 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](https://confluence.hl7.org/download/attachments/113675673/HL7%2520Da%2520Vinci%2520Exception%2520Report_Final%2520%2528June%252025%252C%25202024%2529.pdf?version=1&modificationDate=1731382945836&api=v2).*

Back to Citation 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](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](https://www.healthit.gov/sites/default/files/page/2020-11/2020-11-17_ICAD_TF_FINAL_Report_HITAC.pdf).*

Back to Citation 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](https://www.healthit.gov/sites/default/files/page/2020-11/2020-11-17_ICAD_TF_FINAL_Report_HITAC.pdf)*.

Back to Citation 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](http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex).*

Back to Citation 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](https://ncvhs.hhs.gov/wp-content/uploads/2022/08/Recommendation-Letter-Modernize-Adoption-of-HIPAA-Transaction-Standards-508.pdf).*

Back to Citation 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](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](https://www.federalregister.gov/citation/86-FR-33318). Retrieved from *[https://ncvhs.hhs.gov/​wp-content/​uploads/​2021/​11/​Public-Comments-Standards-Subcommittee-Listening-Session-August-25-2021.pdf](https://ncvhs.hhs.gov/wp-content/uploads/2021/11/Public-Comments-Standards-Subcommittee-Listening-Session-August-25-2021.pdf).*

Back to Citation 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](https://ncvhs.hhs.gov/wp-content/uploads/2022/08/Recommendation-Letter-Modernize-Adoption-of-HIPAA-Transaction-Standards-508.pdf).*

Back to Citation 295. See, for example, 89 FR 100763 (Version D.0/Version 1.2 to Version F6/Version 15 8 months transition period).

Back to Citation 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](https://www.federalregister.gov/citation/89-FR-8938))

Back to Citation 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](https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf).*

Back to Citation 298.

                         CAQH. (n.d.). 2024 CAQH Index Report. Retrieved from *[https://www.caqh.org/​hubfs/​Index/​2024%20Index%20Report/​CAQH_​IndexReport_​2024_​FINAL.pdf](https://www.caqh.org/hubfs/Index/2024%2520Index%2520Report/CAQH_IndexReport_2024_FINAL.pdf).*

Back to Citation 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](https://www.federalregister.gov/d/2022-27437/p-141)* and the CDex IG proposal in subsequent pages of this section.

Back to Citation 300.

                         American Medical Association. (2024). 2024 AMA Prior Authorization Physician Survey. Retrieved from *[https://www.ama-assn.org/​system/​files/​prior-authorization-survey.pdf](https://www.ama-assn.org/system/files/prior-authorization-survey.pdf).*

Back to Citation 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](https://www.caqh.org/hubfs/Index/2024%2520Index%2520Report/CAQH_IndexReport_2024_FINAL.pdf).*

Back to Citation 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](https://confluence.hl7.org/download/attachments/113675673/HL7%2520Da%2520Vinci%2520Exception%2520Report_Final%2520%2528June%252025%252C%25202024%2529.pdf?version=1&modificationDate=1731382945836&api=v2).*

Back to Citation 303.

                         American Medical Association. (2024). 2024 AMA Prior Authorization Physician Survey. Retrieved from *[https://www.ama-assn.org/​system/​files/​prior-authorization-survey.pdf](https://www.ama-assn.org/system/files/prior-authorization-survey.pdf).*

Back to Citation 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](https://confluence.hl7.org/download/attachments/113675673/HL7%2520Da%2520Vinci%2520Exception%2520Report_Final%2520%2528June%252025%252C%25202024%2529.pdf?version=1&modificationDate=1731382945836&api=v2).*

Back to Citation 305.

                         Those operating rules are available at *[https://www.caqh.org/​core/​operating-rules](https://www.caqh.org/core/operating-rules).*

Back to Citation 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](https://confluence.hl7.org/download/attachments/113675673/HL7%2520Da%2520Vinci%2520Exception%2520Report_Final%2520%2528June%252025%252C%25202024%2529.pdf?version=1&modificationDate=1731382945836&api=v2).*

Back to Citation 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](https://confluence.hl7.org/download/attachments/113675673/HL7%2520Da%2520Vinci%2520Exception%2520Report_Final%2520%2528June%252025%252C%25202024%2529.pdf?version=1&modificationDate=1731382945836&api=v2).*

Back to Citation 308.

                         HIPAA § 261 as amended by § 1104 of the Patient Protection and Affordable Care Act ([Public Law 111-148](https://www.govinfo.gov/link/plaw/111/public/148) as amended by [Public Law 111-152](https://www.govinfo.gov/link/plaw/111/public/152)).

Back to Citation 309.

                         Health Level Seven International. (n.d.). Da Vinci Clinical Data Exchange (CDex) IG. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-cdex/">https://hl7.org/​fhir/​us/​davinci-cdex/</a>.*

Back to Citation 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](https://ncvhs.hhs.gov/wp-content/uploads/2022/08/Recommendation-Letter-Modernize-Adoption-of-HIPAA-Transaction-Standards-508.pdf).*

Back to Citation 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](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process).*

Back to Citation 312.

                         As defined in [45 CFR 160.103](https://www.ecfr.gov/current/title-45/section-160.103), small health plans are those with annual receipts of $5 million or less.

Back to Citation 313.

                         
                        See [42 CFR 422.122(b)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(b)) for MA organizations, [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) for state Medicaid FFS programs, [42 CFR 457.732(b)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(b)) for state CHIP FFS programs, through cross reference to [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in 432 CFR 457.1233(d) for CHIP managed care entities, and [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for QHP issuers on the FFEs.

Back to Citation 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](https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf).*

Back to Citation 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](https://www.ansi.org/american-national-standards/info-for-standards-developers/accredited-standards-developers#q=Health%2520Level%2520Seven%2520International&sort=%2540titlecomputed%2520ascending).*

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](https://www.hl7.org/implement/standards/ansiapproved.cfm?ref=nav).*

Back to Citation 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](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/events-latest-news).*

Back to Citation 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](https://www.caqh.org/hubfs/Index/2024%2520Index%2520Report/CAQH_IndexReport_2024_FINAL.pdf).*

Back to Citation 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](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](https://www.healthit.gov/sites/default/files/page/2020-03/HITAC%2520Annual%2520Report%2520for%2520FY19_508.pdf).*

Back to Citation 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](https://www.healthit.gov/sites/default/files/page/2019-12/2019-10-16_ISP_TF_Final_Report_signed_508.pdf).*

Back to Citation 322.

                         Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology. (n.d.). Interoperability Standards Platform. Retrieved from *<a href="https://www.healthit.gov/isp/">https://www.healthit.gov/​isp/</a>.*

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](https://www.healthit.gov/isp/about-isa).*

Back to Citation 324.

                         Health Leven Seven International. (2026, March 27). Da Vinci Coverage Requirements Discovery IG. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-crd/2.2.1/en/">https://hl7.org/​fhir/​us/​davinci-crd/​2.2.1/​en/</a>.*

Back to Citation 325.

                         Health Level Seven International. (2026, March 27). Da Vinci Documentation Templates and Rules IG. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/">https://hl7.org/​fhir/​us/​davinci-dtr/​2.2.0/​en/</a>.*

Back to Citation 326.

                         Health Leven Seven International. (2026, March 27). Da Vinci Prior Authorization Support (PAS) FHIR IG. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-pas/2.2.1/en/">https://hl7.org/​fhir/​us/​davinci-pas/​2.2.1/​en/</a>.*

Back to Citation 327.

                         Health Leven Seven International. (2026, March 27). CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button). Retrieved from *<a href="https://build.fhir.org/ig/HL7/carin-bb/en/">https://build.fhir.org/​ig/​HL7/​carin-bb/​en/</a>*

Back to Citation 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](http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex).*

Back to Citation 329.

                         Health Leven Seven International. (2025, February 25). Da Vinci PDex Plan Net IG. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.2/">https://hl7.org/​fhir/​us/​davinci-pdex-plan-net/​STU1.2/</a>.*

Back to Citation 330.

                         Health Leven Seven International. (2025, February 11). Da Vinci CDex IG. Retrieved from *<a href="https://build.fhir.org/ig/HL7/davinci-ecdx/">https://build.fhir.org/​ig/​HL7/​davinci-ecdx/</a>.*

Back to Citation 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](https://www.healthit.gov/data/quickstats/hospital-routine-electronic-notification).*

Back to Citation 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](https://www.ncbi.nlm.nih.gov/books/NBK606653/pdf/Bookshelf_NBK606653.pdf).*

Back to Citation 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 *<a href="https://www.ncbi.nlm.nih.gov/books/NBK606033/">https://www.ncbi.nlm.nih.gov/​books/​NBK606033/</a>.*

Back to Citation 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](https://www.cms.gov/files/document/qso-21-18-hospitals-cahs.pdf).*

Back to Citation 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](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](https://developer.healthgorilla.com/docs/adt-network).*

Back to Citation 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](https://www.healthit.gov/data/data-briefs/standards-adoption-among-health-information-exchange-organizations).*

Back to Citation 338.

                         Office of the National Coordinator for Health IT. (2026, February 11). TEFCA. Retrieved from *<a href="https://healthit.gov/policy/tefca/">https://healthit.gov/​policy/​tefca/</a>.*

Back to Citation 339.

                         Health Level Seven International FHIR. (2024, October 2). Topic-Based Subscriptions Framework. Retrieved from *[https://build.fhir.org/​subscriptions.html](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](https://build.fhir.org/subscriptiontopic.html).*

Back to Citation 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](https://build.fhir.org/ig/HL7/davinci-alerts/usecases.html).*

Back to Citation 342.

                         Office of the National Coordinator for Health IT. (2026, February 11). TEFCA. Retrieved from *<a href="https://healthit.gov/policy/tefca/">https://healthit.gov/​policy/​tefca/</a>.*

Back to Citation 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](http://hl7.org/fhir/us/davinci-atr/ImplementationGuide/hl7.fhir.us.davinci-atr).*

Back to Citation 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](https://www.youtube.com/watch?v=VnbBxxyZLc8).*

Back to Citation 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](https://www.ibm.com/reports/data-breach).*

Back to Citation 346.

                         
                        See 
                         sections 262(aa) and 264(c) of [Public Law 104-191](https://www.govinfo.gov/link/plaw/104/public/191).

Back to Citation 347.

                         
                        See [45 CFR part 160](https://www.ecfr.gov/current/title-45/part-160) and [45 CFR part 164, subparts A](https://www.ecfr.gov/current/title-45/part-164/subpart-A) and [C](https://www.ecfr.gov/current/title-45/part-164/subpart-C).

348.

                         
                        See [45 CFR 164.306(a)](https://www.ecfr.gov/current/title-45/section-164.306#p-164.306(a)).

Back to Citation 349.

                         
                        See [45 CFR 164.306(b)-(d)](https://www.ecfr.gov/current/title-45/section-164.306#p-164.306(b)).

Back to Citation 350.

                         
                        See [45 CFR 164.306(e)](https://www.ecfr.gov/current/title-45/section-164.306#p-164.306(e)).

Back to Citation 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](https://www.congress.gov/bill/113th-congress/senate-bill/2521/text).*

Back to Citation 352.

                         Federal Information Security Modernization Act of 2014. ([Pub. L. 113-283](https://www.govinfo.gov/link/plaw/113/public/283), 3554, Dec. 18, 2014, 128 Stat. 2751).

Back to Citation 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](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](https://oig.hhs.gov/reports-and-publications/workplan/summary/wp-summary-0000665_2.asp#:~:text=and%2520transmitted%2520securely.-,Review%2520of%2520Medicare%2520Administrative%2520Contractor%2520Information%2520Security%2520Program%2520Evaluations%2520for,of%2520their%2520Section%2520912%2520evaluations).*

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](https://www.congress.gov/bill/108th-congress/house-bill/1).*

Back to Citation 356. Public Law 111-5, 123 Stat. 226 (Feb. 17, 2009).

Back to Citation 357.

                         Sec. 13401(a) and (b) of [Public Law 111-5](https://www.govinfo.gov/link/plaw/111/public/5), 123 Stat. 260 (codified in [42 U.S.C. 17931(a)](https://www.govinfo.gov/link/uscode/42/17931) and [(b)](https://www.govinfo.gov/link/uscode/42/17931)).

Back to Citation 358.

                         Sec. 13401(c) of [Public Law 111-5](https://www.govinfo.gov/link/plaw/111/public/5), 123 Stat. 260 (codified in [42 U.S.C. 17931(c)](https://www.govinfo.gov/link/uscode/42/17931)).

Back to Citation 359.

                         
                        See [Public Law 116-321](https://www.govinfo.gov/link/plaw/116/public/321), 134 Stat. 5072, adding sec. 13412 (Jan. 5, 2021) (codified in [42 U.S.C. 17941](https://www.govinfo.gov/link/uscode/42/17941)); see also [42 U.S.C. 17931](https://www.govinfo.gov/link/uscode/42/17931) *et seq.*

Back to Citation 360.

                         The White House. (2024, April 30). National Security Memorandum on Critical Infrastructure Security and Resilience. Retrieved from *<a href="https://bidenwhitehouse.archives.gov/briefing-room/presidential-actions/2024/04/30/national-security-memorandum-on-critical-infrastructure-security-and-resilience/">https://bidenwhitehouse.archives.gov/​briefing-room/​presidential-actions/​2024/​04/​30/​national-security-memorandum-on-critical-infrastructure-security-and-resilience/</a>.*

Back to Citation 361.

                         Centers for Medicare & Medicaid Services. (2025, July 31). CMS Interoperability Framework. Retrieved from *[https://www.cms.gov/​health-technology-ecosystem/​interoperability-framework](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](https://www.cms.gov/newsroom/press-releases/white-house-tech-leaders-commit-create-patient-centric-healthcare-ecosystem).*

Back to Citation 363.

                         Office of the National Coordinator for Health Information Technology. (2018, November). SAFER Guides. Retrieved from *[https://www.healthit.gov/​topic/​safety/​safer-guides](https://www.healthit.gov/topic/safety/safer-guides).*

Back to Citation 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](https://www.cms.gov/files/document/cms-safer-guides-infographic-2023.pdf).*

Back to Citation 365.

                         Office of the National Coordinator for Health IT. (2025, February 21). SAFER Guides. Retrieved from *[https://www.healthit.gov/​topic/​safety/​safer-guides](https://www.healthit.gov/topic/safety/safer-guides).*

Back to Citation 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](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](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](https://www.youtube.com/usgovhhsocr).*

Back to Citation 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](https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool).*

Back to Citation 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](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](https://bidenwhitehouse.archives.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf).*

Back to Citation 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](https://hhscyber.hhs.gov/performance-goals.html).*

Back to Citation 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](https://aspr.hhs.gov/cip/hph-cybersecurity-framework-implementation-guide/Pages/default.aspx).*

Back to Citation 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](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](https://www.ftc.gov/system/files/ftc_gov/pdf/920a_start_with_security_en_aug2023_508_final_0.pdf).*

Back to Citation 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](https://csrc.nist.gov/pubs/sp/800/66/r2/final).*

Back to Citation 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](https://dx.doi.org/10.2139/ssrn.4579292).*

Back to Citation 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](https://nsarchive.gwu.edu/document/15310-health-care-industry-cybersecurity-task-force).*

Back to Citation 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.

Back to Citation 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](https://www.cisa.gov/sites/default/files/publications/CISA_Insight_Provide_Medical_Care_Sep2021.pdf).*

Back to Citation 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](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](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](https://www.gao.gov/blog/rising-cyberthreats-increase-cyber-insurance-premiums-while-reducing-availability#:~:text=In%2520our%25202021%2520report%252C%2520we,instead%2520offering%2520cyber%2520coverage%2520separately).*

Back to Citation 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](https://www.ecfr.gov/current/title-45/section-170.102).

Back to Citation 384.

                         Centers for Medicare & Medicaid Services (2024). CMS Interoperability. Retrieved from *[https://www.cms.gov/​priorities/​key-initiatives/​burden-reduction/​interoperability/​cms-interoperability](https://www.cms.gov/priorities/key-initiatives/burden-reduction/interoperability/cms-interoperability).*

Back to Citation 385.

                         Standardized APIs enable one software applicable to access the services or data of another, securely and efficiently, without human intervention.

Back to Citation 386.

                         Office of the National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov Test Kits. Retrieved from *<a href="https://inferno.healthit.gov/test-kits/">https://inferno.healthit.gov/​test-kits/</a>.*

Back to Citation 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](https://www.healthit.gov/topic/certification-ehrs/onc-approved-testing-partners).*

Back to Citation 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.

Back to Citation 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.*

Back to Citation 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](https://www.jstor.org/stable/26661167).*

Back to Citation 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.

Back to Citation 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.*

Back to Citation 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.

Back to Citation 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](https://www.cms.gov/priorities/innovation/innovation-models/wiser).*

Back to Citation 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](https://www.cms.gov/priorities/innovation/key-concepts/voluntary-vs-mandatory-participation).*

Back to Citation 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](https://www.ama-assn.org/practice-management/prior-authorization/fixing-prior-auth-first-speed-payers-response-times#:~:text=Survey%2520data%2520from%25202024%2520has,a%2520week%2520for%2520an%2520answer).*

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](https://www.careviso.com/news-events/how-long-does-prior-authorization-take#:~:text=How%2520Long%2520Does%2520Prior%2520Authorization,potential%2520for%2520delays%2520in%2520care).*

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 *<a href="https://www.kff.org/patient-consumer-protections/poll-finding/kff-health-tracking-poll-public-finds-prior-authorization-process-difficult-to-manage/">https://www.kff.org/​patient-consumer-protections/​poll-finding/​kff-health-tracking-poll-public-finds-prior-authorization-process-difficult-to-manage/</a>.*

Back to Citation 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)](https://www.ecfr.gov/current/title-42/section-422.566#p-422.566(c)(1)(ii)).

Back to Citation 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 *<a href="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/">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/</a>.*

Back to Citation 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](https://www.cms.gov/medicare/payment/fee-schedules/clinical-laboratory-fee-schedule-clfs/date-service-policy).*

Back to Citation 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](https://www.federalregister.gov/citation/71-FR-69624)), which appeared in the **Federal Register** on December 1, 2006, and is set forth in [42 CFR 414.510](https://www.ecfr.gov/current/title-42/section-414.510).

Back to Citation 403.

                         
                        See [42 CFR 422.138(b)(1)](https://www.ecfr.gov/current/title-42/section-422.138#p-422.138(b)(1)) and [(2)](https://www.ecfr.gov/current/title-42/section-422.138#p-422.138(b)(2)).

Back to Citation 404.

                         
                        See [42 CFR 422.568(b)(1)(ii)](https://www.ecfr.gov/current/title-42/section-422.568#p-422.568(b)(1)(ii)) for MA organizations, [42 CFR 422.631(d)(2)(i)(B)](https://www.ecfr.gov/current/title-42/section-422.631#p-422.631(d)(2)(i)(B)) *(2)* for applicable integrated plans, [42 CFR 440.230(e)(1)(i)](https://www.ecfr.gov/current/title-42/section-440.230#p-440.230(e)(1)(i)) for state Medicaid FFS programs, [42 CFR 457.495(d)(2)(i)](https://www.ecfr.gov/current/title-42/section-457.495#p-457.495(d)(2)(i)) for state CHIP FFS programs, [42 CFR 438.210(d)(1)(i)(B)](https://www.ecfr.gov/current/title-42/section-438.210#p-438.210(d)(1)(i)(B)) for Medicaid managed care plans, and through cross reference to [42 CFR 438.210](https://www.ecfr.gov/current/title-42/section-438.210) in [42 CFR 457.1230(d)](https://www.ecfr.gov/current/title-42/section-457.1230#p-457.1230(d)) for CHIP managed care entities.

Back to Citation 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](https://www.ncart.us/uploads/userfiles/files/documents/Evidence%2520and%2520Guidance%2520Supporting%2520Coverage%2520of%2520Standing%2520Devices-%2520July%25202021%2520(2).pdf).*

406.

                         Mock, J.V., National Seating & Mobility. (2022, May 3). Tips to Overcome Documentation Burnout. Retrieved from *<a href="https://www.nsm-seating.com/journal/tips-to-overcome-documentation-burnout/">https://www.nsm-seating.com/​journal/​tips-to-overcome-documentation-burnout/</a>.*

Back to Citation 407.

                         U.S. Bureau of Labor Statistics. (*2024, May). National Occupational Employment and Wage Estimates.* Retrieved from *[https://data.bls.gov/​oes/​#/​industry/​000000](https://data.bls.gov/oes/#/industry/000000).*

Back to Citation 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)](https://www.govinfo.gov/link/uscode/26/424)).

Back to Citation 409.

                         Centers for Medicare & Medicaid Services. (2024). MA Plan Directory. Retrieved from *[https://www.cms.gov/​files/​zip/​ma-plan-directory-march-2024.zip](https://www.cms.gov/files/zip/ma-plan-directory-march-2024.zip).*

Back to Citation 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](https://data.medicaid.gov/dataset/0bef7b8a-c663-5b14-9a46-0b5c2b86b0fe/data?conditions%255b0%255d%255bproperty%255d=year&conditions%255b0%255d%255bvalue%255d=2021&conditions%255b0%255d%255boperator%255d=%253D).*

Back to Citation 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](https://data.healthcare.gov/dataset/2cfb30f4-7c65-42bd-bc4c-a3fbcf1cb2cd).*

Back to Citation 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)](https://www.govinfo.gov/link/uscode/42/11151)).

Back to Citation 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](https://www.federalregister.gov/citation/85-FR-25622)). 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.

Back to Citation 414.

                         
                        See [45 CFR 160.103](https://www.ecfr.gov/current/title-45/section-160.103).

Back to Citation 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](https://www.federalregister.gov/citation/89-FR-8758)).

Back to Citation 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](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.

Back to Citation 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](https://www.healthit.gov/data/quickstats/adoption-electronic-health-records-hospital-service-type-2019-2021).*

Back to Citation 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](https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019).*

Back to Citation 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](https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019).*

Back to Citation 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](https://www.sprypt.com/blog/guide-to-the-cost-of-ehr-implementation-for-healthcare-providers).*

Back to Citation 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 *<a href="https://www.healthit.gov/playbook/certified-health-it/">https://www.healthit.gov/​playbook/​certified-health-it/</a>.*

422.

                         Kalinin, K. (2025, May 8). EHR Implementation Cost Breakdown: Factors Affecting the Price in 2025. Topflight. Retrieved from *<a href="https://topflightapps.com/ideas/cost-of-ehr-implementation/">https://topflightapps.com/​ideas/​cost-of-ehr-implementation/</a>.*

Back to Citation 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](https://www.healthit.gov/data/quickstats/adoption-electronic-health-records-hospital-service-type-2019-2021).*

Back to Citation 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](https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019).*

Back to Citation 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](https://www.census.gov/data/tables/2022/econ/susb/2022-susb-annual.html).*

Back to Citation 426.

                         Office of the National Coordinator for Health Information Technology. (2025, August 11). Section 2: Certified Health IT. ASTP Health IT Playbook. Retrieved from *<a href="https://www.healthit.gov/playbook/certified-health-it/">https://www.healthit.gov/​playbook/​certified-health-it/</a>.*

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](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 *<a href="https://topflightapps.com/ideas/cost-of-ehr-implementation/">https://topflightapps.com/​ideas/​cost-of-ehr-implementation/</a>.*

Back to Citation 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](https://www.census.gov/data/tables/2022/econ/susb/2022-susb-annual.html).*

Back to Citation 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.

Back to Citation 431.

                         
                        See 
                         the 2020 CMS Interoperability and Patient Access final rule ([85 FR 25623](https://www.federalregister.gov/citation/85-FR-25623)) for information on the methodology used to define and identify parent organizations.

Back to Citation 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](https://www.caqh.org/hubfs/Index/2024%2520Index%2520Report/CAQH_IndexReport_2024_FINAL.pdf).*

Back to Citation 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](https://confluence.hl7.org/spaces/DVP/pages/113675673/Da+Vinci+HIPAA+Exception?preview=/113675673/113675685/Approval%2520%25232021031001.pdf).*

Back to Citation 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.

Back to Citation 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](https://www.ehrinpractice.com/largest-ehr-vendors.html).*

Back to Citation 436.

                         Newman, D. (2024, December 9). Top EHR Vendors 2025-Epic, Cerner/Oracle, Meditech, Allscripts. Healthcare IT Skills. Retrieved from *<a href="https://healthcareitskills.com/top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/">https://healthcareitskills.com/​top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/</a>.*

Back to Citation 437.

                         Newman, D. (2024, December 9). Top EHR Vendors 2025-Epic, Cerner/Oracle, Meditech, Allscripts. Healthcare IT Skills. Retrieved from *<a href="https://healthcareitskills.com/top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/">https://healthcareitskills.com/​top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/</a>.*

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](https://www.healthit.gov/data/quickstats/health-care-professional-certified-health-it-developers).*

Back to Citation 439.

                         MediBill RCM LLC. (2025, April 23). How Medical Billing Clearinghouses Work? A Deep Dive into Claim Submission & Processing. MediBill RCM LLC. Retrieved from *<a href="https://www.medibillrcm.com/blog/how-medical-billing-clearinghouses-work/">https://www.medibillrcm.com/​blog/​how-medical-billing-clearinghouses-work/</a>.*

Back to Citation 440.

                         Health Level Seven International. (2026, March 27). Da Vinci—Coverage Requirements Discovery (CRD) IG. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-crd/2.2.1/en/">https://hl7.org/​fhir/​us/​davinci-crd/​2.2.1/​en/</a>.*

Back to Citation 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](https://hl7.org/fhir/us/davinci-dtr/2.2./en/0).*

Back to Citation 442.

                         Health Level Seven International. (2026, March 27). Da Vinci—Prior Authorization Support (PAS) IG. Retrieved from *<a href="https://hl7.org/fhir/us/davinci-pas/2.2.1/en/">https://hl7.org/​fhir/​us/​davinci-pas/​2.2.1/​en/</a>.*

Back to Citation 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](https://www.federalregister.gov/d/2024-14975/p-2093).*

Back to Citation 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](https://www.cms.gov/files/zip/mlr-public-use-file-2022.zip).*

Back to Citation 445.

                         Medicaid and CHIP patients may pay premiums under certain circumstances.

Back to Citation 446.

                         Centers for Medicare & Medicaid Services. (2025, August 04). Trustees Report & Trust Funds. Retrieved from *<a href="https://www.cms.gov/data-research/">https://www.cms.gov/​data-research/</a> statistics-trends-and-reports/trustees-report-trust-funds.*

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](https://us.pagefreezer.com/en-US/wa/browse/0a7f82bb-be6e-448a-ae11-373d22c37842?url=https:%252F%252Fwww.hhs.gov%252Fabout%252Fbudget%252Ffy2025%252Findex.html&timestamp=2025-02-24T07:03:59Z).*

Back to Citation 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](https://www.bls.gov/oes/current/oes_nat.htm).*

Back to Citation 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.

Back to Citation 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](https://www.cms.gov/newsroom/press-releases/hhs-secretary-kennedy-cms-administrator-oz-secure-industry-pledge-fix-broken-prior-authorization).*

Back to Citation 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](https://www.ahip.org/health-plans-are-making-voluntary-commitments-to-support-patients-and-providers).*

Back to Citation 452.

                         Office of Management and Budget. (2003). Circular A-4. Retrieved from *[https://www.reginfo.gov/​public/​jsp/​Utilities/​a-4.pdf](https://www.reginfo.gov/public/jsp/Utilities/a-4.pdf).*

Back to Citation 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)](https://www.govinfo.gov/link/uscode/26/424)).

Back to Citation 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](https://www.sba.gov/federal-contracting/contracting-guide/size-standards/size-standards-tool).*

Back to Citation 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](https://www.medicaid.gov/medicaid/managed-care/downloads/2024-medicaid-managed-care-enrollment-report.pdf).*

Back to Citation 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](https://www.sba.gov/federal-contracting/contracting-guide/size-standards/size-standards-tool).*

Back to Citation 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](https://www.cms.gov/CCIIO/Resources/Data-Resources/mlr.html).*

Back to Citation 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](https://www.cms.gov/CCIIO/Resources/Data-Resources/mlr.html).*

Back to Citation 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](https://ncvhs.hhs.gov/wp-content/uploads/2020/08/Comments-CAQH%2520CORE%2520Proposed%2520Operating%2520Rules%2520for%2520Federal%2520Adoption%2520508.pdf).*

Back to Citation 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.

Back to Citation 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](https://www.ehrinpractice.com/largest-ehr-vendors.html).*

Back to Citation 462.

                         Newman, D. (2024, December 9). Top EHR Vendors 2025-Epic, Cerner/Oracle, Meditech, Allscripts. Healthcare IT Skills. Retrieved from *<a href="https://healthcareitskills.com/top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/">https://healthcareitskills.com/​top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/</a>.*

Back to Citation 463.

                         Newman, D. (2024, December 9). Top EHR Vendors 2025-Epic, Cerner/Oracle, Meditech, Allscripts. Healthcare IT Skills. Retrieved from *<a href="https://healthcareitskills.com/top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/">https://healthcareitskills.com/​top-ehr-vendors-2025-epic-cerner-meditech-allscripts-veradigm/</a>.*

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](https://www.healthit.gov/data/quickstats/health-care-professional-certified-health-it-developers).*

Back to Citation 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).

Back to Citation 466.

                         
                        See [42 CFR 422.122(b)](https://www.ecfr.gov/current/title-42/section-422.122#p-422.122(b)) for MA organizations, [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) for state Medicaid FFS programs, [42 CFR 457.732(b)](https://www.ecfr.gov/current/title-42/section-457.732#p-457.732(b)) for state CHIP FFS programs, through cross reference to [42 CFR 431.80(b)](https://www.ecfr.gov/current/title-42/section-431.80#p-431.80(b)) in [42 CFR 438.242(b)(7)](https://www.ecfr.gov/current/title-42/section-438.242#p-438.242(b)(7)) for Medicaid managed care plans, through cross reference to [42 CFR 438.242](https://www.ecfr.gov/current/title-42/section-438.242) in [42 CFR 457.1233(d)](https://www.ecfr.gov/current/title-42/section-457.1233#p-457.1233(d)) for CHIP managed care entities, and [45 CFR 156.223(b)](https://www.ecfr.gov/current/title-45/section-156.223#p-156.223(b)) for individual market QHP issuers on the FFEs.

Back to Citation BILLING CODE 4150-28-P

BILLING CODE 4150-28-C

[FR Doc. 2026-07205 Filed 4-10-26; 4:15 pm]

Published Document: 2026-07205 (91 FR 19890)