# 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

> Briefs, arguments, decisions, and more.

URL: https://www.frixlaw.com/law-library/documents/fr%3A2026-07205

## Record

- **Collection:** Federal Register
- **Document type:** Proposed Rule
- **Published:** April 14, 2026
- **Citation:** 91 FR 19890

## Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
42 CFR Parts 403, 422, 431, 438, 440, and 457
Office of the Secretary
45 CFR Parts 156, 162, and 170
[CMS-0062-P]
RIN 0938-AV44
Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability Standards and Prior Authorization for Drugs for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges

AGENCY:

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

ACTION:

Proposed rule.

SUMMARY:

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

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

3.
By express or overnight mail.
You may send written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-0062-P, Mail Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.

For information on viewing public comments, see the beginning of the
SUPPLEMENTARY INFORMATION
section.

FOR FURTHER INFORMATION CONTACT:

CMSInteroperability@cms.hhs.gov
for general inquiries.

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

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

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

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

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

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

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

SUPPLEMENTARY INFORMATION:

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

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

Table of Contents

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

A. Purpose and Background

B. Summary of Major Proposals

C. Specific Terms Used in this Proposed Rule

D. Severability

II. Provisions of the Proposed Rule

A. Interoperability Standards for APIs

B. Electronic Prior Authorization for Drugs

C. Improving Communications and Decision Timeframes for Prior Authorizations

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

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

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

G. Open Payments Civil Monetary Penalties

H. Modifications to HIPAA Standards Related to Prior Authorization

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

III. Requests for Information

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

B. Increasing Health Care Resiliency

C. Improving Implementation of Payer Application Programming Interface Technology

D. Step Therapy

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

IV. Collection of Information Requirements

V. Regulatory Impact Analysis

VI. Response to Comments

Regulation Text

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

A. Purpose and Background

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

1

See
42 CFR 422.119(b) for MA organizations, 42 CFR 431.60(b) for state Medicaid FFS programs, 42 CFR 457.730(b) for state CHIP FFS programs, cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(b) for individual market QHP issuers on the FFEs.

The “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals (CAHs) in the Medicare Promoting Interoperability Program” final rule (89 FR 8758) (hereinafter referred to as the “2024 CMS Interoperability and Prior Authorization final rule”) appeared in the
Federal Register
on February 8, 2024. In that rule, we finalized requirements for impacted payers to improve the electronic exchange of health care information, not just with patients, but also with providers and other payers. We also finalized requirements for impacted payers to implement and maintain a Prior Authorization API that supports electronic prior authorization between providers and payers.
2

We also finalized general process requirements for prior authorization, such as requiring MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to respond to prior authorization requests for non-drug items and services within certain timeframes.

2

See
42 CFR 422.122(b) for MA organizations, 42 CFR 431.80(b) for state Medicaid FFS programs, 42 CFR 457.732(b) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(b) for individual market QHP issuers on the FFEs.

In the 2024 CMS Interoperability and Prior Authorization final rule, we did not propose or finalize requirements that apply to drugs of any type because, as we discussed in the proposed and final rules, the processes and electronic standards for prior authorization of drugs differ from the non-drug items and services included in our final policies. We also acknowledged that there are existing laws and regulations around the prior authorization of drugs that may apply to impacted payers (such as the existing electronic prescribing requirements for covered Part D drugs in 42 CFR 423.160) (87 FR 76240 and 76241, and 89 FR 8762). However, we received many public comments in response to the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program” proposed rule (87 FR 76238) (hereinafter referred to as the “2022 CMS Interoperability and Prior Authorization proposed rule”), which appeared in the
Federal Register
on December 13, 2022, as well as additional feedback from providers, payers, and standards developing organizations (SDOs), indicating that while some prior authorization processes and standards for drugs currently exist, the health care industry would benefit from consistent electronic prior authorization requirements to promote patients' timely access to drugs and alleviate burden for providers and payers. Commenters emphasized the impact that prior authorization for drugs has on patients and providers and urged CMS to implement similar requirements for drugs as were proposed for non-drug items and services. In addition, commenters explained that the Prior Authorization API can facilitate electronic prior authorization for drugs covered under a medical benefit, so the same standards and requirements could be used for that category of drugs. Commenters also pointed out that requirements already existed for Medicare Part D sponsors to support (and prescribers to use) a standard adopted by the Secretary for the prior authorization of covered Part D drugs, the National Council for Prescription Drug Programs (NCPDP) SCRIPT Standard Implementation Guide (NCPDP SCRIPT standard). Those

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

The 2024 CMS Interoperability and Prior Authorization final rule also established, improved, or shortened prior authorization timeframes for impacted payers other than QHP issuers on the FFEs (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities) to respond to prior authorization requests for non-drug items and services. Specifically, we finalized timeframes of 7 calendar days for standard requests and 72 hours for expedited requests, with the possibility of an extension of up to 14 days in certain circumstances (89 FR 8878). For Medicaid and CHIP, state law may establish a shorter timeframe.
3

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

3

See
42 CFR 440.230(e) for state Medicaid FFS programs, 42 CFR 457.495(d)(2) for state CHIP FFS programs, 42 CFR 438.210(d) for Medicaid managed care plans, and 42 CFR 457.1230(d) for CHIP managed care entities. State law may not impose a shorter timeline on MA organizations in light of the preemption provisions in section 1856(b)(3) of the Social Security Act (the Act) and 42 CFR 422.402.

At the time, we did not propose to change those timeframes because they are aligned with other non-grandfathered group and individual market plans. However, we received numerous comments that opposed the exclusion of QHP issuers on the FFEs from these policies and urged that QHPs offered on the FFEs should be aligned with the requirements for other CMS programs. Some expressed concern that not doing so would have negative effects on enrollee care, and that enrollees with coverage through these plans should be entitled to the same protections as those with coverage through the other impacted payers. In addition, we received comments that recommended we reconsider the exclusion of drugs from our proposals and suggested that CMS finalize the prior authorization process and Prior Authorization API requirements in the 2024 CMS Interoperability and Prior Authorization final rule to cover drugs covered under a medical benefit. Commenters further expressed that by failing to include drugs in those requirements, CMS was failing to address the biggest culprit of delay to timely care and administrative burden.

B. Summary of Major Proposals

