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

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.

D. Requirements for Issuers That Offer Small Group Market

Qualified Health Plans on the Federally-facilitated Small Business Health Options Program Exchanges

F. Updates to Patient Access, Provider Directory, Provider

Access, and Payer-to-Payer APIs; API Usage Metrics

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

A. Purpose and Background

The ``Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for MA Organizations and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers'' final rule (85 FR 25510) (hereinafter referred to as the ``2020 CMS Interoperability and Patient Access final rule'') appeared in the Federal Register on May 1, 2020. That rule was the first phase of CMS's interoperability rulemaking and focused on giving patients access to their health data maintained by their payer through a Patient Access API. In that rule, we required MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and issuers that offer individual market QHPs on the FFEs (hereinafter referred to as ``individual market QHP issuers on the FFEs'') to implement a Patient Access API that allows patients, through health apps with the necessary functionality, to easily access their claims and encounter information, provider remittances, patient cost- sharing information, and clinical data, including laboratory results, maintained by the impacted payer.\1\ --------------------------------------------------------------------------- \1\ See 42 CFR 422.119(b) for MA organizations, 42 CFR 431.60(b) for state Medicaid FFS programs, 42 CFR 457.730(b) for state CHIP FFS programs, cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(b) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- The ``Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals (CAHs) in the Medicare Promoting Interoperability Program'' final rule (89 FR 8758) (hereinafter referred to as the ``2024 CMS Interoperability and Prior Authorization final rule'') appeared in the Federal Register on February 8, 2024. In that rule, we finalized requirements for impacted payers to improve the electronic exchange of health care information, not just with patients, but also with providers and other payers. We also finalized requirements for impacted payers to implement and maintain a Prior Authorization API that supports electronic prior authorization between providers and payers.\2\ We also finalized general process requirements for prior authorization, such as requiring MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to respond to prior authorization requests for non-drug items and services within certain timeframes. --------------------------------------------------------------------------- \2\ See 42 CFR 422.122(b) for MA organizations, 42 CFR 431.80(b) for state Medicaid FFS programs, 42 CFR 457.732(b) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(b) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we did not propose or finalize requirements that apply to drugs of any type because, as we discussed in the proposed and final rules, the processes and electronic standards for prior authorization of drugs differ from the non-drug items and services included in our final policies. We also acknowledged that there are existing laws and regulations around the prior authorization of drugs that may apply to impacted payers (such as the existing electronic prescribing requirements for covered Part D drugs in 42 CFR 423.160) (87 FR 76240 and 76241, and 89 FR 8762). However, we received many public comments in response to the ``Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program'' proposed rule (87 FR 76238) (hereinafter referred to as the ``2022 CMS Interoperability and Prior Authorization proposed rule''), which appeared in the Federal Register on December 13, 2022, as well as additional feedback from providers, payers, and standards developing organizations (SDOs), indicating that while some prior authorization processes and standards for drugs currently exist, the health care industry would benefit from consistent electronic prior authorization requirements to promote patients' timely access to drugs and alleviate burden for providers and payers. Commenters emphasized the impact that prior authorization for drugs has on patients and providers and urged CMS to implement similar requirements for drugs as were proposed for non-drug items and services. In addition, commenters explained that the Prior Authorization API can facilitate electronic prior authorization for drugs covered under a medical benefit, so the same standards and requirements could be used for that category of drugs. Commenters also pointed out that requirements already existed for Medicare Part D sponsors to support (and prescribers to use) a standard adopted by the Secretary for the prior authorization of covered Part D drugs, the National Council for Prescription Drug Programs (NCPDP) SCRIPT Standard Implementation Guide (NCPDP SCRIPT standard). Those [[Page 19892]] commenters suggested modeling requirements for the other types of impacted payers on the existing Part D requirements in 42 CFR 423.160, as established in the ``Medicare Program; Secure Electronic Prior Authorization for Medicare Part D'' final rule (85 FR 86824) (hereinafter referred to as the ``2020 Medicare Part D ePA final rule''), which appeared in the Federal Register on December 31, 2020. The 2024 CMS Interoperability and Prior Authorization final rule also established, improved, or shortened prior authorization timeframes for impacted payers other than QHP issuers on the FFEs (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities) to respond to prior authorization requests for non-drug items and services. Specifically, we finalized timeframes of 7 calendar days for standard requests and 72 hours for expedited requests, with the possibility of an extension of up to 14 days in certain circumstances (89 FR 8878). For Medicaid and CHIP, state law may establish a shorter timeframe.\3\ Some of the payers affected by those requirements had existing timeframes for prior authorization decisions, notices, and appeals that differed, so we aligned the prior authorization decision timeframes across impacted payers, except for QHP issuers on the FFEs (89 FR 8878). As discussed in the 2022 CMS Interoperability and Prior Authorization proposed rule and the 2024 CMS Interoperability and Prior Authorization final rule, we did not propose prior authorization decision timeframes for QHP issuers on the FFEs, in part because existing regulations in 45 CFR 147.136 already establish internal claims and appeals processes, external review processes, and pre-service claims (prior authorization) requirements for all non-grandfathered group and individual market plans or coverage (87 FR 76297 and 89 FR 8879). Specifically, 45 CFR 147.136(b)(3) specifies that individual market QHP issuers on the FFEs are generally subject to requirements of the Employee Retirement Income Security Act of 1974 (hereinafter referred to as ``ERISA'') (Pub. L. 93-406, enacted September 2, 1974) and internal claims and appeals procedures applicable to group health plans under 29 CFR 2560.503-1 as if the issuer were a group health plan. Thus, QHP issuers on the FFEs are required to provide notification of a plan's benefit determination for pre-service claims to enrollees within a reasonable period of time appropriate to the medical circumstances, but not later than 15 days for standard prior authorization decisions, and as soon as possible, taking into account the medical exigencies, but not later than 72 hours for expedited requests. The latter is a similar timeframe for notices to enrollees for expedited authorization decisions as finalized for other impacted payers (89 FR 8880). --------------------------------------------------------------------------- \3\ See 42 CFR 440.230(e) for state Medicaid FFS programs, 42 CFR 457.495(d)(2) for state CHIP FFS programs, 42 CFR 438.210(d) for Medicaid managed care plans, and 42 CFR 457.1230(d) for CHIP managed care entities. State law may not impose a shorter timeline on MA organizations in light of the preemption provisions in section 1856(b)(3) of the Social Security Act (the Act) and 42 CFR 422.402. --------------------------------------------------------------------------- At the time, we did not propose to change those timeframes because they are aligned with other non-grandfathered group and individual market plans. However, we received numerous comments that opposed the exclusion of QHP issuers on the FFEs from these policies and urged that QHPs offered on the FFEs should be aligned with the requirements for other CMS programs. Some expressed concern that not doing so would have negative effects on enrollee care, and that enrollees with coverage through these plans should be entitled to the same protections as those with coverage through the other impacted payers. In addition, we received comments that recommended we reconsider the exclusion of drugs from our proposals and suggested that CMS finalize the prior authorization process and Prior Authorization API requirements in the 2024 CMS Interoperability and Prior Authorization final rule to cover drugs covered under a medical benefit. Commenters further expressed that by failing to include drugs in those requirements, CMS was failing to address the biggest culprit of delay to timely care and administrative burden.

B. Summary of Major Proposals

We are proposing to require that impacted payers support electronic prior authorization for all drugs that require prior authorization. We are proposing two separate sets of standards to facilitate electronic prior authorization for all drugs, the HL7 FHIR standard (and certain FHIR IGs) as one set, and three NCPDP standards (the NCPDP SCRIPT standard, NCPDP Formulary & Benefit Standard Implementation Guide [NCPDP F&B standard], and the NCPDP Real-Time Prescription Benefit Standard Implementation Guide [NCPDP RTPB standard]) as the other set. The FHIR standard, including the IGs, and the three NCPDP standards, all facilitate electronic prior authorization for drugs; which standards set is applicable depends on whether the drug is covered under the payer's medical benefit or its pharmacy benefit. We are proposing to require impacted payers to expand their Prior Authorization API, finalized in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8758), to incorporate drugs covered under a medical benefit. We are also proposing to require impacted payers (other than MA organizations for whom requirements already exist) to support the proposed NCPDP standards for the electronic prior authorization of drugs covered under a pharmacy benefit. As proposed in this proposed rule, the Prior Authorization API comprises the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG, the HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) IG, and the HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG, and can be used to support drugs under a medical benefit, but should not be used for the prior authorization of drugs covered under a pharmacy benefit. Specifically, the PAS IG states that the IG ``SHOULD NOT be used for any medication that is covered under a pharmacy benefit where prior authorization is provided by another electronic exchange process (for example, NCPDP SCRIPT).'' \4\ --------------------------------------------------------------------------- \4\ NOTE: This document contains links to non-United States Government websites. We are providing these links because they contain additional information relevant to the topic(s) discussed in this document or that otherwise may be useful to the reader. We cannot attest to the accuracy of information provided on the cited third-party websites or any other linked third-party site. We are providing these links for reference only; linking to a non-United States Government website does not constitute an endorsement by CMS, HHS, or any of their employees of the sponsors or the information and any products presented on the website. Also, please be aware that the privacy protections generally provided by United States Government websites do not apply to third-party sites. Health Level Seven International. (2026, March 27). Da Vinci Prior Authorization Support (PAS) FHIR: Use Cases and Overview. Retrieved from https://hl7.org/fhir/us/davinci-pas/2.2.1/en/usecases.html. --------------------------------------------------------------------------- Conversely, the NCPDP SCRIPT standard include instructions that it is to be used for ``products covered by a patient's pharmacy benefit.'' The NCPDP F&B and NCPDP RTPB standards complement the NCPDP SCRIPT standard and apply to the same category of drugs. Payers can use the NCPDP F&B standard to make available formulary and benefit information, including prior authorization requirements, at the health plan level. The NCPDP RTPB standard enables real-time exchange at the point-of- prescribing of patient-specific eligibility, coverage, and estimated cost-sharing information for drugs covered [[Page 19893]] under a pharmacy benefit. Therefore, these sets of FHIR and NCPDP standards are mutually exclusive and, when used in conjunction, encompass the full scope of drugs that are covered by any particular payer. We propose that impacted payers be required to support electronic prior authorization for all drugs through the Prior Authorization API and NCPDP standards beginning on October 1, 2027. Our proposals regarding the prior authorization of drugs are similar to the provisions finalized for non-drug items and services in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8897) but with special consideration to existing policies, operational processes, and standards for the electronic prior authorizations of drugs. The proposals would require impacted payers to support electronic prior authorization for all drugs, which should improve the process for impacted payers' patients and providers. In section II.A. of this proposed rule, we describe each of these standards and how they would be used. In section II.B. of this proposed rule, we describe our proposals as they apply to each category of impacted payer, including program specifics as to distinction of drugs covered under medical benefits versus drugs covered under pharmacy benefits. For the proposed requirement to incorporate drugs covered under a medical benefit into the Prior Authorization API, we are proposing an October 1, 2027 compliance date. As discussed in section II.B.3. of this proposed rule, incorporating drugs into Prior Authorization APIs means that, using the proposed standards, information is available through the API as to whether prior authorization is required for drugs covered under a medical benefit, the coverage and documentation requirements for prior authorization are available, and that the API can transmit prior authorization requests and decisions between providers and the payer. Medicare Part D sponsors (including MA organizations that offer a Medicare Advantage Prescription Drug [MA-PD] plan) are already required, in 42 CFR 423.160(b)(1), to use an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) as part of their electronic prescription drug programs. Prescribers and dispensers are also required to use an adopted version of the NCPDP SCRIPT standard when electronically transmitting prescriptions and prescription-related information for covered Part D drugs for Part D- eligible individuals. Similarly, beginning January 1, 2027, Part D sponsors are required, in 42 CFR 423.160(b)(3) and (b)(5), to implement for uses described in those paragraphs unexpired versions of the NCPDP F&B and RTPB standards adopted by the Secretary in 45 CFR 170.205(u) and 45 CFR 170.205(c), respectively. We propose that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, including small group market QHP issuers on the FF-SHOPs, similarly could use any unexpired version of the NCPDP standards adopted by the Secretary in 45 CFR 170.205(b), (c), and (u) to support electronic prior authorization of drugs covered under a pharmacy benefit. We are proposing an October 1, 2027 compliance date to support the proposed NCPDP standards to facilitate electronic prior authorization of drugs covered under a pharmacy benefit. Consistent with section 3004(b)(3) of the PHSA, the Secretary adopts standards for HHS use, including those adopted in 45 CFR 170.215. We are proposing to require impacted payers to implement and maintain their required FHIR APIs in conformance with certain applicable standards adopted in 45 CFR 170.215, without specifying versions of each required standard, which would allow impacted payers to use unexpired versions of the required standards, as the Secretary adopts updated versions in 45 CFR 170.215. Where more than one unexpired version of a standard is adopted in 45 CFR 170.215, impacted payers would be able to use any of the unexpired standards, allowing for transition periods as updated versions are adopted by the Secretary and older versions expire. To support interoperability, these proposals require impacted payers to implement and maintain API technology conformant with certain IGs that were recommended in the 2024 CMS Interoperability and Prior Authorization final rule, as applicable to each interoperability API (89 FR 8945). We are proposing an October 1, 2027 compliance date to implement the proposed standards. We are also recommending additional IGs for some of the APIs that could be used to support certain use cases. We are proposing to replace the policy finalized in the 2024 CMS Interoperability and Prior Authorization final rule that allows states with small FFS populations to request an exemption from CMS for the non-drug items and services Prior Authorization API requirements with a policy that would allow all state Medicaid and CHIP FFS programs to request extensions to the compliance date for that requirement. We are proposing that those extensions would only be available until the compliance date for the HIPAA Administrative Simplification proposals in this rule, if the proposals are finalized. In addition, we are proposing a process for state Medicaid and CHIP FFS programs to request from CMS extensions to allow additional time to meet the proposed requirement to incorporate drugs covered under a medical benefit into the Prior Authorization API and the proposed requirement to support the NCPDP standards for electronic prior authorization of drugs covered under a pharmacy benefit, if they meet certain criteria. We are also proposing that QHP issuers on the FFEs be permitted to request an exception from the requirement to support electronic prior authorization of drugs covered under a pharmacy benefit through the proposed NCPDP standards, as part of the annual QHP certification process. Issuers could seek an exception by submitting a narrative justification with information specified in 45 CFR 156.223(h), including why the QHP issuer on the FFEs cannot reasonably satisfy the requirements for the applicable plan year.\5\ Those proposals are similar to the exception policies finalized in the 2024 CMS Interoperability and Prior Authorization final rule and are discussed in section II.B.7. of this proposed rule.\6\ --------------------------------------------------------------------------- \5\ We note that existing language in 45 CFR 156.223(d)(1)(i) would also allow QHP issuers to request an exception to the requirement, if finalized, to incorporate electronic prior authorization for drugs under a medical benefit into the Prior Authorization API. \6\ For exceptions, see 45 CFR 156.222(c) and 45 CFR 156.223(d) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- We are proposing to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to respond to the provider with a specific reason for denying a prior authorization request for any drugs. We are proposing an October 1, 2027 compliance date for those impacted payers to respond to a provider with a specific reason for denying a prior authorization request for any drugs. This proposal builds on the requirement finalized in the 2024 CMS Interoperability and Prior Authorization final rule that impacted payers must provide a specific reason to the provider for denying a prior authorization request for non-drug items and services.\7\ --------------------------------------------------------------------------- \7\ See 42 CFR 422.122(a) for MA organizations and applicable integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs, through cross reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8) for Medicaid managed care plans, 42 CFR 457.732(a) for state CHIP FFS programs, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(a) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- [[Page 19894]] For state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities, the timeframes for making decisions on prior authorization requests for covered outpatient drugs is 24 hours.\8\ However, the term ``covered outpatient drugs'' does not apply to all drugs that are covered by states for which states receive Federal Financial Participation (FFP) from CMS. Therefore, we are requesting comment to identify whether there are drugs for which a prior authorization timeframe does not currently exist and needs to be established. If there are gaps identified in the prior authorization decision timeframe requirements for drugs, in order to align patient protections and create consistent requirements across the Medicaid and CHIP programs, we propose to require state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities to provide notice of prior authorization decisions for drugs within a timeframe that aligns with applicable existing decision timeframe requirements. We are proposing an October 1, 2027 compliance date. In addition, we are proposing to require state CHIP FFS programs to make decisions on prior authorization requests for prescription drugs for which the state receives FFP no later than 24 hours after receiving a prior authorization request, rather than the current requirements that cover both drugs and non-drug items and services. We are proposing an October 1, 2027 compliance date. --------------------------------------------------------------------------- \8\ See section 1927(d)(5)(A) of the Act for state Medicaid FFS programs, 42 CFR 438.3(s)(6) for Medicaid managed care plans, and 42 CFR 457.1230(d) for CHIP managed care entities. --------------------------------------------------------------------------- We are proposing to shorten timeframes within which QHP issuers on the FFEs, including small group market QHP issuers on the FF-SHOPs, must make a decision on prior authorization requests by establishing timeframes by which QHP issuers on the FFEs must notify requesting providers of their decision. The proposed timeframes generally align with the timeframes for other impacted payers that we finalized in the 2024 CMS Interoperability and Prior Authorization final rule for non- drug items and services (89 FR 8878) and that we are proposing for drugs in this proposed rule. Specifically, we propose to require QHP issuers on the FFEs to send notice of their decision to the requesting provider for standard prior authorization requests for non-drug items and services as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after receiving the request. We are not proposing to change the existing 72-hour timeframe to notify enrollees about prior authorization decisions on expedited requests for non-drug items and services, but are proposing that QHP issuers on the FFEs notify the requesting provider of their decision on a prior authorization request for non-drug items and services within the same timeframe. These proposed timeframes for non-drug items and services align with existing timeframes that were finalized in the 2024 CMS Interoperability and Prior Authorization final rule for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities (89 FR 8878). We are also proposing to require QHP issuers on the FFEs to send notice of their decision to the requesting provider for standard prior authorization requests for drugs as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request. We are further proposing to require QHP issuers on the FFEs to send notice of their decision to the requesting provider for expedited prior authorization requests for drugs as expeditiously as the enrollee's health condition requires, but no later than 24 hours after receiving the request. These proposed timeframes generally align with existing requirements for Part D sponsors in 42 CFR 423.568(b) and in 42 CFR 423.572(a). For these proposals, we are proposing an October 1, 2027 compliance date. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized an annual March 31 reporting deadline for all impacted payers to report Patient Access API usage metrics to CMS and to publicly post prior authorization metrics for non-drug items and services from the previous year (89 FR 8784, 8817, and 8855). However, we have determined that such deadlines may not align with Medicaid managed care plans' and CHIP managed care entities' contract rating periods and with the QHP certification process for QHP issuers on the FFEs. Therefore, to align the reporting deadlines with the contract rating period, we are now proposing to require Medicaid managed care plans and CHIP managed care entities to report Patient Access API usage metrics from each rating period to states no later than 90 days after the end of each rating period and to publicly post the required prior authorization metrics for non-drug items and services no later than 90 days after the end of each rating period. For QHP issuers on the FFEs, we are proposing regulatory text to refer to the reporting deadline for Patient Access API usage metrics in a manner similar to the reporting deadlines for other plan data that CMS collects during the annual QHP certification process. Specifically, we propose that following each year it offers a QHP on an FFE, a QHP issuer on the FFEs must report the specified metrics to CMS as aggregated, de-identified data at the issuer level in the form and manner and within the timeframes specified by the Secretary. That would allow flexibility for CMS to include API usage metrics reporting within specific deadlines set for the QHP certification process, which, in practice, is generally the final deadline for the QHP certification process that takes place the following year.\9\ We are proposing that these changes become effective beginning on the effective date of the final rule. --------------------------------------------------------------------------- \9\ Information about QHP certification, including deadlines can be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline. --------------------------------------------------------------------------- Building on the requirement finalized in the 2024 CMS Interoperability and Prior Authorization final rule that impacted payers must report Patient Access API usage metrics to CMS, we are proposing to require impacted payers to report similar usage metrics about their Provider Access, Payer-to-Payer, and Prior Authorization APIs.\10\ Collecting these metrics should help CMS evaluate the impact of our policies and plan for future changes, if necessary. We are proposing that the metrics would be reported annually by MA organizations at the contract level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans and CHIP managed care entities at the plan and program level, and QHP issuers on the FFEs at the issuer level. We are proposing that beginning in 2028, MA organizations and state Medicaid and CHIP FFS programs would be required to report the previous calendar year's metrics by March 31 of each year. We are proposing that Medicaid managed care plans and CHIP managed care entities would report their metrics to states from [[Page 19895]] each rating period no later than 90 days after the end of each rating period. We are proposing that QHP issuers on the FFEs report their API usage metrics as aggregated, de-identified data at the issuer level in the form and manner and within the timeframes specified by the Secretary, as we are proposing to amend the deadline for Patient Access API usage metrics. For these proposals, we propose compliance dates beginning in 2028. --------------------------------------------------------------------------- \10\ See 42 CFR 422.119(f) for MA organizations, 42 CFR 431.60(f) for state Medicaid FFS programs, through cross reference to 431.60 in 42 CFR 438.242(b)(5)(iii) for Medicaid managed care plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing cross reference to 42 CFR 438.242 in existing 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(f) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to report on their websites certain prior authorization metrics for non-drug items and services, including the percentage of prior authorizations that were approved, denied, approved after appeal, and approved after the timeframe for review was extended (89 FR 8897). In an effort to provide more useful and complete information, we are now proposing that impacted payers report a numeric count for each of those metrics (in addition to the percentages). We are also proposing that impacted payers report six new metrics: four new metrics about prior authorization denials after an extended timeframe and appeals for non- drug items and services and two new metrics about prior authorization approvals after an extended timeframe and appeals for non-drug items and services for expedited prior authorization requests only. The proposed metrics complement existing metrics finalized in the 2024 CMS Interoperability and Prior Authorization final rule about prior authorization approvals after an extended timeframe and appeals for non-drug items for standard prior authorization requests. We are proposing compliance dates beginning in 2028 for impacted payers to report the additional metrics. Similarly, we are proposing to require impacted payers to publicly post on their websites a set of metrics on prior authorizations for all drugs (excluding covered Part D drugs for MA-PD plans). To align with the finalized requirements and our new proposals, we are proposing that these reports must be posted no later than March 31 following any calendar year that the impacted payer offered that type of plan for MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs, and no later than 90 days after the end of each rating period for Medicaid managed care plans and CHIP managed care entities.\11\ We are proposing compliance dates beginning in 2028 for impacted payers to post these metrics. --------------------------------------------------------------------------- \11\ See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through cross reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- We propose to include small group market QHP issuers on the FF- SHOPs in the list of impacted payers for all the proposals in this proposed rule that apply to individual market QHPs on the FFEs. In addition, we are proposing to apply the existing requirements in 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223, which were finalized in the 2020 CMS Interoperability and Patient Access final rule and in the 2024 CMS Interoperability and Prior Authorization final rule (85 FR 25510 and 89 FR 8758), to small group market QHP issuers on the FF- SHOPs. We did not apply these policies to small group market QHP issuers on the FF-SHOPs in previous rulemaking due to concerns about placing burden on these issuers (85 FR 25553 and 89 FR 8767). However, based on subsequent research, all issuers that offer small group market QHPs on the FF-SHOPs, as of the time of this proposal, also offer individual market QHPs on the FFEs. Therefore, we anticipate that the burden for these issuers to implement these proposals for their small group market QHPs on the FF-SHOPs should be relatively low because these issuers are already required to implement the policies for their individual market QHPs on the FFEs. Since plan year 2021, we have only seen one instance of a new entrant into an FF-SHOP Exchange. However, should this change in the future--for example, if an issuer that does not offer one or more individual market QHPs on the FFEs newly enters an FF-SHOP, and this proposal has been finalized, we could still mitigate potential burden for such an issuer by considering whether an exception to one or more of these requirements is appropriate based on, for example, whether such an exception would be in the interests of qualified individuals and qualified employers.\12\ --------------------------------------------------------------------------- \12\ For more information on interoperability and QHP certification, including further detail on the exceptions process, see https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability. Discussion of this topic is also available in the 2024 CMS Interoperability and Prior Authorization final rule preamble: 89 FR 8906. --------------------------------------------------------------------------- Throughout this proposed rule, we will refer to ``QHP issuers on the FFEs'' where we propose requirements that apply to both individual market QHP issuers on the FFEs and small group market QHP issuers on the FF-SHOPs, and we will refer to ``small group market QHP issuers on the FF-SHOPs'' in proposals to apply requirements in 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223 that we previously finalized for individual market QHP issuers on the FFEs. We are proposing that references to QHP issuers on the FFEs in 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223 would include small group market QHP issuers on the FF-SHOPs, because that term is used throughout 45 CFR part 156 Subpart C to refer to QHPs offered in both the individual and small group markets. We will only use different terminology in cases where there is a need to distinguish between individual market QHP issuers on the FFEs and small group market QHP issuers on the FF-SHOPs, such as in proposals to apply a different compliance date for small group market QHP issuers on the FF-SHOPs. For example, because the requirements in 45 CFR 156.221 already took effect for plan years beginning on or after January 1, 2021, our proposed amendment to that regulation would apply the requirements to implement and maintain a Patient Access API to small group market QHP issuers on the FF-SHOPs as of plan years beginning on or after January 1, 2028. We are also proposing a compliance date of plan years beginning on or after January 1, 2028 for small group market QHP issuers on the FF-SHOPs to comply with rules in 45 CFR 156.222 to implement and maintain Provider Access and Payer-to-Payer APIs unless granted an exception pursuant to 45 CFR 156.222(c). We believe that aligning these compliance dates would simplify these requirements, and that it likely provides enough time for issuers that have already implemented the required APIs for their individual market QHPs on the FFEs. The phrase ``plan years beginning on or after January 1'' already accommodates small group market QHP issuers on the FF-SHOPs that may have non-calendar year plan years. We solicit comments on the proposals throughout this rule specifically regarding the proposed compliance dates for small group market QHP issuers on the FF-SHOPs, including regarding whether these plans may need more time to implement these requirements. For instance, how could the prior authorization proposals in section II.B. of this proposed rule (electronic prior authorization proposal applicable to all QHP issuers on the FFEs) and II.C. of this proposed rule (prior authorization processes applicable to all QHP issuers on the FFEs) affect small group market QHP issuers on the FF- SHOPs' ability [[Page 19896]] to meet the requirements proposed in section II.D. of this proposed rule (requirements for small group market QHP issuers on the FF-SHOPs), and vice versa? To support implementation of the policies finalized in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules, we propose to require impacted payers to report their API endpoints for each of the required APIs to CMS. In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, we received numerous comments from the public indicating that a centralized directory of API endpoints would be necessary to unlock the full potential of our electronic data exchange policies and reduce administrative burden (89 FR 8932). For instance, a centralized directory of API endpoints could help providers locate a payer's Provider Access API to request patient data or Prior Authorization API to submit a prior authorization request. In addition, payers will need to discover each other's API endpoints to exchange data via the Payer- to-Payer API. Commenters emphasized that there would be a significant burden if payers' API endpoints had to be found individually rather than being listed in a centralized directory. Therefore, we are proposing to require impacted payers to report their Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization API endpoints and related information to CMS no later than 60 days after the effective date of a final rule, in a manner to be determined. We are also proposing that new impacted payers be required to report this information no later than 60 days before they begin covering patients under the applicable CMS program. To ensure that patients, providers, and other payers can have complete and appropriate access to information about prior authorizations, we are proposing to require impacted payers to make information about prior authorization requests and decisions for all drugs available to patients via the Patient Access, Provider Access, and Payer-to-Payer APIs (collectively ``Access APIs''). For the Patient Access and Provider Access APIs, this includes, as applicable, the status of the prior authorization; the date the prior authorization was approved or denied; the date or circumstance under which the authorization ends; the drug or drugs approved (including the dosage); if the prior authorization was denied, a specific reason why the request was denied; and related structured administrative and clinical documentation submitted by a provider. For the Payer-to-Payer API, that includes, as applicable, the status of the prior authorization; the date the prior authorization was approved; the date or circumstance under which the authorization ends; the drugs or drugs approved (including the dosage); and related structured and unstructured administrative and clinical documentation submitted by a provider, excluding denied prior authorization requests. We are proposing an October 1, 2027 compliance date for these proposals. In addition, we are proposing to add a definition for ``failure to report'' in 42 CFR 403.902 to support the Open Payments program. The Open Payments program, mandated by section 1128G of the Social Security Act (hereinafter referred to as ``the Act'') and codified in 42 CFR 403.900 through 403.914, requires the pharmaceutical and medical device industry to submit information about certain payments or other transfers of value made to certain types of health care providers. This proposal would allow CMS to impose a CMP on applicable manufacturers or applicable GPOs if those entities fail to grant CMS timely access to documents for the purposes of an audit authorized by 42 CFR 402.912(e)(2). We propose this definition be effective beginning on the effective date of the final rule. Under the Administrative Simplification provisions of HIPAA (Part C of Title XI of the Act), HHS is proposing to adopt the FHIR standard and certain associated IGs as the standards for dental, professional, and institutional ``referral certification and authorization'' transactions and ``eligibility for a health plan'' transactions associated with prior authorization. Specifically, in addition to the FHIR standard, HHS is proposing to adopt the HL7 FHIR US Core (US Core), HL7 Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Framework (SMART App Lauch), CRD, DTR, and PAS IGs in place of the adopted versions of the X12N 278 Health Care Services Review--Request for Review and Response transaction standard (X12N 278 transaction standard) in 45 CFR 162.1302 and the existing X12N 270/271 Health Care Eligibility Benefit Inquiry and Response transaction standard (X12N 270/271 transaction standard) in 45 CFR 162.1202 for transactions related to prior authorization. Additionally, HHS is proposing to adopt the HL7 FHIR Da Vinci Clinical Data Exchange (CDex) IG in 45 CFR 162.1302(g)(2)(vii) as the attachment standard for prior authorization transactions. The proposals to adopt the FHIR standards would only apply to dental, professional, and institutional transactions, not to those for retail pharmacy drugs, which are currently required to be conducted using NCPDP standards. HHS proposes a compliance date for these HIPAA Administrative Simplification proposals 24 months after the effective date of a final rule, except for small health plans, for which HHS proposes a compliance date 36 months after the effective date of a final rule. HHS is making these proposals after evaluating the results of the exception from the currently adopted standards granted to the HL7 Da Vinci Project, as provided in 45 CFR 162.940, to test FHIR standards.\13\ --------------------------------------------------------------------------- \13\ Centers for Medicare & Medicaid Services. (2026, April 7). Exceptions Process. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process. --------------------------------------------------------------------------- As part of this proposed rule, ONC \14\ is proposing to adopt updated versions of certain health IT standards and specifications in 45 CFR 170.215 on behalf of HHS. Specifically, ONC is proposing to adopt updated versions of the health IT standards and specifications codified in 45 CFR 170.215(j)(1) through (3), (k)(1), (m), and (n), which CMS is proposing to require impacted payers to use. Additionally, ONC is proposing a January 1, 2028 expiration date for versions of the standards and specifications currently in 45 CFR 170.215(j)(1) through (3), (k)(1), (m), and (n), provided that the proposals to adopt the newer versions of these adopted standards are finalized. These updated standards versions could support a more robust health IT infrastructure, create consistency for industry, and facilitate interoperability by ensuring that health IT leveraging these standards under different HHS programs use the same baseline standards for the same use cases, such as electronic prior authorization. --------------------------------------------------------------------------- \14\ ASTP/ONC is now referred to as ONC, pursuant to a notice which appeared in the Federal Register on April 1, 2026 (91 FR 16204). Although, at the time of specific references noted herein, ONC was either referenced as ASTP/ONC or as ONC, for clarity, all references in this document are now noted as ONC. --------------------------------------------------------------------------- Finally, we are publishing five requests for information (RFIs) to gather information that may support future rulemaking or other initiatives. The RFIs are related to electronic event notifications for value-based care and care coordination, health care resiliency and securing health care operations in a modern health care ecosystem, improving the implementation of payer API technology through testing and [[Page 19897]] certification, using technology to manage step therapy, and prior authorization requirements for laboratory tests and durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS) items. Electronic event notifications are valuable tools for coordinating care in the modern health care environment, and we are seeking comment on ways to improve this process with expanded use and content of electronic event notifications (often referred to as admission, discharge, and transfer, or ``ADT'' notifications). We want to understand the types of providers or other entities that should receive ADT notifications along with technical approaches that are currently in use or that could be used for patient event notifications. We also seek comments on health IT certification criteria for notification capabilities and strengthening enforcement of ADT notification requirements. Hacking, ransomware, and other cybersecurity attacks on health care systems and electronic protected health information (ePHI) present an ever-increasing threat. These attacks have already caused, and could continue to cause, significant disruption to the health care industry, potentially resulting in significant harm to patients, providers, payers, and the health care ecosystem at large. We are seeking feedback on opportunities to strengthen, protect, and increase the resiliency of our health care system in cybersecurity spaces to prevent and better handle future threats. Additionally, we would like to hear about existing standards and technologies, as well as the current role of point-to-point connections within the health care system. Monitoring compliance and technical conformance with standards is critical to effective interoperability within the health care ecosystem based on the API requirements that we have established for impacted payers. We are seeking comment on steps that we could take to improve oversight of payer APIs, for instance, through strengthening testing and transparency requirements. We are also exploring opportunities to leverage existing programs, such as the ONC Health IT Certification Program, to ensure that API technology used by payers meets the technical requirements we establish. We are also seeking comments on ways to streamline the step therapy process through technology and data sharing (such as the Payer-to-Payer API) to allow payers access to historical patient information. We seek comment on how technology may facilitate step therapy determinations and improve current step therapy processes. This includes the role of technology in evaluating and applying step therapy criteria and how payers evaluate and honor step therapy criteria from other payers. Prior authorization requirements for laboratory tests and DMEPOS items have emerged, in some instances, as a barrier to care and coverage that impacts both patients and providers. The primary issues associated with prior authorization for laboratory tests and DMEPOS items are coordination between providers and laboratories or DMEPOS suppliers and the length of time approval takes for tests and equipment. We are soliciting public comment on how prior authorization for laboratory tests and DMEPOS items impacts patient care and provider burden and what can be done to mitigate that burden.

C. Specific Terms Used in This Proposed Rule

Throughout this proposed rule, we use terms such as ``patient,'' ``consumer,'' ``beneficiary,'' ``enrollee,'' and ``individual.'' In this proposed rule, we use the term ``patient'' as an inclusive term. Each CMS program may use different terms to refer to patients in regulation. Therefore, in this proposed rule, we use ``patients'' collectively across programs. However, when discussing proposals for a particular program, we will use specific terms applicable to individuals covered under that program. Also, when we discuss patients, the term includes, where applicable, a patient's personal representative. For example, a patient or their personal representative may access certain types of information under the proposals in this proposed rule. However, when we refer to a patient's medical needs or health records, we do not include the medical needs or health records of the patient's personal representative. Pursuant to the ``Standards for Privacy of Individually Identifiable Health Information'' final rule (65 FR 82462) (hereinafter referred to as the ``HIPAA Privacy Rule''), which appeared in the Federal Register on December 28, 2000, 45 CFR 164.502(g), and related guidance, a ``personal representative'' is a person authorized under state or other applicable law to act on behalf of an individual in making health care-related decisions (such as a parent, guardian, or person with a medical power of attorney).15 16 Under the HIPAA Privacy Rule, the individual's personal representative generally may exercise the right to access the individual's protected health information (PHI). --------------------------------------------------------------------------- \15\ See 45 CFR parts 160 and 164, subparts A and E. \16\ United States Department of Health and Human Services. (2020, January 31). Health Information and Privacy. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html and https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html. --------------------------------------------------------------------------- We also use terms such as ``payer,'' ``plan,'' and ``issuer'' in this proposed rule. Certain portions of this proposed rule are applicable to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans (managed care organizations [MCOs], Prepaid Inpatient Health Plans [PIHPs], and Prepaid Ambulatory Health Plans [PAHPs]), CHIP managed care entities (MCOs, PIHPs, and PAHPs), QHP issuers on the FFEs, including proposals for small group market QHP issuers on the FF-SHOPs. We use the term ``impacted payer'' in the preamble of this proposed rule as an inclusive term for all these entities and programs and, in the case of plans, plan types, but we also use specific terms as applicable in various sections of this proposed rule. Notably, the term ``impacted payers'' only applies to the CMS proposals in this proposed rule, not to the HHS proposals for HIPAA Administrative Simplification. As discussed in section II.H. of this proposed rule, the HIPAA Administrative Simplification proposals would apply to HIPAA covered entities, as described in section 1172(a) of the Act and defined in 45 CFR 160.103. Some plans that participate in those CMS programs may not be permitted to use prior authorization (such as Private FFS MA plans) or may choose not to use prior authorization. Our prior authorization proposals only apply to the extent that a payer (or plan) uses prior authorization. Therefore, if an impacted payer does not use prior authorization, they would not be subject to the prior authorization proposals. However, other proposals, such as those related to the Access APIs and standards, would apply to all types of plans under the categories of impacted payers. Many payers use a pharmacy benefit manager (PBM) to manage prescription drug benefits on their behalf, including through utilization management techniques such as prior authorization. These proposals do not apply directly to PBMs, but we understand that, if these proposals are finalized, PBMs may play a role in helping impacted payers meet the requirements proposed in this rule. For example, if a PBM is contracted by an impacted payer to manage its prescription drug benefits, including to [[Page 19898]] conduct prior authorization, it may make sense for the payer to have providers send prior authorization requests for those drugs directly to the PBM. In that case, if finalized, the PBM would be required to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs, thereby making electronic prior authorization available to providers and meeting the proposed requirement on behalf of the impacted payer. Such arrangements would be permissible under these proposals, if allowed under applicable program rules. However, we emphasize that the ultimate responsibility for regulatory compliance would be on impacted payers themselves. Although Medicare FFS is not directly affected by the CMS interoperability regulations, CMS continues to explore and initiate opportunities to enhance electronic prior authorization within the Medicare FFS program, as appropriate, including those for drugs. The Medicare FFS program has developed a Prior Authorization API that makes available Medicare coverage criteria rules and documentation requirements to providers. This API helps providers determine whether prior authorization is required and identify the necessary documentation. The API also facilitates the extraction of relevant clinical information from the provider's electronic health record (EHR) to compile the required documentation and enables the electronic submission of prior authorization requests in a structured format to CMS review contractors. We want to ensure that Medicare beneficiaries can benefit from the policies we are proposing, regardless of their coverage or delivery system. We intend for the Medicare FFS program to be a market leader on electronic prior authorization and therefore, seek comment throughout this proposed rule on how these proposals could apply to Medicare FFS. In addition, Medicare FFS is a HIPAA covered entity, subject to the HIPAA Administrative Simplification statutory provisions. Therefore, if HHS' proposals in section II.H. are finalized, Medicare FFS would be subject to the electronic transaction standards adopted by the Secretary. As was the case for the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules, Medicare Supplemental Insurance plans (commonly known as Medigap) are not impacted payers. Medigap plans do not perform prior authorization but rely on coverage determinations by Medicare FFS. In addition, as stated in the 2020 CMS Interoperability and Patient Access final rule, Program of All-Inclusive Care for the Elderly (PACE) organizations are not impacted payers under the CMS interoperability rules (85 FR 25621). For purposes of this proposed rule, references to QHP issuers on the FFEs exclude issuers offering stand-alone dental plans (SADPs) on the FFEs. In the 2024 CMS Interoperability and Prior Authorization final rule, we did not propose or finalize requirements applicable to SADP issuers because they have relatively lower enrollment and premium intake compared to individual market QHP issuers on the FFEs. In addition, we had concerns that requiring those plans to comply with the final rule's policies could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees (89 FR 8766). Several public comments also made this point, that a requirement for SADP issuers to implement the required FHIR APIs would impose burden with minimal or no benefit (85 FR 25552 and 25553). Additionally, SADP issuers are not required to cover prescription drugs. When a dental provider writes a prescription, that drug is generally processed through the enrollee's non-dental medical benefit. Although dental providers may provide medication as part of a dental procedure, such as local anesthesia, it is our understanding that this is generally part of the dental procedure itself and therefore dental providers are reimbursed for the service as a bundle rather than through a separate claim for drugs. Therefore, we are not proposing to apply requirements to SADP issuers, but we solicit comment on whether the considerations described previously do in fact diminish the need for electronic prior authorization requirements and prior authorization process requirements for SADP issuers. We solicit comments on whether we should consider future rulemaking to apply these proposed requirements and those finalized in the 2024 CMS Interoperability and Prior Authorization final rule to SADP issuers. For the purposes of this proposed rule, FFEs include FFEs in states that perform plan management functions, and as noted in the 2024 CMS Interoperability and Prior Authorization final rule, State-based Exchanges on the Federal Platform (SBE-FPs) are not FFEs, even though patients in those states enroll in coverage through HealthCare.gov (89 FR 8761). Hence, issuers in SBE-FPs would not be impacted payers subject to the CMS proposals in this proposed rule. We believe that it is appropriate at this time to continue to exclude issuers on the State-based Exchanges (SBEs), including SBE-FPs, as impacted payers to keep with prior interoperability rulemaking. As we assess the effectiveness of interoperability policies, we will consider whether future rulemaking to include those types of issuers as impacted payers is appropriate, as we are proposing now for small group market QHP issuers on the FF-SHOPs. Importantly, we will be informed by the Patient Access API usage metrics required in 45 CFR 156.221(f), and, if finalized, the proposed Provider Access, Payer-to-Payer, and Prior Authorization API usage metrics discussed in section II.F.2.c. of this proposed rule. This data, as well as information we receive from issuers applying for QHP certification about their interoperability activities, will help us to understand how patients, providers, and payers use these tools and the success of current requirements. We also solicit comment in this proposed rule on whether to consider future rulemaking to extend these proposals, and those policies finalized in the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules, to issuers that offer coverage through SBE-FPs, SBEs, or both. In the 2024 CMS Interoperability and Prior Authorization final rule, we encouraged these Exchanges to consider adopting similar requirements (89 FR 8761), and, in this proposed rule, we solicit comment on the extent to which they have or may do so, as well as potential feasible deadlines for issuers in those Exchanges to implement interoperability requirements, so their enrollees can benefit from access to their health care data and more efficient and timely prior authorization processes. In this proposed rule, we use the terms ``provider'' and ``supplier'' to mean individuals, organizations, and institutions that provide or furnish health services, such as clinicians (that is, physicians and other practitioners), hospitals, skilled nursing facilities (SNFs), home health agencies, hospice settings, laboratories, pharmacies, suppliers of DMEPOS items, and community- based organizations, as appropriate in the context used. Similarly, we are generally not using the term ``prescriber'' in this rule, as ``provider'' is a broader term that includes any individual who authorizes a particular prescription or order. Our proposals related to the prior authorization of drugs are discussed in the context of providers who request [[Page 19899]] prior authorization from a payer, which may or may not be the actual prescriber. Many of the existing and proposed interoperability standards are based on API technology. An API is a set of rules that lets different software systems communicate with each other. It defines how one program (a client, often an app) can request data or services from another system (a server), and how the response should be structured. APIs are commonly used to connect apps. For example, a health app can use an API implemented within a payer's system to request and receive a specific patient's data. This allows developers to build on and communicate with existing systems without needing to understand their internal workings. APIs are essential for building modern, integrated digital experiences in a variety of industries, including health care, banking, and e-commerce.\17\ --------------------------------------------------------------------------- \17\ The Office of the National Coordinator for Health Information Technology. (n.d.). Application Programming Interfaces. Retrieved from https://www.healthit.gov/api-education-module/story_html5.html. --------------------------------------------------------------------------- Throughout this rule, we collectively refer to the APIs finalized in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules--the Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization APIs--as the ``interoperability APIs.'' When we refer to ``access APIs,'' we mean those that are used primarily to access a specific patient's health record, the Patient Access, Provider Access, and Payer-to-Payer APIs. Each of the interoperability APIs are required to be built using the FHIR standard. FHIR is a standards framework created by HL7 to electronically exchange health information via APIs using the latest technology standards. FHIR defines categories of data, called ``Resources'' that, individually or in combination, satisfy most common use cases. The Patient Resource, for example, includes demographic data related to a patient, such as their name, address, and phone number. Using these FHIR Resources enables granular data retrieval, so that a request returns just the relevant data rather than a full record or document that itself must then be searched. Once they are modified for specific requirements using FHIR's built-in capabilities, combinations of Resources are brought together in an IG to address a specific use case, such as a provider directory or prior authorization. This structure lends itself well to expansion beyond FHIR's core capabilities.\18\ --------------------------------------------------------------------------- \18\ The Office of the National Coordinator for Health Information Technology. (n.d.). What Is HL7[supreg] FHIR[supreg]? Retrieved from https://www.healthit.gov/sites/default/files/page/2021-04/What%20Is%20FHIR%20Fact%20Sheet.pdf. --------------------------------------------------------------------------- As in the 2024 CMS Interoperability and Prior Authorization final rule, we use the term ``prior authorization'' to refer to the process through which a provider, such as an individual clinician, acute care hospital, ambulatory surgical center, or clinic, obtains approval from a payer before providing care (89 FR 8761). A prior authorization is made up of two parts--a request from a provider and a decision/response by a payer. We refer to the provider's workflow and associated information and documentation as the ``prior authorization request'' and the payer's processes and associated information and documentation as the ``prior authorization decision.'' Payers establish prior authorization requirements to help control costs and ensure payment accuracy by verifying that an item, service, or drug is medically necessary for the specific patient, meets coverage criteria, and, for some payers, is consistent with standards of care before being provided. As we explained in the 2024 CMS Interoperability and Prior Authorization final rule, prior authorization has an important place in the health care system for utilization management, but the process and delays continue to be challenging for providers (89 FR 8914). Furthermore, issuers with complex payer policies, inconsistent use of electronic standards, and other technical barriers create provider workflow challenges and an environment in which the prior authorization process is a primary source of burden for both providers and payers and can create a health risk for patients if they don't receive medically necessary care in a timely manner. In this proposed rule, we refer to two categories of drugs--``drugs covered under a pharmacy benefit'' and ``drugs covered under a medical benefit.'' We acknowledge that these terms do not have statutory or regulatory correlations for impacted payers other than MA organizations (based on the distinctions between Parts A, B, and D). For instance, for Medicaid and CHIP, we propose that the distinction can be distinguished by the systems used to process claims. We are using ``drugs covered under a pharmacy benefit'' to reflect how the NCPDP SCRIPT standard describes the category of drugs within its scope.\19\ Conversely, we are using ``drugs covered under a medical benefit'' to describe the category of drugs for which the NCPDP SCRIPT standard is not to be used, pursuant to the IG, but is within the scope of the Prior Authorization API, based on instructions in the PAS IG, which states that the IG ``SHOULD NOT be used for any medication that is covered under a pharmacy benefit where prior authorization is provided by another electronic exchange process (for example, NCPDP SCRIPT).'' These standards and their scopes are further discussed in sections II.A.2. and II.A.3. of this proposed rule. We request comment on whether there are drugs covered by any impacted payer that may not fit into the categories ``drugs covered under a medical benefit'' and ``drugs covered under a pharmacy benefit'' and how such drugs can be included in one of those two categories. --------------------------------------------------------------------------- \19\ See 89 FR 51262. --------------------------------------------------------------------------- When we refer to both drugs covered under a pharmacy benefit and drugs covered under a medical benefit, throughout this rule we use the terms ``all drugs'' or ``any drugs.'' Further discussion of these terms is included in the discussion of those standards in section II.A. of this proposed rule. HL7 is an American National Standards Institute (ANSI)-accredited SDO that develops the FHIR standard and the IGs referenced throughout this proposed rule. In addition, they are a designated standard maintenance organization (DSMO), designated by the Secretary under 45 CFR 162.910.\20\ NCPDP is a non-profit ANSI-accredited SDO supporting standards for the drug supply chain. The NCPDP SCRIPT, F&B, and RTPB standards are established standards that can support prior authorization and other prescription information exchange tasks for drugs covered under a pharmacy benefit, as described further in sections II.A. and II.B. of this proposed rule. --------------------------------------------------------------------------- \20\ As announced in the Federal Register in 65 FR 50373. ---------------------------------------------------------------------------

D. Severability

In this proposed rule, CMS and HHS propose a variety of policies related to prior authorization. To the extent a court may enjoin one provision of this final rule, CMS and HHS propose that the other provisions should remain in effect, ensuring the continuity of the regulations. We propose that any provision of the requirements of this rule that is held to be invalid or unenforceable by its terms or as applied to any person or circumstance would be construed so as to continue to give maximum effect to the provision permitted by law, unless such holding is one of utter invalidity or unenforceability, in which event we [[Page 19900]] propose that the provision would be severable from the other provisions of this rulemaking and would not affect the remainder thereof or the application of the provision to persons not similarly situated or to dissimilar circumstances. We propose that if any section, subsection, sentence, clause, phrase, word, provision, or application of this final rule shall be found to be invalid, illegal, unconstitutional, or unenforceable, that finding shall not affect or undermine the validity of any other section, subsection, sentence, clause, phrase, word, provision, or application which can be enforced without the use of the offending provision. We request comments from the public on severability, particularly which policies could be severable, if finalized, and how the other policies in a final rule would operate absent those particular provisions.

1. Background

Standards set the foundation for consistent technical implementation to support interoperable exchange of information, which facilitates efficient, safe, and high-quality care for patients. In the 2024 CMS Interoperability and Prior Authorization final rule, we require impacted payers to use API technology conformant with specific standards in 45 CFR 170.215 applicable to the interoperability APIs (89 FR 8927). We finalized requirements to use these standards through cross-references to 45 CFR 170, subpart B, where ONC adopts standards that may be used across HHS programs. Those standards, which are applicable to different APIs, include the following: Health Level Seven (HL7[supreg]) Fast Healthcare Interoperability Resources (FHIR[supreg]), Release 4.0.1 in 45 CFR 170.215(a)(1); HL7 FHIR US Core IG, Standard for Trial Use (STU) 3.1.1 in 45 CFR 170.215(b)(1)(i) (US Core IG); HL7 Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Framework IG, Release 1.0.0 in 45 CFR 170.215(c)(1) (SMART App Launch IG); FHIR Bulk Data Access (Flat FHIR) IG, v1.0.0: STU 1 in 45 CFR 170.215(d)(1) (Bulk Data Access IG); and OpenID Connect Core 1.0, incorporating errata set 1, in 45 CFR 170.215(e)(1) (OpenID Connect Core). The specific standards for the interoperability APIs are listed in Table H3 of the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8945). In that same final rule, we finalized policies that allow impacted payers to use updated standards for these APIs, if specific conditions are met, which are similar to policies previously finalized in the 2020 CMS Interoperability and Patient Access final rule.\21\ We also strongly recommended payers use additional IGs for each API, listed in Table H3 (89 FR 8945). --------------------------------------------------------------------------- \21\ See 42 CFR 422.119(c)(4)(ii) for MA organizations, 42 CFR 431.60(c)(4)(ii) for state Medicaid FFS programs; through cross references to 42 CFR 431.60 in 42 CFR 438.242(b)(5), 42 CFR 431.61(a) in 42 CFR 438.242(b)(7), 42 CFR 431.61(b)(1) in 42 CFR 438.242(b)(7), 42 CFR 431.70 in 42 CFR 438.242(b)(6), 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans; 42 CFR 457.730(c)(4)(ii) for state CHIP FFS programs; through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(c)(4)(ii) for individual market QHP issuers. --------------------------------------------------------------------------- The ``Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing'' proposed and final rules (88 FR 23746 and 89 FR 1192) (hereinafter referred to as the ``HTI-1 proposed rule'' and the ``HTI-1 final rule''), appeared in the Federal Register on April 18, 2023 and January 9, 2024, respectively. In that rulemaking, which took place between the 2022 and 2024 CMS Interoperability and Prior Authorization proposed and final rules, the Secretary adopted updated versions of several standards set forth in 45 CFR 170.215 and finalized expiration dates for previous versions of standards. As a result, the 2024 CMS Interoperability and Prior Authorization final rule finalized requirements for impacted payers to use standards in 45 CFR 170.215 available at the time of the 2022 CMS Interoperability and Prior Authorization proposed rule, and not versions subsequently proposed and finalized by the Secretary. Some of those required versions now have established expiration dates. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements to use the versions of the standards in 45 CFR 170.215 that we had proposed, not those that were newly adopted in the HT1-1 final rule. For example, when the 2022 CMS Interoperability and Prior Authorization proposed rule appeared in the Federal Register on December 13, 2022, the US Core IG, STU 3.1.1 and SMART App Launch IG, Release 1.0.0 were the current versions of these standards. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that impacted payers must use the versions set forth in the proposed rule (which had not yet expired on the date the final rule appeared in the Federal Register), although the Secretary adopted newer versions (US Core IG, STU 6.1.0 in 45 CFR 170.215(b)(1)(ii) and SMART App Launch IG, Release 2.0.0 in 45 CFR 170.215(c)(2)) in the HTI-1 final rule (89 FR 1284, 1285, and 1291). The Secretary also finalized a January 1, 2026 expiration date for the US Core IG, STU 3.1.1 (in 45 CFR 170.215(b)(1)(i)) and the SMART App Launch IG, Release 1.0.0 (in 45 CFR 170.215(c)(1)). Upon the specified expiration date, the expired versions of the standards are no longer eligible for certification of Health IT Modules through the ONC Health IT Certification Program (89 FR 1285 and 1292). As of this proposed rule, there are two adopted versions of the US Core IG: (1) the US Core IG, STU 3.1.1 (in 45 CFR 170.215(b)(1)(i)), which expired on January 1, 2026, and (2) the US Core IG, STU 6.1.0 (in 45 CFR 170.215(b)(1)(ii)) without an expiration date. Through our proposals in this rule, we are seeking to align with the regulatory framework established by ONC to adopt, update, and expire health IT standards incorporated by reference in the Code of Federal Regulations (CFR). Accordingly, under our proposals, if ONC establishes an expiration date for an adopted standard, or for a specific version thereof, in subpart B of 45 CFR part 170, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements. We believe these proposals will support greater alignment across interoperability standards requirements that impact payers, health care providers, health IT developers and other parties. In the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules, we also finalized policies that allow impacted payers to voluntarily conform with updated versions of the standards we have required payers to use in 45 CFR 170.213 and 45 CFR 170.215 (such as the US Core IG and SMART App Launch IG), provided that (1) the National Coordinator for Health Information Technology (hereinafter referred to as the ``National Coordinator'') has approved the updated version for use in the ONC Health IT Certification Program; (2) the updated version of the standard does not disrupt an end user's ability to access the required data via that API; and (3) the updated standard is not prohibited by law (85 FR 25532 and 89 FR 8946). In addition, impacted payers may use an [[Page 19901]] updated version if required by other applicable law.\22\ Under these provisions, impacted payers may upgrade to newer versions of the required standards, subject to the specified limiting conditions (85 FR 25532 and 89 FR 8946). --------------------------------------------------------------------------- \22\ See 42 CFR 422.119(c)(4)(ii) for MA organizations, 42 CFR 431.60(c)(4)(ii) for state Medicaid FFS programs; through cross references to 42 CFR 431.60 in 42 CFR 438.242(b)(5), 42 CFR 431.61(a) in 42 CFR 438.242(b)(7), 42 CFR 431.61(b)(1) in 42 CFR 438.242(b)(7), 42 CFR 431.70 in 42 CFR 438.242(b)(6), 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans; 42 CFR 457.730(c)(4)(ii) for state CHIP FFS programs; through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(c)(4)(ii) for individual market QHP issuers. --------------------------------------------------------------------------- Finally, in the 2022 CMS Interoperability and Prior Authorization proposed rule, we did not propose, nor did we finalize any requirements in the 2024 CMS Interoperability and Prior Authorization final rule, that applied to any drugs because, as we discussed in the proposed and final rules, the processes and standards for prior authorization of drugs differ from the non-drug items and services included in our final policies (89 FR 8762). However, we received many public comments in response to the 2022 CMS Interoperability and Prior Authorization proposed rule, as well as additional feedback from providers, payers, and SDOs, indicating that while some prior authorization processes and standards for drugs currently exist, patients and other stakeholders would benefit from consistent requirements to provide patients timely access to drugs, and from a streamlined electronic prior authorization process that alleviates burden for providers and impacted payers.

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

Pharmacy Benefit a. NCPDP SCRIPT Standard After considering stakeholder comments on the 2022 CMS Interoperability and Prior Authorization proposed rule, our goals for interoperability across impacted payers, and the technical standards available to support electronic prior authorization for drugs, we are now proposing to require impacted payers to support electronic prior authorization for drugs. We are proposing to require impacted payers to use either the FHIR standards and IGs required for the Prior Authorization API or the NCPDP SCRIPT standard depending upon whether the drugs are covered under a medical benefit or a pharmacy benefit, as detailed by the standards implementation specifications, and further discussed below. As discussed further in section II.B. of this proposed rule, we are proposing to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT Standard Implementation Guide (NCPDP SCRIPT) \23\ adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs covered under a pharmacy benefit. In the ``Medicare Program; Medicare Prescription Drug Benefit Program; Health Information Technology Standards and Implementation Specifications'' final rule (89 FR 51238) (hereinafter referred to as the ``2024 Part D and Health IT Standards'' final rule), which appeared in the Federal Register on June 17, 2024, ONC finalized a January 1, 2028 expiration date for the NCPDP SCRIPT Standard Implementation Guide, Version 2017071 in 45 CFR 170.205(b)(1), and adopted the NCPDP SCRIPT Standard Implementation Guide, Version 2023011 in 45 CFR 170.205(b)(2) (89 FR 51244 and 51258-51259). Like the approach discussed above for required standards for payer APIs, our proposals in this rule seek to align to ONC's framework to adopt and update versions of the SCRIPT standard. Under these proposals, if ONC establishes an expiration date for the NCPDP SCRIPT standard in 45 CFR 170.205(b), or for a specific version thereof, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements. We are proposing an October 1, 2027 compliance date for this proposed requirement. --------------------------------------------------------------------------- \23\ NCPDP SCRIPT Standard IG, Versions 2017071 and 2023011. NCPDP SCRIPT IGs are available to NCPDP members for free and to non- members for a fee at https://standards.ncpdp.org/Access-to-Standards.aspx. --------------------------------------------------------------------------- NCPDP is a not-for-profit ANSI-accredited SDO representing the pharmacy services industry and is responsible for developing and maintaining standards for the exchange of information between providers, pharmacies, and payers. NCPDP is an SDO for pharmacy standards, including billing, subrogation, formulary and benefits, electronic prior authorization, electronic prescribing, and real-time benefit checks. The NCPDP SCRIPT standard can be used for multiple transactions between entities during the prescribing and dispensing processes including between providers, pharmacies, and payers for electronic prescribing; electronic prior authorization; and medication history exchange. This proposed rule focuses only on the electronic prior authorization functionality of the standard. The NCPDP SCRIPT standard is the most widely used standard by providers and payers for electronic prescribing and electronic prior authorization for drugs covered under a pharmacy benefit. The NCPDP SCRIPT standard can be used by providers to submit a prior authorization request to the payer (including the payer's processor or PBM, as appropriate). The NCPDP SCRIPT standard is designed specifically and solely for a category of drugs, which are described as ``drugs covered under a pharmacy benefit.'' \24\ The transactions in the NCPDP SCRIPT standards for electronic prior authorization are not intended to be used to communicate information for medical items or services or drugs covered under a medical (non-pharmacy) benefit. --------------------------------------------------------------------------- \24\ NCPDP (2015, August). NCPDP SCRIPT Standard Supports Electronic Prior Authorization (ePA) Fact Sheet. Retrieved from https://ncpdp.org/NCPDP/media/pdf/NCPDP_ePA_Fact_Sheet.doc. --------------------------------------------------------------------------- (1) Scope of the NCPDP SCRIPT Standard and FHIR IGs for Electronic Prior Authorization of Drugs In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a policy that established HL7 FHIR, Release 4.0.1 as the API base standard for the Prior Authorization API.\25\ Specifically, we finalized that certain impacted payers must implement and maintain the Prior Authorization API, and that the Prior Authorization API use the HL7 FHIR standard, Release 4.0.1 for electronic prior authorization of non-drug items and services (89 FR 8859 and 8861). We also strongly recommended that impacted payers use the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG, the HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) IG, and HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG when implementing the Prior Authorization API (89 FR 8863). These FHIR IGs are technically capable of supporting prior authorization of non-drug items and services and drugs covered under a medical benefit. The FHIR specifications, specifically the PAS IG, states that it ``SHOULD NOT be used for any Medication that is covered under a pharmacy benefit where prior authorization is provided by another electronic exchange process (for [[Page 19902]] example, NCPDP SCRIPT).'' 26 27 That directive is intended to differentiate the scope of the FHIR IGs for prior authorization from the scope of the NCPDP SCRIPT standard, which is used for prior authorization of drugs under a pharmacy benefit. --------------------------------------------------------------------------- \25\ See 45 CFR 170.215(a)(1). \26\ See section II.A.4.a.6. of this proposed rule for a description of the CRD, DTR, and PAS IGs and section II.A.4.b.4. of this proposed rule regarding CMS's proposal to require use of these IGs for the Prior Authorization API. \27\ Health Level Seven International (2024, December 20). Da Vinci Prior Authorization Support (PAS) FHIR: Use Cases and Overview. Retrieved from https://hl7.org/fhir/us/davinci-pas/usecases.html. --------------------------------------------------------------------------- The 2024 Part D and Health IT Standards final rule requires prescribers, dispensers, and Part D sponsors (as part of their electronic prescription drug programs) to use a version of the NCPDP SCRIPT standard adopted in 170.205(b) to transmit electronic prior authorization for covered Part D drugs for Part D eligible individuals (89 FR 51239). Any drugs covered by MA plans other than covered Part D drugs, that is, drugs payable under Part A or Part B, are not within the scope of the NCPDP SCRIPT standard and instead are within the scope of the Prior Authorization API (using HL7 FHIR, Release 4.0.1). However, we acknowledge that for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, there is currently no statutory or regulatory definition that distinguishes between drugs covered under a pharmacy benefit and drugs covered under a medical benefit, as described in the NCPDP SCRIPT or Da Vinci FHIR IGs for electronic prior authorization. Therefore, if these proposals, found in sections II.A.2. and II.B.3. of this proposed rule, are finalized as proposed, we anticipate that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs would analyze their list of covered drugs for which they require prior authorization and determine whether electronic prior authorization for each drug could be supported by the NCPDP SCRIPT standard or should instead be provided through the Prior Authorization API. Drugs covered under a pharmacy benefit, which would use the NCPDP SCRIPT standard for electronic prior authorization requests, are often those medications dispensed at a retail pharmacy. Drugs covered under a medical benefit, which would use the Prior Authorization API, are often those dispensed by a medical provider in a health care setting. We understand that the same drug could fall into different categories for different impacted payers based on their terms of coverage, but we do not think that would undermine this proposal's effectiveness because impacted payers could indicate which method a provider should use to submit a particular prior authorization. The CRD IG has the technical capability to return specific coverage information through the ``CoverageInformation'' extension, and we seek comment on how the ``CoverageInformation'' extension could best be utilized to indicate whether a particular drug is covered under a medical benefit and, therefore, that the Prior Authorization API should be used for electronic prior authorization. Similarly, we seek comment on whether the impacted payers could utilize the NCPDP Real-Time Prescription Benefit (RTPB) standard to indicate whether a drug is covered under a medical benefit. We also solicit comment on whether there are existing technical solutions or methods that show promise but would require additional development that impacted payers could utilize to indicate to providers how a prior authorization request for a drug should be submitted. In addition, we discuss below how the NCPDP Formulary & Benefit (F&B) or NCPDP RTPB standards could be used. (2) Transactions As of the date this proposed rule appears in the Federal Register, providers can use the NCPDP SCRIPT standard versions 2017071 and 2023011 for multiple transactions associated with the electronic prior authorization of drugs covered under a pharmacy benefit. The SCRIPT standard can be used in conjunction with the NCPDP F&B or NCPDP RTPB standards, to support a complete workflow around determining whether prior authorization is required. Additionally, these versions of the NCPDP SCRIPT standard include transactions for requesting prior authorization for drugs, communicating decisions, and exchanging information regarding appeals. The NCPDP SCRIPT standard version 2023011 has numerous updates from version 20217071, including that it can facilitate a three-way transaction to notify providers and pharmacies when prior authorization has been requested.28 29 The NCPDP SCRIPT standard versions 2017071 and 2023011 support both the workflow to determine whether prior authorization is required and the coverage and documentation requirements to receive a decision, as well as the technical processes to send prior authorization requests from a provider to a payer, followed by the payer's responses (for example, approved, denied, and additional information required). The NCPDP SCRIPT standard versions 2017071 and 2023011 also support features that minimize manual data entry by the provider based on information in the EHR or other health IT system. These functions should reduce the time a provider or their administrative staff spend reviewing and responding to payer documentation requirements for prior authorization decisions. The NCPDP SCRIPT standard versions 2017071 and 2023011 can send information to a payer (or the payer's PBM) in real time, which should result in faster prior authorization approvals and therefore faster patient access to medications compared to manual prior authorization processes. We note that the NCPDP SCRIPT standard version 2017071 expires on January 1, 2028, which is shortly after the proposed compliance date for certain impacted payers to support an unexpired version of the NCPDP SCRIPT standard adopted in 45 CFR 170.205(b). If our proposal is finalized, we would expect those impacted payers to utilize only the NCPDP SCRIPT standard versions 2023011 after January 1, 2028 to meet the proposed requirements. --------------------------------------------------------------------------- \28\ NCPDP. (2022, January 14). Re: Next version of SCRIPT Standard Recommendations. Retrieved from https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2022/202201NCPDP-SCRIPTNextVersionLetter.pdf. \29\ NCPDP. (2023, February 13). Re: Proposed Rule CMS-4201-P. Retrieved from https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2023/20230213_To_CMS_CMS_4201_P_NPRM.pdf. --------------------------------------------------------------------------- Therefore, we are proposing to require that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the following transactions to support electronic prior authorization of drugs covered under a pharmacy benefit: [[Page 19903]] [GRAPHIC] [TIFF OMITTED] TP14AP26.273 We emphasize that our proposals in this rule would not impose requirements directly on providers. We are not proposing to require providers to use the NCPDP SCRIPT standards or to conduct electronic prior authorization, but we acknowledge other HHS programs aim to support providers' ability to conduct electronic prior authorization using the NCPDP SCRIPT standard. The ``Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability: Electronic Prescribing, Real-Time Prescription Benefit and Electronic Prior Authorization'' final rule (hereinafter referred to as the ``HTI- 4 final rule'') (90 FR 36536) appeared in the Federal Register as part of the ``Medicare Program; Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals (IPPS) and the Long-Term Care Hospital Prospective Payment System and Policy Changes and Fiscal Year (FY) 2026 Rates; Changes to the FY 2025 IPPS Rates Due to Court Decision; Requirements for Quality Programs; and Other Policy Changes; Health Data, Technology, and Interoperability: Electronic Prescribing, Real- Time Prescription Benefit and Electronic Prior Authorization'' final rule (hereinafter collectively referred to as the ``FY 2026 IPPS/LTCH final rule'') (90 FR 36536), which appeared in the Federal Register on August 4, 2025. In the HTI-4 final rule, ONC finalized that Health IT Modules certified under the ONC Health IT Certification Program to 45 CFR 170.315(b)(3) are permitted to maintain conformance with either version 2017071 or version 2023011 of the NCPDP SCRIPT standard up to and including December 31, 2027. On and after January 1, 2028, all Health IT Modules certified to 45 CFR 170.315(b)(3) are required to support the NCPDP SCRIPT standard version 2023011. ONC also finalized that Health IT Modules seeking certification to the updated ``electronic prescribing'' health IT certification criterion in 45 CFR 170.315(b)(3) using the NCPDP SCRIPT standard version 2023011 must support certain electronic prior authorization transactions by January 1, 2028 (90 FR 36541). Eligible hospitals and CAHs that participate in the Medicare Promoting Interoperability Program and MIPS eligible clinicians that participate in the MIPS Promoting Interoperability performance category must use certified EHR technology (42 CFR 495.4, 495.24(f)(1), and 414.1375(b)(1)). As provided in 42 CFR 414.1305 and 42 CFR 495.4, we define certified EHR technology (CEHRT) for these programs as EHR technology that has been certified under the ONC Health IT Certification Program to meet the 2015 Edition Base EHR definition or subsequent Base EHR definition \30\ and [[Page 19904]] has been certified to certain ONC health IT certification criteria, adopted in 45 CFR 170.315, as necessary to report on objectives and measures in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. To complete the measures under the Electronic Prescribing objectives in those programs, eligible hospitals, CAHs, and MIPS eligible clinicians must use CEHRT certified to the ``electronic prescribing'' criterion in 45 CFR 170.315(b)(3).\31\ Once their Health IT Module is certified to the ``electronic prescribing'' criterion finalized in the HTI-4 final rule, to complete the relevant measure requirements, participants in these programs are required to meaningfully use certified health IT capable of electronic prior authorization for prescription drugs using the NCPDP SCRIPT standard version 2023011 by January 1, 2028. --------------------------------------------------------------------------- \30\ Base EHR means an electronic record of health-related information on an individual that (1) Includes patient demographic and clinical health information, such as medical history and problem lists; (2) Has the capacity to provide clinical decision support; support physician order entry; capture and query information relevant to healthcare quality; exchange electronic health information with, and integrate such information from other sources; and (3) Has been certified to the certification criteria adopted by the Secretary in all of the following: section 170.315(a)(1), (2), or (3); (a)(5) and (14), (b)(1), (c)(1), and (g)(7), (9), (10); and (h)(1) or (2); section 170.315(a)(9) or (b)(11) for the period up to and including December 31, 2024; section 170.315(b)(11) on and after January 1, 2025; section 170.315(b)(4) on and after January 1, 2028 (see 45 CFR 170.102). \31\ For eligible hospitals and CAHs, see the FY 2026 IPPS/LTCH final rule (89 FR 69615); for MIPS eligible clinicians, see the CY 2025 Medicare Physician Fee Schedule final rule (89 FR 98417-98427). --------------------------------------------------------------------------- We believe that providers would embrace electronic prior authorization using the NCPDP SCRIPT standard, as electronic prior authorization is less burdensome than manual prior authorization, as commenters told CMS in response to the 2022 CMS Interoperability and Prior Authorization proposed rule (89 FR 8765). In section II.C.4. of this proposed rule, we propose to require impacted payers to conduct electronic prior authorization using the NCPDP SCRIPT standard, which supports CMS's interoperability goals by reducing burden on providers and impacted payers. Requiring impacted payers to support the NCPDP SCRIPT standard also aligns with requirements for Medicare Part D prescribers, dispensers, and Part D sponsors, as finalized in the 2024 Part D and Health IT Standards final rule (89 FR 51238) and previous rulemaking, and enables other payers and providers to benefit from consistent standards. b. NCPDP Formulary & Benefit Standard The NCPDP F&B standard complements standards utilized for electronic prescribing, electronic prior authorization, and real-time prescription benefit applications, including the NCPDP SCRIPT standard, by providing formulary and benefit information at the health plan level. As discussed in section II.B. in this proposed rule, we are proposing to require impacted payers to support an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u), for providers to use in their prior authorization workflow for drugs covered under a pharmacy benefit. In the 2024 Part D and Health IT Standards final rule, the Secretary adopted the NCPDP F&B standard version 60 in 45 CFR 170.205(u)(1) (89 FR 51260). This is the most recently published and adopted version of the standard as of the date this proposed rule appears in the Federal Register. Accordingly, if ONC establishes an expiration date for the NCPDP F&B standard or for a specific version thereof, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements, and would be required to use another unexpired version adopted by the Secretary in 45 CFR 170.205(u). We are proposing an October 1, 2027 compliance date for this proposed requirement. If this proposal is finalized, impacted payers could use an unexpired version of the NCPDP F&B standard adopted by the Secretary to provide a range of formulary and benefit information, such as formulary status, preferred alternatives, benefit coverage, and estimated co-pay information to end users, including providers, at the time of prescribing. This formulary and benefit information enables providers to determine at the point of prescribing whether a particular drug is covered and whether the impacted payer requires prior authorization. The information can then be used to create and send an electronic prior authorization request, using the NCPDP SCRIPT standard, to the payer or PBM, as appropriate. The NCPDP F&B standard relies on payers producing a periodic flat file (or simple, plain text database) that includes point-in-time information about drugs covered under a pharmacy benefit.\32\ The NCPDP F&B standard is mature and has widespread industry adoption to provide useful information about group-level drug coverage for a variety of use cases. However, the NCPDP F&B standard does not require this information to be updated in real time; therefore, as information changes, a payer's F&B file could become out of date. Furthermore, information is provided for group-level coverage information rather than being patient-specific. --------------------------------------------------------------------------- \32\ National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit Standard IG, Version 13. NCPDP RTPB IGs are available to NCPDP members for free and to non-members for a fee at https://standards.ncpdp.org/Access-to-Standards.aspx. --------------------------------------------------------------------------- c. NCPDP Real-Time Prescription Benefit Standard The NCPDP RTPB standard enables the real-time exchange of patient- specific eligibility, drug coverage (including any restrictions and alternatives), and estimated cost sharing to enable access to this information at the point of prescribing. In the 2024 Part D and Health IT Standards final rule, the Secretary adopted the NCPDP RTPB standard version 13 in 45 CFR 170.205(c)(1) (89 FR 51260). This is the most recently published and adopted version of the standard as of the date this proposed rule appeared in the Federal Register. As discussed in section II.B.6. of this proposed rule, we are proposing to require impacted payers to support an unexpired version of the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c). Accordingly, if ONC establishes an expiration date for the NCPDP RTPB standard or for a specific version thereof, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements, and would be required to use another unexpired version adopted by the Secretary in 45 CFR 170.205(c). We are proposing an October 1, 2027 compliance date for this proposed requirement. While the NCPDP F&B standard provides group-level coverage information to the provider, the NCPDP RTPB standard provides member- specific information to the provider. The NCPDP F&B and NCPDP RTPB standards can complement each other in the provider's workflow to allow for relevant formulary, coverage, cost, and prior authorization information to be utilized when prescribing a drug. Findings from NCPDP grant-funded research on the NCPDP F&B and NCPDP RTPB standards showed that when the NCPDP F&B standard is used in conjunction with the NCPDP RTPB standard, providers had a more complete view of patient-specific medication options, costs, and prior authorization information at the point of prescribing.\33\ --------------------------------------------------------------------------- \33\ Journal of American Pharmacists Association. (2023, February 2). Formulary & Benefit and Real-time Pharmacy Benefit: Electronic Standards Delivering Value to Prescribers and Pharmacists. Retrieved from https://www.japha.org/article/S1544-3191(23)00016-X/abstractqq. --------------------------------------------------------------------------- [[Page 19905]] Utilizing the proposed NCPDP standards for electronic prior authorization in the provider's workflow would likely lead to faster prior authorization processes and thus result in improved patient access to prescribed medications. In summary, we request comment on our proposals in the CFR citations listed in Table 2, and specifically on the following: The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs covered under a pharmacy benefit. The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u) to make available formulary and benefits information for drugs covered under a pharmacy benefit. The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c) for exchanging real-time coverage information regarding drugs covered under a pharmacy benefit. The proposed October 1, 2027 compliance date for these proposals, as discussed in section II.B.2.c. of this proposed rule. In addition, we request comments on the following: Through what mechanisms do payers make their NCPDP F&B files available today? How frequently do payers or their PBMs update their F&B flat file today? How often should payers update their F&B flat file to account for formulary or benefit changes? How often do payers update the indicators for whether prior authorization is required within their F&B flat files? How often does that information change and is there typically a lag between policy changes and published F&B flat files? How frequently do providers use the NCPDP F&B standard as part of their prior authorization workflow today? How well integrated is the NCPDP F&B standard into providers' EHRs today? How accurate is the group-level information included in the NCPDP F&B standard to specific patients? How could impacted payers utilize the NCPDP RTPB standard to indicate whether a drug is covered under a medical benefit? Through what mechanisms do payers make information available using the NCPDP RTPB standard today? How frequently do providers use tools conforming to the NCPDP RTPB standard as part of their prior authorization workflow today? How prevalent is implementation of the NCPDP RTPB standard into providers' EHRs today? How automated are current interactions with the NCPDP RTPB standard within providers' EHRs and clinical workflow? For electronic prior authorization, would or could requiring impacted payers to make available information using the NCPDP RTPB standard negate the need for impacted payers to make available information using the NCPDP F&B standard? Does the NCPDP RTPB standard include all the necessary formulary and benefits information and functionality that would be available by using the NCPDP F&B standard for electronic prior authorization? Would requiring impacted payers to make information available using both standards add value, or create additional burden, specifically related to electronic prior authorization of drugs? Does the CRD IG have the technical capability to return specific coverage information through the ``CoverageInformation'' extension? ++ How could the ``CoverageInformation'' extension be best utilized to indicate whether a particular drug is covered under a medical benefit and whether the Prior Authorization API should be used for electronic prior authorization? Are there other existing technical solutions or methods that impacted payers could utilize to indicate to providers how a prior authorization request for a drug should be submitted?

3. Required Standards for FHIR APIs

a. Modification to Required Standards for FHIR APIs We are proposing to require each impacted payer to implement and maintain APIs that are conformant with applicable standards in 45 CFR 170.215 in a manner that will allow for progressive adoption of new versions of these required standards. Under this approach, impacted payers would be permitted to conform with any updated versions of the required standards as the Secretary adopts them, via notice and comment rulemaking, in 45 CFR 170.215. In addition, if ONC establishes an expiration date for a standard in 45 CFR 170.215, or for a specific version thereof, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements. When more than one unexpired version of a required standard is adopted in 45 CFR 170.215, impacted payers would be able to use any of the unexpired versions of the adopted standard to meet the interoperability requirements. This would allow impacted payers to have more predictable transition periods to update their APIs, and to conform with newer versions of the required standards in 45 CFR 170.215 as they are adopted, and older versions expire. CMS and ONC will work in close collaboration to evaluate the standards adopted in 45 CFR 170.215 and determine whether and when updated versions are ready for adoption through rulemaking. For example, in the 2024 CMS Interoperability and Prior Authorization final rule, we required impacted payers to use API technology conformant with the SMART App Launch IG, Release 1.0.0, in 45 CFR 170.215(c)(1) (89 FR 8927-8928). In this proposed rule, we are proposing to revise this requirement so that impacted payers would be required to use API technology conformant with an unexpired version of the SMART App Launch IG adopted by the Secretary in 45 CFR 170.215(c). As of the date this proposed rule appears in the Federal Register, adopted versions of this standard include: (1) the SMART App Launch IG, Release 1.0.0 in 45 CFR 170.215(c)(1), which expired on January 1, 2026, and (2) the SMART App Launch IG, Release 2.0.0 in 45 CFR 170.215(c)(2), without an expiration date. In this example, impacted payers would need their API technology to be conformant with SMART App Launch IG, Release 2.0.0, as that would be the only unexpired version available upon the effective date of a final rule. Finalizing this proposal, which would require impacted payers to use an unexpired version of the required standards cross-referenced in 45 CFR 170.215, would revise the existing requirement that impacted payers use specific versions of these standards that have since expired. We propose to update the technical requirements for each API, for each impacted payer, to cross reference to [[Page 19906]] locations in 45 CFR 170.215 that include all versions of the required standards adopted by the Secretary. For readability purposes, citations where we are proposing to require the standards and IGs in 45 CFR 170.215 for each impacted payer are listed in Table 2. Specifically, we propose to update the cross references to the following: HL7 FHIR Standard in 45 CFR 170.215(a); US Core IG in 45 CFR 170.215(b)(1); SMART App Launch IG in 45 CFR 170.215(c); Bulk Data Access IG in 45 CFR 170.215(d); and OpenID Connect Core in 45 CFR 170.215(e). We propose that the revised references to 45 CFR 170.215(a), (b)(1), and (c) through (e), as listed in Table 3, would be effective beginning on the effective date of the final rule, for all interoperability APIs. Impacted payers would continue to be required to maintain the Patient Access and Provider Directory APIs that they are presently required to maintain. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to make the Provider Access, Payer-to-Payer, and Prior Authorization APIs available beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the first rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for individual market QHP issuers on the FFEs) (89 FR 8759-8760). This proposal would not change those compliance dates but would allow impacted payers to better plan for implementation by those dates as the Secretary adopts new standards or specifies new expiration dates for existing standards, or specific versions thereof, adopted in 45 CFR 170.215. As discussed in section II.A.1. of this proposed rule, ONC has adopted additional versions of certain required standards, which are included in Table 2. We also expect that several of the standards and IGs we currently require, or recommend and are proposing to require, may have newer versions published before this rule is finalized. For example, we expect that some of the IGs discussed in this proposed rule will be updated to support newer versions of the US Core IG. In this proposed rule, we discuss either the most recently published or most recently adopted versions of the standards and IGs at the time this proposed rule appears in the Federal Register. In summary, we request comment on our proposals in the CFR citations listed in Table 2, and specifically on the following: The proposal to require impacted payers to implement and maintain API technology conformant with unexpired versions of the standards adopted by the Secretary in 45 CFR 170.215, specifically 45 CFR 170.215(a), (b)(1), and (c), (d), and (e), as applicable. The proposal to become effective beginning on the effective date of the final rule. In addition, we request comments on the following: Whether there are opportunities to streamline our regulatory requirements in instances where requiring conformance with the previously recommended IGs proposed in II.A.4.b. of this proposed rule for specific API use cases would achieve the same functional goal as explicitly requiring conformance with both the use-case specific IGs and required IGs or standards. For instance, whether it is necessary to require the base FHIR standard as well as the CRD, DTR, and PAS IGs that we propose to require for the Prior Authorization API, or whether requiring the CRD, DTR, and PAS IGs alone, which are based on the FHIR standard, would provide comparable technical guidance for implementers while reducing regulatory complexity. + Scenarios in which independently requiring both the required standards in this section (II.A.3.a. of the proposed rule) and use-case specific IGs proposed in section II.A.4.b. of the proposed rule could introduce alignment challenges. For instance, where one required standard references a specific version of another required standard, independent adoption of the latter standard could present further alignment challenges. + Instances in which requiring conformance with both the required standards in this section (II.A.3.a. of this proposed rule) and the use-case specific IGs proposed in section II.A.4.b. of the proposed rule are necessary to fully represent necessary technical requirements and should be maintained. Comments on whether it would be helpful to payers to more specifically identify capabilities of required IGs relevant to a specific API, to further streamline requirements and reduce unnecessary development. For instance, whether we should specify only those capabilities of the SMART App Launch IG relevant to the Patient Access API use case (e.g. the ``Patient Access for Standalone Apps'' Capability Set as well as the capabilities of ``launch-standalone'' and ``context-standalone-patient,'' and the capabilities in subsections ``Authorization Methods,'' ``Client Types,'' ``Single Sign-on,'' and ``Permissions'' except the ``permission-online'' and ``permission- user'').

4. Requiring Additional Implementation Guides to Support

Interoperability APIs a. Description of the Implementation Guides Using standards and IGs supports consistent implementation across the industry, thus leading to interoperable data exchange. There are many FHIR IGs that exist to support data exchange between payers, providers, and patients and enable the exchange of data such as claims, encounter, clinical, and coverage information; drug formulary information; and prior authorization information. Here, we provide descriptions of FHIR IGs that we require or recommend impacted payers support (89 FR 8927 and 8928, 8937, and 8945). Specifically, we required impacted payers to use the Bulk Data Access IG for the Provider Access and Payer-to-Payer APIs, while the other IGs described later in this section were recommended.\34\ We are now proposing to require impacted payers to support these IGs as described in section II.A.4.b. of this proposed rule. Table 2 outlines the citations to where we propose to require use of the standards for each of the specified APIs. --------------------------------------------------------------------------- \34\ See 45 CFR 170.215(d)(1). --------------------------------------------------------------------------- (1) CARIN Implementation Guide for Blue Button[supreg] The Creating Access to Real-time Information Now through Consumer Directed Exchange (CARIN) Alliance designed the HL7 FHIR CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button) IG \35\ to meet the requirements in the 2020 CMS Interoperability and Patient Access final rule for impacted payers to make available adjudicated claims and encounter data, from a financial perspective, via a Patient Access API through consumer-directed exchange (85 FR 25532). Consumer-directed exchange occurs when a patient or an authorized personal representative requests the patient's digital health information via a health app or other third-party data steward, such as a health information exchange (HIE). As of the date this proposed rule appears in the Federal Register, the most recently published version is the CARIN IG for Blue Button, Version 2.2.0--STU 2.2. --------------------------------------------------------------------------- \35\ Health Level Seven International. (n.d.). CARIN IG for Blue Button. Retrieved from http://hl7.org/fhir/us/carin-bb/ImplementationGuide/hl7.fhir.us.carin-bb. --------------------------------------------------------------------------- [[Page 19907]] (2) HL7 FHIR Da Vinci PDex Implementation Guide The HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG \36\ facilitates the creation and exchange of a patient's health history using clinical data (based on US Core Profiles established from FHIR R4) in a manner that allows providers to integrate the data received into their EHRs. The PDex IG supports sharing of payer data through a more clinical perspective, in line with the United States Core Data for Interoperability (USCDI) and US Core IG, than a financial perspective as is done with the CARIN IG for Blue Button. However, the PDex IG does include information about prior authorizations that impacted payers are required to make available by the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8758). The PDex IG can support all the required data elements for prior authorization data exchange, though we note that the PDex IG enhancements to support payer to payer bulk data exchange, payer to provider exchange, and explanation of benefits are currently in draft form and have not appeared in ballot, but have been tested at multiple Connectathons. The PDex IG has been updated to support newer versions of the US Core IG, including versions 6.1.0 and 7.0.0. As of the date this proposed rule appears in the Federal Register, the most recently published and adopted version is the PDex IG, Version 2.1.0--STU 2.1. --------------------------------------------------------------------------- \36\ Health Level Seven International. (n.d.). Da Vinci PDex IG. Retrieved from http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex. --------------------------------------------------------------------------- (3) HL7 FHIR Da Vinci PDex US Drug Formulary Implementation Guide The HL7 FHIR Da Vinci PDex US Drug Formulary IG (PDex US Drug Formulary IG) \37\ defines a FHIR interface to a payer's drug formulary information for patients. A drug formulary is a list of prescription drugs covered by the payer under the patient's coverage. The primary use case for this FHIR interface is to enable patients to understand the costs for drugs that have been prescribed and to compare their drug costs across different types of coverage. As of the date this proposed rule appears in the Federal Register, the most recently published version is the PDex US Drug Formulary IG, Version 2.1.0--STU 2. --------------------------------------------------------------------------- \37\ Health Level Seven International. (n.d.). Da Vinci PDex US Drug Formulary IG. Retrieved from http://hl7.org/fhir/us/davinci-drug-formulary/ImplementationGuide/hl7.fhir.us.davinci-drug-formulary. --------------------------------------------------------------------------- (4) HL7 FHIR Da Vinci PDex Plan Net Implementation Guide The HL7 FHIR Da Vinci PDex Plan Net IG (PDex Plan Net IG) \38\ defines a FHIR interface to access information about a payer's health plans, associated networks, and the providers and other entities that participate in their networks. Publishing that information through a publicly available FHIR API allows third party developers to build apps for patients to find in-network care that could be covered by their payer. As of the date this proposed rule appears in the Federal Register, the most recently published version is the PDex Plan Net IG, Version 1.2.0--STU 1.2 US. --------------------------------------------------------------------------- \38\ Health Level Seven International. (n.d.). Da Vinci PDex Plan Net IG. Retrieved from http://hl7.org/fhir/us/davinci-pdex-plan-net/ImplementationGuide/hl7.fhir.us.davinci-pdex-plan-net. --------------------------------------------------------------------------- 5) FHIR Bulk Data Access Implementation Guide The FHIR Bulk Data Access (Flat FHIR) IG (Bulk Data Access IG) \39\ was developed to facilitate the exchange of a large number of patient records at the same time. FHIR APIs generally work well for accessing small amounts of data, but large data exports can require hundreds or thousands of requests that may overwhelm a FHIR server. This IG defines a standardized, FHIR-based approach for asynchronously exporting bulk data from a FHIR server to an authorized client. As of the date this proposed rule appears in the Federal Register, the most recently published version is the Bulk Data Access IG (v3.0.0: STU 3). --------------------------------------------------------------------------- \39\ Health Level Seven International. (n.d.). FHIR Bulk Data Access IG. Retrieved from http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/hl7.fhir.uv.bulkdata. --------------------------------------------------------------------------- (6) HL7 FHIR Da Vinci CRD, DTR, and PAS Implementation Guides These three IGs are designed to be used by payers to develop and implement the Prior Authorization API. The HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG \40\ defines a workflow to allow payers to provide information about coverage requirements to providers through their EHR or other health IT system. This is the first stage of the process for determining whether prior authorization is required for certain items or services. The CRD IG enables the Prior Authorization API to inform a provider whether prior authorization is required and provide information about the payers' prior authorization coverage rules, so the provider knows what is necessary to support prior authorization approval. As of the date this proposed rule appears in the Federal Register, the most recently published version is the CRD IG, Version 2.2.1--STU 2.2.\41\ --------------------------------------------------------------------------- \40\ Health Level Seven International. (n.d.). Da Vinci CRD IG. Retrieved from http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd. \41\ Health Level Seven International. (2026, March 27). Da Vinci CRD IG, Version 2.2.1--STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-crd/2.2.1/en/. --------------------------------------------------------------------------- The HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) IG \42\ specifies how payer documentation requirements for prior authorization requests can be communicated to a provider. If necessary, this would allow providers to download questionnaires and populate them automatically with information from their EHR or other health IT systems to demonstrate medical necessity or other coverage requirements based on the payer's specific rules. The DTR IG can also automate the assemblage of documentation to support a prior authorization request. For instance, the DTR IG can be used to write rules that support automatically extracting patient information from the EHR or other health IT system for the provider to review and confirm before submission. As of the date this proposed rule appears in the Federal Register, the most recently published version is the DTR IG, Version 2.2.0--STU 2.2.\43\ --------------------------------------------------------------------------- \42\ Health Level Seven International. (n.d.). Da Vinci DTR IG. Retrieved from http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr. \43\ Health Level Seven International. (2026, March 27). Da Vinci DTR IG, Version 2.2.0--STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/. --------------------------------------------------------------------------- The HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG \44\ enables prior authorization requests and decisions to be transmitted via FHIR API from within providers' EHRs or other health IT systems. The PAS IG is the basis for: (1) assembling the information necessary to substantiate the clinical need for a particular treatment; and (2) submitting the assembled information and prior authorization request to the intended recipient. The PAS IG also defines capabilities for managing prior authorization requests, including checking the status of a previously submitted request, updating a previously submitted request, and canceling a request. As of the date this proposed rule appears in the Federal Register, the most recently published [[Page 19908]] version is the PAS IG, Version 2.2.1--STU 2.2.\45\ --------------------------------------------------------------------------- \44\ Health Level Seven International. (n.d.). Da Vinci PAS IG. Retrieved from http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas. \45\ Health Level Seven International. (2026, March 27). Da Vinci PAS IG, Version 2.2.1--STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-pas/2.2.1/en/. --------------------------------------------------------------------------- b. Requiring Implementation Guides In the 2024 CMS Interoperability and Prior Authorization final rule, we discussed use-case specific IGs that impacted payers can use to implement their interoperability APIs (89 FR 8937). Using those IGs supports interoperability because impacted payers need not develop an approach independently, which should save time and resources. In that final rule, we strongly encouraged payers to use the IGs listed as ``recommended'' in Table H3 for each API, in addition to the required standards in 45 CFR 170.215 (89 FR 8945). We recommended specific IGs for each API to provide guidance to the industry without locking payers into the versions of those IGs available at the time of the 2022 CMS Interoperability and Prior Authorization proposed rule (89 FR 8937). We carefully considered the versions of the recommended IGs that were available at the time and determined that they were not ready to be proposed as requirements. However, we acknowledged that by recommending rather than requiring certain IGs, there is potential for implementation variation that could limit interoperability and ultimately lead to rework for impacted payers if we required the IGs in the future (89 FR 8937). We believed that those IGs would continue to be refined as they were tested and implemented in the real world. We stated that we would continue to monitor and evaluate the IGs' development and consider whether to propose to require their use in the future (89 FR 8937). Since publication of the 2022 CMS Interoperability and Prior Authorization proposed rule, those IGs have continued to mature, and updated versions of many of the recommended IGs have been published. Therefore, we are now proposing to require impacted payers to implement and maintain API technology conformant with specific IGs for each applicable API. We propose to require these IGs to through cross references to the applicable citations in 45 CFR 170.215. For readability purposes, citations where we propose to require the IGs for each type of impacted payer are listed in Table 2. In the HTI-4 final rule, the Secretary adopted the following IGs (90 FR 37167 and 37182): CARIN IG for Blue Button, Version 2.0.0--STU 2 in 45 CFR 170.215(k)(1)(i); PDex IG, Version 2.1.0--STU 2.1 in 45 CFR 170.215(k)(2)(i); PDex US Drug Formulary IG, Version 2.0.1--STU 2 in 45 CFR 170.215(m)(1); PDex Plan Net IG, Version 1.1.0--STU 1.1 US in 45 CFR 170.215(n)(1); CRD IG, Version 2.0.1--STU 2 in 45 CFR 170.215(j)(1); DTR IG, Version 2.0.1--STU 2 in 45 CFR 170.215(j)(2)(i); and PAS IG, Version 2.0.1--STU 2 in 45 CFR 170.215(j)(3)(i). Since publication of the ``Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability'' proposed rule (89 FR 63498) (hereinafter referred to as the ``HTI-2 proposed rule''), which appeared in the Federal Register on August 5, 2024, and subsequent finalization of the HTI-4 final rule, updated versions of many of the standards and IGs have been published. In section II.J. of this proposed rule, ONC is now proposing to adopt updated versions of standards in 45 CFR 170.215 and proposing to add expiration dates to versions of these standards that were previously adopted in 45 CFR 170.215. We propose to cross reference the locations in 45 CFR 170.215 that include those versions of a specific standard adopted by the Secretary, and specify that impacted payers must use an unexpired version of the standard at that location: CARIN IG for Blue Button in 45 CFR 170.215(k)(1); PDex IG in 45 CFR 170.215(k)(2); PDex US Drug Formulary IG in 45 CFR 170.215(m)(1); PDex Plan Net IG in 45 CFR 170.215(n)(1); CRD IG in 45 CFR 170.215(j)(1); DTR IG in 45 CFR 170.215(j)(2); and PAS IG in 45 CFR 170.215(j)(3). Requiring impacted payers to use an unexpired version of the standards adopted in 45 CFR 170.215 automatically incorporates updated versions into the interoperability requirements as they are adopted by the Secretary. Specifically, if the Secretary adopts updated versions of any of these standards, such as the updated versions ONC has proposed for adoption in section II.J. of this proposed rule (subject to finalization), those versions would be incorporated in 45 CFR 170.215. As noted previously, if the Secretary establishes an expiration date for a standard, or for specific version thereof, upon the specified expiration date, impacted payers would no longer be permitted to use that standard or version to meet the interoperability requirements. We propose that impacted payers would be required to implement and maintain API technology conformant with an unexpired version of the proposed additional FHIR IGs for each API as described in section II.A.4.b. of this proposed rule beginning on October 1, 2027. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized compliance dates beginning in 2027 for impacted payers to implement and maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs (89 FR 8790, 8820, and 8860). We recognize that impacted payers may already be developing and implementing their APIs to comply with the technical requirements established in the 2024 CMS Interoperability and Prior Authorization final rule in preparation for the January 1, 2027 compliance deadline. Some impacted payers may have opted not to use the currently recommended IGs, which we now propose to require. Therefore, we believe that the proposed October 1, 2027 compliance date would provide impacted payers with additional time to update their APIs to conform to the additional IGs we are proposing to require beginning on October 1, 2027. Table 3 in this proposed rule lists the required standards finalized in the 2024 CMS Interoperability and Prior Authorization final rule and additional FHIR IGs proposed in this rule by applicable API. (1) Patient Access API In the 2020 CMS Interoperability and Patient Access final rule, we required impacted payers to implement and maintain a standards-based Patient Access API (85 FR 25558).\46\ The Patient Access API allows patients, through the health apps of their choice, to easily access their claims and encounter information, including provider remittances and patient cost-sharing, as well as all data classes and data elements included in a content standard (USCDI) adopted by the Secretary in 45 CFR 170.213.\47\ In the 2024 CMS [[Page 19909]] Interoperability and Prior Authorization final rule, we finalized a requirement that, beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must include certain information about prior authorizations for non- drug items and services in the data that are available through the Patient Access API (89 FR 8768).\48\ In that 2024 final rule, we also finalized a requirement that impacted payers must implement and maintain their Patient Access APIs conformant with standards in 45 CFR 170.215, including FHIR, US Core IG, SMART App Launch IG, and the OpenID Connect Core 1.0. --------------------------------------------------------------------------- \46\ See 42 CFR 422.119(a) for MA organizations, 42 CFR 431.60(a) for state Medicaid FFS programs, 42 CFR 457.730(a) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 457.730 in 42 CFR 457.1233(d)(2) for CHIP managed care entities, and 45 CFR 156.221(a) for individual market QHPs. \47\ See 42 CFR 422.119(b)(1) for MA organizations, 42 CFR 431.60(b)(3) for state Medicaid FFS programs, cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730 for state CHIP FFS programs, through cross reference to 42 CFR 438.242 in existing 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(b)(1)(iii) for individual market QHP issuers. \48\ See 42 CFR 422.119(b)(1)(iv) for MA organizations, 42 CFR 431.60(b) for state Medicaid FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(b) for state CHIP FFS programs, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(b) for individual market QHP issuers. --------------------------------------------------------------------------- To further support consistent implementation of the Patient Access API, we are now proposing to require impacted payers to implement and maintain API technology conformant with an unexpired version of the CARIN IG for Blue Button, the PDex IG, and the PDex US Drug Formulary IG adopted by the Secretary. Specifically, we are proposing to require impacted payers to implement and maintain a Patient Access API conformant with the CARIN IG for Blue Button to support sharing claims and encounter data, the PDex IG to support sharing clinical data and prior authorization information, and the PDex US Drug Formulary IG to share a formulary of drugs covered by the payer under the patient's health plan through the Patient Access API. We believe that by requiring these IGs, impacted payers would format data available through the Patient Access API in a consistent manner that would allow health app developers to easily access and display patients' health data, thus having those data readily available and easily accessible to patients. Enabling patients to easily access their health information electronically through an API should allow patients to better manage their health care. (2) Provider Access API In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement for impacted payers to implement and maintain a Provider Access API conformant with standards in 45 CFR 170.215, including FHIR, US Core IG, SMART App Launch IG, and the Bulk Data Access IG (85 FR 25521-25522 and 89 FR 8788). Providers would be able to use that API to access current patient data from impacted payers, including adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard (USCDI) in 45 CFR 170.213, and certain information about prior authorizations for non-drug items and services.\49\ --------------------------------------------------------------------------- \49\ See 42 CFR 422.121(a)(2) for MA organizations, 42 CFR 431.61(a)(2) for state Medicaid FFS programs, 42 CFR 457.731(a)(2) for CHIP FFS programs, through cross reference to 42 CFR 431.61 in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(a)(2) for individual market QHP issuers. --------------------------------------------------------------------------- To facilitate care coordination and to further standardize impacted payers' APIs, we are now proposing to require impacted payers to implement and maintain API technology conformant with an unexpired version of the CARIN IG for Blue Button and the PDex IG adopted by the Secretary in their Provider Access API implementation. Specifically, we are proposing to require impacted payers to implement and maintain a Provider Access API conformant with the CARIN IG for Blue Button, to support sharing claims and encounter data, as well as the PDex IG, to support sharing clinical data and prior authorization information. In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to make drug formulary information available through the Provider Access API in alignment with the Patient Access API requirements set forth in the 2020 CMS Interoperability and Patient Access final rule.\50\ We refer readers to section II.E.3. of this proposed rule, where we discuss our proposal to remove drug formulary information from the content required in the Provider Access and Payer-to-Payer APIs. However, we will consider the comments we receive on this proposal and may choose to retain this requirement, in which case we propose here, as an alternative, to require the PDex US Drug Formulary IG at the citations identified in Table 2 along with the other standards for the Provider Access API to support consistent solutions for sharing drug formulary information. --------------------------------------------------------------------------- \50\ See cross reference to 42 CFR 422.119(b) in 42 CFR 422.121(a)(2) for MA organizations, through cross reference to 42 CFR 431.60(b) in 42 CFR 431.61(a)(2) for state Medicaid FFS programs, through cross reference to 42 CFR 457.730(b) in 42 CFR 457.731(a)(2) for state CHIP FFS programs, through cross reference to 42 CFR 431.61 in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(a)(1) for individual market QHP issuers. --------------------------------------------------------------------------- (3) Provider Directory API In the 2020 CMS Interoperability and Patient Access final rule, we finalized a requirement that impacted payers (excluding QHP issuers on the FFEs) must implement and maintain a Provider Directory API to make available specific information about their provider networks.\51\ Impacted payers were required to implement and maintain the Provider Directory API by January 1, 2021.\52\ To further standardize implementation, we are now proposing to require impacted payers to implement and maintain a Provider Directory API conformant with an unexpired version of the PDex Plan Net IG adopted by the Secretary. The PDex Plan Net IG defines the technical parameters and data elements to share information about a payer's network and the providers and other entities that participate in their network. --------------------------------------------------------------------------- \51\ See 42 CFR 422.120(a) for MA organizations, 42 CFR 431.70(a) for state Medicaid FFS programs, 42 CFR 457.760(a) for state CHIP FFS programs, through cross reference to 42 CFR 431.70 in 42 CFR 438.242(b)(6) for Medicaid managed care plans, and through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities. \52\ See 42 CFR 422.120(c) for MA organizations, 42 CFR 431.70(c) for state Medicaid FFS programs, 42 CFR 457.760(c) for state CHIP FFS programs, through cross reference to 42 CFR 431.70(c) in 42 CFR 438.242(b)(6) for Medicaid managed care plans, and through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities. --------------------------------------------------------------------------- (4) Payer-to-Payer API In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that, beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Payer-to-Payer API to exchange patient data when a patient moves between payers or has concurrent coverage to ensure continued access to their health data and support care continuity and coordination between payers.\53\ Specifically, this data [[Page 19910]] exchange requirement includes adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard (USCDI) in 45 CFR 170.213, and certain information about prior authorizations for non-drug items and services.\54\ --------------------------------------------------------------------------- \53\ See 42 CFR 422.121(b)(1) for MA organizations, 42 CFR 431.61(b)(1) for state Medicaid FFS programs, through cross reference to 42 CFR 431.61(b)(1) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, 42 CFR 457.731(b) for state CHIP FFS programs, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(b)(1) for individual market QHPs. \54\ See 42 CFR 422.121(b)(4)(ii) for MA organizations, 42 CFR 431.61(b)(4)(ii) for state Medicaid FFS programs, through cross reference to 42 CFR 431.61(b)(4) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, 42 CFR 457.731(b) for state CHIP FFS programs, 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(b)(4)(ii) for individual market QHPs. --------------------------------------------------------------------------- To ensure impacted payers are implementing the Payer-to-Payer API in an interoperable and standardized way, we are now proposing to require impacted payers to implement and maintain API technology conformant with the CARIN IG for Blue Button and the PDex IG. Specifically, we are proposing to require impacted payers to implement and maintain a Payer-to-Payer API conformant with an unexpired version of the CARIN IG for Blue Button adopted by the Secretary to support sharing claims and encounter data, as well as the PDex IG to support sharing clinical data and prior authorization information. In the 2024 CMS Interoperability and Prior Authorization final rule, we require impacted payers to make drug formulary information available through the Payer-to-Payer API in alignment with the Patient Access API requirements set forth in the 2020 CMS Interoperability and Patient Access final rule.\55\ We refer readers to section II.E.3. of this proposed rule, where we discuss our proposal to remove drug formulary information from the content required in the Payer-to-Payer and Provider Access APIs. However, we will consider the comments we receive on this proposal and may choose to retain this requirement, in which case we propose here, as an alternative, to require the PDex US Drug Formulary IG at the citations identified in Table 2 along with the other standards for the Payer to Payer API to support consistent solutions for sharing drug formulary information. --------------------------------------------------------------------------- \55\ See cross reference to 42 CFR 422.119(b) in 42 CFR 422.121(b)(4)(ii)(A) for MA organizations, through cross reference to 42 CFR 431.60(b) in 42 CFR 431.61(b)(4)(ii)(A) for state Medicaid FFS programs, through cross reference to 42 CFR 457.730(b) in 42 CFR 457.731(b)(4)(ii)(A) for state CHIP FFS programs, through cross reference to 42 CFR 431.61 in 42 CFR 438.242(b)(7), and through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d). --------------------------------------------------------------------------- (5) Prior Authorization API To streamline the prior authorization process, in the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that impacted payers must implement and maintain a Prior Authorization API beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).\56\ The Prior Authorization API would allow providers to determine whether a specific impacted payer requires prior authorization for a certain item or service, query the impacted payer's prior authorization documentation requirements, as well as facilitate the automated compilation of necessary information to submit a prior authorization request electronically (89 FR 8861). --------------------------------------------------------------------------- \56\ See 42 CFR 422.122(b) for MA organizations, 42 CFR 431.80(b) for state Medicaid FFS programs, through cross reference to 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, 42 CFR 457.732(b) for state CHIP FFS programs, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d), and 45 CFR 156.223(b) for individual market QHPs. --------------------------------------------------------------------------- At the time of the 2022 CMS Interoperability and Prior Authorization proposed rule, we did not believe that the CRD, DTR, and PAS IGs were mature enough to propose requiring impacted payers to use them, and therefore, we only recommended their use. In the final rule, we updated our recommendations to the latest versions of the CRD, DTR, and PAS IGs (89 FR 8937 and 8945). Upon reviewing updated versions of the CRD, DTR, and PAS IGs that have been published since the 2022 CMS Interoperability and Prior Authorization proposed rule appeared in the Federal Register, we now believe that these IGs are mature enough for us to propose to require their use. We believe that requiring impacted payers to use these three IGs in their Prior Authorization APIs would avoid inconsistent or proprietary solutions that would make it challenging for providers to easily connect with impacted payers. Therefore, to ensure uniform and consistent implementations of the Prior Authorization API, we are now proposing to require impacted payers to implement and maintain API technology conformant with an unexpired version of the CRD, DTR, and PAS IGs adopted by the Secretary to implement their required Prior Authorization API. Specifically, we are proposing to require impacted payers to implement and maintain a Prior Authorization API conformant with an unexpired version of the CRD IG adopted by the Secretary to define the technical implementation to allow providers to access coverage requirements through their EHR or other health IT system. The CRD IG allows providers to then discover specific payer requirements for what services are covered by the payer and whether prior authorization is required.\57\ We are also proposing to require impacted payers to implement and maintain a Prior Authorization API conformant with an unexpired version of the DTR IG adopted by the Secretary so providers can consistently access documentation requirements through their EHR or other health IT system, as well as to gather information needed to support prior authorization requests.\58\ Finally, we are proposing to require impacted payers to implement and maintain a Prior Authorization API conformant with an unexpired version of the PAS IG adopted by the Secretary to enable the direct submission of prior authorization requests from providers' health IT systems to the impacted payer.\59\ --------------------------------------------------------------------------- \57\ Health Level Seven International. (n.d.). Da Vinci CRD IG. Retrieved from http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd. \58\ Health Level Seven International. (n.d.). Da Vinci DTR IG. Retrieved from http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr. \59\ Health Level Seven International. (n.d.). Da Vinci PAS IG. Retrieved from http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas. --------------------------------------------------------------------------- In summary, we request comment on our proposals in the CFR citations listed in Table 2, and specifically the following: The proposal to require impacted payers to use an unexpired version of the CARIN IG for Blue Button, the PDex IG, and the PDex US Drug Formulary IG adopted by the Secretary for their Patient Access API. The proposal to require impacted payers to use an unexpired version of the CARIN IG for Blue Button and the PDex IG adopted by the Secretary for their Provider Access API. The proposal to require impacted payers to use an unexpired version of the PDex Plan Net IG adopted by the Secretary for their Provider Directory API. The proposal to require impacted payers to use an unexpired version of the CARIN IG for Blue Button and the [[Page 19911]] PDex IG adopted by the Secretary for their Payer-to-Payer API. The proposal to require impacted payers to use an unexpired version of the CRD, DTR, and PAS IGs adopted by the Secretary for their Prior Authorization API. The alternative proposal to require impacted payers to use an unexpired version of the PDex US Drug Formulary IG adopted by the Secretary, if the drug formulary data requirement is retained, for impacted payers' Provider Access and Payer-to-Payer API. The proposed October 1, 2027 compliance date for the proposed requirements for impacted payers. c. Using Testing Tools To Ensure Conformance With Implementation Guides The technical requirements for the APIs we finalized in the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules include general requirements for impacted payers to test their interoperability APIs (85 FR 25514 and 89 FR 8927).\60\ For instance, technical requirements for APIs established by MA plans in 42 CFR 422.119(c) state that payers must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly. We are seeking to provide more information about the existing testing requirement to further advance interoperable data exchange across the health care system using standard APIs. --------------------------------------------------------------------------- \60\ For information on current regulatory requirements that are applicable to each impacted payer, see Table H1: Use of Interoperability Standards for Required APIs and Table H2: Use of Updated Standards for the Required APIs in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8943 and 8944). For information on the proposed regulatory requirements that would be applicable to each impacted payer, see Table 2: Proposed Updates to Required Standards for Interoperability APIs in section II.A.5. of this proposed rule. --------------------------------------------------------------------------- Testing tools are available that can help impacted payers to meet existing testing requirements for APIs, for instance, with ensuring conformance to specified standards. The Inferno testing tool on HealthIT.gov (hereinafter referred to as ``Inferno'') is an HL7 FHIR testing tool offered by ONC.\61\ Inferno is an open-source tool for creating, executing, and sharing conformance tests for numerous FHIR standards and IGs. ONC has developed test kits within Inferno that can be used by payers to test API conformance with certain versions of the required standards and proposed IGs.\62\ For example, Inferno test kits are currently published for the following specifications: --------------------------------------------------------------------------- \61\ Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov. Retrieved from https://inferno.healthit.gov/. \62\ Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov Test Kits. Retrieved from https://inferno.healthit.gov/test-kits/. --------------------------------------------------------------------------- CRD IG, Version 2.0.1--STU 2; DTR IG, Version 2.0.1--STU 2; PAS IG, Version 2.0.1--STU 2; CARIN IG for Blue Button, Version 2.0.0--STU 2; PDex IG, Version 2.0.0--STU 2; PDex US Drug Formulary IG, Version 2.0.1--STU 2; and PDex Plan Net IG, Version 1.1.0--STU 1.1. Inferno uses a combination of automated and manual verification to assess a system's conformance. Inferno can act as a server to test an app by receiving requests, returning appropriate responses, and validating the conformance of the app's requests and its ability to handle the responses appropriately. Inferno can also test a server by acting as an app, making requests against the server and validating the conformance and appropriateness of the server's responses. We intend to work with ONC on additional and updated test kits for subsequently adopted versions of the IGs above, new versions of the IGs identified through the Standards Version Advancement Process (SVAP) that may be available for voluntary use by payers, and additional IGs identified to support payer APIs. CMS strongly encourages impacted payers to utilize available testing tools, such as the Inferno testing tool, to meet the existing testing requirements and ensure conformance with the required IGs. We also encourage impacted payers to publish testing results to demonstrate conformance with the technical requirements. Doing so would increase transparency and trust that the technology has been properly implemented to facilitate interoperability. Inferno can be downloaded for local deployment and is hosted on ONC's website at https://inferno.healthit.gov/. We also note that we include an RFI in section III.C. of this proposed rule soliciting public feedback on how we can continue to strengthen oversight mechanisms to ensure the required interoperability APIs are appropriately implemented. d. Voluntary Use of Updated Versions of Required Standards As discussed in section II.A.1. of this proposed rule, we previously finalized policies that allow impacted payers to conform with updated versions of the required standards in 45 CFR 170.213 and 45 CFR 170.215 under certain conditions. There are certain conditions that must be met for impacted payers to be permitted to use updated versions of the required standards, for example, the conditions described in 42 CFR 422.119(c) for MA plans. We emphasize two of those conditions here. First, we note that if impacted payers choose to use updated standards, it must not disrupt an end user's ability to access the required data as finalized in the 2020 CMS Interoperability and Patient Access and 2024 CMS Interoperability and Prior Authorization final rules (85 FR 25532 and 89 FR 8935). Another condition that permits impacted payers to voluntarily use an updated version of a required standard in 45 CFR 170.213 or 45 CFR 170.215 is when the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program.\63\ The National Coordinator approves updated versions of standards for the ONC Health IT Certification Program through the Standards Version Advancement Process (SVAP), pursuant to 45 CFR 170.555, as finalized in the ``21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program'' final rule (85 FR 25642) (hereinafter referred to as the ``ONC Cures Act final rule''), which appeared in the Federal Register on May 1, 2020, as a Maintenance of Certification flexibility included in the real-world testing Condition of Certification (85 FR 25775). This flexibility permits health IT developers to voluntarily use, in certain certified Health IT Modules, newer versions of adopted standards if specific conditions are met, which allows the ONC Health IT Certification Program to keep pace with the industry's standards development efforts. --------------------------------------------------------------------------- \63\ See 42 CFR 422.119(c)(4)(ii) for MA organizations, 42 CFR 431.60(c)(4)(ii) for state Medicaid FFS programs; through cross references to 42 CFR 431.60 in 42 CFR 438.242(b)(5), 431.61(a) in 42 CFR 438.242(b)(7), 42 CFR 431.61(b)(1) in 42 CFR 438.242(b)(7), 42 CFR 431.70 in 42 CFR 438.242(b)(6), 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans; 42 CFR 457.730(c)(4)(ii) for state CHIP FFS programs; through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(c)(4)(ii) for individual market QHP issuers. --------------------------------------------------------------------------- Under SVAP, after a standard has been adopted through notice and comment rulemaking, ONC engages in an open and transparent process to timely ascertain whether an updated version of the adopted standard or implementation specification should be [[Page 19912]] approved by the National Coordinator for health IT developers' voluntary use in the ONC Health IT Certification Program. ONC publishes updated versions of standards under consideration for SVAP and lists the updated versions of standards that the National Coordinator has approved as part of the Interoperability Standards Advisory (ISA) on HealthIT.gov.\64\ Members of the public can use this resource to review standards that may be approved through SVAP in the future, as well as provide input on which updated versions should be approved. SVAP occurs annually, meaning that newer versions of standards will continue to be updated and assessed by ONC for use. Impacted payers may find it beneficial to monitor the SVAP process to stay current on standards updates and to assess whether adoption of a newer version of a standard may be an option. We encourage impacted payers to review these resources to better understand how updated versions of the standards in 45 CFR 170.213 and 45 CFR 170.215 may be approved by the National Coordinator through SVAP and meet that condition for using an updated standard. --------------------------------------------------------------------------- \64\ Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology. (n.d.). SVAP. Retrieved from https://www.healthit.gov/isa/standards-version-advancement-process. ---------------------------------------------------------------------------

5. Recommended Implementation Guides To Support Interoperability APIs

and Request for Comment As we have discussed, using common standards and IGs supports consistent implementations across the industry. However, as noted in the 2024 CMS Interoperability and Prior Authorization final rule, IGs take time to mature (89 FR 8839 through 8841). We believe it is important to recommend these additional IGs, although they may not be fully mature, to provide direction towards a common set of specifications. If we did not include these recommendations, it could lead to more implementation variation and cause a greater burden on implementers. We are now recommending additional IGs for certain interoperability APIs. For the Provider Access API we are recommending the HL7 FHIR Da Vinci Member Attribution (ATR) List IG (ATR List IG).\65\ The ATR List IG provides specific technical guidance for payers and providers to exchange Member Attribution Lists. The Member Attribution List typically contains information about plans/contracts, attributed patients, attributed providers, attributed organizations, and patient coverage and can be used by providers and payers to support use cases for quality reporting, payer data exchange, and clinical data exchange by identifying populations of patients that are relevant between data exchange partners. The ATR List IG allows transactions to exchange a full Member Attribution List, request changes to existing Member Attribution Lists, and request and receive notifications of changes to Member Attribution Lists. As of the date this proposed rule appears in the Federal Register, the most recently published version is the ATR List IG, Version 2.1.0--STU 2.1. --------------------------------------------------------------------------- \65\ Health Level Seven International. (n.d.). Da Vinci ATR List IG. Retrieved from http://hl7.org/fhir/us/davinci-atr/ImplementationGuide/hl7.fhir.us.davinci-atr. --------------------------------------------------------------------------- For the Provider Access API specifically, the ATR List IG can be used to identify members with an established patient treatment, contractual, or other type of relationship with providers, provider groups, and organizations to enable data exchange access. Impacted payers could also use the ATR List IG to identify groups of members that are opting out of sharing data with providers. For the Prior Authorization API, we are recommending the HL7 FHIR Da Vinci Clinical Data Exchange (CDex) IG.\66\ The CDex IG provides detailed guidance that helps implementers use FHIR-based interactions to support specific clinical data exchanges. In the context of the IG, ``clinical data'' means any information a provider holds in a patient's health record. Unlike the PDex IG, the format of the data exchanged is not limited to FHIR resources but includes the ability to provide attachments such as HL7 Consolidated Clinical Document Architecture (C- CDA) documents, Portable Document Formats (PDFs), text files, and other types of data. Using the CDex IG allows the standardized exchange of non-structured data, such as radiological images, questionnaires, or lab results, as attachments for a variety of purposes, including determining the medical necessity of a prior authorization request. As of the date this proposed rule appears in the Federal Register, the most recently published version is the CDex IG, Version 2.1.0--STU 2.1. The CDex IG describes how attachments to claims and prior authorizations transactions can be requested and sent to support payer operations. We are recommending the CDex IG specifically to support prior authorization exchanges but note that its capabilities go beyond that purpose and can be used in the other APIs. --------------------------------------------------------------------------- \66\ Health Level Seven International. (n.d.). Da Vinci CDex IG. Retrieved from http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex. --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we discussed different methods of authentication and authorization (89 FR 8841-8842). We recognized that while protocols involving specific user credentials managed by an impacted payer could be used for the Provider Access and Prior Authorization APIs, other protocols, such as SMART Backend Services, mutual Transport Layer Security (mTLS), Unified Data Access Profiles (UDAPTM), or other trust community-specified means to enable authentication, may be easier to implement at scale (89 FR 8942). Likewise, protocols requiring user level credentials, managed by the impacted payer, are generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API where an individual may not be directly initiating the exchange. As discussed in the 2024 CMS Interoperability and Prior Authorization final rule, efforts have been made to further refine the specifications for security (including authentication) at scale through UDAP via the FHIR at Scale Taskforce (FAST) Security for Scalable Registration, Authentication, and Authorization IG (FAST Security IG) (89 FR 8802). We are recommending the FAST Security IG \67\ to support standardized dynamic registration, authentication, and authorization requirements for the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs to provide a more uniform, standardized, and automated application registration pathway. The FAST Security IG enables scalable and standardized application registration capabilities compatible with FHIR and the SMART App Launch IG. As of the date this proposed rule appears in the Federal Register, the most recently published version is the FAST Security IG, Version 2.0.0--STU 2. --------------------------------------------------------------------------- \67\ Health Level Seven International. (n.d.). FAST Security IG. Retrieved from https://build.fhir.org/ig/HL7/fhir-udap-security-ig/. --------------------------------------------------------------------------- We are recommending the FAST Security IG, rather than proposing to require it, given nascent adoption of business-to-business API-based technologies among impacted payers. We acknowledge that for the FAST Security IG to work successfully, there needs to be an entity or a set of entities to manage the trust between participating organizations (trust community). While the FAST Security [[Page 19913]] IG provides for client registration, authentication, and authorization, the entity that performs the registration must have a ``trust relationship'' established. CMS is considering whether it would be valuable to recommend additional authentication and authorization standards within FHIR. One authentication and authorization method that can be used within the FAST Security IG is Tiered Open Authorization (Tiered OAuth).68 69 Tiered OAuth enables the federation of digital identity management across multiple trusted identity providers using the OpenID Core standard. This frees a data holder (such as an impacted payer) from having to solely rely on a single identity provider to maintain the digital identities across all accessing users. --------------------------------------------------------------------------- \68\ UDAP Unified Data Access Profiles. (n.d.) UDAP Tiered OAuth for User Authentication. Retrieved from https://www.udap.org/udap-user-auth-stu1.html. \69\ Health Level Seven International. (n.d.). FAST Security IG. Retrieved from https://build.fhir.org/ig/HL7/fhir-udap-security-ig/. --------------------------------------------------------------------------- In addition to the NCPDP implementation standards discussed in sections II.A.2.b. and II.A.2.c. of this proposed rule that facilitate the exchange of prescription drug benefit information, we also recognize that HL7 has developed a FHIR IG called the CARIN Consumer Real-Time Pharmacy Benefit Check (RTPBC) IG.\70\ This IG could enable patients to access real-time information about the cost and insurance coverage of their prescription medications. Specifically, the RTPBC IG could help patients determine their benefit coverage, estimate their out-of-pocket costs for specific drugs at the pharmacy, and explore potential alternative medications. While we are not proposing to require or recommend adoption of this IG at this time, we acknowledge that there may be value in making such information available through the Patient Access API. --------------------------------------------------------------------------- \70\ Health Level Seven International. (n.d.). Consumer Real- Time Pharmacy Benefit Check IG. Retrieved from https://hl7.org/fhir/us/carin-rtpbc/. --------------------------------------------------------------------------- In summary, we request comment on our recommendations, and specifically on the following: The recommendation for impacted payers to use the ATR List IG to document and share attribution lists that identify whose patient data may be shared with a provider through the Provider Access API. The recommendation for impacted payers to use the CDex IG for the Prior Authorization API for exchanging attachments related to prior authorization. The recommendation for impacted payers to use the FAST Security IG for registration, authentication, and authorization for the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. Whether any of these IGs are now mature and important enough for CMS to adopt in a final rule. In addition, we request comment on the following: How can CMS know whether and when the ATR List, CDex, and FAST Security IGs are ready for us to propose to require their use? Should CMS consider recommending or requiring the FAST Security IG ``Tiered OAuth'' in future rulemaking? If CMS proposes, in future rulemaking, to require the FAST Security IG, should we also propose to require impacted payers to use Tiered OAuth for user authentication? If so, to which APIs should that proposal apply? Would this be a useful solution to enable authentication and authorization at scale? Are there trust communities that exist today that impacted payers can utilize for business-to-business authentication and authorization? Do such communities exist for other stakeholders in the health care system, such as providers, or in other industries that could be used or expanded for this purpose? How much testing is necessary and under what readiness conditions would it be appropriate for us to propose to require use of the FAST Security IG for the Patient Access, Provider Access, Payer-to- Payer, and Prior Authorization APIs? Should CMS consider recommending the RTPBC IG? Are there differences in scope or use cases between the RTPBC IG and the Da Vinci PDex Drug Formulary IG? Specifically, would RTPBC IG provide additional or distinct benefits compared to the PDex Drug Formulary IG, or do the two largely address overlapping use cases? Is there value in providing patients with real-time prescription drug cost and coverage information through the Patient Access API? Are there potential technical or operational challenges associated with implementing the RTPBC IG within the Patient Access API? Is there enough patient demand via third-party apps to justify the burden of implementing the RTPBC IG? Do any third-party apps currently include this functionality, or would developers build it, if recommended? Do payers or PBMs currently support the required technical standards to enable third-party apps to use the RTPBC IG and would payers build that functionality, if recommended?

6. Clarification of Standards for the Provider Directory FHIR API

In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that we were removing the SMART App Launch IG in 45 CFR 170.215(c)(1) and OpenID Connect Core in 45 CFR 170.215(e), which were erroneously included as required standards for the Provider Directory API in Table 10 of the 2022 CMS Interoperability and Prior Authorization proposed rule (87 FR 76320 and 89 FR 8928) and codified in the CFR. CMS also discussed this in the 2020 CMS Interoperability and Patient Access final rule, where we finalized a policy that security protocols related to user authentication and authorization in 45 CFR 170.215, namely the SMART App Launch IG and OpenID Connect Core standard, would not apply to the Provider Directory API (85 FR 25560). We are now proposing that impacted payers be required to implement and maintain a Provider Directory API (MA organizations in 42 CFR 422.120(a), state Medicaid FFS programs in 42 CFR 431.70(a), state CHIP FFS programs in 42 CFR 457.760(a), Medicaid managed care plans through cross reference to 42 CFR 431.70 in 42 CFR 438.242(b)(6), and CHIP managed care entities through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d)) conformant with FHIR in 45 CFR 170.215(a) and US Core IG in 45 CFR 170.215(b)(1), but not the SMART App Launch IG in 45 CFR 170.215(c)(1) or OpenID Connect Core in 45 CFR 170.215(e)(1). [[Page 19914]] [GRAPHIC] [TIFF OMITTED] TP14AP26.274 [[Page 19915]] [GRAPHIC] [TIFF OMITTED] TP14AP26.275 [[Page 19916]] [GRAPHIC] [TIFF OMITTED] TP14AP26.276 [[Page 19917]] [GRAPHIC] [TIFF OMITTED] TP14AP26.277 [[Page 19918]] [GRAPHIC] [TIFF OMITTED] TP14AP26.278 [[Page 19919]] [GRAPHIC] [TIFF OMITTED] TP14AP26.279 [[Page 19920]] [GRAPHIC] [TIFF OMITTED] TP14AP26.280 [[Page 19921]] [GRAPHIC] [TIFF OMITTED] TP14AP26.281

1. Background of the Prior Authorization API

In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to implement and maintain a Prior Authorization API with compliance dates beginning in 2027 (by January 1, 2027 for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027 for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027 for individual market QHP issuers on the FFEs).\96\ The Prior Authorization API enables providers to conduct electronic prior authorizations directly from their EHRs or other health IT systems by determining whether a payer requires prior authorization for a particular item or service, accessing coverage and documentation requirements, submitting the prior authorization request, and receiving a response to that request, thereby easing a significant point of administrative burden. --------------------------------------------------------------------------- \96\ See 42 CFR 422.122(b) for MA organizations, 42 CFR 431.80(b) for state Medicaid FFS programs, 42 CFR 457.732(b) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(b) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- In that final rule, we limited the required content accessible through the Prior Authorization API to non-drug items and services. We excluded all drugs covered by impacted payers (for example, drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital) (89 FR 8762). We explained in the 2022 CMS Interoperability and Prior Authorization proposed rule and 2024 CMS Interoperability and Prior Authorization final rule that existing processes and standards for prior authorization of drugs differ significantly from those for non-drug items and services (87 FR 76240-76241 and 89 FR 8765). [[Page 19922]] In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, we received numerous comments requesting that we reconsider the exclusion of drugs from the proposed requirements. Those comments stated that providers face similar challenges with prior authorizations for drugs as with non-drug items and services, and that the current prior authorization processes sometimes delay access to medically necessary drug treatments. Commenters noted that the inconsistent use of technology and standards can create barriers to care and burden both providers and payers. For example, providers are sometimes unaware that a prior authorization is required until a payer rejects a prescription claim presented to a pharmacy, which causes delays for patients to receive necessary medication and affects the provider's ability to timely identify and prescribe an alternative medication. In many cases, providers still have to use fax, telephone, or payer-specific web portals for drug prior authorizations. While portals are used for data entry, they typically do not provide immediate feedback to providers about prior authorization requirements or accept supporting documentation, nor do they provide real time responses. Thus, current methods can be inefficient and create additional process challenges (89 FR 8765-8766). Many commenters, including payers and providers, advocated that prior authorization for drugs could and should be incorporated into the Prior Authorization API. Commenters specifically emphasized the need for more streamlined electronic prior authorization processes for drugs administered in a medical setting, such as infusions, oral cancer drugs, oral antiemetics, and drugs for terminal or chronic conditions, such as cancer or multiple sclerosis. Other commenters pointed to existing rules that require Medicare Part D sponsors to offer electronic prior authorization for covered Part D drugs via a standard adopted by the Secretary, which includes NCPDP SCRIPT standard versions 2017071 and 2023011, adopted in 45 CFR 170.205(b)(1) and 45 CFR 170.205(b)(2) (89 FR 8765-8766). In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that we would gather additional information and consider opportunities for future rulemaking (89 FR 8765). After considering stakeholder comments, our goals for interoperability, and the technical standards available to support electronic prior authorization for drugs, we are now proposing to require impacted payers to support electronic prior authorization for all drugs using a combination of standards, including the HL7[supreg] FHIR[supreg] standards that compose the Prior Authorization API and the NCPDP standards required for covered Part D drugs.

2. Existing Standards for Electronic Prior Authorizations

a. Electronic Prior Authorization API In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to implement and maintain a FHIR API to facilitate prior authorization for non-drug items and services.\97\ The FHIR standards are designed to support the interoperable exchange of health care information. In that final rule, we also recommended impacted payers use certain IGs within their Prior Authorization APIs, namely the CRD IG, DTR IG, and PAS IG (89 FR 8861). Details about the standards and IGs for the Prior Authorization API, including proposals to now require those IGs, are in section II.A. of this proposed rule. The IGs provide consistent formats to discover coverage and documentation requirements and exchange prior authorization requests and responses. The IGs include a set of workflows designed to support the exchange of prior authorization information, which includes drugs covered under a medical benefit and excludes those covered under a pharmacy benefit for which prior authorization is facilitated by another electronic exchange process (for example, the NCPDP SCRIPT standard). --------------------------------------------------------------------------- \97\ See 42 CFR 422.122(b) for MA organizations, 42 CFR 431.80(b) for state Medicaid FFS programs, 42 CFR 457.732(b) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(b) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- b. X12N 278 Transaction Standard for Prior Authorization(s) Under the HIPAA Administrative Simplification rules, the Secretary has adopted standards for use by covered entities--which includes all impacted payers--for, among other transactions, referral certification and authorization, a subset of which are used for prior authorization.\98\ In January 2024, HHS announced it was exercising its enforcement discretion regarding the standard adopted under HIPAA for electronic prior authorization, the X12N 278 transaction standard.\99\ HHS announced that it would not take enforcement action against HIPAA covered entities that, as part of a Prior Authorization API, do not use the X12N 278 transaction standard. HHS issued that notice of enforcement discretion based on substantial industry and stakeholder comments regarding the potential requirement to use the X12N 278 transaction standard in combination with the Prior Authorization API. Stakeholders informed HHS that requiring the HIPAA standard to be used within the FHIR standard would be duplicative, unnecessary, and burdensome. HHS's exercise of enforcement discretion is intended to promote efficiency. In section II.H.3. of this proposed rule, HHS is proposing to replace the X12N 278 transaction standard by adopting the Prior Authorization API as the HIPAA standard for prior authorization- related transactions. --------------------------------------------------------------------------- \98\ See 45 CFR 162.1302. \99\ Department of Health and Human Services. (2024, February 28). Statement of Enforcement Discretion for Referral Certification and Authorization Transaction Standard at 45 CFR 162.1302 for HIPAA Covered Entities Subject to the 2024 CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) that Implement an All-FHIR- Based Prior Authorization API. Retrieved from https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf. --------------------------------------------------------------------------- c. The NCPDP SCRIPT Standard for Electronic Prior Authorizations The 2020 Medicare Part D ePA final rule (85 FR 86824-86827) extensively details the NCPDP SCRIPT standard's history. For context, we provide here some of the narrative from that final rule. Congress required electronic prior authorization in the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (hereinafter referred to as the ``SUPPORT Act'') (Pub.

L. 115-271, enacted October 24, 2018). Section 6062 of the SUPPORT Act

amended section 1860D-4(e)(2) of the Act to require Part D sponsors and prescribing health care professionals to use technical standards adopted by the Secretary when transmitting electronic prior authorization requests and responses for coverage of a covered Part D drug for a Part D eligible individual enrolled in a Part D plan (PDP). The 2020 Medicare Part D ePA final rule established the NCPDP SCRIPT standard version 2017071 as the required standard for electronic prior authorization for covered Part D drugs in 42 CFR 423.160(b)(8) (85 FR 86832). Part D sponsors and providers were permitted to use the standard beginning [[Page 19923]] January 1, 2021 and were required to do so beginning January 1, 2022. In the 2024 Part D and Health IT Standards final rule, ONC finalized a January 1, 2028 expiration date for the NCPDP SCRIPT standard version 2017071 in 45 CFR 170.205(b)(1) and adopted the NCPDP SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2). In the same final rule, CMS finalized the requirement in 42 CFR 423.160(b)(1) that communication of electronic prior authorization must comply with a standard in 45 CFR 170.205(b). Therefore, Part D sponsors, providers, and dispensers are permitted to use either version of the NCPDP SCRIPT standard to conduct electronic prior authorization for drugs until January 1, 2028, when the NCPDP SCRIPT standard version 2023011 must be used exclusively (89 FR 51247). d. Other HIPAA Standards for Pharmacy Transactions In 2009, the Secretary adopted the NCPDP Telecommunication Standard IG, Version D, Release 0 (Version D.0) as a HIPAA Administrative Simplification transaction standard to improve the efficiency of retail pharmacy transactions.\100\ Version D.0 is used for retail pharmacy electronic transactions between pharmacies and payers. Version D.0 allows for accurate and consistent data exchange, reduces errors in claims processing, enhances eligibility and benefits verification, and streamlines pharmacy transactions, contributing to an efficient health care exchange for pharmacies, health care clearinghouses (where used as an intermediary between pharmacies and payers), and payers. Though Version D.0 is largely used for claims and eligibility transactions, it also includes the capability to transmit prior authorization requests from, and responses to, pharmacies. --------------------------------------------------------------------------- \100\ See 45 CFR 162.1302. --------------------------------------------------------------------------- On December 13, 2024, the ``Administrative Simplification: Modifications of Health Insurance Portability and Accountability Act of 1996 (HIPAA) National Council for Prescription Drugs (NCPDP) Retail Pharmacy Standards; and Modification of the Medicaid Pharmacy Subrogation Standard'' final rule (89 FR 100763) (hereinafter referred to as the ``2024 HIPAA NCPDP Pharmacy Standards final rule'') appeared in the Federal Register. In that final rule, the Secretary adopted the NCPDP Telecommunication Standard IG, Version F6 (Version F6) to replace Version D.0 to address emerging industry needs and improve the accuracy of pharmacy claim transactions, such as larger fields to accommodate increasingly expensive drugs (89 FR 100767-100768). The NCPDP Version F6 Telecommunications standard, like Version D.0, is designed for transactions between pharmacies and payers, not between non-pharmacy providers and payers (89 FR 100767-100768). The CMS proposal to require payers to support the NCPDP SCRIPT standard for electronic prior authorization does not conflict with the HIPAA transaction standard because electronic prior authorizations utilizing the NCPDP SCRIPT standard are not intended to be used by pharmacies. This rulemaking does not affect pharmacies, which will continue to be required by HIPAA to use Version F6. 3. Proposed Requirement To Incorporate Drugs Covered Under a Medical Benefit Into the Prior Authorization API for All Impacted Payers We are now proposing to require impacted payers to expand the scope of the required Prior Authorization API to incorporate drugs covered under a medical benefit, as that term is explained in section I.C. of this proposed rule. We are proposing an October 1, 2027 compliance date for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. Stakeholder input indicates that enhancing the Prior Authorization API by incorporating drugs covered under a medical benefit would improve the prior authorization process by giving providers and patients more timely information about prior authorization requirements to obtain these drugs. As with non-drug items and services, a Prior Authorization API enables EHRs or other health IT to determine whether prior authorization is required, collect documentation, and submit a request. Expanding the scope of impacted payers' Prior Authorization APIs to incorporate drugs covered under a medical benefit would streamline the administrative process for providers and result in payers receiving more complete requests and fewer unnecessary requests, which could accelerate decision-making. Reducing those burdens should mitigate ambiguity and reduce delays in providing patients with medically necessary drugs. Therefore, we are proposing to require impacted payers to enhance their Prior Authorization APIs by incorporating prior authorization coverage and documentation requirements for drugs covered under a medical benefit, as we describe that term in section I.C. of this proposed rule, beginning October 1, 2027. The IGs we are proposing to require for the Prior Authorization API include a set of workflows designed to support prior authorization. Those workflows specifically include drugs covered under a medical benefit and exclude drugs covered under a pharmacy benefit, for which prior authorization is conducted by another electronic exchange process, such as the NCPDP SCRIPT standard. We emphasize that adding drugs covered under a medical benefit to the non-drug items and services included in the Prior Authorization API requires no changes to the existing standards, the IGs we are proposing to require in section II.A. of this proposed rule, or other recommended IGs. Furthermore, the functionality of the Prior Authorization API would not need to be modified, but the specific coverage and documentation requirements for drugs covered under a medical benefit would have to be added to the content available via the API.\101\ --------------------------------------------------------------------------- \101\ Health Level Seven International. (2026, March 27). Da Vinci Prior Authorization Support (PAS) FHIR IG. Retrieved from https://hl7.org/fhir/us/davinci-pas/usecases.html#scope-of-work-flow. --------------------------------------------------------------------------- While we describe some of the types of drugs that might be covered under a medical benefit versus a pharmacy benefit for each payer in section I.C. of this proposed rule, we do not intend to specify an exhaustive list of drugs covered under a medical benefit, as each payer structures their formularies differently while following statutory and regulatory coverage requirements. For example, while certain infusions, injections, and services conducted in a provider's office could be included under a medical benefit, self-administered oral medications would likely be included under a pharmacy benefit. However, we intend the categories of ``drugs covered under a medical benefit'' and ``drugs covered under a pharmacy benefit'' to be mutually exclusive and collectively include all drugs covered by any particular payer. Put differently, we are proposing that electronic prior authorization must be available for all drugs covered by any impacted payer for which they require prior authorization, either through the Prior Authorization API or NCPDP SCRIPT standards adopted by the Secretary. In Medicare FFS, drugs are either payable by Part A or Part B, or covered by Part D prescription drug coverage. Medicare Part B may pay for prescription drugs and biologicals (hereinafter referred to as ``drugs'') [[Page 19924]] administered in an outpatient setting under certain conditions, for example, drugs provided as part of (or incident to) a physician's service and drugs furnished for use with covered DMEPOS items. Many drugs payable under Part A or Part B are infused or injected by physicians such as oncologists, rheumatologists, and urologists. Drugs payable by Part A or Part B are not usually self-administered. Medicare Part D is the prescription drug benefit of Medicare, which covers most outpatient prescription drugs through Plan D sponsors and MA organizations offering MA-PD plans. Covered Part D drugs are defined in section 1860D-2(e) of the Act. A Part D drug is further defined in 42 CFR 423.100 and includes the following, if used for a medically accepted indication as defined by section 1860D-2(e)(4) of the Act: A drug that may be dispensed only upon a prescription that is described in sections 1927(k)(2)(A)(i) through (iii) of the Act. A biological product described in sections 1927(k)(2)(B)(i) through (iii) of the Act. Insulin described in section 1927(k)(2)(C) of the Act. Medical supplies associated with the injection of insulin. A vaccine licensed under section 351 of the Public Health Service Act (hereinafter referred to as the ``PHSA'') (Pub. L. 115-5, enacted November 21, 1997) and its administration. A combination product approved and regulated by the Food and Drug Administration (FDA) as a drug, vaccine, or biologic. The following are excluded from the definition of Part D drugs: Drugs for which payment as so prescribed and dispensed or administered to an individual is available for that individual under Part A or Part B. Drugs that may be excluded from coverage or otherwise restricted under sections 1927(d)(2) or (d)(3) of the Act, except for smoking cessation agents. Medical foods that are not regulated as drugs under section 505 of the Federal Food, Drug, and Cosmetic Act (Pub. L. 75- 717, enacted June 25, 1938). With some limited exceptions, MA plans are statutorily required to cover Part A and Part B benefits, including drugs. Most MA plans also include Part D prescription drug coverage for their Medicare enrollees. These MA-PDs include drug coverage as a single plan, and patients enrolled in an MA-PD plan likely do not experience a distinction between drugs that are payable under Part A or Part B and those covered under Part D. Medicare patients who are enrolled in an MA plan that cannot offer Part D coverage (like Medical Savings Account plans) or choose not to offer Part D coverage (like certain MA-only plans) can join a separate, standalone PDP. For MA plans, the term ``drugs covered under a pharmacy benefit'' as used in this proposed rule means covered Part D drugs, as defined in 42 CFR 423.100. Conversely, ``drugs covered under a medical benefit'' as used in this rule means any drugs payable under Part A or Part B. For Medicaid, although ``prescribed drugs'' is an optional Medicaid benefit category under section 1905(a)(12) of the Act, all states currently provide this benefit for all categorically eligible individuals and most other enrollees within their Medicaid programs. States are permitted to apply prior authorization requirements to covered outpatient drugs as long as the prior authorization program complies with the requirements of section 1927(d)(5) of the Act.\102\ Medicaid managed care plans must conduct their prior authorization programs in compliance with the requirements of section 1927(d)(5) of the Act, as if such requirements applied to the Medicaid managed care plan, if covered outpatient drugs are included in their contracts.\103\ For CHIP, section 2110(a)(6) of the Act authorizes states to cover drugs within CHIP. For CHIP managed care entities, 42 CFR 457.1230(d) cross references to the Medicaid managed care regulations in 42 CFR 438.210. --------------------------------------------------------------------------- \102\ Per section 1927(k)(3) of the Act and 42 CFR 447.502, drugs that are provided as part of, or as incident to and in the same setting as a service, and for which payment is made in Medicaid as payment for part of the service, and not as direct reimbursement are not ``covered outpatient drugs.'' Accordingly, the prior authorization requirements in section 1927(d)(5) of the Act do not apply to such drugs. \103\ See 42 CFR 438.3(s)(6). --------------------------------------------------------------------------- For Medicaid and CHIP FFS, we believe that the distinction between drugs within the proposed scope of the Prior Authorization API and within the scope of the proposed NCPDP standards can be distinguished by the systems used to process claims. We expect drugs that are processed in a claims adjudication system that is not at the point of sale would be within the proposed scope of the Prior Authorization API. Conversely, we expect that drugs that are processed in a point of sale or real-time claims adjudication system would be within the scope of the proposed NCPDP standards. Thus, the systems that state Medicaid and CHIP FFS programs use to process claims may serve as an effective framework for determining which drugs fit within the scope of the Prior Authorization API and which drugs fit within the scope of the NCPDP standards. States that cover drugs under state Medicaid or CHIP FFS or both programs generally use their Medicaid Management Information System (MMIS) to process medical claims and another pharmacy system, such as an electronic claims management system (ECMS), described in 42 CFR 456.722, or PBM, to process pharmacy claims. We believe that the systems that states use to process claims may be directly relevant to the state's determination of whether the proposed FHIR or NCPDP standards should apply for particular prior authorization requests. To meet the requirements of the 2024 CMS Interoperability and Prior Authorization final rule, states should already be planning to integrate the Prior Authorization API for non-drug items and services with their MMIS or related systems.\104\ States (or their PBMs) may be able to build the proposed NCPDP standards into the state Medicaid and CHIP FFS pharmacy systems. If those systems accurately align with the scope of each standard, states could use the proposed standards for the electronic prior authorization of drugs into separate systems without duplication or overlap. We also emphasize that this dichotomy should not and, if finalized, would not affect any other Medicaid or CHIP policies related to drug coverage. --------------------------------------------------------------------------- \104\ See 42 CFR 431.80(b) for state Medicaid FFS programs and 42 CFR 457.732(b) for state CHIP FFS programs. --------------------------------------------------------------------------- Section 1301(a)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the Health Care and Education Reconciliation Act of 2010 (hereinafter referred to as the ``Affordable Care Act'') (Pub. L. 111-148, enacted March 23, 2010 and Pub. L. 111-152, enacted March 30, 2010), and section 2707 of the PHSA require QHP issuers on the FFEs to cover the essential health benefits (EHBs), which includes items and services in the categories described in section 1302(b) of the Affordable Care Act, one of which is prescription drugs. There is no statutory or regulatory distinction between drugs covered under a medical benefit, as described by the scope of the Prior Authorization API, and drugs covered under a pharmacy benefit, as described by the NCPDP SCRIPT standard, for QHP issuers on the FFEs. There are also no existing requirements for QHP issuers on the FFEs to support electronic prior authorization for drugs [[Page 19925]] in either category. However, we understand that most QHP issuers on the FFEs structure benefits into medical and pharmacy categories and therefore should follow their own distinctions for drug coverage. Should these electronic prior authorization proposals be finalized, impacted payers would need to review the list of covered drugs for which they require prior authorization to determine whether they fit into the scope of the Prior Authorization API (drugs covered under a medical benefit) or the NCPDP SCRIPT standard (drugs covered under a pharmacy benefit). Once each payer has evaluated those drugs that require prior authorization and identified those that may be processed through the Prior Authorization API, the applicable rules, requirements, and templates would need to be developed and incorporated into the API. We are proposing compliance dates beginning October 1, 2027 for this proposal. We believe 1 year is the appropriate period for impacted payers to evaluate and incorporate the additional prior authorization rules and requirements into their Prior Authorization API. In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, commenters stated that payers and developers generally need 1 to 2 years to implement a new system (89 FR 8824-8825). In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized compliance dates for policies that require API development and enhancement beginning in 2027, which provided impacted payers approximately 3 years to implement the finalized requirements (89 FR 8784, 8817, 8855, and 8897). That feedback was based on the totality of our policies that require API development or enhancement--to require three new APIs and to update the Patient Access API. This proposal would not require impacted payers to build new APIs from scratch, but to incorporate prior authorization requirements for drugs covered under a medical benefit into the existing Prior Authorization APIs. Based on previous industry feedback on development timelines and our experience implementing the CMS Medicare FFS Prior Authorization API, we believe the effort to add those prior authorization rules to the API would not require more than a year. In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following: The proposal to require impacted payers to incorporate coverage and documentation requirements into the Prior Authorization API to support electronic prior authorization for drugs covered under a medical benefit, as that term describes the scope of the Prior Authorization API FHIR standards. The proposed October 1, 2027 compliance date for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHPs issuers on the FFEs. In addition, we request comments on the following: Is the scope of the Prior Authorization API, as defined by its implementation guidance and the description of drugs covered under a medical benefit, clear and appropriate for impacted payers? For MA organizations, are there drugs other than those payable under Part B, such as supplemental benefits, that should be covered by our proposals to require MA organizations to support electronic prior authorization? Is the rubric to categorize drugs as within the scope of the Prior Authorization API (covered under a medical benefit) or within the scope of the NCPDP standards (covered under a pharmacy benefit) based on the system through which the claims are processed applicable to and appropriate for all or most state Medicaid and CHIP FFS programs? Is the system through which claims are processed the accurate and appropriate way to differentiate the categories of drugs that are within scope of the Prior Authorization API versus the NCPDP standards for other types of impacted payers? 4. Proposed Requirement To Support the NCPDP SCRIPT Standard for Prior Authorization for State Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated Exchanges We propose to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs covered under a pharmacy benefit, as that term is described in the standard, further discussed in section I.C. of this proposed rule. We are making these proposals in response to comments we received on the 2022 CMS Interoperability and Prior Authorization proposed rule that stated that requiring impacted payers to support electronic prior authorization of drugs would support faster access to necessary medications for patients and reduce administrative burden on providers. We are proposing an October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. Requiring state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary would align requirements for these payers with the existing requirement for Medicare Part D sponsors, prescribers, and dispensers in 42 CFR 423.160(b)(1). Specifically, as discussed in section II.A. of this proposed rule, we propose that those impacted payers would be required to support an adopted version of the NCPDP SCRIPT standard to enable providers to electronically submit prior authorization requests and receive prior authorization decisions for drugs covered under a pharmacy benefit using the following transactions: PAInitiationRequest and PAInitiationResponse PARequest and PAResponse PAAppealRequest and PAAppealResponse PACancelRequest and PACancelResponse PANotification (NCPDP SCRIPT standard version 2023011 only) We are not proposing to require providers to use electronic prior authorization in this proposed rule. Rather, we are proposing that an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary must be available for providers to use for prior authorization, and that the payer must send the response to the prior authorization request using the same standard. If ONC establishes an expiration date for an adopted version of the NCPDP SCRIPT standard in 45 CFR 170.205(b), upon the specified expiration date, that version would no longer be eligible for use by impacted payers to meet the interoperability requirements. State Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs may continue to make non-electronic means of conducting prior authorization (for example, fax, phone call, or direct data entry through a payer portal) available to providers. However, should these proposals be finalized, an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary would be the only electronic method these payers would be [[Page 19926]] permitted to use for the prior authorization of drugs covered under a pharmacy benefit as that term is described by the implementation guidance of the NCPDP SCRIPT standard, as discussed in sections II.A.2. and II.A.3. of this proposed rule. The NCPDP SCRIPT standard is already used by Medicare Part D sponsors, prescribers, and dispensers and required for various purposes by 15 states (for example, for electronic prior authorization and for electronic prescribing). The proposal to require other impacted payers to support the standard should create greater efficiency for providers and drive interoperability across CMS programs.\105\ --------------------------------------------------------------------------- \105\ American Medical Association. (2024). 2024 Prior Authorization (PA) State Law Chart. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-state-law-chart.pdf. --------------------------------------------------------------------------- We propose an October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary. That aligns with the feedback we received in response to the 2022 CMS Interoperability and Prior Authorization proposed rule that payers and developers generally need at least a year to implement a new system (89 FR 8824). In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized compliance dates beginning in 2027 for policies that require API development and enhancement. That afforded impacted payers approximately 3 years to implement from when the rule was finalized (89 FR 8784, 8817, 8855, and 8897). That feedback was based on the totality of our proposals that require API development or enhancement--to require three new APIs and to update the Patient Access API. We believe it is appropriate to afford payers and developers approximately a year to implement this proposal, which will require time for programming, testing, education, and outreach. In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following: The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the electronic prior authorization of drugs covered under a pharmacy benefit. The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an adopted version of the NCPDP SCRIPT standard using the following transactions: PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification (currently NCPDP SCRIPT standard version 2023011 only). The proposed October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. 5. Proposed Requirement To Support the NCPDP Formulary and Benefit Standard for State Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated Exchanges We are proposing to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u) by October 1, 2027. Accordingly, upon the specified expiration date of a version of the NCPDP F&B standard adopted in 45 CFR 170.205(u), that version would no longer be eligible for use by impacted payers to meet this proposal, if finalized. As discussed in section II.A.2.b. of this proposed rule, the NCPDP F&B standard enables providers to view formulary and benefit information at a group level. The NCPDP F&B standard supports the NCPDP SCRIPT standard by giving providers information at the point of prescribing about whether a payer covers a particular drug and whether the payer requires prior authorization. Therefore, our proposal to require impacted payers to support an unexpired version of the NCPDP F&B standard adopted by the Secretary should enhance providers' ability to electronically request prior authorization for drugs covered under a pharmacy benefit. As with our other proposals, the NCPDP F&B standard should enable a more seamless exchange of prior authorization requirements, which should help state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs more efficiently manage their pharmacy benefits and prior authorization programs. A standardized approach to providing formulary and prior authorization information could make provider and payer operations more efficient and reduce costs. The 2024 Part D and Health IT Standards final rule also includes requirements for transmitting formulary and benefits information between Part D sponsors and providers using the NCPDP F&B standard. Specifically, until January 1, 2027, that rule requires Part D sponsors to use either NCPDP F&B standard version 3.0 or an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u). Beginning January 1, 2027, Part D sponsors are required to use an unexpired version of a standard adopted by the Secretary in 45 CFR 170.205(u), which is currently NCPDP F&B standard version 60 (89 FR 51250-51251).\106\ Our proposal to require the other types of impacted payers (state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u) would align payers and should reduce the burden on providers currently using disparate systems and standards across payers. --------------------------------------------------------------------------- \106\ National Council for Prescription Drug Programs. NCPDP Formulary and Benefit Standard Implementation Guide, Version 60. Retrieved from https://standards.ncpdp.org/Access-to-Standards.aspx. NCPDP F&B standard IGs are available to NCPDP members for free and to non-members for a fee at this website. --------------------------------------------------------------------------- In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following: The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u) to make available formulary and benefits information for drugs covered under a pharmacy benefit. The proposed October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. [[Page 19927]] 6. Proposed Requirement To Support the NCPDP Real-Time Prescription Benefit Standard for State Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated Exchanges We also propose that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs support an unexpired version of the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c) by October 1, 2027. The 2024 Part D and Health IT Standards final rule requires, beginning January 1, 2027, Part D sponsors' real-time benefit tools to comply with an unexpired version of a standard adopted by the Secretary in 45 CFR 170.205(c) (89 FR 51247 and 51251).\107\ Currently, the version of the NCPDP RTPB standard that the Secretary has adopted in 45 CFR 170.205(c) is NCPDP RTPB standard version 13, adopted in 45 CFR 170.205(c)(1). As discussed in section II.A.2.c. of this proposed rule, the NCPDP RTPB standard enables real-time, patient-specific prescription benefit information to be delivered to providers at the point of prescribing. This proposal should coalesce support for the NCPDP SCRIPT standard and improve efficiency and accuracy. By integrating the NCPDP RTPB standard into the prior authorization process, payers could provide immediate feedback to providers about a patient's coverage, including whether a drug covered under a pharmacy benefit requires prior authorization, alternative covered medications, and patient out-of-pocket costs. State Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs could reduce administrative costs by providing prior authorizations and coverage information up front by avoiding unnecessary requests. Providers and patients could benefit from implementing the NCPDP RTPB standard because real-time benefit information could reduce care delays or unexpected costs. --------------------------------------------------------------------------- \107\ National Council for Prescription Drug Programs. NCPDP Real-Time Prescription Benefit Standard, Implementation Guide, Version 13. Retrieved from https://standards.ncpdp.org/Access-to-Standards.aspx. NCPDP RTPB standard IGs are available to NCPDP members for free and to non-members for a fee at this website. --------------------------------------------------------------------------- Our proposal to require these standards continues our goal towards interoperability and adoption of modern standards, reducing industry fragmentation. This standardization could encourage innovation and development of more sophisticated clinical decision support tools. In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following: The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to support an unexpired version of the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c) to make available real-time coverage information for drugs covered under a pharmacy benefit. The proposed October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. 7. Extensions, Exemptions, and Exceptions In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized processes for state Medicaid and CHIP FFS programs to request an extension to the compliance date or an exemption from requirements to build some of the interoperability APIs if they meet certain criteria.\108\ We also finalized a process for individual market QHP issuers on the FFEs to request an exception from the requirement to build the interoperability APIs under certain circumstances.\109\ --------------------------------------------------------------------------- \108\ For the Provider Access and Payer-to-Payer APIs, see 42 CFR 431.61(c) for state Medicaid FFS programs and 42 CFR 457.731(c) for state CHIP FFS programs. For the Prior Authorization API, see 42 CFR 431.80(c) for state Medicaid FFS programs and 42 CFR 457.732(d) for state CHIP FFS programs. \109\ For the Provider Access and Payer-to-Payer APIs, see 45 CFR 156.222(c). For the Prior Authorization API, see 45 CFR 156.223(d). --------------------------------------------------------------------------- However, if HHS finalizes its proposal to adopt the FHIR specifications that compose the Prior Authorization API as the HIPAA standard for ``referral certification and authorization'' transactions (further discussed in section II.H. of this proposed rule), it could affect impacted payers' (which are HIPAA covered entities) ability to request extensions, exemptions, and exceptions from the requirement to implement the Prior Authorization API finalized in the 2024 CMS Interoperability and Prior Authorization final rule. a. State Medicaid and CHIP Fee-for-Service Programs The process for state Medicaid and CHIP agencies to request an exemption from the Prior Authorization API includes requirements, in 42 CFR 431.80(c)(2)(ii)(B)(2) and 42 CFR 457.732(d)(2)(ii)(B)(2), that states must provide an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. At the time the 2024 CMS Interoperability and Prior Authorization final rule was finalized and today, the existing HIPAA standard for prior authorization transactions is the X12N 278 transaction standard. We finalized the exemption process with the understanding that a HIPAA- compliant X12N 278 transaction standard would be an acceptable alternative to meet that requirement. However, if HHS's HIPAA proposals in section II.H. are finalized, that standard would no longer be HIPAA- compliant as of the finalized compliance date. Because the purpose of the HIPAA Administrative Simplification provisions is to ensure that covered entities do not use electronic transactions other than those adopted by the Secretary, there would be no other permissible alternative electronic methods for state Medicaid and CHIP FFS programs to use. Since there would be no other HIPAA- permitted alternative electronic methods once HIPAA proposals are finalized, state Medicaid and CHIP FFS programs previously eligible for an exemption to the Prior Authorization API would no longer have the ability to sustain an alternative plan to support electronic prior authorization.\110\ The HIPAA Administrative Simplification statute and regulations do not provide for exceptions or exemptions, other than that described in 45 CFR 162.940 to permit testing of proposed modifications. Therefore, in order to ensure that the Prior Authorization API exemption requirements finalized in 42 CFR 431.80(c)(2) for state Medicaid FFS programs and in 42 CFR 457.732(d)(2) for state CHIP FFS programs do not conflict with the proposed HIPAA Administration Simplification requirements, we are proposing to remove the policy finalized in the 2024 CMS Interoperability and Prior Authorization final rule that allows states with small FFS populations to request an exemption from CMS for the non-drug items and services Prior Authorization API requirements. If finalized as proposed, removal of this policy would result in the eventual expiration of any approved exemptions without the possibility of renewal. Notably, there are no HIPAA standard transactions related to the Patient Access, Provider Directory, Provider Access, or Payer- to-Payer APIs, so the [[Page 19928]] ability to request an exemption for these standards would not be affected and we are proposing no changes to the extensions and exemptions policies finalized in the 2024 CMS Interoperability and Prior Authorization final rule for those APIs. --------------------------------------------------------------------------- \110\ See 42 CFR 431.80(c)(2)(ii)(B)(2). --------------------------------------------------------------------------- However, to provide additional flexibility to state Medicaid and CHIP FFS programs, we are proposing to extend the policy that allows any state to request extensions for additional years until the HIPAA compliance date, if HHS finalizes its proposals. As discussed in section II.H.8. of this proposed rule, we are proposing a multiple year gap between the finalized Prior Authorization API compliance dates for impacted payers and the proposed compliance dates to our proposals to adopt FHIR standards as the HIPAA transaction standard for prior authorization transactions. As discussed in section II.H. of this proposed rule, we believe it would be appropriate to give 24 months for implementation between the effective date of the final rule and the proposed compliance date for most covered entities and 36 months for small health plans. As defined in 45 CFR 160.103, small health plans are those with annual receipts of $5 million or less. As state Medicaid and CHIP agencies are not commercial entities, they may generally be considered small health plans.\111\ As state Medicaid and CHIP agencies are not considered for-profit entities, we would not expect them to reach the small health plan $5 million dollar threshold and therefore would be considered small health plans for the purpose of granting extensions up to 36 months. --------------------------------------------------------------------------- \111\ See discussion in 65 FR 82579 that clarifies that ``pure premiums'' can be substituted for ``annual receipts,'' as appropriate. --------------------------------------------------------------------------- Some states may be unable to meet the proposed CMS interoperability compliance dates in this proposed rule due to funding challenges for necessary contracting and staff resources to develop and implement the technical requirements, depending on when the final rule is published in relation to a state's FY, legislative session, budget process, and related timelines. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state's implementation of these proposals. The timeline for an openly competed procurement process and the time required to onboard the contractor and develop the technical capabilities proposed here can be lengthy for states. A state might need to hire new staff with the necessary skills to implement our finalized policies and proposals to require impacted payers to support electronic prior authorization. Overlapping requirements with varying timelines and exceptions add significant uncertainty to state FFS operations and makes responsible stewardship of federal funding more challenging. If HHS finalizes its proposals to modify the HIPAA transaction standard for prior authorization transactions, states would need to track multiple compliance dates, understand which standards are permissible at different times, and potentially procure funding and staffing to revise new API system implementations accordingly in coordination with state legislatures. These requirements, whether final or proposed, come at a time when state resources are allocated toward implementation of recent statutory changes, notably the Working Families Tax Cut legislation (Pub. L. 119-21, enacted July 4, 2025), making it difficult for them to reallocate or redirect resources. Providing state Medicaid and CHIP FFS programs the ability to request extensions to the compliance dates proposed here could mitigate these challenges. In addition, it could align with the requirements for covered entities that are not CMS impacted payers to use the proposed FHIR standard if they engage in electronic prior authorization. To align with the proposals to support electronic prior authorization for drugs with those for electronic prior authorization of non-drug items and services, we also propose to offer similar flexibilities for state Medicaid and CHIP FFS programs to request extensions to the October 1, 2027 compliance date for the proposed requirements to incorporate drugs into the Prior Authorization API and to support the NCPDP standards for the electronic prior authorization of drugs. Should our proposals be finalized, a state Medicaid or CHIP FFS program could request from CMS extensions to the compliance dates for (1) the non-drug items and services Prior Authorization API requirements finalized in the 2024 CMS Interoperability and Prior Authorization final rule; (2) the proposal to incorporate drugs into the Prior Authorization API; and (3) the proposal to require impacted payers to support NCPDP standards for the electronic prior authorization of drugs. States must be clear to which of these requirements they are requesting an extension and the required justification must be attenuated to the specific requirements. We propose that a state must submit that request as a part of its annual Advance Planning Document (APD) for MMIS operations expenditures in sufficient time to be approved before the applicable compliance date. The state's request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the state Medicaid or CHIP FFS program; (2) a report on completed and ongoing state activities that evidence a good faith effort towards compliance; and (3) a comprehensive plan to meet the requirements before a finalized HIPAA compliance date. Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS were to determine that the request adequately establishes a need to delay implementation and that the state has a comprehensive plan to implement the proposed requirements before a finalized HIPAA compliance date. We understand that state Medicaid and CHIP FFS programs have numerous competing priorities and face additional funding and staff limitations compared to commercial entities (89 FR 8902). Therefore, we encourage states to contact their Medicaid Enterprise Systems (MES) officer, if necessary for proper and efficient operations, to discuss their extenuating circumstances. Any flexibility granted to a state Medicaid or CHIP FFS program would be temporary and limited to the unique circumstances of the program. b. Exceptions for Qualified Health Plan Issuers on the Federally- facilitated Exchanges In the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules, we finalized a process for individual market QHP issuers on the FFEs to submit a request for an exception from the technical requirements finalized in those rules.\112\ We explained that ability of QHP issuers on the FFEs to implement the interoperability APIs might vary based on their available resources. --------------------------------------------------------------------------- \112\ For the Patient Access API, see 45 CFR 156.221(h). For the Provider Access and Payer-to-Payer APIs, see 45 CFR 156.222(c). For the Prior Authorization API, see 45 CFR 156.223(d). --------------------------------------------------------------------------- Those final rules established that individual market QHP issuers on the FFEs that apply for an exception must submit a narrative justification as part of their QHP application. That narrative [[Page 19929]] justification must describe the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and/or enrollees, the current or proposed means of providing health information to the applicable recipient, and solutions and a timeline to achieve compliance with the requirements of the applicable section. As described previously, any current or proposed means that differ from the finalized interoperability standard must be compliant with the HIPAA administrative simplification requirements. In the 2024 CMS Interoperability and Prior Authorization final rule, we also noted that QHP issuer certification applications in recent years indicated that most QHP issuers on the FFEs are compliant with the requirements to implement and maintain a Patient Access API; that is, they did not request exceptions through the process. Of the QHP issuers on the FFEs that did request exceptions, many explained in their justifications that they planned to become compliant with the API requirements mid-way through the upcoming plan year (89 FR 8906). CMS takes a similar approach during the QHP certification process in other instances where flexibility may be warranted based on a QHP issuer's circumstances. For example, per 45 CFR 156.230(a)(2)(ii), if a plan applying for QHP certification to be offered through the FFE does not satisfy the network adequacy standards described in paragraphs 45 CFR 156.230(a)(2)(i)(A) and 45 CFR 156.230(a)(2)(i)(B), as part of its QHP application, the issuer must include a justification describing how the plan's provider network provides an adequate level of service for enrollees and how the plan's provider network will be strengthened and brought closer to compliance with the network adequacy standards prior to the start of the plan year. The issuer must provide information as requested by the FFE to support this justification. Our experience with these exceptions processes for rules that are currently in effect suggest that making an exception available prevents the FFE from potentially losing issuer participation based on concerns the issuer will ultimately be able to address during or before the plan year, typically resulting in no potential harm to consumers. In particular, we have observed that QHP issuers have submitted narrative justifications that may meet or be close to meeting the standards of providing an adequate level of service to enrollees by the start of the applicable plan year. Therefore, we propose an exception process to the proposed NCPDP standards requirements for QHP issuers on the FFEs in 45 CFR 156.223(i). We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirement to support the proposed NCPDP standards, the issuer would have to include in its QHP application a narrative justification describing the reasons why it could not satisfy the requirements for the applicable plan year, the effect of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers and facilitating prior authorization, and solutions and a timeline to achieve compliance with the applicable requirements. We propose that an FFE may grant an exception to the proposed requirement to support the NCPDP standards if it determines that making QHPs of such issuer available through the Exchange is in the interests of qualified individuals and qualified employers in the state or states in which the Exchange operates and that an exception is warranted to permit the issuer to offer QHPs through the FFE. This proposal is consistent with the exceptions for individual market QHP issuers on the FFEs that we finalized for the Patient Access, Provider Access, Payer- to-Payer, and Prior Authorization APIs.\113\ --------------------------------------------------------------------------- \113\ For additional discussion of considerations related to granting an exception, please see 2024 CMS Interoperability and Prior Authorization final rule preamble (89 FR 8905-8906). --------------------------------------------------------------------------- In addition, we propose to amend the requirements in 45 CFR 156.223(h)(1)(iii) to specify that QHP issuers on the FFEs, as part of a request for an exception from the Prior Authorization API requirements in 45 CFR 156.223(b), describe the current or proposed means of conducting prior authorization. Under the current requirement finalized in the 2024 CMS Interoperability and Prior Authorization final rule, QHP issuers on the FFEs that are applying for an exception must describe their current or proposed means of providing health information to providers. However, providing health information to providers does not describe the full scope of the Prior Authorization API. While part of the purpose of the Prior Authorization API is to make available to providers information about prior authorization requirements, it is also to facilitate prior authorization using bidirectional data exchanges between providers and payers. To align with the full scope and purpose of the Prior Authorization API, we believe that any QHP issuer on the FFE that applies for an exception should describe how they will facilitate prior authorization, not just how health information will be provided to providers. In summary, we request comment on our proposals in the CFR citations listed in Table 4, and specifically on the following: The proposal to remove the policy finalized in the 2024 CMS Interoperability and Prior Authorization final rule that allows states with small FFS populations to request an exemption from CMS for the non-drug items and services Prior Authorization API requirements. The proposal that state Medicaid and CHIP FFS programs may request extensions to the finalized compliance date to implement the Prior Authorization API and the proposed compliance date to incorporate drugs covered under a medical benefit into the Prior Authorization API. The proposal that state Medicaid and CHIP FFS programs may request extensions and that QHP issuers on the FFEs may request an exception from the proposed requirement to support an unexpired version of the NCPDP standards that the Secretary has adopted in 45 CFR 170.205(b), (c), or (u). The proposal to amend language in 45 CFR 156.223(i)(1)(iii) to require that a QHP issuer on the FFEs seeking an exception from the Prior Authorization API requirements and/or proposed requirement to support an unexpired version of the NCPDP standards that the Secretary has adopted in 45 CFR 170.205(b), (c), or (u) to describe their current or proposed means of conducting prior authorization. In addition, we request comments on the following: Flexibilities and options that can be provided to state Medicaid and CHIP FFS programs eligible for an exemption and QHP issuers on the FFEs eligible for an exception that would reduce burden for the reasons outlined previously, while ensuring compliance with the proposed or adopted HIPAA transaction standards. [[Page 19930]] [GRAPHIC] [TIFF OMITTED] TP14AP26.282 [[Page 19931]] 8. Statutory Authorities a. Medicare Advantage Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, including the provisions in section 1852 of the Act. Section 1852(c)(1)(G) of the Act requires that MA organizations disclose to their enrollees any rules regarding prior authorization, and section 1852(g)(1) of the Act requires MA organizations to have procedures for making timely determinations regarding whether an enrollee is entitled to receive a health service. Section 1857(e)(1) of the Act authorizes the addition of contract terms for contracts between the Secretary and an MA organization determined by the Secretary to be ``necessary and appropriate'' for the MA program. This broad authority encompasses the adoption of standards for electronic prior authorization, which are important for improving efficiency and reducing burdens in health care delivery. The Prior Authorization API is an electronic means for receiving and responding to requests for coverage determinations before the services are rendered or items furnished. The proposed requirement to incorporate drugs covered under a medical benefit that may require prior authorization into the Prior Authorization API is consistent with MA organizations' obligations under sections 1852(c)(1)(G) and 1852(g)(1) of the Act. Pursuant to the Secretary's authority under sections 1856(b) and 1857(e)(1) of the Act, we are proposing to require MA organizations to expand the scope of the Prior Authorization API to incorporate drugs covered under a medical benefit. We propose additional requirements for MA organizations to ensure that providers have further information about drug prior authorization through the Prior Authorization API required under regulations in 42 CFR 422.122(b). This proposed requirement would necessitate updating the Prior Authorization API with information about the coverage and documentation requirements for prior authorization of drugs covered under a medical benefit and responding to prior authorization requests for such drugs through the Prior Authorization API. We propose requiring MA organizations to expand the Prior Authorization API using recommended or updated implementation specifications discussed in section II.A. of this proposed rule. These implementation specifications are expected to improve the prior authorization process by addressing absences in providers' access to information about the prior authorization rules and documentation requirements for drugs. Under our proposal, the mandatory Prior Authorization API would communicate the coverage and documentation requirements for prior authorization for drugs covered under a medical benefit, indicating if authorization is required and what documentation is required to support an authorization request. This electronic API- enabled access to information should improve timely access to care for patients by mitigating delays for necessary medications known to occur when a provider is trying to determine drug coverage or eligibility requirements or does not know what documents to submit to obtain prior authorization. If applicable, providers' burden may be reduced if they can submit a prior authorization request and access status and decision information for drugs through an MA organization's Prior Authorization API. The required Prior Authorization API can potentially improve the efficiency of the prior authorization process for drugs covered under a medical benefit as much as it does for non-drug items and services if the number of appeals, denials, and requests for additional documentation can be reduced. We believe this proposal to extend the scope of the Prior Authorization API to incorporate drugs covered under a medical benefit should contribute to program efficiency and effective operations and should be in the best interest of MA enrollees. b. State Medicaid and CHIP For Medicaid, most of the proposals described in this section are authorized by sections 1902(a)(4), 1902(a)(8), and 1902(a)(19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals, which may result in faster beneficiary access to services. Section 1902(a)(19) of the Act requires states to ensure that care and services under a Medicaid state plan are provided in a manner consistent with the simplicity of administration, which can result in more uniform IT regulations and standards that are in the best interests of the recipients. For Medicaid managed care, section 1932(c)(1)(A) of the Act requires that states that contract with Medicaid MCOs develop and implement a quality assessment and improvement strategy that includes standards for access to care so that covered services are available within reasonable timeframes. CMS relies on our authority in section 1902(a)(4) of the Act to apply these standards for PIHPs and PAHPs. The proposals to incorporate drugs covered under a medical benefit into the Prior Authorization API and to improve electronic prior authorization for covered outpatient drugs by supporting the adopted version of the NCPDP SCRIPT standard by the Medicaid programs is supported by the sections of the Act referenced previously. For this proposal, CMS would rely on our authority in section 1902(a)(4) of the Act to adopt these standards for PIHPs and PAHPs. This would ensure that the same requirements apply to MCOs, PIHPs, and PAHPs. The proposal for state Medicaid FFS programs and Medicaid managed care plans to implement electronic prior authorization for drugs is expected to improve the efficiency and timeliness of the prior authorization process for Medicaid beneficiaries, providers, state Medicaid agencies, and Medicaid managed care plans by addressing inefficiencies that might exist in the process today. Support for the proposed FHIR and NCPDP standards could allow a provider to determine whether a prior authorization is required and the documentation requirements for that prior authorization request. The Prior Authorization API and NCPDP SCRIPT standard can improve the prior authorization process by making it more efficient, including by reducing the number of denials and appeals or eliminating requests for additional documentation. Those standards could-- Enable providers to submit a complete prior authorization request faster and easier; Support more timely notice to the provider and beneficiary of the disposition of the prior authorization request; and Permit improved scheduling of services or filing appeals, depending on the decision. For CHIP, we are proposing these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children effectively and efficiently that is coordinated with other sources of health benefits coverage. We are proposing to require state CHIP FFS programs and CHIP managed [[Page 19932]] care entities to implement systems to support electronic prior authorization for all drugs to improve the prior authorization process for patients, providers, and payers. We believe these proposals should address deficiencies and inefficiencies that exist currently. Today, a payer's rules about when prior authorization is required for drugs and the documentation requirements are not necessarily easily accessible for providers. The Prior Authorization API and support for the proposed NCPDP standards should enable a provider to determine whether prior authorization is required for a drug, to access the documentation requirements, and to submit a prior authorization request electronically. While we expect providers to be the primary beneficiaries of these proposals, improving prior authorization for drugs could also serve the requirements in section 2101(a) of the Act that CHIP ensures access to coverage and coordinated care. c. Qualified Health Plan Issuers on the Federally-facilitated Exchanges Section 1311(e)(1)(A) of the Affordable Care Act requires that Exchanges only certify plans as QHPs if they meet the requirements for certification promulgated by the Secretary under section 1311(c)(1) of the Affordable Care Act, while section 1311(e)(1)(B) of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines that making such plans available is in the interests of qualified individuals and qualified employers in the state or states in which the Exchange operates. For QHP issuers on the FFEs, we are proposing to amend the QHP certification standard that we finalized in the 2024 CMS Interoperability and Prior Authorization final rule using the same authority under section 1311(e)(1) of the Affordable Care Act. These proposals would expand the use of specific technology and standards to promote efficiency and transparency in the prior authorization process for drugs, which should improve access to care for enrollees in QHPs offered by issuers on the FFEs by ensuring that the QHP issuers on the FFEs respond to prior authorization requests promptly through a modernized process and clearly explain their rationale in cases of denial. Our proposal to require that QHP issuers on the FFEs support electronic prior authorization for all covered drugs either through the Prior Authorization API as described in 45 CFR 156.223(b) or through an unexpired version of the NCPDP SCRIPT standard that the Secretary has adopted in 45 CFR 170.205(b), combined with the ability of QHP issuers on the FFEs to request an exception, is in the interest of qualified individuals and qualified employers because it balances the goals of ensuring access to health care with robust QHP issuer participation on the FFEs. Enrollees in QHPs on the FFEs may receive approved covered drugs more quickly when their providers can submit a prior authorization request electronically. These proposed requirements would allow providers to determine whether prior authorization is required for drugs, submit the necessary documentation, and receive an electronic response in real-time or near real-time. As we explained in the 2024 CMS Interoperability and Prior Authorization final rule regarding the APIs required in that final rule (89 FR 8786), we believe that, with limited exceptions, certifying only health plans that support electronic prior authorization for all covered drugs and adhere to the other requirements described in this section of the preamble is in the interests of qualified individuals and qualified employers in the state or states in which a QHP issuer on the FFEs operates because of the opportunities for improvements in patient care. We encourage SBEs, including SBE-FPs, to consider whether a similar requirement should apply to issuers participating in their Exchanges.

1. Background for Improving Prior Authorization Process

In the 2024 CMS Interoperability and Prior Authorization final rule, we described the impact of excessive wait times for prior authorization decisions on patients, providers, and payers (89 FR 8858 and 8859). We discussed surveys, federal reports, and studies, including a multi-year survey conducted by the American Medical Association (AMA) about delays in care and medical risks to patients due to issues with prior authorization (89 FR 8859).\114\ Concerns about prior authorization processes have remained the same. According to a 2024 AMA report, 29 percent of physicians reported that prior authorization had led to a severe adverse event for a patient in their care, including hospitalization, permanent impairment, or death, and 94 percent reported that prior authorization harmed patient clinical outcomes.\115\ In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, many commenters stated that delays in responding to prior authorization requests for drugs significantly impacted patient care, health, and burden on providers (89 FR 8765). --------------------------------------------------------------------------- \114\ American Medical Association. (2025). 2024 AMA prior authorization physician survey. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf. \115\ American Medical Association. (2023, March 13). Toll from prior authorization exceeds alleged benefits, say physicians. Retrieved from https://www.ama-assn.org/press-center/press-releases/toll-prior-authorization-exceeds-alleged-benefits-say-physicians. --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized specific process requirements for impacted payers to improve the prior authorization process for non-drug items and services. We established prior authorization decision timeframes for impacted payers other than QHP issuers on the FFEs (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities) and required that, when denying a prior authorization request for non-drug items and services, impacted payers respond to the requesting provider with a specific reason for the denial (89 FR 8897). Shortening and standardizing timeframes for prior authorization decisions across programs improves access to health care and can mitigate the negative impacts of delays, particularly for individuals with chronic or complex conditions. The term ``denial'' means that the payer has refused to authorize coverage for a recommended medical treatment, procedure, or medication. Payers deny coverage for various reasons, such as a determination that the service or medication is not medically necessary or does not meet their coverage criteria. Requesting providers need to clearly understand the reason for denial so that additional information can be provided or alternative care options can be considered. In the 2024 CMS Interoperability and Prior Authorization final rule, we also finalized requirements on impacted payers to publicly report certain prior authorizations metrics for non-drug items and services annually beginning in 2026.\116\ By sharing appropriate data, payers can build trust with their patients and providers and showcase [[Page 19933]] their commitment to improving services. Beyond information about which services require prior authorization and the requirements for approval, greater transparency about payer performance on denials, timeframes, and volumes could be helpful for the public. Such reporting improves accountability and can identify opportunities for improvement. --------------------------------------------------------------------------- \116\ See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through existing cross reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- The proposals in this proposed rule to extend our technical and process requirements for prior authorization to all drugs should improve patients' access to services. We intend these proposals to create more unified processes for providers to request and receive prior authorization for drugs. Such standardization and consistency should allow providers to spend more time on patient care and less time on administrative tasks and paperwork. Additionally, standardized processes could reduce wait times and resubmissions and result in more efficient and accurate decision-making.

2. Proposed Requirement To Include a Specific Reason for Denial in

Response to Prior Authorization Requests for All Drugs a. Background In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that, beginning in 2026, impacted payers must provide a specific reason for denial in their response to a provider's prior authorization request for non-drug items and services, regardless of the method used to communicate the prior authorization request or decision.\117\ We are now proposing to add the same requirements for denied prior authorizations for all drugs for impacted payers that are not already subject to such a requirement. Throughout the 2022 CMS Interoperability and Prior Authorization proposed rule (87 FR 76238) and the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8758), we described opportunities to improve the prior authorization process, specifically where better communication between payers and providers could mitigate confusion about the status of a prior authorization and why a request was denied. Although prior authorization has a role in the health care system, denying services that do not meet the payer's internal coverage or utilization criteria or do not meet regulatory or statutory requirements should not adversely impact the health or well-being of the patient. If a denial is ineffectively communicated, then it could cause a patient to delay or abandon treatment. --------------------------------------------------------------------------- \117\ See 42 CFR 422.122(a) for MA organizations and applicable integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs, 42 CFR 457.732(a) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(a) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we explained that payers deny prior authorizations for a variety of reasons, including because the payer does not consider the items to be medically necessary, the patient exceeded limits on allowable covered care, or documentation to support the request was missing or inadequate (89 FR 8872). The reasons for denying prior authorizations for drugs may be similar. Health plan formularies are lists of generic and brand-name drugs covered by a health plan and may include drug tiering information. If prior authorization is denied because of a payer's formulary or utilization management policies and that is not clearly communicated, then the provider cannot effectively act on behalf of the patient. When a payer provides a specific reason for a denial, a provider can take appropriate actions such as resubmitting the request with updated information, appealing the decision, or identifying alternative drugs or treatments. Payers send denials through various channels--electronically, by mail, via portal, or by fax. When doing so, they often use proprietary codes or narrative text to communicate the reasons for denial. For some payers, the process of communicating denials remains both inefficient and inconsistent. The result is that providers may not have timely, clear direction on the next steps for providing appropriate care for their patients after a denied prior authorization request. b. Existing Requirements To Communicate With Providers About Denied Prior Authorization Requests for Drugs As described in the 2024 CMS Interoperability and Prior Authorization final rule, some impacted payers are required by existing federal laws and regulations to notify providers or patients when the payer denies or makes an adverse decision on a prior authorization request (89 FR 8874-8876). We are not proposing to alter or replace existing requirements for payers to notify patients, but to add requirements to ensure a specific reason for denial is communicated to providers. In addition to the existing program notification requirements, communicating specific reasons for denial increases transparency, reduces burden, and improves efficiencies for both payers and providers. Under existing regulations, an MA organization must notify the enrollee (and the prescribing physician or other prescriber involved, as appropriate) of its determination on a request for a Part B drug as expeditiously as the enrollee's health condition requires but no later than 72 hours after receiving a standard request and no later than 24 hours after receiving an expedited request.\118\ When a request for a Part B drug is denied, MA organizations must provide the specific reasons for the denial along with certain other information, such as how to request an appeal.\119\ CMS provides a standardized form \120\ that MA organizations must use, which captures a specific rationale of why the item, service, or Part B drug was denied, including a description of the applicable coverage rule or applicable plan policy (for example, the Evidence of Coverage provision) upon which the action was based and a specific explanation about what information is needed to approve coverage, if applicable. Given that existing regulations require MA organizations to notify the enrollee and the prescriber, as appropriate, of a decision on a Part B drug request, we are not proposing any changes related to the notice requirements for a prior authorization decision by an MA organization in this rule. Similar notice requirements, including a reason for denial, exist for Part D sponsors making prior authorization decisions.\121\ Standardized MA and Part D denial notices, which plans must send to enrollees, require a specific reason for the denial and the following language: ``Share a copy of this decision with your doctor and discuss next steps. If your doctor asked for coverage on your [[Page 19934]] behalf, we already sent them a copy of this denial notice.'' \122\ --------------------------------------------------------------------------- \118\ See 42 CFR 422.568(b)(3) and 42 CFR 422.572(a)(2). \119\ See 42 CFR 422.568(e) and 42 CFR 422.572(e). \120\ See 42 CFR 422.2267(e)(16); See Integrated Denial Notice Form 10003-NDMCP, which has the instructions, form, and Spanish translation. See Centers for Medicare & Medicaid Services. (2024, September 10). MA Denial Notice. Retrieved from https://www.cms.gov/medicare/forms-notices/beneficiary-notices-initiative/ma-denial-notice. \121\ Centers for Medicare & Medicaid Services. (2024, November 18). Parts C & D Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance. Retrieved from https://www.cms.gov/medicare/appeals-and-grievances/mmcag/downloads/parts-c-and-d-enrollee-grievances-organization-coverage-determinations-and-appeals-guidance.pdf. \122\ See Integrated Denial Notice Form 10003-NDMCP Eff Jan 2025 available at: Centers for Medicare & Medicaid Services. (2024, September 10). MA Denial Notice. Retrieved from https://www.cms.gov/medicare/forms-notices/beneficiary-notices-initiative/ma-denial-notice. --------------------------------------------------------------------------- Similarly, Medicaid managed care plans and CHIP managed care entities must notify the requesting provider and give the beneficiary written notice of any decision by the plan to deny a service authorization request or to authorize a service in an amount, duration, or scope that is less than requested.\123\ As specified in 42 CFR 438.242(b)(8), by the rating period beginning on or after January 1, 2026, Medicaid managed care plans must communicate a specific reason for any denials to the provider, regardless of the method used to communicate that information, for prior authorization requests for non- drug items and services.\124\ These requirements also apply to CHIP managed care entities by cross reference.\125\ --------------------------------------------------------------------------- \123\ See 42 CFR 438.210(c) and 438.242(b)(8) for Medicaid managed care plans and 42 CFR 457.1230(d) for CHIP managed care entities. \124\ As specified in 42 CFR 438.242(b)(8) by cross-reference to 42 CFR 431.80(a). \125\ See 42 CFR 457.1233(d). --------------------------------------------------------------------------- While 45 CFR 156.223(a) requires QHP issuers on the FFEs to include a specific reason for the denial of a prior authorization request to the provider, this requirement explicitly excludes prescription drugs. c. Proposed Requirement To Include a Specific Reason for Denial to Providers When Denying Prior Authorization of All Drugs for State Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on the Federally-facilitated Exchanges We propose that beginning October 1, 2027, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs be required to provide a specific reason to providers when denying a prior authorization request for drugs, regardless of the method used to send the prior authorization request or decision. This proposal is an effort to improve the communication between those impacted payers and providers when they deny a prior authorization request for drugs. This proposal would align with the requirement finalized in the 2024 CMS Interoperability and Prior Authorization final rule that impacted payers send to providers a specific reason for denying a prior authorization request for non-drug items and services.\126\ We now propose to apply that same denial notice requirement to state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs for prior authorizations for drugs. This proposed change should lead to those payers providing more transparent communication in their decision-making, allowing providers to address any deficiencies in the request or consider alternative treatments. --------------------------------------------------------------------------- \126\ See 42 CFR 422.122(a) for MA organizations and applicable integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs, 42 CFR 457.732(a) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(a) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- The content of the response should include a specific reason for denying a prior authorization request for drugs that helps a provider to understand why the request was denied and what actions must be taken to resubmit or appeal the decision. A specific reason for denial could include information about the specific plan coverage criteria on which the denial is based, why documentation did not support the medication or prescription, or why the drug is not deemed necessary. This proposal could improve the current processes and reduce manual effort and costs by increasing the likelihood that providers whose prior authorization request for drugs is denied have all the information they need to decide the next steps to care for the patient, including whether and how to appeal the denial. We are proposing an October 1, 2027 effective date for this proposal, as these protections are important to patients. This proposal does not affect existing patient notice requirements for state Medicaid and CHIP FFS programs and QHP issuers on the FFEs. State Medicaid and CHIP FFS programs are required to provide a beneficiary with timely and adequate written notice of a ``denial or change in benefits and services.'' \127\ In case of an adverse benefit determination, QHP issuers on the FFEs must include in their notice to enrollees certain information, including the reason(s) for the adverse benefit determination, a denial code and its meaning, and a description of the QHP issuer on the FFEs' standard that was used in the denial.\128\ Like the requirement that we finalized in the 2024 CMS Interoperability and Prior Authorization final rule for non-drug items and services, our proposed requirement should ensure that providers who submit prior authorization requests for drugs receive information directly from impacted payers regarding an adverse prior authorization determination, which should expedite their ability to appeal the determination or provide additional information if needed. --------------------------------------------------------------------------- \127\ See 42 CFR 435.917(a) for state Medicaid FFS programs and 42 CFR 457.1180 for state CHIP FFS programs. \128\ See 29 CFR 2560.503-1(g), 45 CFR 147.136(b)(2)(i), and 45 CFR 147.136(b)(3)(ii)(E)(3). --------------------------------------------------------------------------- In addition to these new requirements, we are proposing to reorganize 42 CFR 438.210(c) and 42 CFR 438.242 to improve readability. This proposal maintains existing program requirements for non-drug items and services while proposing these new requirements for Medicaid managed care plans to provide specific denial reasons for drug prior authorization requests. In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following: The proposal to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to communicate to providers a specific reason for denying a prior authorization request for any drugs, regardless of the method used to send the prior authorization request or decision. The proposed October 1, 2027 compliance date for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. The proposed structural changes to 42 CFR 438.210(c) and 42 CFR 438.242 to improve readability.

3. Prior Authorization Decision Timeframes

a. Background In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to make prior authorization decision requests on non-drug items and services as expeditiously as a patient's health condition requires but no later than 7 calendar days after receiving a standard request and no later than 72 hours after receiving an expedited request, effective in 2026 (89 FR 8897). However, we did not propose or finalize those requirements for QHP issuers on the FFEs, in part because existing regulations in 45 CFR 147.136 establish timelines for all non-grandfathered [[Page 19935]] group health plans and health insurance issuers offering individual and group health insurance coverage (``plans and issuers'') to notify claimants, participants, beneficiaries, and enrollees (patients) of prior authorization (referred to in those regulations as a ``pre- service'') decisions (89 FR 8879). Specifically, 45 CFR 147.136(b)(3)(i) generally requires plans and issuers to meet the requirements of the claims and appeals procedures applicable to group health plans in 29 CFR 2560.503-1, as if the coverage were a group health plan. Under those requirements, QHP issuers on the FFEs must notify patients of a plan's benefit determination on a prior authorization request as expeditiously as a patient's health condition requires but no later than 15 days after a standard request and as soon as possible, taking into account the medical exigencies, but no later than 72 hours for expedited requests (referred to in those regulations as ``urgent care'' claims). Notably, these timeframes apply to non-drug items and services, as well as drugs. While neither 45 CFR 147.136(b)(3) nor 29 CFR 2560.503-1 require plans and issuers to notify the requesting provider of a prior authorization decision, when they do, HHS presumes that they do so within the same timeframes that they are required to notify patients. As a result, beginning in 2026, QHP issuers on the FFEs effectively have longer to provide notification of a decision on a standard prior authorization request for non-drug items and services (a maximum of 15 days) as compared to other impacted payers (a maximum of 7 days).\129\ In contrast, QHP issuers on the FFEs effectively have the same amount of time to provide notification of a decision on a standard prior authorization request for non-drug items and services as other impacted payers (a maximum of 72 hours). Finally, in both cases, as noted, there is no regulatory requirement that QHP issuers on the FFEs notify providers of any prior authorization decision. --------------------------------------------------------------------------- \129\ As noted above, effective in 2026, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must notify claimants and providers of prior authorization decisions on non-drug items and services no later than 7 calendar days for standard requests and no later than 72 hours for expedited requests --------------------------------------------------------------------------- In addition to the requirements for non-drug items and services, MA organizations, state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities have existing decision timeframe requirements for prior authorization of certain drugs. MA organizations must notify the enrollee (and the prescribing physician or other prescriber involved, as appropriate) of a determination regarding coverage of a Part B drug as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the standard request and no later than 24 hours after receiving the expedited request.\130\ Similarly, Part D sponsors, including MA-PDs, have the same requirements for prior authorization decisions on Part D drugs (with the possibility of an extension).\131\ The Part D sponsor must notify the enrollee (and the prescribing physician or other prescriber involved, as appropriate) of its determination as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the standard request and no later than 24 hours after receiving the expedited request. Given the existing prior authorization decision timeframe requirements for Part B and Part D drugs, we do not believe that additional proposals for MA organizations or Part D sponsors are necessary or appropriate at this time. However, we request comment on whether there are any drugs payable under Part A that are not included as part of a larger bundle of inpatient services to which the timeframe to make prior authorizations decisions should apply for MA organizations. If so, we would consider finalizing a policy to ensure that all drugs that require prior authorization have appropriate decision timeframes. --------------------------------------------------------------------------- \130\ See 42 CFR 422.568(b)(3) and 42 CFR 422.572(a)(2). \131\ See 42 CFR 423.568(b) and 42 CFR 423.572(a). --------------------------------------------------------------------------- State Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities also have existing decision timeframe requirements for covered outpatient drugs.\132\ Specifically, state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities must respond to a prior authorization request for a covered outpatient drug within 24 hours of the request and dispense at least a 72-hour supply of the drug in emergencies. However, there is no requirement specific to drugs for state CHIP FFS programs. Instead, state CHIP FFS programs must adhere to the general decision-making timeframe, which mandates that prior authorization decisions be made in accordance with the medical needs of the patient within 14 days after receiving a request for services (beginning on January 1, 2026, the timeframe will be 7 calendar days for standard requests and 72 hours for expedited requests).\133\ --------------------------------------------------------------------------- \132\ See section 1927(d)(5)(A) of the Act for state Medicaid FFS programs, 42 CFR 438.210(d)(3) and 42 CFR 438.3(s)(6) for Medicaid managed care plans, and through cross reference to 42 CFR 438.210(d)(3) in 42 CFR 457.1230(d) for CHIP managed care entities. \133\ See 42 CFR 457.495(d). --------------------------------------------------------------------------- As discussed in sections II.C.3.c. and II.C.3.d. of this proposed rule, we are now requesting information on whether there are gaps in timeframe requirements for some drugs and if there are we are proposing to apply the prior authorization decision timeframes for non-drug items and services outlined in the 2024 CMS Interoperability and Prior Authorization final rule to that subset of drugs for which there are not already established prior authorization timeframes. This would apply to both state Medicaid FFS programs and Medicaid managed care plans. We are also proposing to modify state CHIP FFS programs' decision-making timeframes for the prior authorization of drugs comport with section 1927(d)(5)(A) of the Act to align with the requirements for those programs. b. Prior Authorization Decision Timeframes for Qualified Health Plan Issuers on the Federally-facilitated Exchanges In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, many commenters disagreed with excluding QHP issuers on the FFEs from the shortened timeframe requirements and asked that CMS reconsider the exclusion. Commenters stated it would be more consistent and equitable for CMS to apply the same timeframe requirements for standard prior authorization decisions for all impacted payers (89 FR 8880). Commenters stated that patients covered by these plans should be entitled to the same protections as those covered by other impacted payers, and that excluding QHP issuers on the FFEs could negatively affect patients by delaying access to care based only on the type of insurance they have. One commenter stated that they did not believe that shortening the prior authorization decision timeframe for QHP issuers on the FFEs from a 15 day response time for standard requests to 7 days would cause an undue burden to those plans. We also received many comments requesting CMS consider adding additional standards to the prior authorization process to address the adverse effects of delays on patients and providers (89 FR 8859). Multiple commenters wrote that CMS should apply even shorter prior authorization decision timeframes to QHP issuers on the FFEs, such as 72 hours for standard [[Page 19936]] requests and 24 hours for expedited requests. In response to the comments received, we stated that we would evaluate opportunities for future rulemaking to alleviate provider burdens and mitigate delays associated with prior authorization (89 FR 8859). We are aware that a growing number of states have passed laws to reduce prior authorization decision timeframes, require technical standards, limit procedural justifications for denials, tie decisions to clinical criteria, and increase transparency.\134\ In addition to public comments that expressed concerns that patients experience delayed or deferred care because of complex prior authorization processes, recent research has suggested that these concerns disproportionately impact those with chronic conditions and mental health care needs.\135\ --------------------------------------------------------------------------- \134\ American Medical Association. (2024). 2024 Prior Authorization (PA) State Law Chart. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-state-law-chart.pdf. \135\ Pollitz, K., Pestaina, K., Lopes, L., Wallace, R., & Lo,

J. (2023, September 29). Consumer Problems with Prior Authorization:

Evidence from KFF Survey. Retrieved from https://www.kff.org/affordable-care-act/issue-brief/consumer-problems-with-prior-authorization-evidence-from-kff-survey/. --------------------------------------------------------------------------- Hence, we are now proposing, in 45 CFR 156.223(i)(1)(i), that beginning October 1, 2027 in response to a request for prior authorization for non-drug items and services, QHP issuers on the FFEs must notify the requesting provider of their decision as expeditiously as a patient's health condition requires but no later than 7 days after receiving a standard prior authorization request and no later than 72 hours after receiving an expedited prior authorization request. We also propose, in 45 CFR 156.223(i)(1)(ii), that beginning October 1, 2027 in response to a prior authorization request for any drug, QHP issuers on the FFEs must notify a requesting provider of their decision as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving a standard prior authorization request and no later than 24 hours after receiving an expedited prior authorization request. These are similar to the timeframes for prior authorization decisions for drugs that we propose for other impacted payers in this proposed rule. The proposed timeframes to require QHP issuers on the FFEs to notify the requesting provider of a prior authorization decision would be new; that is, there is currently no requirement for QHP issuers on the FFEs to notify providers of a prior authorization decision within any specific period of time. This proposal would not change existing prior authorization notification requirements in 45 CFR 147.136 for patients but would create a new requirement for QHP issuers on the FFEs to notify the requesting provider of a prior authorization decision within a specific timeframe based on the nature of the request, and these timeframes would generally be shorter than the maximum amount of time that QHP issuers on the FFEs have to notify patients regarding standard prior authorization requests under existing regulations in 45 CFR 147.136.\136\ --------------------------------------------------------------------------- \136\ Consistent with the treatment of the requirement that payers provide the specific reason for denying a prior authorization request in the payer's response to the provider established in the 2024 CMS Interoperability and Prior Authorization final rule, the burden associated with notifying the requesting provider of the health plan's prior authorization determination is considered usual and customary as the disclosure is integral to the business practice and function of the health plan. Therefore, we have identified the burden associated with communicating a prior authorization decision as a usual and customary business practice that does not require a burden calculation pursuant to 5 CFR 1320.3(b)(2). --------------------------------------------------------------------------- Establishing a new requirement for QHP issuers on the FFEs to notify providers of prior authorization decisions on non-drug items and services and drugs, and aligning those timelines with current and proposed timelines for other impacted payers, could improve patient care and minimize administrative burden for providers who would be able to expect prior authorization decisions within the same timeframe from all impacted payers. We are not proposing to shorten the timeframes for QHP issuers on the FFEs to notify patients of prior authorization decisions as established in 45 CFR 147.136(b)(3); however, we recognize that QHP issuers on the FFEs may voluntarily adopt shorter patient notification timeframes that align with the proposed provider notification timeframes to minimize administrative burden. Therefore, this proposal may result in faster notification for patients than is required by 45 CFR 147.136(b)(3) and may result in QHP issuers on the FFEs notifying patients more quickly than plans and issuers subject to 45 CFR 147.136(b)(3), including issuers on SBEs. We expect that the proposed timeframes for notifying providers would be feasible for QHP issuers on the FFEs given the notification functionality of the Prior Authorization API and NCPDP standards that we are proposing QHP issuers on the FFEs to support for electronic prior authorization. Those standards support direct electronic communications between payers and providers about prior authorizations. In addition, that available technology can accelerate the decision- making itself and we are of the view that QHP issuers on the FFEs should be part of this trend in process improvement. As noted above, we are proposing that QHP issuers on the FFEs notify the requesting provider ``as expeditiously as the enrollee's health condition requires,'' subject to the proposed time limits, which is the standard for non-drug items and services used by MA organizations,\137\ Part D sponsors,\138\ Medicaid,\139\ and CHIP.\140\ We are proposing that, in determining what an enrollee's health condition requires, QHP issuers on the FFEs must abide by the same requirement to make decisions in accordance with established accepted standards of medical practice in assessing an individual's medical condition, and we solicit comment on whether any other language in regulation or in sub-regulatory guidance is necessary to ensure that QHP issuers on the FFEs adhere to this standard. --------------------------------------------------------------------------- \137\ See 42 CFR 422.568(b)(1) and 42 CFR 422.568(b)(3). \138\ See 42 CFR 423.568(b) and 42 CFR 423.572(a). \139\ See 42 CFR 440.230(e)(1). \140\ See 42 CFR 457.495(d), using the phrase ``In accordance with the medical needs of the patient . . . .'' --------------------------------------------------------------------------- We also propose, in 45 CFR 156.223(i)(2), that for purposes of 45 CFR 156.223(i)(1), a standard prior authorization request has the meaning given in 29 CFR 2560.503-1(m)(2) to a ``pre-service claim'' and an expedited prior authorization request has the meaning given in 29 CFR 2560.503-1(m)(1) to a ``claim involving urgent care,'' as determined by the attending provider, and the issuer shall defer to such determination of the attending provider. By relying on existing definitions, we seek to maintain consistency across requirements related to prior authorization for QHP issuers on the FFEs. We also propose, in 45 CFR 156.223(i)(3)(i), that the QHP issuer on the FFEs may extend the timeframes to notify the requesting provider of a prior authorization decision by up to 14 calendar days under any of the following circumstances: (1) if the provider requests the extension; (2) the extension is justified and in the provider's or enrollee's interest because the QHP issuer on the FFEs needs additional medical evidence from another provider or the enrollee in order to issue a decision; or (3) the extension is justified due to extraordinary, exigent, or other non-routine circumstances and is in the provider's or enrollee's interest. If extended, the QHP issuer on the FFEs [[Page 19937]] would be required to notify the provider of its determination as expeditiously as the enrollee's health condition requires, but no later than upon expiration of the extension. We also propose to require, in 45 CFR 156.223(i)(3)(ii), that when the QHP issuer on the FFEs extends the timeframe, it must notify the requesting provider in writing of the reasons for the extension and inform the provider of the right to file an expedited grievance if the provider disagrees with the QHP issuer on the FFE's decision to grant an extension. This language is similar to the corresponding provision that CMS finalized in the 2024 Interoperability and Prior Authorization final rule. We believe it is appropriate for QHP issuers on the FFEs as well, but solicit comment on whether that is the case or if it should be amended. In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following: The proposal to require QHP issuers on the FFEs to provide notice to the requesting provider of prior authorization decisions as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after receiving a standard prior authorization request for non-drug items and services and as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving an expedited request for non-drug items and services. The proposal to require QHP issuers on the FFEs to provide notice to the requesting provider of prior authorization decisions as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving a standard prior authorization request for drugs and as expeditiously as the enrollee's health condition requires, but no later than 24 hours after receiving an expedited request for drugs. The proposal that QHP issuers on the FFEs may extend the timeframes to notify the requesting provider of a prior authorization decision by up to 14 calendar days under certain circumstances, and the QHP issuers on the FFEs must notify the requesting provider in writing of the reasons for the delay and inform the provider of the right to file an expedited grievance if the provider disagrees with the QHP issuer on the FFEs' decision to grant an extension. The proposal that for purposes of 45 CFR 156.223(i)(1), a standard prior authorization request has the meaning given in 29 CFR 2560.503-1(m)(2) to a ``pre-service claim'' and an expedited prior authorization request has the meaning given in 29 CFR 2560.503-1(m)(1) to a ``claim involving urgent care'' for QHP issuers on the FFEs. The proposed October 1, 2027 compliance date. In addition, we request comments on the following: Whether requiring QHP issuers on the FFEs to provide notice to requesting providers of prior authorization decisions in a shorter timeframe than they are currently required to provide notice to patients of prior authorization decisions is sufficient to improve enrollees' care, or if CMS should consider also applying shorter timeframes for notification to patients, as well. Whether there would be burden due to the different timeframes for QHP issuers on the FFEs to notify a requesting provider of a prior authorization decision and to notify participants, beneficiaries, and enrollees of prior authorization decisions, and how we could potentially alleviate that burden. Whether we should finalize shorter timeframes for QHP issuers on the FFEs to notify the requesting provider of prior authorization requests for drugs, specifically, 24 hours for all requests (standard or expedited), to align with the existing requirements for state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities, and our proposal for state CHIP FFS programs. Whether the requirement to make decisions as ``expeditiously as the enrollee's health condition requires'' is appropriate, or whether additional or alternative language or sub- regulatory guidance is necessary to help ensure impacted payers make timely decisions and for consistency with existing decision timeframes in 45 CFR 147.136(b)(3) and 29 CFR 2560.503-1(f). Whether QHP issuers' parent organizations that participate in multiple CMS-regulated programs, such as MA organizations or Medicaid managed care plans, already have experience responding to prior authorization requests more quickly than it is currently required by existing market wide rules that they can leverage to improve processes for their QHPs offered on the FFEs. Whether QHP issuers on the FFEs' plan management systems can readily distinguish between a policy applicable to a QHP offered on an FFE, a policy applicable to off-Exchange individual or small group coverage, or a QHP issuer in an SBE. c. Prior Authorization Decision Timeframes for Drugs That Are Not Covered Outpatient Drugs for State Medicaid Fee-for-Service Programs, Medicaid Managed Care Plans, and CHIP Managed Care Entities As discussed previously, section 1927(d)(5)(A) of the Act establishes a 24-hour timeframe for state Medicaid FFS programs to respond to requests for prior authorization of covered outpatient drugs for which FFP is available. However, that timeframe may not apply to all drugs that are covered by states for which states receive FFP. In the 2022 CMS Interoperability and Prior Authorization proposed rule, which addressed prior authorization decision timeframes for non-drug items and services, CMS received comments indicating that drugs should have been included in the prior authorization timeframe policies and that gaps exist regarding timeframe requirements on prior authorizations for certain drugs. Given that covered outpatient drugs already have an established statutory timeframe for prior authorization pursuant to section 1927 of the Act, we seek to address the comments concerning a possible gap in prior authorization timeframes for a subset of drugs which are not covered outpatient drugs. In addition, to address concerns by commenters, we explain the prior authorization decision timeframes for drugs that otherwise meet the definition of covered outpatient drugs in section 1927(k)(2) of the Act but are excluded from the definition of covered outpatient drugs due to meeting the criteria in the limiting definition of covered outpatient drug in section 1927(k)(3) of the Act. Section 1927(k)(3) of the Act limits the term ``covered outpatient drug'' to exclude any drug, biological product, or insulin provided as part of, or as incident to and in the same setting as, certain services (and for which payment may be made under that subchapter as part of payment for those services and not as direct reimbursement for the drug).\141\ To the extent that state Medicaid and CHIP programs cover and impose prior authorization requirements on these drugs that are not covered outpatient drugs, we believe the same decision timeframe requirements that [[Page 19938]] apply to prior authorization for the non-drug items and services should apply to a drug that is provided incident to those services. Therefore, non-covered outpatient drugs that meet the limiting definition in section 1927(k)(3) of the Act should align with the timeframe requirements for non-drug items and services, which is 7 calendar days for standard requests and 72 hours for expedited requests. We believe it is most appropriate to align the prior authorization decision timeframe for a drug that meets the limiting definition in section 1927(k)(3) of the Act with the services it is provided as part of, or incident to. We believe this will ensure a prior authorization decision is rendered for the drug and non-drug items and services within the same timeframe as opposed to having the drug reviewed under a different timeframe than the remainder of the service with which it is bundled with. --------------------------------------------------------------------------- \141\ The services listed in section 1927(k)(3) of the Act are: inpatient hospital services; hospice services; dental services, except that drugs for which the State plan authorizes direct reimbursement to the dispensing dentist are covered outpatient drugs; physicians' services; outpatient hospital services; nursing facility services and services provided by an intermediate care facility for the mentally retarded; other laboratory and x-ray services; and renal dialysis. --------------------------------------------------------------------------- One example of this subset of drugs are those that are administered in an inpatient hospital setting. Drugs administered in an inpatient setting are typically paid for as part of a bundled payment, which includes a variety of items, services, and drugs. Under that payment model, when prior authorization is required, it is typically submitted as a bundle and drugs are not separated from non-drug items and services; drugs and non-drug items and services are reviewed under the same prior authorization request and therefore same timeframe. In those situations, we do not believe there is a need for a separate timeframe for the drug component of the prior authorization; the prior authorization timeframes established in the 2024 CMS Interoperability and Prior Authorization final rule would apply to the entirety of the prior authorization request. In addition, we request comment on whether there are categories of non-covered outpatient drugs for which it would be more appropriate to finalize a decision timeframe that aligns with the statutory requirement for covered outpatient drugs at section 1927(d)(5)(A) of the Act. It is unclear whether there are drugs (that are not covered outpatient drugs) for which states require prior authorization and for which 24 hours would be the appropriate decision timeframe, rather than the longer decision timeframe for non-drug items and services. As stated, we do not desire to create different timeframes for prior authorization decisions for drugs versus non-drug items and services for which reimbursement and prior authorization requests are bundled. However, we also want to address any gaps for standalone prior authorization requests for drugs that either do not have an existing prior authorization decision timeframe requirement, or for which the prior authorization decision timeframe is misaligned with our other proposals in this proposed rule. We propose that if commenters identify gaps in the decision timeframe requirements for drugs, we would apply the same requirements to Medicaid MCOs, PIHPs, and PAHPs by amending 42 CFR 438.210 and CHIP managed care entities by the existing cross reference to 42 CFR 438.210 in 42 CFR 457.1230(d). We are proposing an October 1, 2027 compliance date for these proposals for state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities. In summary, we request comments on the following: The scope of drugs for which we are proposing these prior authorization requirements. Are there additional drugs that currently have no established prior authorization timeframe requirements for which such timeframes should be established? Is there a need to apply prior authorization timeframe requirements to the scope of drugs proposed in this rule? Are there other types of drugs for which we should finalize a requirement that aligns with the 24 hour timeframe established for covered outpatient drugs by section 1927(d)(5)(A) of the Act? The proposed October 1, 2027 compliance date for state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities. Whether we should consider future rulemaking to propose a requirement for MA organizations to respond to all prior authorization requests for drugs no later than 24 hours to align with the Medicaid and CHIP requirements for covered outpatient drugs. Whether there are any drugs payable under Medicare Part A that are not included as part of a larger bundle of inpatient services to which the timeframe to make prior authorizations decisions should apply for MA organizations. d. Prior Authorization Decision Timeframes for Prescription Drugs for State CHIP Fee-for-Service Programs To align with the existing requirements for state Medicaid FFS programs, Medicaid managed care plans, and CHIP managed care entities requirements for covered outpatient drugs, as well as the proposals described in section II.C.3.c. of this proposed rule, we propose to shorten the timeframe for state CHIP FFS programs to make prior authorization decisions on prescription drugs for which the state receives FFP, as described in section 2110(a)(6) of the Act. As noted previously, the current requirement is the same 7 days for standard requests and 72 hours for expedited requests as for non-drug items and services, while other payers have shorter decision timeframes for the prior authorization of drugs than for non-drug items and services. We are proposing to establish a requirement that state CHIP FFS programs must provide notice to providers and beneficiaries of prior authorization decisions for prescription drugs for which FFP is available in accordance with the beneficiary's medical needs but no later than 24 hours after receiving the prior authorization request. This proposal would align with the existing state Medicaid FFS program requirements for covered outpatient drugs in section 1927(d)(5)(A) of the Act. This proposed alignment for timeframe requirements should ensure that providers and patients have similarly efficient processes across all impacted payers and within CMS programs, regardless of how drugs are categorized under the Act. We are proposing an October 1, 2027 compliance date. In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following: The proposal to require state CHIP FFS programs to provide notice to providers and patients of prior authorization decisions in accordance with the beneficiary's medical needs, but no later than 24 hours after receiving a prior authorization request for prescription drugs for which FFP is available. The proposed October 1, 2027 compliance date. 4. Update to State Medicaid and CHIP Fee-for-Service Programs' Decision Timeframe Terminology After finalizing the 2024 CMS Interoperability and Prior Authorization final rule, we determined that the regulations in 42 CFR 440.230(e) and 42 CFR 457.495(d) needed to be written more clearly to align with the finalized policy as explained in that rule (89 FR 8897). In 42 CFR 440.230(e), we established that state Medicaid FFS programs must make prior authorization decisions on requests for non-drug items and services no later than 7 calendar days for standard requests and 72 hours for expedited requests. We also provided that states could establish shorter timeframes, with which the state [[Page 19939]] Medicaid agency would have to comply. The regulation refers to this as a ``shorter minimum timeframe,'' but the intent of this requirement is to establish a maximum period of time for a state to make a decision on a prior authorization request. We are therefore proposing to remove the word ``minimum'' to explain that states may establish timeframes that are shorter, but not longer, than those we finalized. Similarly, 42 CFR 457.495(d) accounts for state laws that may establish different timeframes but does not limit those requirements to being shorter than the 14 days for standard requests and 72 hours for expedited requests. Therefore, we are proposing to align the language for state CHIP FFS program timeframes with that for state Medicaid FFS program timeframes by specifying that state CHIP FFS programs must make prior authorization decisions for non-drug items and services no later than 7 calendar days for standard requests and 72 hours for expedited requests unless a shorter timeframe is established by the state. Both these proposals are consistent with the explanation of our finalized policies in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8879). We propose that this change would be effective on the effective date of the final rule, as it does not change the existing regulatory requirement. In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following: The proposal to revise regulatory language for state Medicaid FFS programs and add regulatory language for state CHIP FFS programs to explain that state Medicaid and CHIP FFS programs must make prior authorization decisions available for non-drug items and services no later than 7 calendar days for standard requests and 72 hours for expedited requests unless a shorter timeframe is established by the state. The proposal to become effective beginning on the effective date of the final rule. 5. Proposed Changes to Reporting Deadlines and Reporting Levels for Publicly Reported Prior Authorization Metrics for Non-Drug Items and Services for Medicaid Managed Care Plans and CHIP Managed Care Entities In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements for impacted payers to publicly report certain prior authorizations metrics about non-drug items and services annually beginning in 2026.\142\ By sharing these data, payers can build trust with their patients and providers and showcase their commitment to improving services. We recognize the need for greater transparency in the prior authorization process and for information to be available to the public. Beyond information about which services require prior authorization and the requirements for approval, greater transparency about payer performance on denials, timeframes, and volumes could help the public and identify opportunities for improvement. --------------------------------------------------------------------------- \142\ See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through existing cross reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- We finalized an annual March 31 deadline for all impacted payers to publicly post prior authorization metrics for the previous year.\31\ However, we have determined that such a deadline may not align with Medicaid managed care plans' and CHIP managed care entities' contract rating periods. For example, Medicaid managed care plan contract rating periods, as defined in 42 CFR 438.2, do not all use the same time period and each state may choose different contract rating periods for each managed care program. Similarly (though rate certifications are not required for CHIP managed care entities), the rating periods for CHIP managed care entities vary across states. Because rating periods do not necessarily align with calendar years, we now believe that the March 31 reporting deadline finalized in the 2024 CMS Interoperability and Prior Authorization final rule is not appropriate for all Medicaid managed care plans and CHIP managed care entities.\143\ Therefore, to align the reporting deadlines with the contract rating period for each program, we are now proposing to require Medicaid managed care plans and CHIP managed care entities to publicly post the required prior authorization metrics no later than 90 days after the end of their rating period. --------------------------------------------------------------------------- \143\ See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through cross reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 1562.223(c) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- We also propose to amend the existing requirements for Medicaid managed care plans and CHIP managed care entities to require that they report the prior authorization metrics finalized in the 2024 CMS Interoperability and Prior Authorization final rule by program, as well as by plan. For consistency with the other Medicaid and CHIP managed care reporting requirements, we believe that it is appropriate to also collect these metrics at the program level. Specifically, if a managed care plan contracts with the state for multiple programs (for example, an adult and child acute care program and a long-term services and supports [LTSS] program), each program's prior authorization metrics would be reported separately. This is also consistent with how states must report all data in the Managed Care Program Annual Report (MCPAR), as described in 42 CFR 438.66(e). Integrated plans would continue to report non-drug items and services covered by MA organizations at the MA contract level, as the separate requirements for MA organizations and Medicaid managed care plans apply under their respective contracts. However, integrated plans would be required to report non-drug items and services covered by Medicaid managed care plans at both the plan and program level. That approach is consistent with the reporting requirements finalized in the 2024 CMS Interoperability and Prior Authorization final rule for non-drug items and services (89 FR 8897). We propose that this change would be effective on the effective date of the final rule to align the reporting requirements as soon as practicable. In summary, we request comment on our proposals in the CFR sections listed in Table 6, and specifically on the following: The proposal to modify the deadlines for Medicaid managed care plans and CHIP managed care entities to report certain metrics about prior authorizations for non-drug items and services to be no later than 90 days after the end of their contract rating period. The proposal to require Medicaid managed care plans and CHIP managed care entities to report certain metrics about prior authorizations for non-drug items and services, finalized in the 2024 Interoperability and Prior Authorization final rule, by program, as well as by plan. The proposals to become effective beginning on the effective date of the final rule. [[Page 19940]] 6. Proposed Changes to Publicly Reported Prior Authorization Metrics for Non-Drug Items and Services for Impacted Payers In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that impacted payers report certain prior authorization metrics aggregated for all non-drug items and services on their public websites (89 FR 8897). After further consideration, we are proposing to amend those metrics to provide more useful and complete information. Currently, impacted payers must report the percentage of prior authorizations that were approved, denied, approved after appeal, and approved after the timeframe for review was extended (89 FR 8889-8890). We are proposing to also require impacted payers to report a numeric count of prior authorization requests, as well as percentages, for certain existing metrics. In addition, we are proposing to add four metrics that are complementary to existing metrics. For simplicity, we use the term ``reporting period'' to describe the period from which data must be reported. Specifically, the reporting period for MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be the calendar year and the reporting period for Medicaid managed care plans and CHIP managed care entities would be the rating period. We propose to require impacted payers to report the following: The total number and percentage of standard prior authorization requests for non-drug items and services that remain denied after appeal during the reporting period.\144\ --------------------------------------------------------------------------- \144\ Appeals for MA organizations are described in 42 CFR 422 Subpart M. Appeals for state Medicaid FFS programs (known as fair hearings) are described in 42 CFR 431 Subpart E and for Medicaid managed care plans in 42 CFR 438 Subpart F. Appeals for state CHIP FFS programs are described in 42 CFR 457 Subpart K and for CHIP managed care entities in 42 CFR 457.1260. Appeals for QHP issuers on the FFEs are described in 45 CFR 147.136. --------------------------------------------------------------------------- ++ Numerator: The total number of standard prior authorization requests for non-drug items and services that were appealed and the denial was upheld. ++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for non-drug items and services. The total number and percentage of expedited prior authorization requests for non-drug items and services that remain denied after appeal during the reporting period. ++ Numerator: The total number of expedited prior authorization requests for non-drug items and services that were appealed and the denial was upheld. ++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for non-drug items and services. The total number and percentage of standard prior authorization requests for non-drug items and services for which the timeframe for review was extended, and the request was denied during the reporting period. ++ Numerator: The total number of standard prior authorization requests for non-drug items and services for which the timeframe for review was extended and the request was denied. ++ Denominator: The total number of standard prior authorization requests for non-drug items and services. The total number and percentage of expedited prior authorization requests for non-drug items and services for which the timeframe for review was extended, and the request was denied during the reporting period. ++ Numerator: The total number of expedited prior authorization requests for non-drug items and services for which the timeframe for review was extended and the request was denied. ++ Denominator: The total number of expedited prior authorization requests for non-drug items and services. The proposed metrics for standard prior authorization requests that are ``denied after appeal'' and ``for which the timeframe for review was extended and the request was denied'' are complementary to the existing metrics for the percentage of standard prior authorization requests that are ``approved after appeal'' or ``for which the timeframe for review was extended and the request was approved.'' The two sets of metrics should generally sum to the total number of standard prior authorization requests for non-drug items and services that were appealed and the total number of standard prior authorization requests for non-drug items and services for which the timeframe for review was extended. For all metrics we are proposing that are related to appeals, appeals include both appeals reviewed internally by the impacted payer as well as by external organizations an impacted payer may contract with to review and process appeals. Appeals include all levels of appeal; internal and external appeals should not be differentiated between and should be aggregated as one metric. Appeals that have not been fully adjudicated within the reporting period may be excluded from the metrics. In addition, we propose that impacted payers report on the following: The total number and percentage of expedited prior authorization requests for non-drug items and services for which the timeframe for review was extended, and the request was approved during the reporting period. ++ Numerator: The total number of expedited prior authorization requests for non-drug items and services for which the timeframe for review was extended and the request was approved. ++ Denominator: The total number of expedited prior authorization requests for non-drug items and services. The total number and percentage of expedited prior authorization requests for non-drug items and services that were approved after appeal during the reporting period. ++ Numerator: The total number of expedited prior authorization requests for non-drug items and services that were appealed, and the denial was overturned. ++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for non-drug items and services. These two metrics would align the metrics for expedited prior authorizations with those for standard prior authorizations. For MA organizations, extensions are described in 42 CFR 422.568(b)(2). For state Medicaid FFS programs, extensions are described in 42 CFR 440.230(e)(1)(i). For state CHIP FFS programs, extensions are described in 42 CFR 457.495(d). For Medicaid managed care plans, extensions are described in 42 CFR 438.210(d), and by cross-reference in 42 CFR 457.1230(d) for CHIP managed care entities. For QHP issuers on the FFEs, extensions would be described by the proposal, discussed earlier, in 45 CFR 156.223(h)(3). Notably, 42 CFR 440.230 does not provide for expedited prior authorization requests to be extended by state Medicaid FFS programs. Therefore, we are not proposing those metrics for state Medicaid FFS programs. The existing and proposed metrics for non-drug items and services are listed in Table 5. We are proposing to require impacted payers to publicly report these additional data to ensure these reports are useful and robust, as well as to align with other CMS reporting requirements. We believe that to make these metrics truly useful, CMS and the public must understand the scope of the prior authorization requests, both as an absolute number and as a percentage, because these numbers are complementary. The absolute number provides a scale and reveals the number of prior authorization requests submitted to the payer over the previous [[Page 19941]] reporting period. A percentage, on the other hand, provides an easy-to- understand metric to compare payers. Both of those numbers are important to provide context to individuals reviewing the reported data. Percentages and absolute numbers also allow for comparison across impacted payers and could highlight differences between payers, both in the number of prior authorization requests that they receive, as well as the approval rates at each stage of the process. Furthermore, using both the absolute number and percentage of prior authorizations in these metrics may avoid misinterpretation of the data. For instance, a small percentage of denied prior authorizations may seem insignificant until one understands that it represents thousands of prior authorizations. Conversely, for a payer that requires few prior authorizations, a large percentage of denials may be misinterpreted. Therefore, reporting both the number and percentage of prior authorization decisions by payers over the previous reporting period provides more comprehensive and useful information of these data while ensuring that the interpretation of these data is accurate and properly contextualized. We also propose minor wording changes to simplify the existing metrics and specify that the proposal include the ``total number'' of prior authorizations for each metric rather than ``aggregated for all items and services.'' We do not intend this proposal to change any policy or the definition of the metrics. [GRAPHIC] [TIFF OMITTED] TP14AP26.283 We are proposing that, if finalized, these additional metrics be effective beginning on the effective date of the final rule to be reported in the following year. We believe that producing these metrics would be a relatively straightforward task for impacted payers that have built their systems to generate the metrics required to be reported beginning in 2026. For example, percentages are derived from numeric counts of numerators and denominators. The numerator should reflect the subset of interest, such as requests approved or denied, and the denominator should be the total number of prior authorization requests (for all metrics not related to appeals). For metrics related to appeals, the denominator should be the total number of decided appeals of prior authorization requests during the reporting period. If an impacted payer has calculated the percentages for the existing metrics, they should already have available the numeric counts without additional burden. The proposals would require impacted payers to publicly report those numeric counts that they should already have. In addition, several of the proposed metrics are complementary to the existing metrics. For example, impacted payers must currently report on the percentage of standard prior authorization requests that were approved after appeal. In order to calculate that percentage, impacted payers would also have to know how many requests were denied after appeal, as those two percentages should total to 100 percent of the adjudicated appeals. Therefore, we believe there should be minimal additional burden to report the proposed new metrics and impacted payers should be able to report the additional metrics by the effective date of the final rule. We believe that the immediate transparency benefits to the public weigh in favor of an effective date as soon as possible. Finally, these additional metrics should provide much-needed context to the payer's prior authorization program; therefore, we are proposing that the additional metrics be required for the first reporting deadline after the effective date of the final rule. In summary, we request comment on our proposals in the CFR citations listed in Table 6, and specifically on the following: The proposal to require impacted payers to report the prior authorization metrics regarding non-drug items and services listed as ``new'' metrics in Table 5 on their public websites. The proposal to become effective beginning on the effective date of the final rule. 7. Proposed Requirement To Publicly Report Prior Authorization Metrics for Drugs for Impacted Payers To incorporate drugs into the existing prior authorization metrics, we are now proposing to require impacted payers to annually report certain metrics about prior authorizations for all drugs (excluding covered Part D drugs for MA-PDs) by posting this information on their public website. Covered Part D drugs and PDPs are not included in this proposal because they are covered in other reporting regulations, and it would be burdensome to add new, duplicative reporting requirements on these plans. The Part D program already has reporting requirements for aggregated coverage determinations, [[Page 19942]] redeterminations, and reopenings for covered Part D drugs.\145\ --------------------------------------------------------------------------- \145\ Existing reporting requirements for PDPs may be found at: Centers for Medicare & Medicaid Services. (2024). Part D Reporting Requirements. Retrieved from https://www.cms.gov/medicare/coverage/prescription-drug-coverage-contracting/part-d-reporting-requirements. --------------------------------------------------------------------------- We propose that impacted payers, other than Medicaid managed care plans and CHIP managed care entities, be required to annually report the previous calendar year's metrics regarding all drugs, excluding covered Part D drugs for MA-PDs, on their public websites beginning in 2028 (with data from 2027) following any calendar year that any of these impacted payers offered that type of plan. We propose to require that these metrics be made publicly available on those impacted payers' websites no later than March 31 to be consistent with the reporting requirements finalized in the 2024 CMS Interoperability and Prior Authorization final rule for non-drug items and services.\146\ To align with our proposal to amend the reporting deadline for Medicaid managed care plans and CHIP managed care entities, discussed previously in section II.C.5. of this proposed rule, we are proposing to require Medicaid managed care plans and CHIP managed care entities to publicly post the required prior authorization metrics no later than 90 days after the end of their rating period. --------------------------------------------------------------------------- \146\ See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through existing cross reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- To tie the metrics to the appropriate terminology for covered drugs, we propose that for these metrics, MA organizations would include any drugs payable under Part B that require prior authorization. Our understanding is that MA organizations do not require separate prior authorization requests for drugs payable under Part A. Rather, when prior authorization is required, it is requested and approved as part of a bundled payment for inpatient services. Therefore, because they are aggregated into requests for other items and services, we are not including drugs payable under Part A in the scope of the metrics we are proposing to require MA organizations to report. However, we request comment on whether there are drugs payable under Part A that require prior authorization separate from other items and services. If that is the case, we believe that metrics about drugs payable under Part A would be as important as those we are proposing for drugs payable under Part B. Therefore, we would consider finalizing that MA organizations report the proposed metrics by aggregating data from drugs payable under Part A and Part B. State Medicaid and Medicaid managed care plans would report on all prescribed drugs described in section 1905(a)(12) of the Act that require prior authorization. State CHIP FFS programs and CHIP managed care entities would report on all prescription drugs described in section 2110(a)(6) of the Act that require prior authorization. Finally, QHP issuers on the FFEs would include all drugs covered by the issuer that require prior authorization. Excluding any category of drug would provide an incomplete picture of the burden and impact of a payer's prior authorization practices. Some specialty and high-cost drugs may be subject to different utilization management requirements or denial rates. By being inclusive, we promote transparency and accountability for the prior authorization process across all types of drugs. For all of the reports for which we are proposing a percentage, we are also proposing that each impacted payer provide, as part of its report, the metrics' calculated numerators and denominators to provide a greater level of detail. Appeals that have not been fully adjudicated within the reporting period may be excluded. Furthermore, we recommend that impacted payers consider the format of their reports so that the data can be easily understood both in writing and graphically. An example of this type of report is available on the Medicare website for the FFS program.\147\ --------------------------------------------------------------------------- \147\ Centers for Medicare & Medicaid Services. (2023, September 15). Prior Authorization and Pre-Claim Review Program Stats. Retrieved from https://www.cms.gov/files/document/prior-authorization-and-pre-claim-review-program-statistics.pdf. --------------------------------------------------------------------------- We propose to require MA organizations to post the following metrics from the previous calendar year on their public websites: A list of all drugs payable under Part B that require prior authorization. The total number and percentage of approved standard prior authorization requests for Part B drugs during the calendar year. ++ Numerator: The total number of approved standard prior authorization requests for Part B drugs. ++ Denominator: The total number of standard prior authorization requests for Part B drugs. The total number and percentage of denied standard prior authorization requests for Part B drugs during the calendar year. ++ Numerator: The total number of denied standard prior authorization requests for Part B drugs. ++ Denominator: The total number of standard prior authorization requests for Part B drugs. The total number and percentage of standard prior authorization requests for Part B drugs for which the timeframe for review was extended, and the request was approved during the calendar year. ++ Numerator: The total number of standard prior authorization requests for Part B drugs for which the timeframe for review was extended and the request was approved. ++ Denominator: The total number of standard prior authorization requests for Part B drugs. The total number and percentage of standard prior authorization requests for Part B drugs for which the timeframe for review was extended, and the request was denied during the calendar year. ++ Numerator: The total number of standard prior authorization requests for Part B drugs for which the timeframe for review was extended and the request was denied. ++ Denominator: The total number of standard prior authorization requests for Part B drugs. The total number and percentage of standard prior authorization requests for Part B drugs approved after appeal during the calendar year.\148\ --------------------------------------------------------------------------- \148\ Appeals for MA organizations are described in 42 CFR 422 Subpart M. --------------------------------------------------------------------------- ++ Numerator: The total number of standard prior authorization requests for Part B drugs that were appealed, and the denial was overturned. ++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for Part B drugs. The total number and percentage of standard prior authorization requests for Part B drugs that remain denied after appeal during the calendar year. ++ Numerator: The total number of standard prior authorization requests for Part B drugs that were appealed, and the denial was upheld. ++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for Part B drugs. The average and median time that elapsed between the submission of requests and decisions for standard prior authorizations for Part B drugs during the calendar year. The total number and percentage of approved expedited prior authorization requests for Part B drugs during the calendar year. ++ Numerator: The total number of approved expedited prior authorization requests for Part B drugs. [[Page 19943]] ++ Denominator: The total number of expedited prior authorization requests for Part B drugs. The total number and percentage of denied expedited prior authorization requests for Part B drugs during the calendar year. ++ Numerator: The total number of denied expedited prior authorization requests for Part B drugs. ++ Denominator: The total number of expedited prior authorization requests for Part B drugs. The total number and percentage of expedited prior authorization requests for Part B drugs for which the timeframe for review was extended, and the request was approved during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for Part B drugs for which the timeframe for review was extended and the request was approved. ++ Denominator: The total number of expedited prior authorization requests for Part B drugs. The total number and percentage of expedited prior authorization requests for Part B drugs for which the timeframe for review was extended, and the request was denied during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for Part B drugs for which the timeframe for review was extended and the request was denied. ++ Denominator: The total number of expedited prior authorization requests for Part B drugs. The total number and percentage of expedited prior authorization requests for Part B drugs approved after appeal during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for Part B drugs that were appealed, and the denial was overturned. ++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for Part B drugs. The total number and percentage of expedited prior authorization requests for Part B drugs that remain denied after appeal during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for Part B drugs that were appealed, and the denial was upheld. ++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for Part B drugs. The average and median time that elapsed between the submission of requests and decisions for expedited prior authorizations for Part B drugs during the calendar year. We propose to require state Medicaid and CHIP FFS programs to post the following metrics from the previous calendar year on their public websites and to require Medicaid managed care plans and CHIP managed care entities to post the following metrics from the previous rating period on their public websites: A list of all drugs that require prior authorization. The total number and percentage of prior authorization requests for all drugs that were approved during the reporting period. ++ Numerator: The total number of prior authorization requests for all drugs that were approved. ++ Denominator: The total number of prior authorization requests for all drugs. The total number and percentage of prior authorization requests for all drugs that were denied during the reporting period. ++ Numerator: The total number of prior authorization requests for all drugs that were denied. ++ Denominator: The total number of prior authorization requests for all drugs. The total number and percentage of prior authorization requests for all drugs approved after appeal during the reporting period.\149\ --------------------------------------------------------------------------- \149\ Appeals for state Medicaid FFS programs (known as fair hearings) are described in 42 CFR 431 Subpart E and for Medicaid managed care plans in 42 CFR 438 Subpart F. Appeals for state CHIP FFS programs are described in 42 CFR 457 Subpart K and for CHIP managed care entities in 42 CFR 457.1260. --------------------------------------------------------------------------- ++ Numerator: The total number of prior authorization requests for all drugs that were appealed, and the denial was overturned. ++ Denominator: The total number of adjudicated appeals for prior authorization requests for all drugs. The total number and percentage of prior authorization requests for all drugs that remain denied after appeal during the reporting period. ++ Numerator: The total number of prior authorization requests for all drugs that were appealed, and the denial was upheld. ++ Denominator: The total number of adjudicated appeals for prior authorization requests for all drugs. The average and median time that elapsed between the submission of requests and decisions for prior authorizations for all drugs during the reporting period. We propose to require QHP issuers on the FFEs to post the following metrics from the previous calendar year on their public websites: A list of all drugs that require prior authorization. The total number and percentage of standard prior authorization requests for all drugs that were approved during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs that were approved. ++ Denominator: The total number of standard prior authorization requests for all drugs. The total number and percentage of standard prior authorization requests for all drugs that were denied during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs that were denied. ++ Denominator: The total number of standard prior authorization requests for all drugs. The total number and percentage of standard prior authorization requests for all drugs for which the timeframe for review was extended, and the request was approved during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs for which the timeframe for review was extended and the request was approved. ++ Denominator: The total number of standard prior authorization requests for all drugs. The total number and percentage of standard prior authorization requests for all drugs for which the timeframe for review was extended, and the request was denied during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs for which the timeframe for review was extended and the request was denied. ++ Denominator: The total number of standard prior authorization requests for all drugs. The total number and percentage of standard prior authorization requests for all drugs approved after appeal during the calendar year.\150\ --------------------------------------------------------------------------- \150\ Appeals for QHP issuers on the FFEs are described in 45 CFR 147.136. --------------------------------------------------------------------------- ++ Numerator: The total number of standard prior authorization requests for all drugs that were appealed, and the denial was overturned. ++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for all drugs. The total number and percentage of standard prior authorization requests for all drugs that remain denied after appeal during the calendar year. ++ Numerator: The total number of standard prior authorization requests for all drugs that were appealed, and the denial was upheld. [[Page 19944]] ++ Denominator: The total number of adjudicated appeals for standard prior authorization requests for all drugs. The average and median time that elapsed between the submission of requests and decisions for standard prior authorizations for all drugs during the calendar year. The total number and percentage of expedited prior authorization requests for all drugs that were approved during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs that were approved. ++ Denominator: The total number of expedited prior authorization requests for all drugs. The total number and percentage of expedited prior authorization requests for all drugs that were denied during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs that were denied. ++ Denominator: The total number of expedited prior authorization requests for all drugs. The total number and percentage of expedited prior authorization requests for all drugs for which the timeframe for review was extended, and the request was approved during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs for which the timeframe for review was extended and the request was approved. ++ Denominator: The total number of expedited prior authorization requests for all drugs. The total number and percentage of expedited prior authorization requests for all drugs for which the timeframe for review was extended, and the request was denied during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs for which the timeframe for review was extended and the request was denied. ++ Denominator: The total number of expedited prior authorization requests for all drugs. The total number and percentage of expedited prior authorization requests for all drugs approved after appeal during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs that were appealed, and the denial was overturned. ++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for all drugs. The total number and percentage of expedited prior authorization requests for all drugs that remain denied after appeal during the calendar year. ++ Numerator: The total number of expedited prior authorization requests for all drugs that were appealed, and the denial was upheld. ++ Denominator: The total number of adjudicated appeals for expedited prior authorization requests for all drugs. The average and median time that elapsed between the submission of requests and decisions for expedited prior authorizations for all drugs during the calendar year. We propose to align impacted payers' reporting levels with those we finalized in the 2024 CMS Interoperability and Prior Authorization final rule.\151\ Specifically, we propose that MA organizations would report at the contract level (applicable integrated plans would report drugs covered by MA organizations at the MA contract level), state Medicaid and CHIP FFS programs would report at the state level, Medicaid managed care plans and CHIP managed care entities would report at the plan and program level (if coverage of drugs is included in their contract), and QHP issuers on the FFEs would report at the issuer level. --------------------------------------------------------------------------- \151\ See 42 CFR 422.122(c) for MA organizations and applicable integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR 438.210(f) for Medicaid managed care plans, through existing cross reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care entities, and 45 CFR 156.223(c) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- We believe that the contract level is appropriate for MA organizations because they generally have multiple plans under the same contract (89 FR 8890). It is common for MA organizations to offer a variety of plans within a service area. The contract-level data are aggregated data collected from the plan benefit packages (PBPs) for all MA plans provided under an individual contract. Data are specific to the contract to which they correspond. CMS already requires MA organizations to report some contract-level data about their organization determinations on an annual basis and assigns Star Ratings at the contract level. We are proposing to align the reporting levels for state Medicaid and CHIP FFS programs in this proposed rule with those finalized in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8897) and the proposed amendment for Medicaid managed care plans and CHIP managed care entities described in section II.C.5. of this proposed rule--that is, at the state level for state Medicaid and CHIP FFS programs and at the plan and program level for Medicaid managed care plans and CHIP managed care entities--to create a cohesive and standardized approach to reporting for the long-term for comparability and analysis for both medical services and drugs. Similarly, requiring individual market QHP issuers on the FFEs to report at the issuer level is consistent with their reporting on quality improvement strategies as described in section 1311(g) of the Affordable Care Act and 45 CFR 156.1130, which also provides consistency with other reporting requirements for QHP issuers on the FFEs' (89 FR 8890). Our proposals for consistency across reporting requirements aim to reduce the reporting burden on issuers and ensure the publication of metrics in a method that issuers are familiar with. We note that it is also consistent with the Transparency in Coverage (TiC) reporting requirements in 45 CFR 156.220 and the level at which a QHP issuer on the FFEs must submit its certification application to participate in an FFE or an SBE-FP. This level is represented by the six-digit ``Issuer ID'' assigned to each QHP issuer on the FFEs as part of the QHP Certification application process, as explained in CMS's Application Instructions.\152\ While a parent organization may perform some of the work associated with reporting this information and may opt to publish the information on its website, the information must be available based on an issuer level as is required by regulation in 45 CFR 156.220 and as specified in the QHP Certification Application Instructions. --------------------------------------------------------------------------- \152\ Qualified Health Plan Certification. (2024, August 8). Application Instructions. Retrieved from https://www.qhpcertification.cms.gov/s/Application%20Instructions. --------------------------------------------------------------------------- In summary, we request comment on our proposals in the CFR sections listed in Table 6, and specifically on the following: The proposal to require MA organizations to report metrics about prior authorization for drugs payable under Part B, and to require state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to report metrics about prior authorization metrics for drugs on their public websites. The proposal to require MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs to annually report the previous calendar year's metrics on their public websites no later than March 31 following any calendar year that the impacted payer offered that type of plan. [[Page 19945]] The proposal to require Medicaid managed care plans and CHIP managed care entities to annually report the previous rating period's metrics on their public websites no later than 90 days after the end of their rating period. The proposal to require MA organizations to report at the contract level (applicable integrated plans would report drugs covered by MA organizations at the MA contract level), state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans and CHIP managed care entities to report at the plan and program level (if coverage of drugs is included in their contract), and QHP issuers on the FFEs to report at the issuer level. The proposed 2028 compliance dates to report metrics from the 2027 reporting period. In addition, we request comments on the following: Whether there are drugs payable under Part A that require prior authorization separate from other non-drug items and services that should be included in the scope of the proposed metrics for MA organizations. BILLING CODE 4150-28-P [[Page 19946]] [GRAPHIC] [TIFF OMITTED] TP14AP26.284 [[Page 19947]] [GRAPHIC] [TIFF OMITTED] TP14AP26.285 [[Page 19948]] BILLING CODE 4150-28-C 8. Statutory Authorities a. Medicare Advantage Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of Title XVIII of the Act. In addition, section 1857(e)(1) of the Act explicitly authorizes the addition of reporting requirements by MA organizations as a contract term between the Secretary and a MA organization where not inconsistent with Part C of Title XVIII of the Act and as the Secretary may find necessary and appropriate. The proposal for MA plans to publicly report additional prior authorization metrics for drugs payable under Part B reflects a necessary and appropriate requirement that is consistent with and carries out Part C, as it should enable patients to assess the implementation of the proposals in this rule. A review of these metrics on individual websites may help CMS understand the impact of the proposed requirements, including the effects of using the Prior Authorization API for drugs payable under Part B. These data may also help plans evaluate and modify their operational policies, improve their use of the Prior Authorization API, and determine if any policy updates would be appropriate. b. State Medicaid and CHIP Section 1902(a)(3) of the Act addresses the requirements for the states to provide policies to protect beneficiaries through opportunities for fair hearings when their services are denied or not acted upon with reasonable promptness. Section 1902(a)(19) of the Act underpins timeliness standards and requires Medicaid state plans to provide safeguards necessary to assure that eligibility for Medicaid- covered services will be determined and such services will be provided consistently with simplicity of administration and in the best interests of recipients. We have proposed that state Medicaid FFS programs and Medicaid managed care plans publish additional data about their prior authorization performance specific to drugs, and we rely on the authorities for Medicaid managed care plans under section 1932(c)(2)(A)(i) of the Act, which supports managed care access standards and requires that states that contract with Medicaid MCOs develop and implement a quality assessment and improvement strategy that includes standards for access to care so that covered services are available within reasonable timeframes. For this proposal, CMS would rely on our authority in section 1902(a)(4) of the Act to adopt these standards for PIHPs and PAHPs. This would ensure that the same requirements apply to MCOs, PIHPs, and PAHPs. For CHIP, we propose these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children effectively and efficiently that is coordinated with other sources of health benefits coverage. This provision authorizes us to propose these requirements for CHIP to obtain access to program data for analysis. Such analysis supports improvements in the efficacy of CHIP programs and more efficient administration of services. We expect that the proposal for state CHIP FFS programs to make prior authorization decisions on all drugs no later than 24 hours should improve timeliness and support process improvements for the state, which is consistent with our authorities under section 2101(a) of the Act in that it enhances the efficiency of the CHIP program. Further, as authorized under section 2107(b)(1) of the Act, the proposal to require state CHIP FFS programs and CHIP managed care entities to report prior authorization metrics publicly should also support the states' oversight, evaluation, and administration responsibilities. c. Qualified Health Plan Issuers on the Federally-facilitated Exchanges The proposals to require QHP issuers on the FFEs to provide the specific reason for denial of prior authorizations of drugs when notifying the provider; notify providers of prior authorization decisions for non-drug items and services and drugs, and to do so within specified timeframes; and publish certain metrics on their websites, are authorized by section 1311(e)(1) of the Affordable Care Act. Section 1311(e)(1)(A) of the Affordable Care Act requires that Exchanges only certify plans as QHPs if they meet the requirements for certification promulgated by the Secretary under section 1311(c)(1) of the Affordable Care Act, and section 1311(e)(1)(B) of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines that making available such plans available is in the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates. We are of the view that these proposals are appropriate QHP certification requirements because they strive to expand several key regulatory and patient-protection obligations established under the Affordable Care Act. We are proposing to require QHP issuers on the FFEs to notify providers of prior authorization decisions for non-drug items and services within the same timeframes applicable to other impacted payers, as established in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8878). Specifically, we are proposing to require QHP issuers on the FFEs to notify providers of prior authorization decisions on non-drug items and services as expeditiously as a patient's health condition requires but no later than 7 calendar days after receiving a standard request and no later than 72 hours after receiving an expedited request. If finalized, this proposal would allow enrollees in health plans on the FFEs to receive covered services more quickly, which may improve patient care. We also propose to require that QHP issuers on the FFEs make prior authorization decisions to providers on all drugs as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving a standard request and, as expeditiously as the enrollee's health condition requires, but no later than 24 hours after receiving an expedited request. This proposal to require QHP issuers on the FFEs to provide notice to requesting providers of prior authorization decisions in a shorter timeframe than they are currently required to provide notice to patients of prior authorization decisions should allow providers to more quickly alter treatment plans, including to send updated prescriptions to pharmacies if a prior authorization is denied. We consider the proposal to require QHP issuers on the FFEs to notify the requesting provider of a prior authorization decision within a specific timeframe based on the nature of the request necessary because delays can directly impact a patient's health. Drugs sometimes need to be taken soon after a diagnosis is rendered and often need to be taken consistently and on time for optimal effectiveness. Delays in obtaining and taking medication could lead to a worsening of a patient's condition, create complications, and potentially require more intensive or costly interventions at a later time. With respect to the proposal to require QHP issuers on the FFEs to publish certain metrics on their websites, we believe that, as payers create and analyze prior authorization metrics reports, they would use the data to learn about and improve their own [[Page 19949]] performance in adjudicating prior authorization requests. Additionally, we believe that the public availability of prior authorization decision data would further transparency in the interests of qualified individuals and qualified employers in the state in which the Exchange operates by providing clear information to consumers that they could use when selecting a new plan. Similarly, some providers may find metrics about prior authorization approvals or appeals useful when selecting payer networks. If finalized, publicly reported prior authorization metrics for drugs could enable CMS to assess the implementation of the policies proposed in this rule. Reviewing these metrics on individual websites may help CMS understand the impact of the proposed requirements, including using the Prior Authorization API for drugs. At the same time, the reports could help QHP issuers on the FFEs evaluate and improve their own operational processes. For the reasons stated in the paragraphs in this section above, we have determined that the proposed changes described in sections II.C.2.c. and II.C.3.b. of this proposed rule are in the interests of qualified individuals and qualified employers in the state or states in which an QHP issuer on the FFEs operates.

D. Requirements for Issuers That Offer Small Group Market Qualified

Health Plans on the Federally-Facilitated Small Business Health Options Program Exchanges

1. Introduction

We propose to apply the existing requirements in 45 CFR 156.221, 45 CFR 156.222, and 45 CFR 156.223, which were finalized in the 2020 CMS Interoperability and Patient Access final rule and in the 2024 CMS Interoperability and Prior Authorization final rule (85 FR 25510 and 89 FR 8758), to small group market QHP issuers on the FF-SHOPs. As discussed in section I.B. of this proposed rule, we are also proposing that small group market QHP issuers on the FF-SHOPs be considered impacted payers for purposes of the proposed QHP issuer requirements described throughout this proposed rule.\153\ We emphasize that neither individual market QHP issuers on the SBEs nor small group market QHP issuers on the SBEs are impacted payers and therefore, would not be subject to these proposals. --------------------------------------------------------------------------- \153\ See the following sections for these proposals: II.A.2.a. through II.A.2.c., II.A.3., II.A.4.b.(1). and II.A.4.b.(2)., II.A.4.b.(4). and II.A.4.b.(5)., II.B.3. through II.B.7., II.C.2.c., II.C.3.b. and II.C.3.d., II.C.6. and II.C.7., II.E.1. through II.E.4., II.F.1.b., II.F.2.b., II.F.2.c., II.F.5.a., and II.F.5.b. of this proposed rule. --------------------------------------------------------------------------- For requirements in 45 CFR 156.221 that have already taken effect for issuers offering individual market QHPs on the FFEs, we propose compliance dates in the future for small group market QHP issuers on the FF-SHOPs. For example, we are proposing a compliance date of plan years beginning on or after January 1, 2028 for small group market QHPs on the FF-SHOPs to comply with 45 CFR 156.221(a), whereas the compliance date for individual market QHPs on the FFEs was for plan years beginning on or after January 1, 2021. For requirements in 45 CFR 156.222 and 45 CFR 156.223 that we expect to take effect before this proposed rule can be finalized, we are also proposing separate compliance dates for small group market issuers on the FF-SHOPs that we believe are reasonable. For example, we are proposing compliance dates for plan years beginning on or after January 1, 2028 for the Provider Access and Payer-to-Payer API requirements in 45 CFR 156.222(a) and (b), and the requirement in 45 CFR 156.221(f) to report Patient Access API usage metrics to CMS. We are also proposing compliance dates of October 1, 2027 for the Prior Authorization API requirements in 45 CFR 156.223(b) and the requirement in 45 CFR 156.223(a) to provide a reason to providers for denying a prior authorization for non-drug items and services. We believe that the proposed compliance dates are the earliest dates that are feasible to implement proposals for small group market QHP issuers given the rulemaking timeline. We are proposing the same compliance dates of October 1, 2027 for certain proposals in this rule that would newly apply to both small group market QHPs on the FF-SHOPs and individual market QHPs on the FFEs. Those proposals include the requirements to implement and maintain certain HL7[supreg] FHIR[supreg] and NCPDP standards to support electronic prior authorization for drugs in 45 CFR 156.223(b)(1)(iii) and (e), as well as notice requirements that create prior authorization decision timeframes in 45 CFR 156.223(i). We are also proposing the same compliance dates, beginning in 2028, for proposals in this rule that would newly apply to both small group market QHPs on the FF-SHOPs and individual market QHPs on the FFEs regarding reporting API usage metrics to CMS in 45 CFR 156.222(a)(6) and (b)(8) and 45 CFR 156.223(e) and publicly reporting prior authorization metrics for drugs in 45 CFR 156.223(d). We did not apply these policies to small group market QHP issuers on the FF-SHOPs in previous rulemaking due to concerns about placing burden on these issuers (85 FR 25553 and 89 FR 8767). However, based on additional research, all issuers that offer small group market QHPs on the FF-SHOPs as of the time of this proposal also offer individual market QHPs on the FFEs. Therefore, we anticipate that the burden for these issuers to implement these policies for their small group market QHPs on the FF-SHOPs should be relatively low because these issuers are already required to implement the policies for their individual market QHPs on the FFEs. Additionally, we believe that enrollees in small group market QHPs on the FF-SHOPs should have access to the benefits of health data transparency discussed in previous rulemaking such as better coordinated care and the ability to make more informed decisions about their care (85 FR 25523 and 89 FR 8820). If these policies are finalized as proposed, and these considerations change in the future-- for example, if an issuer that does not offer one or more individual market QHPs on the FFEs newly enters an FF-SHOP, then under this proposal, we could consider whether to provide an exception to one or more of these requirements through our established process, as described in section II.D.7. of this proposed rule, during the annual QHP certification process, if it is appropriate based on the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates and an exception is warranted to permit the issuer to offer QHPs through the FFE.\154\ --------------------------------------------------------------------------- \154\ For more information on interoperability and QHP certification, including further detail on the exceptions process, see https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability. Discussion of this topic is also available in the 2024 CMS Interoperability and Prior Authorization final rule preamble: 89 FR 8906. ---------------------------------------------------------------------------

2. General API Requirements Background

In the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules, we finalized general API requirements that apply across the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs.\155\ We are now proposing to [[Page 19950]] require small group market QHP issuers on the FF-SHOPs to implement these requirements, which already apply to individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- \155\ We discuss final requirements in the 2020 CMS Interoperability and Patient Access final rule and the 2024 CMS Interoperability and Prior Authorization final rule for all impacted payers, but for ease of reference, we are only providing citations to these requirements for individual market QHP issuers on the FFEs. See 45 CFR 156.221(a) for the Patient Access API, 45 CFR 156.222(a) for the Provider Access API, 45 CFR 156.222(b) for the Payer-to- Payer API, and 45 CFR 156.223(b) for the Prior Authorization API for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- The previously finalized rules required impacted payers, including individual market QHP issuers on the FFEs, to implement and maintain API technology conformant with certain applicable standards adopted by ONC in 45 CFR 170.215.\156\ Table 3 in this proposed rule lists the required and recommended standards and IGs to support API implementation, including updates proposed in this rulemaking. Impacted payers are permitted to use an updated version of a required standard for the APIs under certain conditions. Specifically, payers may use updated versions of standards in 45 CFR 170.213 and 45 CFR 170.215 if the following conditions are met: (1) the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; (2) the updated version of the standard does not disrupt an end user's ability to access the required data via that API; and (3) the updated standard is not prohibited by law. Payers may also use an updated version if required by other applicable law.\157\ --------------------------------------------------------------------------- \156\ See 45 CFR 156.221(c) for the Patient Access API, 45 CFR 156.222(a)(1)(ii) for the Provider Access API, 45 CFR 156.222(b)(1)(ii) for the Payer-to-Payer API, and 45 CFR 156.223(b) for the Prior Authorization API. \157\ See 45 CFR 156.221(c)(4). --------------------------------------------------------------------------- To ensure that the APIs function properly, impacted payers must conduct routine testing and monitoring and perform updates as appropriate. That includes assessments to verify that the API is fully and successfully implementing privacy and security features, such as those required for compliance with the HIPAA Privacy Rule and ``Security Standards for the Protection of Electronic Protected Health Information'' (68 FR 8334) (hereinafter referred to as the ``HIPAA Security Rule'') which appeared in the Federal Register on February 20, 2003 (45 CFR part 160 and subparts A and C of part 164), 42 CFR part 2, and other applicable laws protecting privacy and security of individually identifiable health data.\158\ --------------------------------------------------------------------------- \158\ See 45 CFR 156.221(c)(2). --------------------------------------------------------------------------- As established in the 2020 CMS Interoperability and Patient Access final rule, to ensure that developers have the information necessary to interact with the APIs, impacted payers must make publicly accessible, by posting on their website or via publicly accessible hyperlink(s), complete accompanying documentation. That documentation must contain: (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/ structures, exceptions and exception handling methods and their returns; (2) the software components and configurations an app must use in order to successfully interact with the API and process its response(s); and (3) all applicable technical requirements and attributes necessary for an app to be registered with any authorization server(s) deployed in conjunction with the API.\159\ --------------------------------------------------------------------------- \159\ See 45 CFR 156.221(d). --------------------------------------------------------------------------- As established in the 2020 CMS Interoperability and Patient Access and the 2024 CMS Interoperability and Prior Authorization final rules, the only reason impacted payers may deny an app or developer API access is if it would present an unacceptable level of risk to the security of PHI on the payer's system.\160\ These risks include, for example, insufficient authentication or authorization controls, poor encryption, or reverse engineering. The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers.\161\ --------------------------------------------------------------------------- \160\ See 45 CFR 156.221(e)(1). \161\ See 45 CFR 156.221(e)(2). ---------------------------------------------------------------------------

3. Patient Access API

a. Background As discussed in the 2020 CMS Interoperability and Patient Access final rule, one critical issue in the U.S. health care system is that people cannot easily access their health information in interoperable forms. Patients and the health care providers caring for them are often presented with an incomplete picture of their health and care as pieces of their information are stored in various, unconnected systems and do not accompany them to every care setting (85 FR 25511). There are numerous benefits associated with individuals having access to their health data through a method that is built upon widely used standards. In the 2020 CMS Interoperability and Patient Access final rule, we finalized requirements for impacted payers, including individual market QHP issuers on the FFEs, to implement and maintain a Patient Access API conformant with certain FHIR standards that permit third-party apps to retrieve certain health information, with the approval and at the direction of a current individual enrollee or the enrollee's personal representative (85 FR 25558). The ability to easily obtain, use, and share claims, encounter, and other health data enables patients to more effectively and easily use the health care system. Providing this ability to enrollees in all QHPs on the FFEs, including small group market QHPs on the FF-SHOPs, would empower more people to access their health information in a manner best suited for them. b. Proposals In the 2020 CMS Interoperability and Patient Access final rule, we finalized a requirement that individual market QHP issuers on the FFEs must implement and maintain a Patient Access API conformant with certain FHIR standards that permit third-party apps to retrieve certain health information, with the approval and at the direction of a current individual enrollee or the enrollee's personal representative.\162\ Starting with plan years beginning on or after January 1, 2021, impacted payers, including individual market QHP issuers on the FFEs, have been required to make available any claims and encounter data and all data classes and data elements included in a content standard in 45 CFR 170.213 (USCDI)\163\ with a date of service on or after January 1, 2016.\164\ Those data must be made available no later than 1 business day after the claim is processed or the data are received by the individual market QHP issuers on the FFEs.\165\ --------------------------------------------------------------------------- \162\ See 45 CFR 156.221(a). \163\ See 45 CFR 156.221(b)(1)(iii). \164\ See 45 CFR 156.221(i)(1). \165\ See 45 CFR 156.221(b)(1)(iii). --------------------------------------------------------------------------- Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers would be required to make available through the Patient Access API certain data about prior authorizations for non-drug items and services that they maintain, beginning in 2027.\166\ The required prior authorization information includes the prior authorization status; the date the prior authorization was approved or denied; the date or circumstance under which the prior authorization ends; the non-drug items and services approved; if denied, a specific reason why the request was denied; and related structured administrative and clinical documentation submitted by a provider.\167\ That prior authorization information must be accessible no later than 1 business day after the payer receives a prior authorization request, must be updated no later than 1 business day after any status change, [[Page 19951]] and must continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.\168\ --------------------------------------------------------------------------- \166\ See 45 CFR 156.221(b)(1)(iv). \167\ See 45 CFR 156.221(b)(1)(iv)(A). \168\ See 45 CFR 156.221(b)(1)(iv)(B). --------------------------------------------------------------------------- To inform and assist patients who want to access their health information via the Patient Access API, the 2020 CMS Interoperability and Patient Access final rule also requires impacted payers to provide, in an easily accessible location on their public websites and through other appropriate mechanisms that they ordinarily use to communicate with current and former enrollees, educational resources in non- technical, simple, and easy-to-understand language. These resources must explain at a minimum: (1) general information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an app including secondary uses of data, and the importance of understanding the security and privacy practices of any app to which they would entrust their health information; and (2) an overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how to submit a complaint to those entities.\169\ --------------------------------------------------------------------------- \169\ See 45 CFR 156.221(g). --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we also finalized a requirement that, beginning in 2026, impacted payers, including individual market QHP issuers on the FFEs, must annually report Patient Access API metrics to CMS in the form of aggregated, de-identified data. Specifically, individual market QHP issuers on the FFEs must report at the issuer level the following metrics: (1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. The 2024 CMS Interoperability and Prior Authorization final rule requires individual market QHP issuers on the FFEs to report the previous calendar year's metrics to CMS by March 31 following any year that they offer an individual market QHP on the FFEs.\170\ --------------------------------------------------------------------------- \170\ See 45 CFR 156.221(f). --------------------------------------------------------------------------- We are now proposing to apply each of these requirements to small group market QHP issuers on the FF-SHOPs to report data from plan years beginning on or after January 1, 2028, with reporting deadlines beginning in 2029. For reporting on Patient Access API usage, we are proposing to require small group market QHP issuers on the FF-SHOPs to annually report the metrics in 45 CFR 156.221(f) at the issuer level in the form and manner and within the timeframes specified by the Secretary. That would allow flexibility for CMS to include API usage metrics reporting within specific deadlines set for the QHP certification process, which in practice is generally the final deadline for the QHP certification process that takes place the following year.\171\ We are proposing to apply this requirement to small group market QHP issuers on the FF- SHOPs for plan years beginning on or after January 1, 2028, following each plan year that the QHP issuer offers a small group market QHP on the FF-SHOP. For example, QHP issuers on the FF-SHOPs would be required to submit metrics from plan years in 2028 as part of the QHP certification process during 2029 for plan years in 2030. This is consistent with our proposal to modify the Patient Access API usage reporting deadline from an annual March 31 date, as further discussed in section II.F.2.b. of this proposed rule. We believe it is also appropriate to align the reporting deadline for small group market QHP issuers on the FF-SHOPs with the annual QHP certification process for the reasons discussed in section II.F.2.b., and so that issuers do not have to adhere to different sets of deadlines for small group market QHPs on the FF-SHOPs and individual market QHPs on the FFEs, which could cause administrative burden. --------------------------------------------------------------------------- \171\ Information about QHP certification, including deadlines can be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline. --------------------------------------------------------------------------- In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

4. Provider Access API

a. Background While the Patient Access API was a significant first step toward sharing individual patient health information with providers, in the 2024 CMS Interoperability and Prior Authorization final rule we explained our belief that it would benefit patients if payers were required to make patient data directly available to providers via an API that is conformant with certain FHIR standards. In the normal course of business, many providers already maintain EHRs and share data for a variety of purposes authorized by the patient and/or existing law. Therefore, in the 2024 CMS Interoperability and Prior Authorization final rule, we required impacted payers to implement and maintain a FHIR API that makes patient data available to providers who have a contractual relationship with the payer and a treatment relationship with the patient.\172\ The Provider Access API has the potential to allow payers to build upon their existing systems and processes to enhance access to patient data, while continuing to protect patient privacy and data security (89 FR 8787). --------------------------------------------------------------------------- \172\ See 45 CFR 156.222(a)(1). --------------------------------------------------------------------------- b. Proposals In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a policy that, beginning in 2027, impacted payers, including individual market QHP issuers on the FFEs, must implement and maintain a Provider Access API to make available patient data upon request from an in-network provider if all the following conditions are met: (1) the payer authenticates the identity of the provider that requests access and attributes the patient to the provider under the required attribution process; (2) the patient does not opt out of the Provider Access API; and (3) disclosure of the data is not prohibited by law. Individual market QHP issuers on the FFEs must make those data available no later than 1 business day after receiving a request from such a provider.\173\ --------------------------------------------------------------------------- \173\ See 45 CFR 156.222(a)(2). --------------------------------------------------------------------------- The data that impacted payers must make available via the Provider Access API include claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard in 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service after January 1, 2016. The required prior authorization information includes the prior authorization status; the date the prior authorization was approved or denied; the date or circumstance under which the prior authorization ends; the non- drug items and services approved; if denied, a specific reason why the request was denied; and related structured administrative and clinical documentation submitted by a provider. That prior authorization information must be accessible no later than 1 business day after the individual market QHP issuer on the FFE receives a prior authorization request, must be updated no later than 1 business day after any [[Page 19952]] status change, and must continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.\174\ --------------------------------------------------------------------------- \174\ See 45 CFR 156.222(a)(2). --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement that impacted payers, including individual market QHP issuers on the FFEs, beginning in 2027, must establish and maintain an attribution process to associate patients with their in-network providers to ensure that the payer only sends a patient's data to providers who have a treatment relationship with that patient.\175\ We also finalized a requirement for impacted payers, including individual market QHP issuers on the FFEs, to provide on their website and through other appropriate provider communications, information in plain language explaining the process for requesting patient data using the Provider Access API. The resources must include information about how to use the payer's attribution process to associate patients with their providers.\176\ --------------------------------------------------------------------------- \175\ See 45 CFR 156.222(a)(3). \176\ See 45 CFR 156.222(a)(5). --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a policy that impacted payers, including individual market QHP issuers on the FFEs, beginning in plan years that start on or after January 1, 2027, must establish and maintain a process for patients to opt out of data exchange via the Provider Access API and that allows patients to change their permission at any time.\177\ This process must be made available to enrollees before the first date on which the payer makes their information available via the Provider Access API, and at any time during their enrollment with the payer.\178\ Impacted payers, including individual market QHP issuers on the FFEs, are also required to provide educational resources in plain language to their patients about the Provider Access API.\179\ Those resources must include information about the benefits of API data exchange with providers; patients' opt out rights; and instructions for both opting out of data exchange and for subsequently opting in, should patients choose to do so.\180\ Impacted payers must make this information available to patients before the first date on which the payer makes their information available via the Provider Access API, no later than 1 week after the start of coverage, and at least annually.181 182 These resources must also be available in an easily accessible location on payers' public websites (89 FR 8817- 8818).\183\ --------------------------------------------------------------------------- \177\ See 45 CFR 156.222(a)(4)(i). \178\ See 45 CFR 156.222(a)(4)(i). \179\ See 45 CFR 156.222(a)(4)(ii). \180\ See 45 CFR 156.222(a)(4)(ii). \181\ As discussed in the 2024 CMS Interoperability and Prior Authorization final rule, where coverage starts prospectively, the deadline would be based on the coverage start date (also known as the coverage effective date). In the case of retroactive coverage, to avoid a deadline in the past, the deadline for the payer to provide the required information about the Payer-to-Payer API, request identifying information about previous/concurrent payer(s), and an opt in would be based on the date that the payer gets patient information and makes the patient's coverage effective (89 FR 8833). \182\ See 45 CFR 156.222(a)(4)(ii). \183\ See 45 CFR 156.222(a)(4)(ii)(D). --------------------------------------------------------------------------- We are now proposing to apply each of these requirements to small group market QHP issuers on the FF-SHOPs for plan years beginning on or after January 1, 2028. We believe that this proposal's compliance date provides sufficient time for those issuers to incorporate their small group market QHPs on the FF-SHOPs into their previous API implementation for individual market QHPs on the FFEs given that small group market QHP issuers on the FF-SHOPs also offer individual market QHPs on the FFEs. However, we solicit comment on whether this is the case. In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

5. Payer-To-Payer API

a. Background In addition to sharing data with their providers, having a patient's data follow them when they change payers, or shared when they have health insurance coverage through multiple payers, can have a multitude of benefits for patient care. For example, a payer receiving data when a new patient enrolls can better support the patient through care coordination related to a chronic condition or ongoing treatment needs. If necessary, patient data can give payers the information they need to assign a case manager or help the patient find providers in their new network. Data exchange among payers--specifically, sending patient data from a patient's previous payer to their new one--is a powerful way to ensure that data follows patients through the health care system and improves care continuity, and helps patients to maintain access to their record over time. In the 2024 CMS Interoperability and Prior Authorization final rule, we required impacted payers, including individual market QHP issuers on the FFEs, to build a Payer-to-Payer API, with certain standards that would facilitate patient data exchange at the start of coverage and between concurrent payers.\184\ --------------------------------------------------------------------------- \184\ See 45 CFR 156.222(b). --------------------------------------------------------------------------- b. Proposals In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a policy that, for plan years beginning on or after January 1, 2027, individual market QHP issuers on the FFEs must implement and maintain a Payer-to-Payer API to exchange patient health information when an enrollee changes payers or has concurrent coverage with two or more payers if the following conditions are met: (1) the payer that requests access has its identity authenticated and includes an attestation with the request that the patient is enrolled with the payer and has opted into the data exchange; and (2) the exchange is not prohibited by law. Impacted payers, including individual market QHP issuers on the FFEs, must make those data available no later than 1 business day after receiving a request from another payer that meets those requirements.\185\ --------------------------------------------------------------------------- \185\ See 45 CFR 156.222(b)(5). --------------------------------------------------------------------------- The data that impacted payers must make available via the Payer-to- Payer API include claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard in 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service within 5 years of the request. The required prior authorization information does not include denied prior authorization requests. It does include the prior authorization status, the date the prior authorization was approved, the date or circumstance under which the prior authorization ends, the non-drug items and services approved, and related structured and unstructured administrative and clinical documentation submitted by a provider. This prior authorization information must be accessible no later than 1 business day after the impacted payer receives a prior authorization request, must be updated no later than 1 business day after any status change, and must continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.\186\ --------------------------------------------------------------------------- \186\ See 45 CFR 156.222(b)(4). --------------------------------------------------------------------------- In the 2024 CMS Interoperability and Prior Authorization final rule, we also [[Page 19953]] finalized requirements that, for plan years beginning on or after January 1, 2027, impacted payers, including individual market QHP issuers on the FFEs, must establish and maintain processes to request that an enrollee opt into the payer to payer data exchange and submit information about their previous and concurrent payers.\187\ Those processes must be in place for current enrollees by the compliance date of plan years beginning on or after January 1, 2027, and then, for new enrollees, no later than 1 week after the coverage start date, or, if coverage has a retroactive start date, no later than 1 week after the coverage is effectuated (89 FR 8855).\188\ In addition, enrollees must be permitted to change their preference at any time.\189\ If an enrollee does not respond or additional information is necessary, the payer must make reasonable efforts to engage with the enrollee to collect this information.\190\ By that compliance date, impacted payers, including individual market QHP issuers on the FFEs, are also required to provide educational resources in plain language to their patients about the Payer-to-Payer API.\191\ Those resources must include the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so.\192\ Impacted payers must make this information available to patients when requesting an enrollee's permission for Payer-to-Payer API data exchange and at least annually thereafter.\193\ These resources must also be available in an easily accessible location on payers' public websites.\194\ --------------------------------------------------------------------------- \187\ See 45 CFR 156.222(b)(2). \188\ See 45 CFR 156.222(b). \189\ See 45 CFR 156.222(b)(2). \190\ See 45 CFR 156.222(b)(2)(ii). \191\ See 45 CFR 156.222(b)(7). \192\ See 45 CFR 156.222(b)(7). \193\ See 45 CFR 156.222(b)(7)(i)-(ii). \194\ See 45 CFR 156.222(b)(7)(iii). --------------------------------------------------------------------------- If an enrollee opts in and provides sufficient information about their previous or concurrent payers, then impacted payers, including individual market QHP issuers on the FFEs, must request the specified data from those payers no later than 1 week after they have sufficient identifying information about previous or concurrent payers and the enrollee has opted in.\195\ In addition, at an enrollee's request, payers must make the same request within 1 week.\196\ Any data received in response to such a request must be incorporated into the payer's records about the enrollee.\197\ In addition, if an enrollee has concurrent payers, the payer must request data from all known concurrent payers at least quarterly and must respond to such a request from other concurrent payers within 1 business day.\198\ --------------------------------------------------------------------------- \195\ See 45 CFR 156.222(b)(4)(iv)(A). In the 2024 CMS Interoperability and Prior Authorization final rule, in which this requirement was finalized for impacted payers including individual market QHP issuers on the FFEs, CMS noted that ``sufficient information'' refers to information about patients' previous/ concurrent payer(s) that would allow them [the payer] to identify and request data from those other payers. CMS left the process of gathering this information open for payers to implement in the least burdensome, most practical way, and noted payers often have established points of contact and existing processes that can apply here; for example, that they use to identify concurrent payers to facilitate coordination of coverage and Medicare Secondary Payer/ Third Party Liability administration (89 FR 8834-8835). \196\ See 45 CFR 156.222(b)(4)(iv)(B). \197\ See 45 CFR 156.222(b)(4)(v). \198\ See 45 CFR 156.222(b)(6). --------------------------------------------------------------------------- We are now proposing to apply each of these requirements to small group market QHP issuers on the FF-SHOPs for plan years beginning on or after January 1, 2028. We believe that this proposal's compliance date provides sufficient time for those issuers to incorporate their small group market QHPs on the FF-SHOPs into their previous API implementation for individual market QHPs on the FFEs given that small group market QHP issuers on the FF-SHOPs also offer individual market QHPs on the FFEs. However, we solicit comment on whether this is the case. In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

6. Prior Authorization API and Prior Authorization Process

a. Background In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement for impacted payers, including individual market QHP issuers on the FFEs, to implement and maintain a Prior Authorization API to improve the prior authorization process between payers and providers for non-drug items and services.\199\ This Prior Authorization API would streamline the prior authorization process for providers and for office staff who support the prior authorization process by automating certain prior authorization tasks, thereby mitigating some of the obstacles of the existing prior authorization process and expediting approval of needed care or explaining why a submitted request is not sufficient. The API would also allow a provider to query the payer's system to determine whether a prior authorization was required for certain non-drug items and services and identify documentation requirements. It would automate the compilation of necessary data for populating the electronic prior authorization request and enable payers to provide the status of the prior authorization decision, including whether the request has been approved or denied. The 2024 CMS Interoperability and Prior Authorization final rule also included requirements that payers include a specific reason for denial of a prior authorization request in their responses to providers,\200\ and publicly report certain prior authorization metrics.\201\ --------------------------------------------------------------------------- \199\ See 45 CFR 156.223(b). \200\ See 45 CFR 156.223(a). \201\ See 45 CFR 156.223(c). --------------------------------------------------------------------------- The 2022 CMS Interoperability and Prior Authorization proposed rule and the 2024 CMS Interoperability and Prior Authorization final rule both discussed the current burden associated with prior authorization processes and explained how making the prior authorization process electronic would reduce the time and burden, expediting patients' access to care and allowing providers to put time back into direct patient care (87 FR 76286 and 89 FR 8862). Requiring all QHP issuers on the FFEs, including small group market QHP issuers on the FF-SHOPs, to adopt electronic prior authorization processes for non-drug items and services would provide these benefits to more patients, and potentially help more providers and administrative staff to mitigate burnout. Including small group market QHP issuers on the FF-SHOPs in requirements to publicly report certain prior authorization metrics and to provide a reason for denial of prior authorization in responses to providers would improve understanding of prior authorization processes' impact on more enrollees and help ensure transparency for more prior authorization requests. The 2024 CMS Interoperability and Prior Authorization final rule also required impacted payers other than individual market QHP issuers on the FFEs (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities), to respond to prior authorization requests within shorter timeframes than they were previously subject to (89 FR 8897). We are proposing to apply these requirements, and additional requirements related to drug prior authorization, to all QHP issuers on the FFEs, including individual market QHP issuers on the FFEs and small group market QHP [[Page 19954]] issuers on the FF-SHOPs, in this rule. For discussion of those proposals please see section II.C.3. of this proposed rule. b. Proposals In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized a requirement for individual market QHP issuers on the FFEs to implement and maintain a Prior Authorization API to improve the prior authorization process between payers and providers for non- drug items and services.\202\ The purpose of the API is to streamline the process and ensure that payers use technology to provide more useful information about when and how to obtain a prior authorization and the status of an approved or denied prior authorization (89 FR 8897). --------------------------------------------------------------------------- \202\ See 45 CFR 156.223(b). --------------------------------------------------------------------------- We finalized a policy that, for plan years beginning on or after January 1, 2027, individual market QHP issuers on the FFEs must implement and maintain a Prior Authorization API that--(1) is populated with the payer's list of non-drug items and services that require prior authorization; (2) can identify all documentation required for approval of any non-drug items or services that require prior authorization; (3) supports a HIPAA-compliant prior authorization request and response; and (4) communicates whether the payer approves the prior authorization request (and the date or circumstance under which the authorization ends), denies the prior authorization request (with a specific reason), or requests more information.\203\ --------------------------------------------------------------------------- \203\ See 45 CFR 156.223(b). --------------------------------------------------------------------------- In addition, we finalized two process requirements for impacted payers, including individual market QHP issuers on the FFEs, to improve the prior authorization process generally. We finalized a policy that beginning January 1, 2026, if an impacted payer denies a prior authorization request (excluding a request for coverage of drugs as defined for QHPs on the FFEs in 45 CFR 156.221(b)(1)(v)), the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information.\204\ --------------------------------------------------------------------------- \204\ See 45 CFR 156.223(a). --------------------------------------------------------------------------- We also finalized a requirement that beginning in 2026, following each year it offers an individual market QHP on the FFEs, an individual market QHP issuer on the FFE must report prior authorization data, excluding data on drugs as defined in 45 CFR 156.221(b)(1)(v), at the issuer level by March 31. The individual market QHP issuer on the FFE must make the following data from the previous calendar year publicly accessible by posting them on its website: A list of all non-drug items and services that require prior authorization. The percentage of standard prior authorization requests that were approved, aggregated for all non-drug items and services. The percentage of standard prior authorization requests that were denied, aggregated for all non-drug items and services. The percentage of standard prior authorization requests that were approved after appeal, aggregated for all non-drug items and services. The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all non-drug items and services. The percentage of expedited prior authorization requests that were approved, aggregated for all non-drug items and services. The percentage of expedited prior authorization requests that were denied, aggregated for all non-drug items and services. The average and median time that elapsed between the submission of a request and a determination by the individual market QHP issuer on the FFE, for standard prior authorizations, aggregated for all non-drug items and services. The average and median time that elapsed between the submission of a request and a decision by the individual market QHP issuer on the FFE for expedited prior authorizations, aggregated for all non-drug items and services.\205\ --------------------------------------------------------------------------- \205\ See 45 CFR 156.223(c). --------------------------------------------------------------------------- We are now proposing to apply each of these requirements to small group market QHP issuers on the FF-SHOPs. Specifically, we propose to amend the requirements in 45 CFR 156.223(a) to respond to providers with a reason for denial and in 45 CFR 156.223(b) to implement and maintain a Prior Authorization API to include small group market QHP issuers on the FF-SHOPs with a compliance date of October 1, 2027. In addition, we propose to amend the requirement in 45 CFR 156.223(c) to publicly report prior authorization metrics to apply it to small group market QHP issuers on the FF-SHOPs beginning in 2028 for calendar year 2027 data. Given that those issuers have met or are working on meeting these proposed requirements for their individual market QHPs on the FFEs, we believe that the proposed compliance dates provide sufficient time to extend their technology solutions and business processes to their small group market QHPs on the FF-SHOPs. However, we solicit comment on whether this is the case. In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs.

7. Exceptions

a. Background The 2020 CMS Interoperability and Patient Access final rule and the 2024 CMS Interoperability and Prior Authorization final rule finalized an exceptions process for individual market QHP issuers on the FFEs that are not able to implement the Patient Access API. An individual market QHP issuer on the FFE can apply for an exception for a particular plan year by submitting a narrative justification as part of its QHP certification application that describes the reasons why it cannot reasonably satisfy the requirements for the applicable plan year, the effect of non-compliance upon providers and enrollees, the current or proposed means of providing the required information to providers or other payers, and solutions and a timeline to achieve compliance with the requirements.\206\ --------------------------------------------------------------------------- \206\ See 156.221(h) for the Patient Access API, 45 CFR 156.222(c) for the Provider Access and Payer-to-Payer APIs, and 45 CFR 156.223(d) for the Prior Authorization API. --------------------------------------------------------------------------- As discussed in the 2024 CMS Interoperability and Prior Authorization final rule, we believe that certifying only health plans that implement these APIs is generally in the interests of enrollees (89 FR 8786 and 8820). However, as also discussed in that final rule, while some individual market QHP issuers on the FFEs are in a position to implement the updates that the rule requires, a wide range of issuers participate in the FFEs and vary in terms of available resources to adopt these requirements (89 FR 8906). Plan offerings can also vary by region and even by county, with some areas in the FFEs having more limited plan offerings than others. Therefore, this exceptions process exists as a safeguard to prevent potential enrollees from going without access to QHP coverage because an issuer is unable to implement these APIs. b. Proposals We propose to apply the same exceptions process to the proposed requirements for small group market [[Page 19955]] QHP issuers on the FF-SHOPs as currently applies to individual market QHP issuers on the FFEs per 45 CFR 156.221(h), including as cross referenced in 45 CFR 156.222(c) and 45 CFR 156.223(d). As we discussed in the 2024 CMS Interoperability and Prior Authorization final rule, we anticipate that the volume of requests for exceptions should be low based on our experience with individual market QHP issuers on the FFEs, among which exception requests are uncommon, and a number of requests have specified that the issuer intends to comply within the upcoming plan year even though they may not be able to do so by January 1 of the upcoming year (89 FR 8906). As also discussed in the 2020 CMS Interoperability and Patient Access final rule, with regard to individual market QHPs on the FFEs, we believe that it is important to provide the FFEs with the option to waive this requirement on a limited basis, for example, if not certifying the issuer's QHP or QHPs would result in consumers having few or no plan options in certain areas (85 FR 25552). We believe that this rationale also applies to small group market QHPs on the FF-SHOPs--that is, that the FF-SHOPs should have the option to consider coverage availability for qualified employers and their employees as a factor when determining whether to certify an FF- SHOP plan notwithstanding its failure to comply with requirements for the Patient Access API in 45 CFR 156.221, the Provider and Payer-to- Payer APIs in 45 CFR 156.222(a) and (b), or the Prior Authorization API in 45 CFR 156.223(b). In summary, we request comment on our proposal to apply the policies and their compliance dates described previously, and in the CFR citations listed in Table 7, to small group market QHP issuers on the FF-SHOPs. BILLING CODE 4150-28-P [[Page 19956]] [GRAPHIC] [TIFF OMITTED] TP14AP26.286 [[Page 19957]] BILLING CODE 4150-28-C

1. API Endpoints

In the 2020 CMS Interoperability and Patient Access final rule, we finalized a requirement that impacted payers must implement and maintain Patient Access and Provider Directory APIs (85 FR 25513). In the 2024 CMS Interoperability and Prior Authorization final rule, we finalized requirements that impacted payers must also implement and maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs (89 FR 8759). During those rulemakings, we received numerous public comments that emphasized the importance of a centralized location to discover payers' API endpoints, which would realize the full potential of these interoperability APIs (85 FR 25562 and 89 FR 8767). An API's endpoint is the digital location, often a URL or IP address, that is set up to accept secure queries to the API. Developers need to know an API's endpoint to configure their apps to interact with the API. Without properly structured and functioning endpoints, an API will not work as intended. APIs can be set up with multiple endpoints, each used for specific data or purposes, or a single endpoint that offers different data depending on how it is queried. We have received public feedback that a centralized listing of impacted payers' API endpoints would significantly improve the ability of payers, providers, patients, and developers to use the interoperability APIs (89 FR 8767). Various entities within the health care system need to have information about payers' API endpoints to achieve the envisioned ecosystem of data exchange via the interoperability APIs. For the Patient Access API, app developers must connect to payers' API endpoints for patients to access their data maintained by that payer. For the Provider Access API, EHR developers must configure providers' EHRs or other health IT to query payers' API endpoints to retrieve patient information maintained by that payer. To use the Payer-to-Payer API, payers must locate patients' previous or concurrent payers' API endpoints in order to send a request for patient data, as required in the 2024 CMS Interoperability and Prior Authorization final rule. For the Prior Authorization API, providers must be able to find the correct payer API endpoint to submit electronic prior authorization requests. Similarly, for the Provider Directory API, third-party developers and health care entities need discoverable endpoints to create innovative apps that help patients find in-network providers and enable care coordination between providers, making centralized endpoint reporting essential for realizing the full potential of publicly accessible provider directory information. Stakeholder feedback from our 2019 CMS Interoperability and Patient Access proposed rule, 2020 CMS Interoperability and Patient Access final rule, 2022 CMS Interoperability and Prior Authorization proposed rule, and 2024 CMS Interoperability and Prior Authorization final rule demonstrates that endpoint discovery remains a significant implementation challenge, with multiple commenters requesting a centralized directory and noting that third-party apps currently struggle with implementation barriers when working with payers. Finding API endpoints individually in myriad locations could be a significant task for app developers, EHR developers, providers, and payers, because without specific requirements, those endpoints are unlikely to be listed or discoverable in a standardized manner. While payers may have some incentive to make their endpoints discoverable, market dynamics may create barriers to voluntary standardization. For example, individual payers may invest resources into comprehensive endpoint discovery while competitors benefit without making similar investments or competitive considerations, which could lead some payers to maintain integration complexity. As part of our oversight and compliance process, CMS has engaged in exercises to discover endpoints from a sampling of impacted payers. Our own work was heavily manual, and we have experienced first-hand that endpoints are listed in a wide variety of locations and formats, including PDFs, from which automated data retrieval is particularly difficult. Instead, we believe it would help everyone in the health care industry for CMS to collect API endpoints and make them publicly available in a standardized format that can easily be accessed and used by app developers, EHR developers, providers, and payers. Furthermore, if payers' API endpoints have to be discovered individually by developers, or entities that want to use the API, the endpoint is more likely to be hard coded into the software systems used by those developers or entities. Individual endpoint discovery is likely to create a manual, resource-intensive process where developers must research each payer's documentation, extract endpoint information, and integrate it directly into their code. The alternative--building a dynamic endpoint discovery system--requires industry-wide coordination and significant development resources that many organizations cannot justify, making individual developer hard coding the more practical, albeit less flexible, solution. Once endpoints are hard coded, maintenance becomes increasingly burdensome, as developers must manually monitor hundreds of payers for changes, modify code, test, and redeploy systems for each endpoint update. Developers may not realize that an endpoint has changed until they receive reports that their software is no longer successfully connecting to an API, at which point they would have to push software updates. This process could take days or weeks, during which API integrations may fail and end users may experience service disruptions. This creates operational challenges for all entities that depend on API access; entities may need to wait for software updates to restore connectivity and access accurate data, potentially causing delays in patient care, data exchange, and administrative processes. Providers using EHRs, health systems relying on integration platforms, and payers using third-party software solutions would all experience service interruptions when hard-coded endpoints become outdated, regardless of whether they maintain in-house development capabilities. Instead, a centralized registry could create greater flexibility and allow for more timely endpoint data availability. Software could make a call to that registry and, with appropriate identifying data, find the latest information about a payer's API endpoint. The software could then automatically use that information to call the payer's API without manual intervention by the developer or entity making the request. Such a process could be implemented into health apps (for the Patient Access and Provider Directory APIs), EHRs or other provider systems (for the Provider Access, Prior Authorization, and Provider Directory APIs), and payers' systems (for the Payer-to-Payer API). Therefore, we are proposing to require, in the CFR citations listed in Table 8, impacted payers to report to CMS their API endpoints for each required interoperability API unless the impacted payer is a state Medicaid or CHIP FFS program that has been granted an extension or a QHP issuer on the FFEs that has been granted an exception from implementing any or all of the [[Page 19958]] interoperability APIs.\207\ To ensure the standardization of payer endpoints, we are proposing to require impacted payers to report their API endpoints as an Endpoint Resource, as defined by an unexpired version of the Health Level Seven (HL7[supreg]) FHIR[supreg] standard adopted in 45 CFR 170.215(a). We are proposing that impacted payers would be required to initially report their API endpoints no later than 60 days after the effective date of a final rule. In future years, we are proposing that new impacted payers would be required to report this information no later than 60 days before they begin covering patients under the applicable CMS program. Thereafter, impacted payers would be required to report changes to CMS within 1 week of any changes to their API endpoint(s) and verify every 12 months that there have been no changes and their data are accurate. API endpoints support time- sensitive health care operations including prior authorization requests, care coordination, and patient data access. Outdated endpoints immediately disrupt these critical functions; the underlying statutory requirements for timely care, efficient operations, and patient access cannot be met with stale endpoint information. Verification every 12 months ensures ongoing accuracy of the centralized registry, compliance with existing statutory obligations for current information, and efficient program administration, through reliable endpoint data. --------------------------------------------------------------------------- \207\ For the Patient Access API, see 45 CFR 156.221(h) for QHP issuers on the FFEs. For the Provider Access and Payer-to-Payer APIs, see 42 CFR 431.61(c)(1)-(2) for state Medicaid FFS programs, 42 CFR 457.731(c)(1) and (2) for state CHIP FFS programs, and 45 CFR 156.222(c) for QHP issuers on the FFEs. For the Prior Authorization API, see 42 CFR 431.80(c)(1) for state Medicaid FFS programs, 42 CFR 457.732(d)(1) for state CHIP FFS programs, and 45 CFR 156.223(d) for QHP issuers on the FFEs. ---------------------------------------------------------------------------

2. API Documentation

In the 2020 CMS Interoperability and Patient Access final rule, we finalized a requirement that impacted payers make the specific business and technical documentation necessary to interact with their Patient Access and Provider Directory APIs freely and publicly accessible (85 FR 25542). In the 2024 CMS Interoperability and Prior Authorization final rule, we extended that requirement to the Provider Access, Payer- to-Payer, and Prior Authorization APIs (89 FR 8815). We explained that transparency is necessary for developers to easily obtain the information needed to develop systems technically compatible with the payer's API. Transparency is also needed so that developers can understand how to successfully interact with a payer's API. This includes how to satisfy any requirements the payer may establish for verifying a developer's identity and their apps' authenticity. As explained in the preamble to the 2020 CMS Interoperability and Patient Access final rule (85 FR 25542), impacted payers must make publicly accessible documentation necessary to interact with their APIs. The existing regulations in 42 CFR 422.119(d), 42 CFR 431.60(d), 42 CFR 457.730(d), and 45 CFR 156.221(d) require impacted payers to make publicly available documentation that includes API syntax, function names, required and optional parameters, software components and configurations, and technical requirements for apps to interact with their APIs. FHIR capability statements are mandatory resources, as defined by an unexpired version of the FHIR standard adopted in 45 CFR 170.215(a), making them inherently part of this required documentation. The required authorization and authentication protocols and implementation details build upon the existing requirement for impacted payers to use the SMART App Launch IG and OpenID Connect Core--to implement certain interoperability APIs.\208\ The SMART App Launch IG is a standards-based framework for secure app connections to health IT systems, and OpenID Connect Core is an identity verification layer built on OAuth 2.0. Those existing requirements necessitate public documentation of authentication protocols. API registration information, when required by payers, constitutes essential documentation that falls within the existing requirement in 42 CFR 422.119(d)(3), 42 CFR 431.60(d)(3), 42 CFR 457.730(d)(3), and 45 CFR 156.221(d)(3) to make publicly accessible all applicable technical requirements and attributes necessary for an app to be registered with any authorization server(s) deployed in conjunction with the API. Without registration procedures, developers cannot establish the necessary access credentials to use the APIs. --------------------------------------------------------------------------- \208\ See, for instance, cross-references to SMART Launch IG in 45 CFR 170.215(c) and OpenID Connect Core in 45 CFR 170.215(e), for the Patient Access API in 42 CFR 422.119(c)(1) for MA organizations, 42 CFR 431.60(c)(1) for state Medicaid FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(c)(1) for CHIP FFS programs, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(c)(1) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- To ensure that the business and technical documentation is publicly available and easily discoverable, we are proposing to require impacted payers to report to CMS the URLs for specific required documentation, at the CFR citations listed in Table 8.\209\ CMS would then publish these URLs for centralized access. CMS proposes that the required URLs must include, as applicable: a direct URL to the FHIR capability statement, as defined by an unexpired version of the FHIR standard adopted in 45 CFR 170.215(a); and one or more URLs for a publicly accessible website with authorization and authentication protocols and implementation details; and API registration information.\210\ Each of those items are elements of the existing standards and documentation requirements that already must be publicly available.\211\ --------------------------------------------------------------------------- \209\ For the Patient Access API, see 45 CFR 156.221(h) for QHP issuers on the FFEs. For the Provider Access and Payer-to-Payer APIs, see 42 CFR 431.61(c)(1)-(2) for state Medicaid FFS programs, 42 CFR 457.731(c)(1) and (2) for state CHIP FFS programs, and 45 CFR 156.222(c) for QHP issuers on the FFEs. For the Prior Authorization API, see 42 CFR 431.80(c)(1) for state Medicaid FFS programs, 42 CFR 457.732(d)(1) for state CHIP FFS programs, and 45 CFR 156.223(d) for QHP issuers on the FFEs. \210\ See 42 CFR 422.119(d) for MA organizations, 42 CFR 431.60(d) for state Medicaid FFS programs, 42 CFR 457.730(d) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d) for QHP issuers on the FFEs. \211\ See 42 CFR 422.119(d) for MA organizations, 42 CFR 431.60(d) for state Medicaid FFS programs, 42 CFR 457.730(d) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d) for QHP issuers on the FFEs. --------------------------------------------------------------------------- The proposed URL reporting requirements directly correspond to existing requirements to make technical documentation publicly available, as follows: (1) FHIR Capability Statement--The capability statement can satisfy the existing requirements to make publicly accessible documentation that includes API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.\212\ Because capability statements document API implementation details, functional capabilities, and operational parameters, [[Page 19959]] they should serve as a the primary source of technical documentation necessary to interact with the API. --------------------------------------------------------------------------- \212\ See 42 CFR 422.119(d)(1) for MA organizations, 42 CFR 431.60(d)(1) for state Medicaid FFS programs, 42 CFR 457.730(d)(1) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(1) for QHP issuers on the FFEs. --------------------------------------------------------------------------- (2) Authorization and Authentication Protocols and Implementation Details--This documentation should satisfy the existing requirements to make publicly accessible all applicable technical requirements and attributes necessary for an app to be registered with any authorization server(s) deployed in conjunction with the API.\213\ Specific information about authorization and authentication protocols and implementation details is essential for developers to ensure that their software can communicate and exchange information with an API. --------------------------------------------------------------------------- \213\ See 42 CFR 422.119(d)(3) for MA organizations, 42 CFR 431.60(d)(3) for state Medicaid FFS programs, 42 CFR 457.730(d)(3) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(3) for QHP issuers on the FFEs. --------------------------------------------------------------------------- (3) API Registration Information--This documentation can satisfy the requirements to make publicly accessible the software components and configurations an application must use in order to successfully interact with the API and process its response(s).\214\ Without registration procedures, developers cannot establish the necessary access credentials to use the APIs. --------------------------------------------------------------------------- \214\ See 42 CFR 422.119(d)(2) for MA organizations, 42 CFR 431.60(d)(2) for state Medicaid FFS programs, 42 CFR 457.730(d)(2) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(2) for QHP issuers on the FFEs. --------------------------------------------------------------------------- These three documentation types--capability statements, authorization and authentication protocols and implementation details, and API registration information--represent discrete components of the broader documentation already required under existing regulations. The proposed URL reporting requirements do not expand the scope of required documentation but rather add to existing requirements by establishing a standardized mechanism for verifying compliance and facilitating discoverable access to required documentation. The URL reporting proposal is integral to the effectiveness of API endpoint reporting. API endpoints are only functional when developers can access the technical documentation needed to integrate with them, including FHIR capability statements, authorization and authentication protocols and implementation details, and API registration information. Without discoverable documentation, centralized endpoint information provides limited value to the health care ecosystem. Both proposals, to report API endpoints and documentation URLs, could facilitate patient access to health information, support care coordination, enable efficient program administration, and reduce administrative burden on developers, providers, and payers. While impacted payers must already make API documentation publicly available under existing regulations, CMS currently lacks an efficient mechanism to systematically verify compliance and facilitate standardized discovery of this documentation across hundreds of payers. The URL reporting proposal could enable CMS to systematically verify that required documentation is publicly accessible, monitor ongoing compliance with existing documentation obligations, and identify compliance gaps more efficiently than manual discovery processes. This could transform fragmented compliance into systematic, verifiable accessibility that serves both regulatory oversight and industry needs. CMS cannot efficiently gather this information independently because doing so would require continuous monitoring of hundreds of payer websites across multiple programs (MA, Medicaid, CHIP, and QHPs on the FFEs), technical staff to locate and verify documentation across varying website structures, and ongoing maintenance as payers modify their websites. Manual discovery by CMS could result in outdated information, discovery delays, and verification challenges, while requiring disproportionate resource allocation compared to the benefit for the industry. This proposal explicitly addresses registration requirements that impacted payers must already meet. The proposed URL reporting requirements are authorized under the same statutory provisions that support the existing documentation requirements and would enable CMS to facilitate centralized discovery of documentation that must already be publicly available under existing regulations.\215\ --------------------------------------------------------------------------- \215\ See sections 1852(d)(1)(A), 1852(g)(1)(A), 1852(h), 1856(b), and 1857(e)(1) of the Act for MA organizations; see sections 1902(a)(4), 1902(a)(6), 1902(a)(8), 1902(a)(19), 1903(m)(2)(A)(xi), and 1932(d)(1) of the Act for state Medicaid FFS programs and Medicaid managed care plans; see sections 2101 and 2102 of the Act for state CHIP FFS programs and CHIP managed care entities; see sections 1311(c) and 1321(a) of the Affordable Care Act for QHP issuers on the FFEs (42 U.S.C. 18031(c), 18041(a)). See section II.E.7. of this proposed rule for a detailed discussion of statutory authorities. --------------------------------------------------------------------------- Maintaining API technology conformant with an unexpired version of the FHIR standard adopted in 45 CFR 170.215(a) is a requirement for all the interoperability APIs; and within that FHIR standard, capability statements are a mandatory resource. A capability statement documents how a FHIR API has been implemented, including the particular unexpired version of the FHIR standard, and which aspects of the standard have been implemented and how.\216\ The statement can be used to describe how to interface with the FHIR server and thus can provide a degree of self-configuration for software clients. For example, a capability statement could indicate whether the FHIR server allows clients to push updates to patient information, or which fields are searchable to find the appropriate patient. Furthermore, a thorough and accurate capability statement would help impacted payers meet their documentation requirements.\217\ --------------------------------------------------------------------------- \216\ Health Level Seven International. (2023, March 26). Resource Capability Statement--Content. Retrieved from https://hl7.org/fhir/capabilitystatement.html. \217\ See 42 CFR 422.119(d)(1) for MA organizations, 42 CFR 431.60(d)(1) for state Medicaid FFS programs, 42 CFR 457.730(d)(1) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(1) for QHP issuers on the FFEs. --------------------------------------------------------------------------- Because capability statements document API implementation details, functional capabilities, and operational parameters, they are a primary source technical documentation that could satisfy the requirement to make documentation that includes API syntax, function names, required and optional parameters, software components and configurations, and technical requirements for apps to interact with their APIs publicly accessible. Ensuring that direct URLs to capability statements are readily available for all payers in a centralized location would reduce developer burden to find each payer's capability statement. Reducing developer burden--whether for a developer of patient apps, EHRs, or payer systems--could expedite patient data exchange and lead to more timely and informed care. We emphasize that we are proposing that impacted payers would have to provide a direct URL to the capability statement itself and not to a documentation site that includes the capability statement. Because the capability statement is a structured file, we believe it is important that software be able to find it automatically without additional manual intervention to find [[Page 19960]] the file within a site reported by the payer. In addition, we propose to require impacted payers to report to CMS a URL or URLs with information about authorization and authentication protocols and implementation details for their API. That information is already required to be posted in a publicly accessible location by impacted payers, but we are now proposing to require impacted payers to report to CMS the location where they have made it available.218 219 Specific information about authorization and authentication protocols and implementation details is essential for developers to ensure that their software can communicate and exchange information with an API. Authorization is the process by which the server gives the requesting client permission to access data. Authentication protocols are those that a payer uses to verify the identity of the requesting entity. However, there is no single protocol for authentication that will address all use cases.\220\ Additionally, within a single API, implementers may need to utilize more than one protocol to address specific population and trading partner needs. Therefore, it is essential that developers know how to design their software, whether for patients, providers, or payers, to successfully access the appropriate data. --------------------------------------------------------------------------- \218\ Authorization and authentication protocols are ``software components and configurations an application must use in order to successfully interact with the API'' and are specifically required to be publicly posted in 42 CFR 422.119(d)(2) for MA organizations, 42 CFR 431.60(d)(2) for state Medicaid FFS programs, 42 CFR 457.730(d)(2) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(2) for QHP issuers on the FFEs. \219\ Authorization protocols (such as OAuth 2.0 and SMART App Launch) define the software components and configurations that apps must implement to obtain permission to access data from the API server, including authorization clients, token handlers, and redirect URI configurations. Authentication protocols (such as OpenID Connect Core) define the software components and configurations that apps must implement to verify the identity of the requesting entity, including authentication flows, identity token processors, and user credential validation modules. \220\ Health Level Seven International. (2023, March 26). FHIR Security. Retrieved from https://hl7.org/fhir/security.html#binding. --------------------------------------------------------------------------- Often, API servers require apps or other software that interact with an API to be registered with the server and receive a key that verifies the app or program making the API call (API key).\221\ That allows the server to identify the app and ensure it has the access rights required to make the particular API call. API keys are not intended to fulfill the same security functions as authorization and authentication protocols for users, but they help payers monitor their APIs and gather data on usage. Because registration is sometimes necessary to connect to an API, if the payer requires registration, we propose to require impacted payers to report to CMS a public URL with information about how developers can register their apps with the API server. We are making those proposals in the CFR citations listed in Table 8. Not all APIs require registration. For example, the 2020 CMS Interoperability and Patient Access final rule (85 FR 25583 and 25584) established that provider directory information must be accessible via an API without requiring authentication. Therefore, payers implementing Provider Directory APIs would not have API registration information to report for that API, and the requirement would not apply. --------------------------------------------------------------------------- \221\ See, for example, the Certified Health IT Product Listing API maintained by ONC at https://chpl.healthit.gov/#/resources/api and the ONC Certification (g)(10) Standardized API Test Kit at https://github.com/onc-healthit/onc-certification-g10-test-kit?tab=readme-ov-file#terminology-prerequisites. --------------------------------------------------------------------------- We propose that CMS would publish those API endpoints and URLs in a centralized location for easy discovery by developers. We emphasize that we are not proposing that impacted payers would be required to report their supporting documentation itself to CMS. Rather, we are proposing that impacted payers would be required to report to CMS one or more public URLs where that documentation can be publicly accessed. However, we request comment on whether a single URL to a site that contains the authorization and authentication protocols and implementation details and API registration information is sufficient, or whether impacted payers should report a separate URL for each of these items. In addition, we request comment on whether there are discrete pieces of information, such as the specific authentication protocol a payer uses, that we should collect to facilitate faster API integration with patient health apps, provider EHRs, and payer systems. We wish to balance the benefits of making as much information available in a standardized and centralized location against the burden of reporting.

3. Alternative Proposal--National Directory of Healthcare Providers &

Services Implementation Guide As an alternative to our primary proposal, the National Directory of Healthcare Providers & Services (NDH) IG could provide a framework for payers to report the proposed information.\222\ The NDH IG has been developed to facilitate and standardize a national directory infrastructure. The NDH IG provides a framework for standardized information sharing about providers, health organizations, and related services, their relationships, and technical connectivity details (for example, electronic endpoints) in FHIR. Within the NDH IG is an Endpoint Profile resource that has already been developed with the resource structure we are proposing for payer endpoint reporting.\223\ The Endpoint Profile within the NDH IG includes several of the data elements we are proposing here, as well as additional information for developers. The NDH IG Endpoint Profile includes extensions to document IG versions, authentication information, trust frameworks, UDAP dynamic registration, environment type (production/test/development), and more. While the NDH IG has not been adopted by HHS at this time, it may provide a simpler method for data submission, as it has been developed by FAST, an HL7 FHIR accelerator program, using the same FHIR standards as the other specifications and IGs discussed in this proposed rule. Tying reporting requirements to an existing FHIR IG may simplify the process for payers to report the proposed data and developers to use the data within a potential centralized registry. --------------------------------------------------------------------------- \222\ Health Level Seven International. (2025, April 10). National Directory of Healthcare Providers & Services (NDH) IG. Retrieved from https://hl7.org/fhir/us/ndh/STU1/index.html. \223\ Health Level Seven International. (2025, April 10). Resource Profile: NDH Base Endpoint Profile. Retrieved from https://hl7.org/fhir/us/ndh/STU1/StructureDefinition-ndh-Endpoint.html. --------------------------------------------------------------------------- Under this alternative proposal, we propose to require impacted payers to report NDH IG Endpoint Profile compliant resources containing the relevant information for each interoperability API. A single Endpoint Resource would be sufficient for cases where a single endpoint manages multiple API types with the same server or service address (URL), requirements, and other documentation. Under this alternative proposal, impacted payers would be required to populate all elements and extensions identified in the profile that are relevant to the specific interoperability API, including, but not limited to: FHIR IGs and [[Page 19961]] versions, dynamic registration information, trust framework, secure exchange artifacts, access control mechanisms, payload Multipurpose internet Mail Extension (MIME) type, and environment type. This alternative proposal is limited to proposing to require impacted payers to submit relevant Endpoint Resources that are compliant with the NDH Endpoint Profile, as opposed to proposing to require full support and implementation of the NDH IG as a whole.

4. Reporting Timelines

In the 2020 CMS Interoperability and Patient Access final rule, we finalized compliance dates in 2021 for the Patient Access and the Provider Directory APIs (except for QHP issuers on the FFEs, which are not subject to the Provider Directory API requirement) (85 FR 25558 and 25559 and 85 FR 25563 and 25564). Therefore, the information we are proposing to require impacted payers to report to CMS should already be publicly available for those two APIs. In the 2024 CMS Interoperability and Prior Authorization final rule, we established compliance dates in 2027 for impacted payers to implement the Provider Access, Payer-to- Payer, and Prior Authorization APIs. We believe that it would benefit payers, providers, and patients to have endpoints publicly available as soon as possible. Therefore, rather than tying a compliance date to the beginning of a calendar year, plan year, or rating period, we are proposing that all impacted payers be required to report the proposed data to CMS no later than 60 days after the effective date of a final rule. The proposed information about their own APIs should be readily available to impacted payers. Therefore, we believe the benefits of making endpoints publicly available, as discussed here, compel an expedited reporting process and deadline. As new payers participate in CMS programs, we propose that they would be required to report the proposed information to CMS no later than 60 days before they begin covering patients under the applicable CMS program. Specifically, that means that a new impacted payer would be required to report 60 days before January 1 for MA organizations and state Medicaid and CHIP FFS programs, 60 days before the beginning of a rating period for Medicaid managed care plans or CHIP managed care entities, and 60 days before a plan year for QHP issuers on the FFEs, depending on the type of plan(s) the impacted payer is offering. After the proposed deadline, we propose that impacted payers would be required to update the information reported to CMS within 1 week of any changes. In addition, to ensure that the latest information is available, we propose that impacted payers would be required to verify that the reported information is still correct every 12 months from the date of the last update or verification. We believe that the burden of reporting API endpoints to CMS would be minimal compared to the burden on payers to individually locate other payers' API endpoints for the Payer-to-Payer API. We seek comment on the burden that reporting API endpoints could place on payers and how CMS can reduce that burden, either with the information we collect or the method of collection. Impacted payers could meet the proposed requirements to verify their information at any time during the year. For instance, we expect that QHP issuers could report (if a new QHP issuer) or verify every 12 months (if an existing QHP issuer) at the same time they apply for certification on the FFEs, which could streamline their reporting requirements and allow CMS to verify that the QHP issuer has met the conditions for certification. While only impacted payers would be subject to these proposals, if finalized, CMS would collect and publish API endpoints and URLs from any payer that implements interoperability APIs, including those that are not impacted payers under the CMS interoperability rules. As we continue to strongly encourage payers not subject to our interoperability rules to participate in data exchange, according to the requirements and standards established in those rules, we would want to facilitate their participation by publishing their API endpoints and documentation URLs.

5. Publication

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

6. Summary

In summary, we request comment on our proposals in the CFR citations listed in Table 8, and specifically on the following: The proposal to require impacted payers to report all API endpoints to CMS, in the form of an Endpoint Resource, as defined by an unexpired version of the FHIR standard adopted in 45 CFR 170.215(a), including, if multiple, appropriate use cases for each. The proposal to require impacted payers to report URLs with the required documentation for each of their interoperability APIs, as applicable: ++ A direct URL to the API FHIR capability statement. ++ Authorization and authentication protocols and implementation details. ++ API registration information. The proposal to require impacted payers to report this information to CMS no later than 60 days after the effective date of a final rule. The proposal to require new impacted payers to report this information no later than 60 days before they begin covering patients under the applicable CMS program. The proposal to require impacted payers to update CMS within 1 week of any changes to the reported information and verify their information at least once every 12 months. The alternative proposal to require impacted payers to report to CMS all NDH IG Endpoint Profile resources containing the relevant information for each interoperability API. In addition, we request comment on the following: Is the proposal to collect a direct URL for the FHIR capability statements necessary, or would a payer endpoint be sufficient to indicate that the capability statement is located at [API endpoint]/metadata, as is required by the FHIR standard, or is that data element duplicative? Whether a single URL to a site that contains the authorization and authentication protocols and implementation details, and API registration information is sufficient, or whether impacted payers should report separate direct URLs for each of these items? Whether there are discrete pieces of information, such as the specific authentication protocol a payer uses, that we should collect to facilitate faster API integration with patient health apps, provider EHRs, and payer systems? Would aligning the reporting requirements with the NDH Endpoint Profile resource reduce payer burden to report the proposed information and/or developer burden to use a centralized registry? If the alternative proposal is finalized, would it negate the need for impacted payers to report URLs to documentation related to authorization and authentication protocols and implementation details and API registration information? [[Page 19962]] The burden that reporting API endpoints could place on payers and how CMS can reduce that burden, either with the information we collect or the method of collection. How CMS could collect and publish the reported information in a manner that would balance the burden on payers with the benefits to developers, patients, providers, and payers. For example: ++ Would a machine-readable file on CMS's website be sufficient? ++ What would the benefits be of a FHIR-enabled registry, either for reporting or publishing? Would using FHIR standards allow a more streamlined and automated reporting process for payers? Would it allow greater flexibility for third-party app developers and EHR developers, which could improve the patient and provider experience? BILLING CODE 4150-28-P [[Page 19963]] [GRAPHIC] [TIFF OMITTED] TP14AP26.287 [[Page 19964]] [GRAPHIC] [TIFF OMITTED] TP14AP26.288 [[Page 19965]] BILLING CODE 4150-28-C

7. Statutory Authorities

a. Medicare Advantage For MA organizations, we are proposing these new requirements under our authority in the following sections of the Act: Section 1852(d)(1)(A) of the Act requires MA organizations offering an MA plan to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner that assures continuity in the provision of benefits. Section 1852(g)(1)(A) of the Act requires an MA organization to have a procedure for making determinations about whether an enrollee is entitled to receive a health service, how much the enrollee is required to pay for such service, and to provide an enrollee with a written notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act also requires that coverage determinations be made on a timely basis. Section 1852(h) of the Act requires that MA organizations have procedures in place to maintain accurate and timely medical records and other health information regarding MA enrollees and to assure enrollees have timely access to such records and information. Section 1856(b) of the Act authorizes the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, including the provisions in section 1852 of the Act. Section 1857(e)(1) of the Act explicitly authorizes the adoption of additional MA contract terms and conditions, including required reporting to CMS by MA organizations, where necessary and appropriate and not inconsistent with Part C of the Medicare statute. One-Week Update Requirement--Section 1857(e)(1) of the Act explicitly authorizes additional contract terms and conditions, including required reporting to CMS by MA organizations, where necessary and appropriate. The proposed 1-week update requirement is necessary to ensure that the centralized registry maintains current endpoint information that supports the statutory requirements in sections 1852(d)(1)(A) (continuity of care), 1852(g)(1)(A) (timely coverage determinations), and 1852(h) (timely access to health records) of the Act. Section 1856(b) of the Act authorizes regulatory standards that carry out Part C requirements. Timely endpoint updates are essential to maintain the effectiveness of these statutory obligations, as outdated endpoints immediately disrupt API functionality and undermine patient access and care coordination. Verification Requirement--The proposed requirement to verify every 12 months is necessary and appropriate to ensure ongoing compliance with API endpoint reporting obligations and the underlying statutory requirements they support, and therefore may be adopted by the Secretary as an additional MA contract term under section 1857(e)(1) of the Act. In addition, section 1856(b) of the Act authorizes the Secretary to establish standards that ensure continued compliance with statutory requirements, including verification that reported information remains accurate to support ongoing patient access and care coordination. API URL Reporting--The proposed requirement for MA organizations to report URLs for API documentation is supported by the same statutory authorities as the 1-week update and verification requirements. Section 1857(e)(1) of the Act authorizes additional contract terms including required reporting to CMS where necessary and appropriate to effectuate the interoperability API requirements established under sections 1852(d)(1)(A), 1852(g)(1)(A), and 1852(h) of the Act. Section 1856(b) of the Act supports the URL reporting proposal as a regulatory standard necessary to ensure that technical information required for API functionality is discoverable, supporting timely patient access to health records, continuity of care, and coverage determinations. Without discoverable documentation, the API endpoints themselves cannot function effectively to serve these statutory purposes. Patient Access API--If developers have to find payer API endpoints individually, it could result in delays to the enrollee's ability to access their records in a timely manner. Therefore, we propose to collect and publish payer API endpoints under our authority under section 1856(b) of the Act to establish standards to carry out section 1852(h), as well as our authority under section 1857(e)(1) of the Act. Facilitating patients' access to their own health information could allow them to identify errors or missing data, thus improving the accuracy and timeliness of the medical records maintained by the MA organization. In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that making these data available through the Patient Access API is consistent with our programmatic authority to establish standards to implement section 1852(h) of the Act and could help patients be more informed about and active in their own care, which could potentially lead to better health outcomes.\224\ --------------------------------------------------------------------------- \224\ See 89 FR 8784. --------------------------------------------------------------------------- Provider Access API--Without a centralized location for providers to find API endpoints, the increased burden may lead to delays in receiving patient data, or providers deciding not to request patient data at all. Therefore, we propose to collect and publish payer API endpoints under our authority under section 1856(b) of the Act to establish standards to carry out sections 1852(d)(1)(A) and 1852(h) of the Act, as well as our authority under 1857(e)(1) of the Act. Facilitating providers' access to patient data would give insight into health history and previous care, thus creating conditions for benefits to be accessible in a manner that assures the continuity of care. As discussed in the 2024 CMS Interoperability and Prior Authorization final rule, the Provider Access API would facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care, which is consistent with the requirement at section 1852(d)(1)(A) of the Act for continuing the provision of benefits.\225\ --------------------------------------------------------------------------- \225\ See 89 FR 8818. --------------------------------------------------------------------------- Payer-to-Payer API--One of the most important purposes of our payer to payer data exchange policy is to facilitate care continuity at the time a patient changes payers. Delays in being able to find the previous payer's API endpoint to request patient data could diminish those benefits. Therefore, we propose to collect and publish payer API endpoints under our authority under section 1856(b) of the Act to establish standards to carry out section 1852(d)(1)(A), as well as our authority under section 1857(e)(1) of the Act. Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers are required to make a ``reasonable effort to locate information about a patient's previous payer,'' including that payer's API endpoints.\226\ Requiring impacted payers to report their API endpoints would ease the burden of finding other payers' endpoints, thus potentially leading to more payer to payer data exchange as envisioned by the CMS interoperability regulations. --------------------------------------------------------------------------- \226\ See 89 FR 8840 and 8841. --------------------------------------------------------------------------- Prior Authorization API--Collecting and publishing payer API endpoints would allow developers to configure provider systems to dynamically find and use the appropriate payer's API endpoint rather than hard coding each payer API endpoint or requiring a provider to find the API endpoint [[Page 19966]] themselves to submit a prior authorization request. Such process barriers could result in untimely delays to patient care and negate some of the benefits that the Prior Authorization API would provide. Therefore, we propose to collect and publish payer API endpoints under our authority under section 1856(b) of the Act to establish standards to carry out section 1852(g)(1)(A), as well as our authority under section 1857(e)(1) of the Act. Reporting API endpoints would facilitate the required procedure for making determinations about enrollee benefits and costs, which would lead to more timely coverage determinations. Provider Directory API--Collecting and publishing payer API endpoints for Provider Directory APIs could facilitate provider and patient access to current, accurate provider network information. Without centralized endpoint discovery, providers and patients face increased burden in locating and accessing provider directory information, which could delay care coordination and patient access to in-network providers. Therefore, we propose to collect and publish payer API endpoints under our authority under section 1856(b) of the Act to establish standards to carry out section 1852(d)(1)(A), as well as our authority under section 1857(e)(1) of the Act. Facilitating access to provider directory information supports the requirement that MA organizations make covered benefits available and accessible in a manner that assures continuity in the provision of benefits. b. Medicaid For state Medicaid FFS programs and Medicaid managed care plans, we are proposing these new requirements under our authority in the following sections of the Act: Section 1902(a)(4) of the Act requires that a state Medicaid plan provides such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan, which includes ensuring that contracted managed care plans comply with federal interoperability requirements. Section 1902(a)(6) of the Act requires states to make reports in a form and containing information required by the Secretary, which can include ensuring that managed care plans under contract provide necessary endpoint information to the state for reporting to CMS. Section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Section 1902(a)(19) of the Act requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. Section 1903(m)(2)(A)(xi) of the Act requires that contracts with Medicaid MCOs include provisions that ensure compliance with applicable requirements. This provides direct authority to impose endpoint reporting requirements on managed care plans through their contracts with states. Section 1932(a) of the Act provides authority for states to implement managed care arrangements and includes certain waiver provisions. Section 1932(d)(1) of the Act establishes that managed care entities must comply with requirements the Secretary determines necessary to carry out the purposes of the Medicaid program One-Week Update Requirement--Section 1902(a)(6) of the Act requires states to make reports ``in a form and containing information required by the Secretary,'' which includes the timing and frequency of such reports. The proposed 1-week update requirement ensures that CMS receives timely information necessary for proper program oversight. Section 1902(a)(4) of the Act requires methods of administration necessary for proper and efficient program operation. Outdated endpoint information could undermine the efficient operation of the Medicaid program by disrupting API functionality that supports beneficiary access to care and data. Verification Requirement--Section 1902(a)(6) of the Act supports verification every 12 months as part of the reporting requirements necessary for proper program oversight and monitoring. Section 1902(a)(4) of the Act requires ongoing administrative methods that ensure proper program operation, which includes verifying the accuracy of reported endpoint information that supports beneficiary services. API URL Reporting--Section 1902(a)(6) of the Act supports the URL reporting proposal as part of the reporting requirements necessary for CMS to facilitate the interoperability framework established under our Medicaid API requirements. This also directly supports requiring states to collect and report API endpoint information from both their FFS programs and contracted managed care plans. Section 1902(a)(4) of the Act requires this as a method of administration necessary for proper and efficient program operation, as centralized documentation discovery supports efficient API implementation and reduces administrative burden on providers and developers. Additionally, section 1902(a)(4) of the Act requires states to ensure proper administration of their Medicaid programs, which includes oversight of managed care plan compliance with federal requirements, including endpoint reporting. States have existing obligations to monitor and ensure managed care plans' compliance with federal requirements, and endpoint reporting falls within this oversight responsibility. Section 1902(a)(19) of the Act supports this requirement as consistent with simplicity of administration and beneficiary interests, as centralized URLs simplify API integration and serve beneficiary interests in data access and care coordination. Patient Access API--We finalized the Patient Access API based on our authority in sections 1902(a)(4) and (a)(19) of the Act. The requirement to make Medicaid patients' health information available through interoperable technology can facilitate beneficiary access to their information in a convenient, timely, and portable way, which is essential for these programs to be effectively and efficiently administered in the best interests of beneficiaries. We have received feedback from developers that when they have to find payer API endpoints individually, it can delay beneficiaries' access to their records. Making these API endpoints publicly accessible through a centralized registry could further enhance beneficiary access by enabling broader innovation in third-party apps and reducing barriers for developers to create patient-friendly tools that help beneficiaries interact with their health information. As explained in the 2020 CMS Interoperability and Patient Access final rule, giving beneficiaries access to their own health data is necessary for the proper and efficient administration of the state plan.\227\ Therefore, we propose to collect and publish payer API endpoints under our authority in sections 1902(a)(4), (6), and (19) of the Act. --------------------------------------------------------------------------- \227\ See 85 FR 25526. --------------------------------------------------------------------------- Provider Access API--Collecting and publishing payer API endpoints would decrease provider burden, which may facilitate a provider's ability to request patient information. Otherwise, there could be delays in receiving patient information or a provider may decide not to request patient data due to that burden. Making patient health information available to providers at the point of care can significantly improve [[Page 19967]] their ability to render Medicaid services effectively, efficiently, and appropriately. The Provider Access API policies should help states fulfill their obligations to operate their state plans efficiently and to ensure that Medicaid services are furnished with reasonable promptness and in a manner consistent with the best interest of the recipients.\228\ Therefore, we propose to collect and publish payer API endpoints under our authority in sections 1902(a)(4), (6), and (19) of the Act. --------------------------------------------------------------------------- \228\ See 89 FR 8785. --------------------------------------------------------------------------- Payer-to-Payer API--Collecting and publishing payer API endpoints would decrease payer burden to locate payer API endpoints to make a request for patient data. That would accelerate payers' ability to make a timely request for patient data, at a point when delays could lead to gaps in care. Those data can provide the information necessary to ensure the beneficiary has timely continuity of care. Therefore, we propose to collect and publish payer API endpoints under our authority in sections 1902(a)(4), (6), (8), and (19) of the Act. Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers are required to make a ``reasonable effort to locate information about a patient's previous payer,'' including that payer's API endpoints.\229\ Requiring impacted payers to report their API endpoints would ease the burden of finding other payers' endpoints, thus potentially leading to more payer to payer data exchange as envisioned by the CMS interoperability regulations. --------------------------------------------------------------------------- \229\ See 89 FR 8840 and 8841. --------------------------------------------------------------------------- Prior Authorization API--As explained in the 2024 CMS Interoperability and Prior Authorization final rule, the Prior Authorization API should improve the efficiency and timeliness of the prior authorization process for Medicaid beneficiaries, providers, state Medicaid agencies, and Medicaid managed care plans by addressing inefficiencies that exist today.\230\ Collecting and publishing payer API endpoints would allow developers to configure provider systems to dynamically find and use the appropriate payer's API endpoint rather than hard coding each payer API endpoint, which may create maintenance burdens and system fragility, or requiring a provider to find the API endpoint themselves to submit a prior authorization request. Doing so would significantly improve the efficiency and timeliness of the prior authorization process, which would ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Therefore, we propose to collect and publish payer API endpoints under our authority in sections 1902(a)(4), (6), (8), and (19) of the Act. --------------------------------------------------------------------------- \230\ See 89 FR 8899. --------------------------------------------------------------------------- Provider Directory API--We propose to collect and publish Provider Directory API endpoints under our authority in sections 1902(a)(4), (6), and (19) of the Act. Section 1902(a)(4) of the Act requires states to provide methods of administration necessary for the proper and efficient operation of state Medicaid plans. Collecting and publishing Provider Directory API endpoints constitutes such a method of administration because it enables systematic verification of API accessibility and compliance monitoring. Section 1902(a)(6) of the Act requires states to make reports in a form and containing information required by the Secretary, which includes the timing and frequency of such reports. This authority supports the proposed requirement for impacted payers to report Provider Directory API endpoints, update CMS within 1 week of changes, and verify information every 12 months. Section 1902(a)(19) of the Act requires states to provide safeguards to ensure that care and services will be provided in a manner consistent with simplicity of administration and the best interests of recipients. Centralized endpoint discovery would serve the best interests of Medicaid beneficiaries by facilitating access to accurate provider directory information, which supports beneficiaries' ability to locate in-network providers and make informed health care decisions. Therefore, we propose to collect and publish Provider Directory API endpoints under our authority in sections 1902(a)(4), (6), and (19) of the Act. c. CHIP For state CHIP FFS programs and CHIP managed care entities, we are proposing these new requirements under our authority in the following sections of the Act: We finalized the interoperability APIs under our general authority in section 2101(a) of the Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. Section 2107(b)(1) of the Act requires state CHIP agencies to collect data, maintain records, and furnish reports in order to enable the Secretary to monitor state program administration and compliance and to evaluate and compare the effectiveness of state plans under this title. One-Week Update and Verification Requirements--Section 2107(b)(1) of the Act requires data collection and reporting to enable monitoring and evaluation. Timely endpoint updates are necessary for CMS to effectively monitor API implementation and ensure continued program effectiveness. Verification every 12 months is necessary for ongoing program monitoring and evaluation of API effectiveness. API URL Reporting--Section 2107(b)(1) of the Act supports URL reporting as necessary data collection and reporting to enable CMS to monitor effective API implementation and evaluate program success. Section 2101(a) of the Act establishes the purpose of providing child health assistance in an effective and efficient manner, and centralized documentation discovery supports efficient API implementation that benefits CHIP beneficiaries by facilitating seamless data exchange and care coordination. Patient Access API--Requiring state CHIP FFS programs to make beneficiaries' health information available through interoperable technology increases patient access to their health information, which can improve the efficacy of state CHIP FFS programs, allow for more efficient communication and administration of services, and promote coordination across various sources of health benefits coverage. As we stated in the 2024 CMS Interoperability and Prior Authorization final rule, the Patient Access API should increase patient access to their health information, which can improve the efficacy of state CHIP FFS programs, allow for more efficient communication and administration of services, and promote coordination across various sources of health benefits coverage.\231\ If developers have to find payer API endpoints individually, it could result in delays to the beneficiaries' ability to access their records in a timely manner. Therefore, we propose to collect and publish payer API endpoints under our authority in section 2107(b)(1) of the Act to help state CHIP FFS programs provide coverage to low-income children more effectively and efficiently. --------------------------------------------------------------------------- \231\ See 89 FR 8786. --------------------------------------------------------------------------- Provider Access API--The more information a provider has to make informed decisions about a patient's care, the more likely it is that patients will receive care that best meets their needs. As explained in the 2024 CMS [[Page 19968]] Interoperability and Prior Authorization final rule, providers can be more effective and efficient in their delivery of CHIP services by having direct access to patient utilization and authorization information.\232\ If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time focused on the patient, rather than on their need to collect information. Therefore, we propose to collect and publish payer API endpoints under our authority in section 2107(b)(1) of the Act to help state CHIP FFS programs provide child health assistance to uninsured, low-income children in an effective and efficient manner. --------------------------------------------------------------------------- \232\ See 89 FR 8819. --------------------------------------------------------------------------- Payer-to-Payer API--The Payer-to-Payer API is central to the goal of coordination with other sources of health benefits coverage for children in section 2101(a) of the Act. Centralizing payer API endpoints could facilitate more efficient and accurate requests for patient information, faster data exchange, and ultimately better care continuity and coordination for CHIP beneficiaries as they enter or exit CHIP coverage. Therefore, we propose to collect and publish payer API endpoints under our authority in section 2101(a) of the Act to help state CHIP agencies provide child health assistance to uninsured, low- income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers are required to make a ``reasonable effort to locate information about a patient's previous payer,'' including that payer's API endpoints.\233\ Requiring impacted payers to report their API endpoints would ease the burden of finding other payers' endpoints, thus potentially leading to more payer to payer data exchange as envisioned by the CMS interoperability regulations. --------------------------------------------------------------------------- \233\ See 89 FR 8840 and 8841. --------------------------------------------------------------------------- Prior Authorization API--The Prior Authorization API facilitates the more efficient and effective exchange of information required to submit a prior authorization request and receive a decision. An improved process may reduce administrative costs for providers and payers and improve timeliness in responding to providers and patients. As explained in the 2024 CMS Interoperability and Prior Authorization final rule, making this information available in a standardized way and permitting access through an API will also serve the requirements in section 2101(a) of the Act that state CHIP agencies ensure access to coverage and coordinated care.\234\ Collecting and publishing payer API endpoints would allow developers to configure provider systems to dynamically find and use the appropriate payer's API endpoint rather than hard coding each payer API endpoint or requiring a provider to find the API endpoint themselves to submit a prior authorization request. Therefore, we propose to collect and publish payer API endpoints under our authority in section 2107(b)(1) of the Act to help state CHIP agencies provide child health assistance to uninsured, low- income children in an effective and efficient manner. --------------------------------------------------------------------------- \234\ See 89 FR 8900. --------------------------------------------------------------------------- Provider Directory API--Centralizing Provider Directory API endpoints could facilitate more efficient access to provider network information, supporting the coordination of care with other sources of health benefits coverage as required under section 2101(a) of the Act. This would help state CHIP agencies provide child health assistance in an effective and efficient manner that is coordinated with other coverage sources. Therefore, we propose to collect and publish payer API endpoints under our authority in sections 2101(a) and 2107(b)(1) of the Act. d. Qualified Health Plan Issuers on the Federally-facilitated Exchanges For QHP issuers on the FFEs, we finalized the API requirements under our authority in section 1311(e)(1) of the Affordable Care Act. Section 1311(e)(1)(A) of the Affordable Care Act requires that Exchanges only certify plans as QHPs if they meet the requirements for certification promulgated by the Secretary under section 1311(c)(1) of the Affordable Care Act, while section 1311(e)(1)(B) of the Affordable Care Act affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates. One-Week Update and Verification Requirements--Section 1311(e)(1)(B) of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines that making such plans available is in the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates. Maintaining current endpoint information through timely updates would serve these interests by ensuring reliable API access for enrollees--enabling them to access their health data, coordinate care with providers, and facilitate seamless data exchange between payers without delays caused by outdated or inaccessible API endpoints. Verification every 12 months would ensure that certified QHPs continue to serve the interests of qualified individuals and qualified employers through reliable, accessible API endpoints. API URL Reporting--Section 1311(e)(1)(B) of the Affordable Care Act provides discretion to certify QHPs if the Exchange determines that making such plans available is in the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates. The proposal to require URL reporting ensures that certified QHPs maintain discoverable API documentation, serving enrollee interests in data access and care coordination. We believe it is in the interest of qualified individuals for health plans provide accessible technical documentation that enables effective API integration and operation. Patient Access API--In the 2020 CMS Interoperability and Patient Access final rule, we stated that generally certifying only health plans that make enrollees' health information available to them in a convenient, timely, and portable way is in the interests of enrollees in the state or states in which a FFE operates (85 FR 25526). If developers have to manually locate payer API endpoints individually, it could introduce operational inefficiencies and development delays that may hinder the enrollee's timely access to their records. Therefore, we propose to collect and publish payer API endpoints under our authority in section 1311(e)(1)(B) of the Affordable Care Act, as we believe it is in the interest of qualified individuals and qualified employers to collect and publish QHP issuers on the FFEs' API endpoints. Provider Access API--In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that it is in the interest of enrollees to generally only certify health plans that make enrollees' health information available to their providers via the Provider Access API (89 FR 8820). Giving providers access to their enrollees' health information supplied by QHP issuers on the FFEs should ensure that providers are better positioned to provide enrollees with seamless and coordinated care and ensure that enrollees are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the enrollee's more complete medical information could also maximize the efficiency of an enrollee's office visits. [[Page 19969]] Without a centralized location to find payer API endpoints, the increased burden may lead to delays in receiving enrollee information or providers deciding not to request enrollee data at all. Therefore, we propose to collect and publish payer API endpoints under our authority in section 1311(e)(1)(B) of the Affordable Care Act, as we believe it is in the interest of qualified individuals and qualified employers to collect and publish QHP issuers on the FFEs' API endpoints. Payer-to-Payer API--In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that it is in the interest of enrollees to generally only certify health plans that have a Payer-to- Payer API in place to exchange information with other payers about new enrollees, concurrent enrollees, and enrollees who have moved to another payer (89 FR 8858). Having enrollee information at the beginning of a new plan may assist the new payer in identifying enrollees who need care management services, which could reduce the cost of care. Delays in being able to find the previous payer's API endpoint to request enrollee data could diminish those benefits. Per the 2024 CMS Interoperability and Prior Authorization final rule, impacted payers are required to make a ``reasonable effort to locate information about a patient's previous payer,'' including that payer's API endpoints.\235\ Requiring impacted payers to report their API endpoints would ease the burden of finding other payers' endpoints, thus potentially leading to more payer to payer data exchange as envisioned by the CMS interoperability regulations. Therefore, we propose to collect and publish payer API endpoints under our authority in section 1311(e)(1)(B) of the Affordable Care Act, as we believe it is in the interest of qualified individuals and qualified employers to collect and publish QHP issuers on the FFEs' API endpoints. --------------------------------------------------------------------------- \235\ See 89 FR 8840 and 8841. --------------------------------------------------------------------------- Prior Authorization API--In the 2024 CMS Interoperability and Prior Authorization final rule, we stated that it is in the interest of enrollees for CMS to generally only certify health plans that have a Prior Authorization API because it enables more accurate submission and processing of prior authorization requests, which could improve the delivery of services to enrollees (89 FR 8901). Collecting and publishing payer API endpoints would allow developers to configure provider systems to dynamically find and use the appropriate payer's API endpoint rather than hard coding each payer API endpoint or requiring a provider to find the API endpoint themselves to submit a prior authorization request. We believe that in reducing provider administrative burden, providers would spend less time on administrative tasks, allowing them to spend more time on enrollee care. Therefore, we propose to collect and publish payer API endpoints under our authority in section 1311(e)(1)(B) of the Affordable Care Act, as we believe it is in the interest of qualified individuals and qualified employers to collect and publish QHP issuers on the FFEs' API endpoints. Provider Directory API--QHP issuers on the FFEs are not subject to Provider Directory API requirements.

1. Information About Prior Authorizations for Drugs in the Patient

Access, Provider Access, and Payer-to-Payer APIs a. Background In the 2024 CMS Interoperability and Prior Authorization final rule, we required impacted payers to make available certain information about prior authorizations for non-drug items and services via a Patient Access API.\236\ We also required impacted payers to make available similar information via Provider Access and Payer-to-Payer APIs (89 FR 8817 and 8855). We finalized compliance dates beginning in 2027 for each of these APIs (by January 1, 2027 for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027 for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027 for individual market QHP issuers on the FFEs) (89 FR 8784, 8817, and 8855). Specifically, impacted payers must make all of the following information available about prior authorization requests and decisions for non-drug items and services via the Patient Access and Provider Access APIs: --------------------------------------------------------------------------- \236\ See 42 CFR 422.119(b)(1)(iv)(A) for MA organizations, 42 CFR 431.60(b)(5)(i) for state Medicaid FFS programs, 42 CFR 457.730(b)(5)(i) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(b)(1)(iv)(A) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- The prior authorization status. The date the prior authorization was approved or denied. The date or circumstance under which the prior authorization ends. The items and services approved. If denied, a specific reason why the request was denied. Related structured administrative and clinical documentation submitted by a provider (89 FR 8784 and 8817). Impacted payers must make the same prior authorization information available through the Payer-to-Payer API, except they are not required to include denied prior authorizations (or a specific reason why the request was denied).\237\ Additionally, impacted payers must make available via the Payer-to-Payer API both structured and unstructured administrative and clinical documentation submitted by a provider.\238\ For each of these APIs--the Patient Access, Provider Access, and Payer- to-Payer APIs (collectively ``Access APIs''), we required that impacted payers make this information about prior authorizations available no later than 1 business day after the payer receives a prior authorization request and must update that information no later than 1 business day after any status change. This information must be available for the duration that the authorization is active and at least 1 year after the prior authorization's last status change (89 FR 8784, 8817, and 8855). Like the rest of the 2024 CMS Interoperability and Prior Authorization final rule, those requirements do not apply to any kind of drugs. --------------------------------------------------------------------------- \237\ See 42 CFR 422.121(b)(4)(ii)(A) for MA organizations, 42 CFR 431.61(b)(4)(ii)(A) for state Medicaid FFS programs, 42 CFR 457.731(b)(4)(ii)(A) for state CHIP FFS programs, through cross reference to 42 CFR 431.61(b)(4) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(b)(4)(ii)(A) for individual market QHP issuers on the FFEs. \238\ See 42 CFR 422.121(b)(4)(ii) for MA organizations, 42 CFR 431.61(b)(4)(ii) for state Medicaid FFS programs, 42 CFR 457.731(b)(4)(ii) for state CHIP FFS programs, through cross reference to 42 CFR 431.61(b)(4) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(b)(4)(ii) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- b. Proposals We emphasize the importance of access to prior authorization information for drugs in section II.B. of this proposed rule. For the reasons we explained in that section and in response to public feedback received on the 2022 CMS Interoperability and Prior Authorization proposed rule, we propose to add information about prior authorization requests and decisions for all drugs to the categories of data impacted payers are required to make available through the Access APIs. We propose to amend the Access API [[Page 19970]] provisions that require impacted payers to make available information about prior authorizations for non-drug items and services and drugs. Consistent with our policies for non-drug items and services, the information about prior authorizations for drugs that we are proposing be made available via the Patient Access and Provider Access APIs is the following: The prior authorization status. The date the prior authorization was approved or denied. The date or circumstance under which the prior authorization ends. The drug or drugs approved (including the dosage). If denied, a specific reason why the request was denied. Related structured administrative and clinical documentation submitted by a provider. For the Payer-to-Payer API, the information about prior authorizations for drugs we propose is the following: The prior authorization status. The date the prior authorization was approved. The date or circumstance under which the prior authorization ends. The drug or drugs approved (including the dosage). Related structured and unstructured administrative and clinical documentation submitted by a provider. In the 2024 CMS Interoperability and Prior Authorization final rule, we excluded denied prior authorization requests for non-drug items and services from the set of information that must be exchanged between payers via the Payer-to-Payer API and are proposing the same for prior authorizations for drugs (89 FR 8827). We propose to exclude denied prior authorization requests because they generally would not reflect ongoing treatment, as it does not demonstrate that patients actually received items, services, or drugs. If a patient ultimately received those items, services, or drugs despite the denied request, that information would have to be gathered from elsewhere (such as clinical data), regardless of whether the requesting payer receives information about the prior authorization decision. Many commenters cited similar justifications for excluding denied prior authorizations in response to the 2022 CMS Interoperability and Prior Authorization proposed rule, and we thus did not finalize a requirement to include denied prior authorization decisions in the Payer-to-Payer API policies. The value of including such information would likely be outweighed by the additional burden on impacted payers to include it and we therefore believe its exclusion remains justified. We refer readers to the 2024 CMS Interoperability and Prior Authorization final rule for a full discussion of our reasoning for this exclusion (89 FR 8830). We propose an October 1, 2027 compliance date for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to make the proposed information about prior authorizations for drugs available via the Access APIs. Because impacted payers are already required to make available information about prior authorizations for non-drug items and services beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) (89 FR 8784, 8817, and 8855), we believe a 9-month implementation window following that date strikes the appropriate balance between urgency and operational feasibility. An October 1, 2027 compliance date allows impacted payers to build upon the infrastructure and processes established for the January 1, 2027 deadline, while providing a defined period to extend that infrastructure to drug prior authorization data. However, we encourage these payers to make this information available via their APIs as soon as possible to benefit their patients. We propose that the requirement to make available information about prior authorization for drugs would be subject to the same timeframes established for making available prior authorization information for non-drug items and services--no later than 1 business day after the payer receives a prior authorization request--and the payer must update that information no later than 1 business day after any status change. This proposal not only aligns with our previously finalized policy, but we continue to believe that 1 business day is the appropriate timeframe for the reasons discussed in the 2024 CMS Interoperability and Prior Authorization final rule (89 FR 8775-8776). Similarly, that 1 business day timeframe aligns with the existing requirements to make claims and encounter data and all data classes and data elements included in a content standard in 45 CFR 170.213 (USCDI) available via the Access APIs no later than 1 business day after being processed or received by the payer. Additionally, we propose that information about prior authorizations for drugs be required to be available via the Access APIs for as long as the authorization is active and at least 1 year after the last status change. Information about denied and expired prior authorizations for drugs would therefore be available for at least 1 year after expiring or being denied. Consistent with the requirements to make available information about prior authorizations for non-drug items and services, we are not proposing to require payers to share a patient's full prior authorization history because that could comprise a significant amount of information that may no longer be clinically relevant. Furthermore, as payers' prior authorization policies may change over time, that information has a limited lifespan of usefulness for a patient's current care. However, our proposal would require payers to make available information about all active authorizations for as long as they are active, which may indicate a relationship to ongoing care. In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following: The proposal to require impacted payers to add information about prior authorization requests and decisions for all drugs to the categories of data they are required to make available through the Access APIs, within the timeframes established for non-drug items and services. The proposed October 1, 2027 compliance dates for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

2. Reporting Usage Metrics for Patient Access, Provider Access, Payer-

to-Payer, and Prior Authorization APIs a. Background Beginning in 2026, impacted payers are required to annually report to CMS certain metrics about patient data requests made via the Patient Access API. Impacted payers must annually report Patient Access API metrics to CMS in the form of aggregated, de-identified data following any year that the payer was subject to the requirement to make the Patient Access API available. Specifically, by March 31, 2026, MA organizations at the contract level, state Medicaid and CHIP FFS programs at the state level, and Medicaid managed care plans and CHIP managed care entities at the plan level must report the following metrics: (1) the total number of unique patients whose data are transferred via the [[Page 19971]] Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient.\239\ The current regulation in 45 CFR 156.221(f) provides that individual market QHP issuers on the FFEs at the issuer level also report these data by March 31, 2026, but CMS has specified to plans in sub-regulatory guidance that we will collect Patient Access API usage metrics during the QHP certification process.\240\ --------------------------------------------------------------------------- \239\ See 42 CFR 422.119(f) for MA organizations, 42 CFR 431.60(f) for state Medicaid FFS programs, 42 CFR 457.730(f) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5)(iii) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities. \240\ See Section 16. Interoperability. Center for Consumer Information and Insurance Oversight. (2026, February 25). FFEs 2027 Draft Letter to Issuers in the Federally-facilitated Exchanges. Retrieved from https://www.cms.gov/files/document/draft-2027-letter-issuers.pdf. --------------------------------------------------------------------------- These data will help CMS better understand whether the Patient Access API requirement is effectively and efficiently providing patients access to their health information and whether payers are providing that required information in a transparent and timely way. Additionally, aggregated usage data from each impacted payer will help us evaluate whether the Patient Access API policies are achieving the desired goals. By gathering that information, we can provide targeted support or guidance to impacted payers, if needed, to ensure that patients have access to their data and can use their data consistently across impacted payers. Multiple data transfers indicate repeat access, showing that patients are either using multiple apps or allowing apps to update their information over the course of the year. While data transfers may not indicate to what extent patients are using apps to manage their health care, it would be a preliminary indicator of interest in the technology (89 FR 8779). The current regulation requires that impacted payers report metrics from the previous calendar year to CMS by March 31 of each year.\241\ In the first year of the requirement, impacted payers will report calendar year 2025 data by March 31, 2026. A MA organization, Medicaid managed care plan, CHIP managed care entity, or individual market QHP issuer on the FFEs that is newly offering coverage in a particular market would naturally have no data to report in its first year of operation and is required to report data following its first year subject to the Patient Access API requirement (89 FR 8780). We did not propose, and thus did not finalize, policies for impacted payers to report usage metrics to CMS about Provider Access, Payer-to-Payer, or Prior Authorization APIs. --------------------------------------------------------------------------- \241\ See 42 CFR 422.119(f) for MA organizations, 42 CFR 431.60(f) for state Medicaid FFS programs, 42 CFR 457.730(f) for state CHIP FFS programs, through cross reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5)(iii) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(f) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- b. Proposed Changes to Patient Access API Usage Metrics for Medicaid Managed Care Plans, CHIP Managed Care Entities, and Individual Market QHP Issuers on the FFEs After finalizing the Patient Access API usage metrics in the 2024 CMS Interoperability and Prior Authorization final rule, we determined that additional proposals would be appropriate for Medicaid managed care plans, CHIP managed care entities, and individual market QHP issuers on the FFEs to align reporting deadlines for API usage metrics with other reporting deadlines. Similar proposals for small group market QHP issuers on the FF-SHOPs, with a later applicability date, are discussed in section II.D. of this proposed rule. Specifically, Medicaid managed care plans' and CHIP managed care entities' program contracts do not all use the same time period, and each state may choose different contract rating periods for each managed care program. Medicaid managed care plans' and CHIP managed care entities' contracts may use any 12-month period and collecting Patient Access API usage data based on a calendar year would thus be out of alignment with other reporting obligations in the contracts. Because rating periods do not necessarily align with calendar years, we now believe that the March 31 reporting deadline finalized in the 2024 CMS Interoperability and Prior Authorization final rule may not be appropriate for all Medicaid managed care plans and CHIP managed care entities. Therefore, to align the reporting deadlines with the contract rating period and its requirements, we are now proposing to require Medicaid managed care plans and CHIP managed care entities to report Patient Access API usage metrics from each rating period to the state no later than 90 days after the end of each rating period. For Medicaid managed care plans, these metrics will be reported to CMS by states in their MCPARs, which are due 180 days after the end of the rating period. Having Medicaid managed care plans report Patient Access API usage metrics to the state no later than 90 days after the end of each rating period provides states with ample time to collect and process the data for inclusion in their MCPARs. To simplify the cross- referencing regulatory text, we also propose, in 42 CFR 438.242(b)(5)(ii)(B), to be explicit that the requirement for Medicaid managed care plans and CHIP managed care entities is to report API usage metrics to the state, rather than to CMS directly. Furthermore, we propose to amend the requirements for Medicaid managed care plans and CHIP managed care entities to clarify that they would be required to report the Patient Access API usage metrics by program, as well as by plan. We plan to collect metrics from Medicaid managed care plans via the states through the MCPAR system, which is set up to receive reports from plans by program.\242\ For consistency with the other Medicaid and CHIP managed care reporting requirements, we believe that it is appropriate to also collect these metrics at the program level. Specifically, this proposal means that if a specific managed care plan contracts with the state for multiple programs (for example, an adult and child acute care program and an LTSS program), each program would separately report Patient Access API usage metrics. This is also consistent with how states must report all data in the MCPAR, as described in 42 CFR 438.66(e). For CHIP managed care entities, we are currently working to finalize the mechanism for states to submit Patient Access API usage metrics to CMS. We plan to provide future guidance for states on CHIP managed care entities reporting requirements and processes. --------------------------------------------------------------------------- \242\ See FAQ #3 citing the requirements in 42 CFR 438.66(e)(1). (2024, March). Medicaid Managed Care Program Annual Report (MCPAR) Technical Assistance Resource for States. Retrieved from https://www.medicaid.gov/sites/default/files/2024-04/mcpar-faq-march-2024v.2.pdf. --------------------------------------------------------------------------- The certification process for new and existing QHP issuers on the FFEs for the next plan year begins in the prior calendar year. QHP issuers on the FFEs are required to submit to CMS their initial application for plan certification for each plan year in June of the previous calendar year. Because the current annual March 31 reporting deadline finalized in 45 CFR 156.221(f) in the 2024 CMS Interoperability and Prior Authorization final rule falls before the annual QHP certification application deadline, we believe it would be more appropriate to align the deadlines so that QHP issuers on the FFEs can submit Patient Access API usage metrics as part of the annual QHP certification process. Further, other [[Page 19972]] reporting requirements in 45 CFR part 156, subpart C do not generally include specific dates by which issuers must report the required information but rely on the annual application deadline.\243\ Therefore, we propose regulatory text to refer to the reporting deadline for Patient Access API usage metrics in a manner similar to the reporting deadlines for other plan data that CMS collects during the annual QHP certification process. Specifically, we propose that following each year it offers a QHP on a FFE, a QHP issuer on the FFEs must report the specified metrics to CMS as aggregated, de-identified data at the issuer level in the form and manner and within the timeframes specified by the Secretary. That would allow flexibility for CMS to include API usage metrics reporting within specific deadlines set for the QHP certification process, which in practice, is generally the final deadline for the QHP certification process that takes place the following year.\244\ For example, QHP issuers on the FFEs would be required to submit metrics from plan years in 2026 as part of the QHP certification process during 2027 for plan years in 2028. In practice, CMS has already issued sub-regulatory guidance that CMS will collect Patient Access API usage metrics during the QHP certification process.\245\ Amending the regulatory text to align with how 45 CFR part 156, subpart C frames other QHP certification-related deadlines would streamline reporting by allowing issuers to report metrics at the same time and to the same systems as the QHP certification application. We are proposing that these changes become effective beginning on the effective date of the final rule. --------------------------------------------------------------------------- \243\ For example, 45 CFR 156.220(b) provides that a QHP issuer on the FFEs must submit transparency in coverage metrics described in paragraph (a) of that section in an accurate and timely manner, to be determined by HHS. \244\ Information about QHP certification, including deadlines, can be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline. \245\ See Section 16. Interoperability. Center for Consumer Information and Insurance Oversight. (2026, February 25). FFEs 2027 Draft Letter to Issuers in the Federally-facilitated Exchanges. Retrieved from https://www.cms.gov/files/document/draft-2027-letter-issuers.pdf. --------------------------------------------------------------------------- In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following: The proposal for Medicaid managed care plans and CHIP managed care entities to report Patient Access API usage metrics to the state no later than 90 days after the end of each rating period. The proposal for QHP issuers on the FFEs to report Patient Access API usage metrics to CMS in the form and manner and within the timeframes specified by the Secretary. The proposal to require Medicaid managed care plans and CHIP managed care entities to report certain metrics about Patient Access API usage, as finalized in the 2024 CMS Interoperability and Prior Authorization final rule, by program, as well as by plan. The proposal to become effective beginning on the effective date of the final rule. c. Proposal to Report Metrics About the Provider Access, Payer-to- Payer, and Prior Authorization API Usage for All Impacted Payers We are proposing that impacted payers be required to report metrics about usage of the Provider Access, Payer-to-Payer, and Prior Authorization APIs, which are required under the 2024 CMS Interoperability and Prior Authorization final rule. We propose that, beginning in 2028, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs would be required to annually report metrics in the form of aggregated, de-identified data. The reporting period for MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be the calendar year, while the reporting period for Medicaid managed care plans and CHIP managed care entities would be the rating period. We propose that, beginning in 2028, MA organizations and state Medicaid and CHIP FFS programs be required to report the previous calendar year's metrics to CMS by March 31 of each year. We propose that by the first rating period beginning on or after January 1, 2028, Medicaid managed care plans and CHIP managed care entities be required to report metrics to states from each rating period no later than 90 days after the end of each rating period. We propose that for plan years beginning on or after January 1, 2028, following each year it offers a QHP on a FFE, unless granted an exception for the previous year, a QHP issuer on the FFEs must report usage metrics to CMS in the form and manner and within the timeframes specified by the Secretary. Impacted payers would thus be required to begin reporting these data in 2028 for the previous reporting period (for most impacted payers, calendar year 2027). As discussed in section II.C.6. of this proposed rule, we use the term ``reporting period'' to describe the period from which data must be reported in order to account for certain differences between impacted payers. We also propose that MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would report the metrics at the same reporting levels, that is, the organizational levels at which the payer aggregates and submits the required data, as finalized for the Patient Access API usage metrics. MA organizations would thus report at the contract level, state Medicaid and CHIP FFS programs at the state level, and QHP issuers on the FFEs at the issuer level. We also propose that Medicaid managed care plans and CHIP managed care entities would report metrics at the plan and program level for the reasons discussed previously. By way of examples, reporting at the issuer level means that a QHP issuer on the FFEs would aggregate data across the plans it offers on a FFE, while reporting at the plan level means that a Medicaid managed care plan would report data specific to that individual plan. As we finalized for the Patient Access API (89 FR 8780), dual eligible special needs plans (D-SNPs) would report consistent with MA organizations at the contract level, and with Medicaid managed care plans at the plan level. Therefore, the MA organization would report information about Provider Access, Payer-to- Payer, and Prior Authorization API usage by its D-SNP enrollees to CMS at the contract level. The affiliated Medicaid managed care plan would report on information about Patient Access API usage by its enrollees to CMS at the plan and program level. In the 2024 CMS Interoperability and Prior Authorization final rule, we explained that we believe that it is most appropriate for MA organizations to report these usage data at the contract level (89 FR 8780). Contract level data represent aggregated information from all PBPs that fall under a single MA contract, with reporting organized by individual contracts rather than by individual plans. We already require MA organizations to annually report contract level data about their organization's determinations to CMS. Maintaining consistent contract level reporting in the MA program would give us useful information while limiting payer burden. By requiring contract level reporting for these metrics, the format of these reported data would remain consistent with other data that MA organizations are required to report. There could be value in requiring MA organizations to report on a plan level in the future to get more discrete data. [[Page 19973]] However, at this time, we continue to believe that the burden of requiring MA organizations to report at the plan level, especially given the small sample sizes of some plans, outweighs the benefits of obtaining that information. Commenters agreed with our proposals in the 2022 CMS Interoperability and Prior Authorization proposed rule that requiring state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans and CHIP managed care entities to report at the plan level, and individual market QHP issuers on the FFEs to report at the issuer level balances the reporting burden and the meaningfulness of the data (89 FR 8780). We explained in the 2024 CMS Interoperability and Prior Authorization final rule that requiring individual market QHP issuers on the FFEs to report at the issuer level, thereby aggregating plans under their purview, is consistent with their reporting on quality improvement strategies, as described in section 1311(g) of the Affordable Care Act and codified in 45 CFR 156.1130(a), which provides consistency with other QHP reporting requirements (89 FR 8890). Likewise, for these proposals, state Medicaid and CHIP FFS programs would report at the state level, Medicaid managed care plans and CHIP managed care entities at the plan and program level, and QHP issuers on the FFEs at the issuer level. Our proposed reporting levels and deadlines are summarized in Table 9. As with the existing Patient Access API metrics (89 FR 8781), if we finalize this proposal, we do not plan to publicly report these metrics at the contract, state, plan and program, or issuer level, but may reference or publish aggregated and de-identified data that does not include names of specific payers or plans. We are also not proposing a specific form or manner of reporting these metrics at this time but would issue specific format and process guidance for submitting these metrics, should they be finalized. We propose that, beginning in 2028, impacted payers be required to annually report Provider Access API usage metrics in the form of aggregated, de-identified data. MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be required to report these metrics directly to CMS and Medicaid managed care plans and CHIP managed care entities would be required to report these metrics to states. Specifically, impacted payers would be required to report the following metrics about their Provider Access API: The total number of unique providers who requested patient data via their Provider Access API. The total number of unique patients whose data were transferred via their Provider Access API to a provider's health IT system (for example, an EHR or health IT system). The total number of patient data transfers via their Provider Access API. In response to the 2022 CMS Interoperability and Prior Authorization proposed rule, some commenters expressed skepticism that providers would use the Provider Access API (89 FR 8792 through 8794). We are proposing these metrics because we believe that they would give us valuable insight into how frequently the Provider Access API is being used. In addition, we believe that obtaining these metrics would be manageable for impacted payers and thus not present a substantial burden. For the purposes of this proposal, payers must count each provider who queries the Provider Access API. As we established in the 2024 CMS Interoperability and Prior Authorization final rule, the Provider Access API should be available to all providers, whether they are an individual, a facility, or a group of providers who have come together as an accountable care organization (ACO), who are appropriately licensed, provide items and services, or drugs eligible for coverage by the payer, and are enrolled with the payer or in the payer's provider network. Though we do not require payers to share patient data with out-of-network or unenrolled providers, we encourage them to do so to the extent permitted by law if they can verify a treatment relationship (89 FR 8790 and 8791). This proposed approach ensures payers would comprehensively report all usage of the Provider Access API, including out-of-network and unenrolled providers where applicable. We believe that impacted payers would be able to obtain these metrics based on their records of which providers have been authenticated and authorized to receive requested patient data. We also recognize, however, that there may be other ways for these payers to obtain these metrics, as well as other outstanding factors that they would need to address to obtain the metrics that we may not be considering. We propose that, beginning in 2028, impacted payers be required to annually report Payer-to-Payer API usage metrics in the form of aggregated, de-identified data. MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be required to report these metrics directly to CMS and Medicaid managed care plans and CHIP managed care entities would be required to report these metrics to states. Specifically, impacted payers would be required to report all of the following metrics about their Payer-to-Payer API: The percent of patients who have opted in to the payer to payer data exchange. The total number of unique patients whose data have been sent to other payers. The total number of unique patients whose data have been received from other payers. We believe that by monitoring the patient opt in rate, we could better understand patient receptiveness to payer to payer data exchange, as well as how impacted payers are implementing it. For example, this information may identify potential barriers to patient opt in, such as unclear patient educational resources. We propose that, beginning in 2028, impacted payers would be required to annually report Prior Authorization API usage metrics in the form of aggregated, de-identified data. MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be required to report these metrics directly to CMS and Medicaid managed care plans and CHIP managed care entities would be required to report these metrics to states. Specifically, impacted payers would be required to report all of the following metrics about their Prior Authorization API: The total number of unique providers who request a prior authorization for items, services, or drugs through their Prior Authorization API. The number of unique prior authorization requests for items, services, and drugs received through their Prior Authorization API. The percentage of all prior authorization requests that were received through their Prior Authorization API. We finalized a requirement in the 2024 CMS Interoperability and Prior Authorization final rule that impacted payers implement and maintain a Prior Authorization API to facilitate electronic prior authorization for providers to send prior authorization requests and receive decisions from payers.\246\ While we strongly encourage [[Page 19974]] providers to use the Prior Authorization API, specific requirements regarding provider adoption are implemented by other programs, such as the Electronic Prior Authorization measures in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We believe that these additional data regarding provider usage would complement the data we would eventually receive from MIPS eligible clinicians, eligible hospitals, and CAHs reporting the Electronic Prior Authorization measures under those programs (89 FR 8909 through 8927). Understanding how many providers are adopting the processes to send and receive electronic prior authorizations through the API would give CMS information to shape future interoperability and prior authorization policies. --------------------------------------------------------------------------- \246\ See 42 CFR 422.122(b) for MA organizations, 42 CFR 431.80(b) for state Medicaid FFS programs, 42 CFR 457.732(b) for state CHIP FFS programs, through cross reference to 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(b) for individual market QHP issuers on the FFEs. --------------------------------------------------------------------------- In summary, we request comment on our proposals in the CFR citations listed in Table 10, and specifically on the following: The proposal to require impacted payers to report metrics about the usage of the Provider Access, Payer-to-Payer, and Prior Authorization APIs in the form of aggregated, de-identified data.