We are proposing to require that impacted payers support electronic prior authorization for all drugs that require prior authorization. We are proposing two separate sets of standards to facilitate electronic prior authorization for all drugs, the HL7 FHIR standard (and certain FHIR IGs) as one set, and three NCPDP standards (the NCPDP SCRIPT standard, NCPDP Formulary & Benefit Standard Implementation Guide [NCPDP F&B standard], and the NCPDP Real-Time Prescription Benefit Standard Implementation Guide [NCPDP RTPB standard]) as the other set. The FHIR standard, including the IGs, and the three NCPDP standards, all facilitate electronic prior authorization for drugs; which standards set is applicable depends on whether the drug is covered under the payer's medical benefit or its pharmacy benefit. We are proposing to require impacted payers to expand their Prior Authorization API, finalized in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8758), to incorporate drugs covered under a medical benefit. We are also proposing to require impacted payers (other than MA organizations for whom requirements already exist) to support the proposed NCPDP standards for the electronic prior authorization of drugs covered under a pharmacy benefit.

As proposed in this proposed rule, the Prior Authorization API comprises the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG, the HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) IG, and the HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG, and can be used to support drugs under a medical benefit, but should not be used for the prior authorization of drugs covered under a pharmacy benefit. Specifically, the PAS IG states that the IG “SHOULD NOT be used for any medication that is covered under a pharmacy benefit where prior authorization is provided by another electronic exchange process (for example, NCPDP SCRIPT).”
4

4
NOTE: This document contains links to non-United States Government websites. We are providing these links because they contain additional information relevant to the topic(s) discussed in this document or that otherwise may be useful to the reader. We cannot attest to the accuracy of information provided on the cited third-party websites or any other linked third-party site. We are providing these links for reference only; linking to a non-United States Government website does not constitute an endorsement by CMS, HHS, or any of their employees of the sponsors or the information and any products presented on the website. Also, please be aware that the privacy protections generally provided by United States Government websites do not apply to third-party sites.

Health Level Seven International. (2026, March 27). Da Vinci Prior Authorization Support (PAS) FHIR: Use Cases and Overview. Retrieved from
https://hl7.org/fhir/us/davinci-pas/2.2.1/en/usecases.html.

Conversely, the NCPDP SCRIPT standard include instructions that it is to be used for “products covered by a patient's pharmacy benefit.” The NCPDP F&B and NCPDP RTPB standards complement the NCPDP SCRIPT standard and apply to the same category of drugs. Payers can use the NCPDP F&B standard to make available formulary and benefit information, including prior authorization requirements, at the health plan level. The NCPDP RTPB standard enables real-time exchange at the point-of-prescribing of patient-specific eligibility, coverage, and estimated cost-sharing information for drugs covered

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

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

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

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

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

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

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

Those proposals are similar to the exception policies finalized in the 2024 CMS Interoperability and Prior Authorization final rule and are discussed in section II.B.7. of this proposed rule.
6

5
We note that existing language in 45 CFR 156.223(d)(1)(i) would also allow QHP issuers to request an exception to the requirement, if finalized, to incorporate electronic prior authorization for drugs under a medical benefit into the Prior Authorization API.

6
For exceptions, see 45 CFR 156.222(c) and 45 CFR 156.223(d) for individual market QHP issuers on the FFEs.

We are proposing to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to respond to the provider with a specific reason for denying a prior authorization request for any drugs. We are proposing an October 1, 2027 compliance date for those impacted payers to respond to a provider with a specific reason for denying a prior authorization request for any drugs. This proposal builds on the requirement finalized in the 2024 CMS Interoperability and Prior Authorization final rule that impacted payers must provide a specific reason to the provider for denying a prior authorization request for non-drug items and services.
7

7

See
42 CFR 422.122(a) for MA organizations and applicable integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs, through cross

reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8) for Medicaid managed care plans, 42 CFR 457.732(a) for state CHIP FFS programs, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(a) for individual market QHP issuers on the FFEs.

For state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities, the timeframes for making decisions on prior authorization requests for covered outpatient drugs is 24 hours.
8

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

8

See
section 1927(d)(5)(A) of the Act for state Medicaid FFS programs, 42 CFR 438.3(s)(6) for Medicaid managed care plans, and 42 CFR 457.1230(d) for CHIP managed care entities.

We are proposing to shorten timeframes within which QHP issuers on the FFEs, including small group market QHP issuers on the FF-SHOPs, must make a decision on prior authorization requests by establishing timeframes by which QHP issuers on the FFEs must notify requesting providers of their decision. The proposed timeframes generally align with the timeframes for other impacted payers that we finalized in the 2024 CMS Interoperability and Prior Authorization final rule for non-drug items and services (89 FR 8878) and that we are proposing for drugs in this proposed rule. Specifically, we propose to require QHP issuers on the FFEs to send notice of their decision to the requesting provider for standard prior authorization requests for non-drug items and services as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after receiving the request. We are not proposing to change the existing 72-hour timeframe to notify enrollees about prior authorization decisions on expedited requests for non-drug items and services, but are proposing that QHP issuers on the FFEs notify the requesting provider of their decision on a prior authorization request for non-drug items and services within the same timeframe. These proposed timeframes for non-drug items and services align with existing timeframes that were finalized in the 2024 CMS Interoperability and Prior Authorization final rule for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities (89 FR 8878). We are also proposing to require QHP issuers on the FFEs to send notice of their decision to the requesting provider for standard prior authorization requests for drugs as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request. We are further proposing to require QHP issuers on the FFEs to send notice of their decision to the requesting provider for expedited prior authorization requests for drugs as expeditiously as the enrollee's health condition requires, but no later than 24 hours after receiving the request. These proposed timeframes generally align with existing requirements for Part D sponsors in 42 CFR 423.568(b) and in 42 CFR 423.572(a). For these proposals, we are proposing an October 1, 2027 compliance date.

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized an annual March 31 reporting deadline for all impacted payers to report Patient Access API usage metrics to CMS and to publicly post prior authorization metrics for non-drug items and services from the previous year (89 FR 8784, 8817, and 8855). However, we have determined that such deadlines may not align with Medicaid managed care plans' and CHIP managed care entities' contract rating periods and with the QHP certification process for QHP issuers on the FFEs. Therefore, to align the reporting deadlines with the contract rating period, we are now proposing to require Medicaid managed care plans and CHIP managed care entities to report Patient Access API usage metrics from each rating period to states no later than 90 days after the end of each rating period and to publicly post the required prior authorization metrics for non-drug items and services no later than 90 days after the end of each rating period. For QHP issuers on the FFEs, we are proposing regulatory text to refer to the reporting deadline for Patient Access API usage metrics in a manner similar to the reporting deadlines for other plan data that CMS collects during the annual QHP certification process. Specifically, we propose that following each year it offers a QHP on an FFE, a QHP issuer on the FFEs must report the specified metrics to CMS as aggregated, de-identified data at the issuer level in the form and manner and within the timeframes specified by the Secretary. That would allow flexibility for CMS to include API usage metrics reporting within specific deadlines set for the QHP certification process, which, in practice, is generally the final deadline for the QHP certification process that takes place the following year.
9

We are proposing that these changes become effective beginning on the effective date of the final rule.

9
Information about QHP certification, including deadlines can be found at
https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline.

Building on the requirement finalized in the 2024 CMS Interoperability and Prior Authorization final rule that impacted payers must report Patient Access API usage metrics to CMS, we are proposing to require impacted payers to report similar usage metrics about their Provider Access, Payer-to-Payer, and Prior Authorization APIs.
10

Collecting these metrics should help CMS evaluate the impact of our policies and plan for future changes, if necessary. We are proposing that the metrics would be reported annually by MA organizations at the contract level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans and CHIP managed care entities at the plan and program level, and QHP issuers on the FFEs at the issuer level. We are proposing that beginning in 2028, MA organizations and state Medicaid and CHIP FFS programs would be required to report the previous calendar year's metrics by March 31 of each year. We are proposing that Medicaid managed care plans and CHIP managed care entities would report their metrics to states from

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

10

See
42 CFR 422.119(f) for MA organizations, 42 CFR 431.60(f) for state Medicaid FFS programs, through cross reference to 431.60 in 42 CFR 438.242(b)(5)(iii) for Medicaid managed care plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing cross reference to 42 CFR 438.242 in existing 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(f) for individual market QHP issuers on the FFEs.

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to report on their websites certain prior authorization metrics for non-drug items and services, including the percentage of prior authorizations that were approved, denied, approved after appeal, and approved after the timeframe for review was extended (89 FR 8897). In an effort to provide more useful and complete information, we are now proposing that impacted payers report a numeric count for each of those metrics (in addition to the percentages). We are also proposing that impacted payers report six new metrics: four new metrics about prior authorization denials after an extended timeframe and appeals for non-drug items and services and two new metrics about prior authorization approvals after an extended timeframe and appeals for non-drug items and services for expedited prior authorization requests only. The proposed metrics complement existing metrics finalized in the 2024 CMS Interoperability and Prior Authorization final rule about prior authorization approvals after an extended timeframe and appeals for non-drug items for standard prior authorization requests. We are proposing compliance dates beginning in 2028 for impacted payers to report the additional metrics.

Similarly, we are proposing to require impacted payers to publicly post on their websites a set of metrics on prior authorizations for all drugs (excluding covered Part D drugs for MA-PD plans). To align with the finalized requirements and our new proposals, we are proposing that these reports must be posted no later than March 31 following any calendar year that the impacted payer offered that type of plan for MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs, and no later than 90 days after the end of each rating period for Medicaid managed care plans and CHIP managed care entities.
11

We are proposing compliance dates beginning in 2028 for impacted payers to post these metrics.

11

See
42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through cross reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers on the FFEs.

We propose to include small group market QHP issuers on the FF-SHOPs in the list of impacted payers for all the proposals in this proposed rule that apply to individual market QHPs on the FFEs. In addition, we are proposing to apply the existing requirements in 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223, which were finalized in the 2020 CMS Interoperability and Patient Access final rule and in the 2024 CMS Interoperability and Prior Authorization final rule (85 FR 25510 and 89 FR 8758), to small group market QHP issuers on the FF-SHOPs. We did not apply these policies to small group market QHP issuers on the FF-SHOPs in previous rulemaking due to concerns about placing burden on these issuers (85 FR 25553 and 89 FR 8767). However, based on subsequent research, all issuers that offer small group market QHPs on the FF-SHOPs, as of the time of this proposal, also offer individual market QHPs on the FFEs. Therefore, we anticipate that the burden for these issuers to implement these proposals for their small group market QHPs on the FF-SHOPs should be relatively low because these issuers are already required to implement the policies for their individual market QHPs on the FFEs. Since plan year 2021, we have only seen one instance of a new entrant into an FF-SHOP Exchange. However, should this change in the future—for example, if an issuer that does not offer one or more individual market QHPs on the FFEs newly enters an FF-SHOP, and this proposal has been finalized, we could still mitigate potential burden for such an issuer by considering whether an exception to one or more of these requirements is appropriate based on, for example, whether such an exception would be in the interests of qualified individuals and qualified employers.
12

12
For more information on interoperability and QHP certification, including further detail on the exceptions process, see
https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability.
Discussion of this topic is also available in the 2024 CMS Interoperability and Prior Authorization final rule preamble: 89 FR 8906.

Throughout this proposed rule, we will refer to “QHP issuers on the FFEs” where we propose requirements that apply to both individual market QHP issuers on the FFEs and small group market QHP issuers on the FF-SHOPs, and we will refer to “small group market QHP issuers on the FF-SHOPs” in proposals to apply requirements in 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223 that we previously finalized for individual market QHP issuers on the FFEs. We are proposing that references to QHP issuers on the FFEs in 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223 would include small group market QHP issuers on the FF-SHOPs, because that term is used throughout 45 CFR part 156 Subpart C to refer to QHPs offered in both the individual and small group markets. We will only use different terminology in cases where there is a need to distinguish between individual market QHP issuers on the FFEs and small group market QHP issuers on the FF-SHOPs, such as in proposals to apply a different compliance date for small group market QHP issuers on the FF-SHOPs. For example, because the requirements in 45 CFR 156.221 already took effect for plan years beginning on or after January 1, 2021, our proposed amendment to that regulation would apply the requirements to implement and maintain a Patient Access API to small group market QHP issuers on the FF-SHOPs as of plan years beginning on or after January 1, 2028. We are also proposing a compliance date of plan years beginning on or after January 1, 2028 for small group market QHP issuers on the FF-SHOPs to comply with rules in 45 CFR 156.222 to implement and maintain Provider Access and Payer-to-Payer APIs unless granted an exception pursuant to 45 CFR 156.222(c). We believe that aligning these compliance dates would simplify these requirements, and that it likely provides enough time for issuers that have already implemented the required APIs for their individual market QHPs on the FFEs.

The phrase “plan years beginning on or after January 1” already accommodates small group market QHP issuers on the FF-SHOPs that may have non-calendar year plan years. We solicit comments on the proposals throughout this rule specifically regarding the proposed compliance dates for small group market QHP issuers on the FF-SHOPs, including regarding whether these plans may need more time to implement these requirements. For instance, how could the prior authorization proposals in section II.B. of this proposed rule (electronic prior authorization proposal applicable to all QHP issuers on the FFEs) and II.C. of this proposed rule (prior authorization processes applicable to all QHP issuers on the FFEs) affect small group market QHP issuers on the FF-SHOPs' ability

to meet the requirements proposed in section II.D. of this proposed rule (requirements for small group market QHP issuers on the FF-SHOPs), and vice versa?

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

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

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

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

13
Centers for Medicare & Medicaid Services. (2026, April 7). Exceptions Process. Retrieved from
https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process.

As part of this proposed rule, ONC
14

is proposing to adopt updated versions of certain health IT standards and specifications in 45 CFR 170.215 on behalf of HHS. Specifically, ONC is proposing to adopt updated versions of the health IT standards and specifications codified in 45 CFR 170.215(j)(1) through (3), (k)(1), (m), and (n), which CMS is proposing to require impacted payers to use. Additionally, ONC is proposing a January 1, 2028 expiration date for versions of the standards and specifications currently in 45 CFR 170.215(j)(1) through (3), (k)(1), (m), and (n), provided that the proposals to adopt the newer versions of these adopted standards are finalized. These updated standards versions could support a more robust health IT infrastructure, create consistency for industry, and facilitate interoperability by ensuring that health IT leveraging these standards under different HHS programs use the same baseline standards for the same use cases, such as electronic prior authorization.

14
ASTP/ONC is now referred to as ONC, pursuant to a notice which appeared in the
Federal Register
on April 1, 2026 (91 FR 16204). Although, at the time of specific references noted herein, ONC was either referenced as ASTP/ONC or as ONC, for clarity, all references in this document are now noted as ONC.

Finally, we are publishing five requests for information (RFIs) to gather information that may support future rulemaking or other initiatives. The RFIs are related to electronic event notifications for value-based care and care coordination, health care resiliency and securing health care operations in a modern health care ecosystem, improving the implementation of payer API technology through testing and

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

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

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

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

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

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

C. Specific Terms Used in This Proposed Rule

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

Under the HIPAA Privacy Rule, the individual's personal representative generally may exercise the right to access the individual's protected health information (PHI).

15

See
45 CFR parts 160 and 164, subparts A and E.

16
United States Department of Health and Human Services. (2020, January 31). Health Information and Privacy. Retrieved from
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html
and
https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html.

We also use terms such as “payer,” “plan,” and “issuer” in this proposed rule. Certain portions of this proposed rule are applicable to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans (managed care organizations [MCOs], Prepaid Inpatient Health Plans [PIHPs], and Prepaid Ambulatory Health Plans [PAHPs]), CHIP managed care entities (MCOs, PIHPs, and PAHPs), QHP issuers on the FFEs, including proposals for small group market QHP issuers on the FF-SHOPs. We use the term “impacted payer” in the preamble of this proposed rule as an inclusive term for all these entities and programs and, in the case of plans, plan types, but we also use specific terms as applicable in various sections of this proposed rule. Notably, the term “impacted payers” only applies to the CMS proposals in this proposed rule, not to the HHS proposals for HIPAA Administrative Simplification. As discussed in section II.H. of this proposed rule, the HIPAA Administrative Simplification proposals would apply to HIPAA covered entities, as described in section 1172(a) of the Act and defined in 45 CFR 160.103.

Some plans that participate in those CMS programs may not be permitted to use prior authorization (such as Private FFS MA plans) or may choose not to use prior authorization. Our prior authorization proposals only apply to the extent that a payer (or plan) uses prior authorization. Therefore, if an impacted payer does not use prior authorization, they would not be subject to the prior authorization proposals. However, other proposals, such as those related to the Access APIs and standards, would apply to all types of plans under the categories of impacted payers.

Many payers use a pharmacy benefit manager (PBM) to manage prescription drug benefits on their behalf, including through utilization management techniques such as prior authorization. These proposals do not apply directly to PBMs, but we understand that, if these proposals are finalized, PBMs may play a role in helping impacted payers meet the requirements proposed in this rule. For example, if a PBM is contracted by an impacted payer to manage its prescription drug benefits, including to

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

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

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

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

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

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

prior authorization from a payer, which may or may not be the actual prescriber.

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

17
The Office of the National Coordinator for Health Information Technology. (n.d.). Application Programming Interfaces. Retrieved from
https://www.healthit.gov/api-education-module/story_html5.html.

Throughout this rule, we collectively refer to the APIs finalized in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules—the Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization APIs—as the “interoperability APIs.” When we refer to “access APIs,” we mean those that are used primarily to access a specific patient's health record, the Patient Access, Provider Access, and Payer-to-Payer APIs. Each of the interoperability APIs are required to be built using the FHIR standard. FHIR is a standards framework created by HL7 to electronically exchange health information via APIs using the latest technology standards. FHIR defines categories of data, called “Resources” that, individually or in combination, satisfy most common use cases. The Patient Resource, for example, includes demographic data related to a patient, such as their name, address, and phone number. Using these FHIR Resources enables granular data retrieval, so that a request returns just the relevant data rather than a full record or document that itself must then be searched. Once they are modified for specific requirements using FHIR's built-in capabilities, combinations of Resources are brought together in an IG to address a specific use case, such as a provider directory or prior authorization. This structure lends itself well to expansion beyond FHIR's core capabilities.
18

18
The Office of the National Coordinator for Health Information Technology. (n.d.). What Is HL7® FHIR®? Retrieved from
https://www.healthit.gov/sites/default/files/page/2021-04/What%20Is%20FHIR%20Fact%20Sheet.pdf.

As in the 2024 CMS Interoperability and Prior Authorization final rule, we use the term “prior authorization” to refer to the process through which a provider, such as an individual clinician, acute care hospital, ambulatory surgical center, or clinic, obtains approval from a payer before providing care (89 FR 8761). A prior authorization is made up of two parts—a request from a provider and a decision/response by a payer. We refer to the provider's workflow and associated information and documentation as the “prior authorization request” and the payer's processes and associated information and documentation as the “prior authorization decision.” Payers establish prior authorization requirements to help control costs and ensure payment accuracy by verifying that an item, service, or drug is medically necessary for the specific patient, meets coverage criteria, and, for some payers, is consistent with standards of care before being provided. As we explained in the 2024 CMS Interoperability and Prior Authorization final rule, prior authorization has an important place in the health care system for utilization management, but the process and delays continue to be challenging for providers (89 FR 8914). Furthermore, issuers with complex payer policies, inconsistent use of electronic standards, and other technical barriers create provider workflow challenges and an environment in which the prior authorization process is a primary source of burden for both providers and payers and can create a health risk for patients if they don't receive medically necessary care in a timely manner.

In this proposed rule, we refer to two categories of drugs—“drugs covered under a pharmacy benefit” and “drugs covered under a medical benefit.” We acknowledge that these terms do not have statutory or regulatory correlations for impacted payers other than MA organizations (based on the distinctions between Parts A, B, and D). For instance, for Medicaid and CHIP, we propose that the distinction can be distinguished by the systems used to process claims. We are using “drugs covered under a pharmacy benefit” to reflect how the NCPDP SCRIPT standard describes the category of drugs within its scope.
19

Conversely, we are using “drugs covered under a medical benefit” to describe the category of drugs for which the NCPDP SCRIPT standard is not to be used, pursuant to the IG, but is within the scope of the Prior Authorization API, based on instructions in the PAS IG, which states that the IG “SHOULD NOT be used for any medication that is covered under a pharmacy benefit where prior authorization is provided by another electronic exchange process (for example, NCPDP SCRIPT).” These standards and their scopes are further discussed in sections II.A.2. and II.A.3. of this proposed rule. We request comment on whether there are drugs covered by any impacted payer that may not fit into the categories “drugs covered under a medical benefit” and “drugs covered under a pharmacy benefit” and how such drugs can be included in one of those two categories.

19

See
89 FR 51262.

When we refer to both drugs covered under a pharmacy benefit and drugs covered under a medical benefit, throughout this rule we use the terms “all drugs” or “any drugs.” Further discussion of these terms is included in the discussion of those standards in section II.A. of this proposed rule.

HL7 is an American National Standards Institute (ANSI)-accredited SDO that develops the FHIR standard and the IGs referenced throughout this proposed rule. In addition, they are a designated standard maintenance organization (DSMO), designated by the Secretary under 45 CFR 162.910.
20

NCPDP is a non-profit ANSI-accredited SDO supporting standards for the drug supply chain. The NCPDP SCRIPT, F&B, and RTPB standards are established standards that can support prior authorization and other prescription information exchange tasks for drugs covered under a pharmacy benefit, as described further in sections II.A. and II.B. of this proposed rule.

20
As announced in the
Federal Register
in 65 FR 50373.

D. Severability

In this proposed rule, CMS and HHS propose a variety of policies related to prior authorization. To the extent a court may enjoin one provision of this final rule, CMS and HHS propose that the other provisions should remain in effect, ensuring the continuity of the regulations. We propose that any provision of the requirements of this rule that is held to be invalid or unenforceable by its terms or as applied to any person or circumstance would be construed so as to continue to give maximum effect to the provision permitted by law, unless such holding is one of utter invalidity or unenforceability, in which event we

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

21

See
42 CFR 422.119(c)(4)(ii) for MA organizations, 42 CFR 431.60(c)(4)(ii) for state Medicaid FFS programs; through cross references to 42 CFR 431.60 in 42 CFR 438.242(b)(5), 42 CFR 431.61(a) in 42 CFR 438.242(b)(7), 42 CFR 431.61(b)(1) in 42 CFR 438.242(b)(7), 42 CFR 431.70 in 42 CFR 438.242(b)(6), 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans; 42 CFR 457.730(c)(4)(ii) for state CHIP FFS programs; through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(c)(4)(ii) for individual market QHP issuers.

The “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” proposed and final rules (88 FR 23746 and 89 FR 1192) (hereinafter referred to as the “HTI-1 proposed rule” and the “HTI-1 final rule”), appeared in the
Federal Register
on April 18, 2023 and January 9, 2024, respectively. In that rulemaking, which took place between the 2022 and 2024 CMS Interoperability and Prior Authorization proposed and final rules, the Secretary adopted updated versions of several standards set forth in 45 CFR 170.215 and finalized expiration dates for previous versions of standards. As a result, the 2024 CMS Interoperability and Prior Authorization final rule finalized requirements for impacted payers to use standards in 45 CFR 170.215 available at the time of the 2022 CMS Interoperability and Prior Authorization proposed rule, and not versions subsequently proposed and finalized by the Secretary. Some of those required versions now have established expiration dates.

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements to use the versions of the standards in 45 CFR 170.215 that we had proposed, not those that were newly adopted in the HT1-1 final rule. For example, when the 2022 CMS Interoperability and Prior Authorization proposed rule appeared in the
Federal Register
on December 13, 2022, the US Core IG, STU 3.1.1 and SMART App Launch IG, Release 1.0.0 were the current versions of these standards. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that impacted payers must use the versions set forth in the proposed rule (which had not yet expired on the date the final rule appeared in the
Federal Register
), although the Secretary adopted newer versions (US Core IG, STU 6.1.0 in 45 CFR 170.215(b)(1)(ii) and SMART App Launch IG, Release 2.0.0 in 45 CFR 170.215(c)(2)) in the HTI-1 final rule (89 FR 1284, 1285, and 1291).

The Secretary also finalized a January 1, 2026 expiration date for the US Core IG, STU 3.1.1 (in 45 CFR 170.215(b)(1)(i)) and the SMART App Launch IG, Release 1.0.0 (in 45 CFR 170.215(c)(1)). Upon the specified expiration date, the expired versions of the standards are no longer eligible for certification of Health IT Modules through the ONC Health IT Certification Program (89 FR 1285 and 1292). As of this proposed rule, there are two adopted versions of the US Core IG: (1) the US Core IG, STU 3.1.1 (in 45 CFR 170.215(b)(1)(i)), which expired on January 1, 2026, and (2) the US Core IG, STU 6.1.0 (in 45 CFR 170.215(b)(1)(ii)) without an expiration date.

Through our proposals in this rule, we are seeking to align with the regulatory framework established by ONC to adopt, update, and expire health IT standards incorporated by reference in the Code of Federal Regulations (CFR). Accordingly, under our proposals, if ONC establishes an expiration date for an adopted standard, or for a specific version thereof, in subpart B of 45 CFR part 170, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements. We believe these proposals will support greater alignment across interoperability standards requirements that impact payers, health care providers, health IT developers and other parties.

In the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules, we also finalized policies that allow impacted payers to voluntarily conform with updated versions of the standards we have required payers to use in 45 CFR 170.213 and 45 CFR 170.215 (such as the US Core IG and SMART App Launch IG), provided that (1) the National Coordinator for Health Information Technology (hereinafter referred to as the “National Coordinator”) has approved the updated version for use in the ONC Health IT Certification Program; (2) the updated version of the standard does not disrupt an end user's ability to access the required data via that API; and (3) the updated standard is not prohibited by law (85 FR 25532 and 89 FR 8946). In addition, impacted payers may use an

updated version if required by other applicable law.
22

Under these provisions, impacted payers may upgrade to newer versions of the required standards, subject to the specified limiting conditions (85 FR 25532 and 89 FR 8946).

22

See
42 CFR 422.119(c)(4)(ii) for MA organizations, 42 CFR 431.60(c)(4)(ii) for state Medicaid FFS programs; through cross references to 42 CFR 431.60 in 42 CFR 438.242(b)(5), 42 CFR 431.61(a) in 42 CFR 438.242(b)(7), 42 CFR 431.61(b)(1) in 42 CFR 438.242(b)(7), 42 CFR 431.70 in 42 CFR 438.242(b)(6), 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans; 42 CFR 457.730(c)(4)(ii) for state CHIP FFS programs; through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(c)(4)(ii) for individual market QHP issuers.

Finally, in the 2022 CMS Interoperability and Prior Authorization proposed rule, we did not propose, nor did we finalize any requirements in the 2024 CMS Interoperability and Prior Authorization final rule, that applied to any drugs because, as we discussed in the proposed and final rules, the processes and standards for prior authorization of drugs differ from the non-drug items and services included in our final policies (89 FR 8762). However, we received many public comments in response to the 2022 CMS Interoperability and Prior Authorization proposed rule, as well as additional feedback from providers, payers, and SDOs, indicating that while some prior authorization processes and standards for drugs currently exist, patients and other stakeholders would benefit from consistent requirements to provide patients timely access to drugs, and from a streamlined electronic prior authorization process that alleviates burden for providers and impacted payers.

2. NCPDP Standards for Prior Authorization of Drugs Covered Under a Pharmacy Benefit

a. NCPDP SCRIPT Standard

After considering stakeholder comments on the 2022 CMS Interoperability and Prior Authorization proposed rule, our goals for interoperability across impacted payers, and the technical standards available to support electronic prior authorization for drugs, we are now proposing to require impacted payers to support electronic prior authorization for drugs. We are proposing to require impacted payers to use either the FHIR standards and IGs required for the Prior Authorization API or the NCPDP SCRIPT standard depending upon whether the drugs are covered under a medical benefit or a pharmacy benefit, as detailed by the standards implementation specifications, and further discussed below.

As discussed further in section II.B. of this proposed rule, we are proposing to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT Standard Implementation Guide (NCPDP SCRIPT)
23

adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs covered under a pharmacy benefit. In the “Medicare Program; Medicare Prescription Drug Benefit Program; Health Information Technology Standards and Implementation Specifications” final rule (89 FR 51238) (hereinafter referred to as the “2024 Part D and Health IT Standards” final rule), which appeared in the
Federal Register
on June 17, 2024, ONC finalized a January 1, 2028 expiration date for the NCPDP SCRIPT Standard Implementation Guide, Version 2017071 in 45 CFR 170.205(b)(1), and adopted the NCPDP SCRIPT Standard Implementation Guide, Version 2023011 in 45 CFR 170.205(b)(2) (89 FR 51244 and 51258-51259). Like the approach discussed above for required standards for payer APIs, our proposals in this rule seek to align to ONC's framework to adopt and update versions of the SCRIPT standard. Under these proposals, if ONC establishes an expiration date for the NCPDP SCRIPT standard in 45 CFR 170.205(b), or for a specific version thereof, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements. We are proposing an October 1, 2027 compliance date for this proposed requirement.

23
NCPDP SCRIPT Standard IG, Versions 2017071 and 2023011. NCPDP SCRIPT IGs are available to NCPDP members for free and to non-members for a fee at
https://standards.ncpdp.org/Access-to-Standards.aspx.

NCPDP is a not-for-profit ANSI-accredited SDO representing the pharmacy services industry and is responsible for developing and maintaining standards for the exchange of information between providers, pharmacies, and payers. NCPDP is an SDO for pharmacy standards, including billing, subrogation, formulary and benefits, electronic prior authorization, electronic prescribing, and real-time benefit checks. The NCPDP SCRIPT standard can be used for multiple transactions between entities during the prescribing and dispensing processes including between providers, pharmacies, and payers for electronic prescribing; electronic prior authorization; and medication history exchange. This proposed rule focuses only on the electronic prior authorization functionality of the standard.

The NCPDP SCRIPT standard is the most widely used standard by providers and payers for electronic prescribing and electronic prior authorization for drugs covered under a pharmacy benefit. The NCPDP SCRIPT standard can be used by providers to submit a prior authorization request to the payer (including the payer's processor or PBM, as appropriate). The NCPDP SCRIPT standard is designed specifically and solely for a category of drugs, which are described as “drugs covered under a pharmacy benefit.”
24

The transactions in the NCPDP SCRIPT standards for electronic prior authorization are not intended to be used to communicate information for medical items or services or drugs covered under a medical (non-pharmacy) benefit.

24
NCPDP (2015, August). NCPDP SCRIPT Standard Supports Electronic Prior Authorization (ePA) Fact Sheet. Retrieved from
https://ncpdp.org/NCPDP/media/pdf/NCPDP_ePA_Fact_Sheet.doc.

(1) Scope of the NCPDP SCRIPT Standard and FHIR IGs for Electronic Prior Authorization of Drugs

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a policy that established HL7 FHIR, Release 4.0.1 as the API base standard for the Prior Authorization API.
25

Specifically, we finalized that certain impacted payers must implement and maintain the Prior Authorization API, and that the Prior Authorization API use the HL7 FHIR standard, Release 4.0.1 for electronic prior authorization of non-drug items and services (89 FR 8859 and 8861). We also strongly recommended that impacted payers use the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG, the HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) IG, and HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG when implementing the Prior Authorization API (89 FR 8863). These FHIR IGs are technically capable of supporting prior authorization of non-drug items and services and drugs covered under a medical benefit. The FHIR specifications, specifically the PAS IG, states that it “SHOULD NOT be used for any Medication that is covered under a pharmacy benefit where prior authorization is provided by another electronic exchange process (for

example, NCPDP SCRIPT).”
26 27

That directive is intended to differentiate the scope of the FHIR IGs for prior authorization from the scope of the NCPDP SCRIPT standard, which is used for prior authorization of drugs under a pharmacy benefit.

25

See
45 CFR 170.215(a)(1).

26

See
section II.A.4.a.6. of this proposed rule for a description of the CRD, DTR, and PAS IGs and section II.A.4.b.4. of this proposed rule regarding CMS's proposal to require use of these IGs for the Prior Authorization API.

27
Health Level Seven International (2024, December 20). Da Vinci Prior Authorization Support (PAS) FHIR: Use Cases and Overview. Retrieved from
https://hl7.org/fhir/us/davinci-pas/usecases.html.

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

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

(2) Transactions

As of the date this proposed rule appears in the
Federal Register
, providers can use the NCPDP SCRIPT standard versions 2017071 and 2023011 for multiple transactions associated with the electronic prior authorization of drugs covered under a pharmacy benefit. The SCRIPT standard can be used in conjunction with the NCPDP F&B or NCPDP RTPB standards, to support a complete workflow around determining whether prior authorization is required. Additionally, these versions of the NCPDP SCRIPT standard include transactions for requesting prior authorization for drugs, communicating decisions, and exchanging information regarding appeals. The NCPDP SCRIPT standard version 2023011 has numerous updates from version 20217071, including that it can facilitate a three-way transaction to notify providers and pharmacies when prior authorization has been requested.
28 29

The NCPDP SCRIPT standard versions 2017071 and 2023011 support both the workflow to determine whether prior authorization is required and the coverage and documentation requirements to receive a decision, as well as the technical processes to send prior authorization requests from a provider to a payer, followed by the payer's responses (for example, approved, denied, and additional information required). The NCPDP SCRIPT standard versions 2017071 and 2023011 also support features that minimize manual data entry by the provider based on information in the EHR or other health IT system. These functions should reduce the time a provider or their administrative staff spend reviewing and responding to payer documentation requirements for prior authorization decisions. The NCPDP SCRIPT standard versions 2017071 and 2023011 can send information to a payer (or the payer's PBM) in real time, which should result in faster prior authorization approvals and therefore faster patient access to medications compared to manual prior authorization processes. We note that the NCPDP SCRIPT standard version 2017071 expires on January 1, 2028, which is shortly after the proposed compliance date for certain impacted payers to support an unexpired version of the NCPDP SCRIPT standard adopted in 45 CFR 170.205(b). If our proposal is finalized, we would expect those impacted payers to utilize only the NCPDP SCRIPT standard versions 2023011 after January 1, 2028 to meet the proposed requirements.

28
NCPDP. (2022, January 14). Re: Next version of SCRIPT Standard Recommendations. Retrieved from
https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2022/202201NCPDP-SCRIPTNextVersionLetter.pdf.

29
NCPDP. (2023, February 13). Re: Proposed Rule CMS-4201-P. Retrieved from
https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2023/20230213_To_CMS_CMS_4201_P_NPRM.pdf.

Therefore, we are proposing to require that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the following transactions to support electronic prior authorization of drugs covered under a pharmacy benefit:

EP14AP26.273

We emphasize that our proposals in this rule would not impose requirements directly on providers. We are not proposing to require providers to use the NCPDP SCRIPT standards or to conduct electronic prior authorization, but we acknowledge other HHS programs aim to support providers' ability to conduct electronic prior authorization using the NCPDP SCRIPT standard.

The “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability: Electronic Prescribing, Real-Time Prescription Benefit and Electronic Prior Authorization” final rule (hereinafter referred to as the “HTI-4 final rule”) (90 FR 36536) appeared in the
Federal Register
as part of the “Medicare Program; Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals (IPPS) and the Long-Term Care Hospital Prospective Payment System and Policy Changes and Fiscal Year (FY) 2026 Rates; Changes to the FY 2025 IPPS Rates Due to Court Decision; Requirements for Quality Programs; and Other Policy Changes; Health Data, Technology, and Interoperability: Electronic Prescribing, Real-Time Prescription Benefit and Electronic Prior Authorization” final rule (hereinafter collectively referred to as the “FY 2026 IPPS/LTCH final rule”) (90 FR 36536), which appeared in the
Federal Register
on August 4, 2025. In the HTI-4 final rule, ONC finalized that Health IT Modules certified under the ONC Health IT Certification Program to 45 CFR 170.315(b)(3) are permitted to maintain conformance with either version 2017071 or version 2023011 of the NCPDP SCRIPT standard up to and including December 31, 2027. On and after January 1, 2028, all Health IT Modules certified to 45 CFR 170.315(b)(3) are required to support the NCPDP SCRIPT standard version 2023011. ONC also finalized that Health IT Modules seeking certification to the updated “electronic prescribing” health IT certification criterion in 45 CFR 170.315(b)(3) using the NCPDP SCRIPT standard version 2023011 must support certain electronic prior authorization transactions by January 1, 2028 (90 FR 36541).

Eligible hospitals and CAHs that participate in the Medicare Promoting Interoperability Program and MIPS eligible clinicians that participate in the MIPS Promoting Interoperability performance category must use certified EHR technology (42 CFR 495.4, 495.24(f)(1), and 414.1375(b)(1)). As provided in 42 CFR 414.1305 and 42 CFR 495.4, we define certified EHR technology (CEHRT) for these programs as EHR technology that has been certified under the ONC Health IT Certification Program to meet the 2015 Edition Base EHR definition or subsequent Base EHR definition
30

and

has been certified to certain ONC health IT certification criteria, adopted in 45 CFR 170.315, as necessary to report on objectives and measures in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. To complete the measures under the Electronic Prescribing objectives in those programs, eligible hospitals, CAHs, and MIPS eligible clinicians must use CEHRT certified to the “electronic prescribing” criterion in 45 CFR 170.315(b)(3).
31

Once their Health IT Module is certified to the “electronic prescribing” criterion finalized in the HTI-4 final rule, to complete the relevant measure requirements, participants in these programs are required to meaningfully use certified health IT capable of electronic prior authorization for prescription drugs using the NCPDP SCRIPT standard version 2023011 by January 1, 2028.

30
Base EHR means an electronic record of health-related information on an individual that (1) Includes patient demographic and clinical health information, such as medical history and problem lists; (2) Has the capacity to provide clinical decision support; support physician order entry; capture and query information relevant to healthcare quality; exchange electronic health information with, and integrate such information

from other sources; and (3) Has been certified to the certification criteria adopted by the Secretary in all of the following: section 170.315(a)(1), (2), or (3); (a)(5) and (14), (b)(1), (c)(1), and (g)(7), (9), (10); and (h)(1) or (2); section 170.315(a)(9) or (b)(11) for the period up to and including December 31, 2024; section 170.315(b)(11) on and after January 1, 2025; section 170.315(b)(4) on and after January 1, 2028 (
see
45 CFR 170.102).

31
For eligible hospitals and CAHs,
see
the FY 2026 IPPS/LTCH final rule (89 FR 69615); for MIPS eligible clinicians,
see
the CY 2025 Medicare Physician Fee Schedule final rule (89 FR 98417-98427).

We believe that providers would embrace electronic prior authorization using the NCPDP SCRIPT standard, as electronic prior authorization is less burdensome than manual prior authorization, as commenters told CMS in response to the 2022 CMS Interoperability and Prior Authorization proposed rule (89 FR 8765). In section II.C.4. of this proposed rule, we propose to require impacted payers to conduct electronic prior authorization using the NCPDP SCRIPT standard, which supports CMS's interoperability goals by reducing burden on providers and impacted payers. Requiring impacted payers to support the NCPDP SCRIPT standard also aligns with requirements for Medicare Part D prescribers, dispensers, and Part D sponsors, as finalized in the 2024 Part D and Health IT Standards final rule (89 FR 51238) and previous rulemaking, and enables other payers and providers to benefit from consistent standards.

b. NCPDP Formulary & Benefit Standard

The NCPDP F&B standard complements standards utilized for electronic prescribing, electronic prior authorization, and real-time prescription benefit applications, including the NCPDP SCRIPT standard, by providing formulary and benefit information at the health plan level. As discussed in section II.B. in this proposed rule, we are proposing to require impacted payers to support an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u), for providers to use in their prior authorization workflow for drugs covered under a pharmacy benefit. In the 2024 Part D and Health IT Standards final rule, the Secretary adopted the NCPDP F&B standard version 60 in 45 CFR 170.205(u)(1) (89 FR 51260). This is the most recently published and adopted version of the standard as of the date this proposed rule appears in the
Federal Register
. Accordingly, if ONC establishes an expiration date for the NCPDP F&B standard or for a specific version thereof, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements, and would be required to use another unexpired version adopted by the Secretary in 45 CFR 170.205(u). We are proposing an October 1, 2027 compliance date for this proposed requirement.

If this proposal is finalized, impacted payers could use an unexpired version of the NCPDP F&B standard adopted by the Secretary to provide a range of formulary and benefit information, such as formulary status, preferred alternatives, benefit coverage, and estimated co-pay information to end users, including providers, at the time of prescribing. This formulary and benefit information enables providers to determine at the point of prescribing whether a particular drug is covered and whether the impacted payer requires prior authorization. The information can then be used to create and send an electronic prior authorization request, using the NCPDP SCRIPT standard, to the payer or PBM, as appropriate.

The NCPDP F&B standard relies on payers producing a periodic flat file (or simple, plain text database) that includes point-in-time information about drugs covered under a pharmacy benefit.
32

The NCPDP F&B standard is mature and has widespread industry adoption to provide useful information about group-level drug coverage for a variety of use cases. However, the NCPDP F&B standard does not require this information to be updated in real time; therefore, as information changes, a payer's F&B file could become out of date. Furthermore, information is provided for group-level coverage information rather than being patient-specific.

32
National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit Standard IG, Version 13. NCPDP RTPB IGs are available to NCPDP members for free and to non-members for a fee at
https://standards.ncpdp.org/Access-to-Standards.aspx.

c. NCPDP Real-Time Prescription Benefit Standard

The NCPDP RTPB standard enables the real-time exchange of patient-specific eligibility, drug coverage (including any restrictions and alternatives), and estimated cost sharing to enable access to this information at the point of prescribing. In the 2024 Part D and Health IT Standards final rule, the Secretary adopted the NCPDP RTPB standard version 13 in 45 CFR 170.205(c)(1) (89 FR 51260). This is the most recently published and adopted version of the standard as of the date this proposed rule appeared in the
Federal Register
.

As discussed in section II.B.6. of this proposed rule, we are proposing to require impacted payers to support an unexpired version of the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c). Accordingly, if ONC establishes an expiration date for the NCPDP RTPB standard or for a specific version thereof, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements, and would be required to use another unexpired version adopted by the Secretary in 45 CFR 170.205(c). We are proposing an October 1, 2027 compliance date for this proposed requirement.

While the NCPDP F&B standard provides group-level coverage information to the provider, the NCPDP RTPB standard provides member-specific information to the provider. The NCPDP F&B and NCPDP RTPB standards can complement each other in the provider's workflow to allow for relevant formulary, coverage, cost, and prior authorization information to be utilized when prescribing a drug. Findings from NCPDP grant-funded research on the NCPDP F&B and NCPDP RTPB standards showed that when the NCPDP F&B standard is used in conjunction with the NCPDP RTPB standard, providers had a more complete view of patient-specific medication options, costs, and prior authorization information at the point of prescribing.
33

33
Journal of American Pharmacists Association. (2023, February 2). Formulary & Benefit and Real-time Pharmacy Benefit: Electronic Standards Delivering Value to Prescribers and Pharmacists.

Retrieved from
https://www.japha.org/article/S1544-3191(23)00016-X/abstractqq.

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

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

• The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs covered under a pharmacy benefit.

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

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

• The proposed October 1, 2027 compliance date for these proposals, as discussed in section II.B.2.c. of this proposed rule.

In addition, we request comments on the following:

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

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

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

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

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

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

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

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

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

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

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

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

• Does the CRD IG have the technical capability to return specific coverage information through the “CoverageInformation” extension?

++ How could the “CoverageInformation” extension be best utilized to indicate whether a particular drug is covered under a medical benefit and whether the Prior Authorization API should be used for electronic prior authorization?

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

3. Required Standards for FHIR APIs

a. Modification to Required Standards for FHIR APIs

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

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

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

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

• HL7 FHIR Standard in 45 CFR 170.215(a);

• US Core IG in 45 CFR 170.215(b)(1);

• SMART App Launch IG in 45 CFR 170.215(c);

• Bulk Data Access IG in 45 CFR 170.215(d); and

• OpenID Connect Core in 45 CFR 170.215(e).

We propose that the revised references to 45 CFR 170.215(a), (b)(1), and (c) through (e), as listed in Table 3, would be effective beginning on the effective date of the final rule, for all interoperability APIs.

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

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

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

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

• The proposal to become effective beginning on the effective date of the final rule.

In addition, we request comments on the following:

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

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

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

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

4. R

[Text truncated at 120,000 characters. The full text is on the page linked above.]

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2026-07205. Public record. Not legal advice.