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

ASTP/ONC received approximately 270 comment submissions on the broad

range of proposals included in the “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” proposed rule (HTI-2 Proposed Rule) (89 FR 63498). We thank all commenters for their thoughtful input. For the purposes of this final rule, we have reviewed and responded to comments on a narrowed set of proposals. Specifically, we summarize and respond to comments related to proposals to:

Update or adopt certification criteria for electronic prescribing, real-time prescription benefit capabilities, provider prior authorization APIs, and related proposals;

Adopt criteria for “modular API capabilities” related to decision support interventions and subscriptions capabilities;

Adopt implementation specifications supporting electronic prior authorization criteria;

Adopt additional implementation specifications that can support exchange of clinical data, administrative data, and provider directory information with payers; and

Update code sets related to medications referenced in certain criteria finalized in the rule.

Comments received in response to other proposals from the HTI-2 Proposed Rule are beyond the scope of this final rule, are still being reviewed and considered, and may be the subject of subsequent final rules related to such proposals in the future. 2. Statutory Basis

The Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created “Title XXX--Health Information Technology and Quality” (Title XXX) to improve healthcare quality, safety, and efficiency through the promotion of health IT and electronic health information (EHI) exchange.

The 21st Century Cures Act (Pub. L. 114-255) (Cures Act) was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, through Title IV--Delivery, amended the HITECH Act by modifying or adding certain provisions to the PHSA relating to health IT.

Section 1860D-4(o) of the Act, as added by section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, Public Law 116-260 (CAA, 2021), requires sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) that meet the requirements described in section 1860D-4(o)(2) of the Act, after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. For purposes of the requirement to implement a real-time benefit tool in section 1860D-4(o)(1) of the Act, section 1860D-4(o)(2)(A) of the Act provides that one of the requirements for an RTBT is that it can integrate with electronic prescribing and EHR systems of prescribing healthcare professionals for the transmission of formulary and benefit information in real time to such professionals. Section 1860D-4(o) of the Act requires incorporation of RTBTs within both the Medicare Part D prescription drug program and the ONC Health IT Certification Program (Certification Program). Specifically, section 119(b) of the CAA, 2021 amends the definition of a “qualified electronic health record” (qualified EHR) in section 3000(13) of the PHSA to add a new subparagraph (C) that requires that a qualified EHR must include (or be capable of including) an RTBT. a. Standards, Implementation Specifications, and Certification Criteria

The HITECH Act established two Federal advisory committees, the Health IT Policy Committee (HITPC) and the Health IT Standards Committee (HITSC). Each was responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria.

Section 4003(e) of the Cures Act amended sections 3002 and 3003 of the PHSA by replacing, in an amended section 3002, the HITPC and HITSC with one committee named the Health Information Technology Advisory Committee (Health IT Advisory Committee or HITAC). Section 3002(a) of the PHSA, as added by the Cures Act, establishes that the HITAC recommends to the National Coordinator policies and standards, implementation specifications, and certification criteria, relating to the implementation of a health information technology infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1) of the PHSA, this includes recommending to the National Coordinator a policy framework to advance interoperable health information technology infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) of the PHSA specifies that in general, the HITAC shall recommend to the National Coordinator for purposes of adoption under section 3004, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Like the process previously required of the former HITPC and HITSC, section 3002(b)(5) of the PHSA requires the HITAC to develop a schedule, updated annually, for the assessment of policy recommendations, which the Secretary publishes in the Federal Register.

Section 3004 of the PHSA establishes a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1) of the PHSA, the Secretary is required, in consultation with representatives of other relevant federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) of the PHSA and subsequently determine whether to propose the adoption of such standards, implementation specifications, or certification criteria. Section 3004(a)(3) of the PHSA requires the Secretary to publish all such determinations in the Federal Register.

Section 3004(b)(3) of the PHSA, titled, Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the HITAC. We consider this provision in the broader context of the HITECH Act and Cures Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria. 3. ONC Health IT Certification Program Rules

Section 3001(c)(5) of the PHSA provides the National Coordinator with

the authority to establish a certification program or programs for the voluntary certification of health IT. Section 3001(c)(5)(A) of the PHSA specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted under section 3004 of the PHSA. The certification program(s) must also include, as appropriate, testing of the technology in accordance with section 13201(b) of the HITECH Act. Section 13201(b) of the HITECH Act requires that, with respect to the development of standards and implementation specifications, the Director of NIST shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. Section 13201(b) of the HITECH Act also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non-federal laboratories to perform testing.

Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D) of the PHSA, which requires the Secretary, through notice and comment rulemaking, to require conditions of certification and maintenance of certification for the Certification Program. Specifically, the health IT developers or entities with technology certified under the Certification Program must, in order to maintain such certification status, adhere to certain conditions and maintenance of certification requirements concerning information blocking; assurances regarding appropriate exchange, access, and use of electronic health information; communications regarding health IT; application programming interfaces (APIs); real world testing; attestations regarding certain conditions and maintenance of certification requirements; and submission of reporting criteria under the EHR Reporting Program in accordance with section 3009A(b) of the PHSA. a. Regulatory History

The Secretary issued an interim final rule with request for comments on January 13, 2010, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 2014), which adopted an initial set of standards, implementation specifications, and certification criteria. On March 10, 2010, the Secretary issued a proposed rule, “Proposed Establishment of Certification Programs for Health Information Technology” (75 FR 11328), that proposed both temporary and permanent certification programs for the purposes of testing and certifying health IT. A final rule establishing the temporary certification program was published on June 24, 2010, “Establishment of the Temporary Certification Program for Health Information Technology” (75 FR 36158), and a final rule establishing the permanent certification program was published on January 7, 2011, “Establishment of the Permanent Certification Program for Health Information Technology” (76 FR 1262).

We have engaged in multiple rulemakings to update standards, implementation specifications, certification criteria, and the Certification Program, a history of which can be found in the October 16, 2015, final rule “2015 Edition Health Information (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (80 FR 62602) (2015 Edition Final Rule). The history can be found at 80 FR 62606. A final rule making corrections and clarifications was published for the 2015 Edition Final Rule on December 11, 2015 (80 FR 76868), to correct preamble and regulatory text errors and clarify requirements of the Common Clinical Data Set (CCDS), the 2015 Edition privacy and security certification framework, and the mandatory disclosures for health IT developers.

The 2015 Edition Final Rule established a new edition of certification criteria (“2015 Edition health IT certification criteria” or “2015 Edition”) and a new 2015 Edition Base EHR definition. The 2015 Edition established the minimum capabilities and specified the related minimum standards and implementation specifications that certified EHR technology (CEHRT) would need to include to support the achievement of “meaningful use” by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs). The Medicare and Medicaid EHR Incentive Programs are now referred to as the Medicare Promoting Interoperability Program and the Merit-based Incentive Payment System (MIPS) Promoting Interoperability performance category.\409\ The final rule also adopted a proposal to change the Program's name to the “ONC Health IT Certification Program” from the ONC HIT Certification Program, modified the Certification Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised Principles of Proper Conduct for ONC-ACBs.

\409\ Section 101(b) of the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) (Pub. L. 114-10, April 16, 2015) sunset the Medicare EHR Incentive Program for Eligible Professionals, set forth at section 1848(o) of the Act. Section 1848(o)(2) of the Act has been incorporated into the MIPS Promoting Interoperability performance category's requirements via section 1848(q)(2)(B)(iv) of the Act. See the Medicare Program; Merit-Based Incentive Payment System (MIPS) and Alternative Payment Model (APM) Incentive Under the Physician Fee Schedule, and Criteria for Physician-Focused Payment Models (the CY 2017 Quality Payment Program) final rule with comment period (81 FR 77018 and 77019) for more information regarding the sunsetting of the Medicare EHR Incentive Program for Eligible Professionals. The Medicaid EHR Incentive Program sunset in 2021 (84 FR 42592).

After issuing a proposed rule on March 2, 2016, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 11056), we published a final rule by the same title (81 FR 72404) (EOA Final Rule) on October 19, 2016. The EOA Final Rule finalized modifications and new requirements under the Certification Program, including provisions related to our role in the Certification Program.

On March 4, 2019, the Secretary published a proposed rule titled, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (84 FR 7424) (ONC Cures Act Proposed Rule). The proposed rule proposed to implement certain provisions of the Cures Act that would advance interoperability and support the access, exchange, and use of electronic health information.

On May 1, 2020, a final rule was published titled, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (85 FR 25642) (ONC Cures Act Final Rule). The final rule implemented certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health IT developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. The final rule also

implemented certain parts of the Cures Act to support patients' access to their EHI, and the implementation of information blocking policies that support patient electronic access. Additionally, the final rule modified the 2015 Edition health IT certification criteria and Certification Program in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as improving patient and health care provider access to EHI and promoting competition. On November 4, 2020, the Secretary published an interim final rule with comment period titled, “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70064) (Cures Act Interim Final Rule). The interim final rule extended certain compliance dates and timeframes adopted in the ONC Cures Act Final Rule to offer the healthcare system additional flexibilities in furnishing services to combat the COVID-19 pandemic, including extending the applicability date for information blocking provisions to April 5, 2021.

On April 18, 2023, the Secretary published a proposed rule titled, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (88 FR 23746) (HTI-1 Proposed Rule). The HTI-1 Proposed Rule proposed to implement the Electronic Health Record (EHR) Reporting Program provision of the Cures Act by establishing new Conditions and Maintenance of Certification requirements for health IT developers under the Certification Program. The HTI-1 Proposed Rule also proposed to make several updates to certification criteria and implementation specifications recognized by the Certification Program, including revised certification criterion for: “clinical decision support” (CDS), “patient demographics and observations”, and “electronic case reporting.” The HTI-1 Proposed Rule also proposed to establish a new baseline version of the United States Core Data for Interoperability (USCDI). Additionally, the HTI-1 Proposed Rule proposed enhancements to support information sharing under the information blocking regulations.

On January 9, 2024, the Secretary issued the “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” final rule (HTI-1 Final Rule), which implemented the EHR Reporting Program provision of the 21st Century Cures Act and established new Conditions and Maintenance of Certification requirements for health IT developers under the Certification Program (89 FR 1192). The HTI-1 Final Rule also made several updates to certification criteria and standards recognized by the Certification Program. The Certification Program updates included revised certification criteria for “decision support interventions,” “patient demographics and observations,” and “electronic case reporting,” as well as adopted a new baseline version of the USCDI standard, USCDI Version 3. Additionally, the HTI-1 Final Rule provided enhancements to support information sharing under the information blocking regulations. Through these provisions, we sought to advance interoperability, improve algorithm transparency, and support the access, exchange, and use of EHI. The HTI-1 Final Rule also updated numerous technical standards in the Certification Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs for health IT developers and users of health IT.

On November 15, 2023, the Secretary issued a proposed rule titled, “Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications” (88 FR 78476). This proposed rule proposed to adopt the National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit standard version 13.

On June 17, 2024, the Secretary issued the “Medicare Program; Medicare Prescription Drug Benefit Program; Health Information Technology Standards and Implementation Specifications” final rule (Part D and Health IT Standards Final Rule) (89 FR 51238 through 51265). This final rule adopted the NCPDP Real-Time Prescription Benefit standard version 13 in 45 CFR 170.205(c)(1) and incorporated this standard by reference in 45 CFR 170.299(k). In this final rule, CMS also adopted requirements for Part D sponsors to use the standard in in 45 CFR 170.205(c)(1) when implementing an RTBT.

On August 4, 2024, the Secretary published a proposed rule titled Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (89 FR 63498) (HTI-2 Proposed Rule). 4. ONC Health IT Certification Program Updates a. Standards and Implementations Specifications (1) National Technology Transfer and Advancement Act

The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A-119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to electing only standards developed or adopted by voluntary consensus bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. Agencies have the discretion to decline the use of existing voluntary consensus standards if it is determined that such standards are inconsistent with applicable law or otherwise impractical, and instead use a government-unique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A-119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that: meet the agency's regulatory, procurement or program needs; deliver favorable technical and economic outcomes; and are widely utilized in the marketplace. In this final rule, all of the standards adopted are voluntary consensus standards. (2) Compliance With Adopted Standards and Implementation Specifications

In accordance with Office of the Federal Register regulations related to “incorporation by reference,” 1 CFR part 51, which we follow when we adopt proposed standards and implementation specifications in any subsequent final rule, the entire standard or implementation specification document is deemed published in the Federal Register when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the standard and

implementation specification includes the entire document unless we specify otherwise. For example, for the HL7 (Fast Healthcare Interoperability Resources) FHIR[supreg] Da Vinci--Coverage Requirements Discovery Implementation Guide, Version 2.0.1--STU 2 (CRD IG) adopted in section IX.B.4.b.(6). of the preamble of this final rule, health IT certified to certification criteria referencing this IG would need to demonstrate compliance with all mandatory elements and requirements of the IG unless otherwise specified. If an element of the IG is optional or permissive in any way, it would remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text would supersede the permissiveness of the IG. (3) “Reasonably Available” to Interested Parties

The Office of the Federal Register has established requirements for materials (for example, standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). To comply with these requirements, in section XI.B.4.b.(8). (“Incorporation by Reference”) of the preamble of this final rule, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we are adopting and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about these standards and implementation specifications throughout the relevant sections of the final rule. b. New and Revised Standards and Certification Criteria (1) Minimum Standards Code Sets Updates

In the final rule titled “Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology” (77 FR 54163) we discussed and revised our policy for adopting newer versions of minimum standards code sets, noting that this approach improves interoperability while creating little additional burden through the inclusion of new code sets (see 45 CFR 170.555 and 77 FR 54268). In the 2015 Edition Final Rule we made additional updates to code sets subject to this policy (80 FR 62612). As we stated in the HTI-1 Final Rule, when determining whether to propose newer versions of minimum standards code sets, we consider the impact on interoperability and whether a newer version would require substantive effort for developers of certified health IT to implement (89 FR 1224). If adopted, newer versions of minimum standards code sets serve as the baseline for certification and developers of certified health IT may use newer versions of these adopted standards on a voluntary basis. We reiterate that while minimum standard code sets update frequently, perhaps several times in a single year, these updates are confined to concepts within the code system, not substantive changes to the standards themselves.

In this final rule, we are only finalizing proposals in the HTI-2 Proposed Rule for minimum standard code sets relevant to medications in 45 CFR170.207(d), as these standards are referenced in two of the certification criteria in this final rule: the updated “electronic prescribing” criterion in 45 CFR 170.315(b)(3) and the new “real-time prescription benefit” criterion in 45 CFR 170.315(b)(4). (2) Medications

In the HTI-2 Proposed Rule, we proposed to revise the citations in 45 CFR 170.207(d) to improve organization of this section (89 FR 63527). Specifically, we proposed to revise 45 CFR 170.207(d)(1) to list standards for clinical drugs and to reference multiple releases of RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine. We proposed in 45 CFR 170.207(d)(1)(ii) to reference RxNorm, December 4, 2023, Full Monthly Release and incorporate it by reference in 45 CFR 170.299(r). We proposed to move the standard adopted in 45 CFR 170.207(d)(1), RxNorm, July 5, 2022, Release, to 45 CFR 170.207(d)(1)(i), and that the adoption of this standard would expire on January 1, 2028. We proposed to move the standard adopted in 45 CFR 170.207(d)(3), RxNorm, September 8, 2015, Release, to 45 CFR 170.207(d)(1)(iii) and proposed that the adoption of this standard would expire on January 1, 2026. Finally, we proposed to move National Drug Codes, currently included via cross- reference in 45 CFR 170.207(d)(4), to 45 CFR 170.207(d)(2). We noted that 45 CFR 170.207(d)(2) was reserved at the time of the proposed rule. We also proposed to reserve 45 CFR 170.207(d)(3) and remove 45 CFR 170.207(d)(4).

The following is a summary of the comments we received on the HTI-2 Proposed Rule and our responses:

Comment: We did not receive any public comments specific to the proposed updates to the code sets in 45 CFR 170.207(d) and reorganization of this section. Commenters generally supported our proposals to update minimum code sets.

Response: We thank commenters for their support. For a discussion of public comments on our proposals referencing the code sets in 45 CFR 170.207(d) as part of the “electronic prescribing” criterion in 45 CFR 170.315(b)(3) and the “real time prescription benefit” criterion in 45 CFR 170.315(b)(4), we refer readers to sections XI.B.4.b.(3) and XI.B.4.b.(4) of the preamble of this final rule, respectively.

After consideration of the public comments, we are finalizing the adoption of the proposed version of RxNorm as RxNorm, December 4, 2023, Full Update Release, and incorporating it by reference in 45 CFR 170.299(r). We are also finalizing the proposed reorganization of 45 CFR 170.207(d), with modification. To improve the organization of the regulation text, we are finalizing the adoption of the most recent version of RxNorm in 45 CFR 170.207(d)(1)(i) (December 4, 2023 release), and renumbering the versions with prior release dates to be in 45 CFR 170.207(d)(1), at (ii) (July 5, 2022 release) and (iii) (September 8, 2015 release).

We are not finalizing the expiration dates that we proposed in the HTI-2 Proposed Rule, specifically, an expiration date of January 1, 2028, for the RxNorm July 5, 2022 release proposed in 45 CFR 170.207(d)(1)(i), and an expiration date of January 1, 2026, for the RxNorm September 8, 2015 release proposed in 45 CFR 170.207(d)(1)(iii). As RxNorm is identified as a minimum standard code set, any release of RxNorm that we adopt in regulation serves as the baseline for certification. Under our policy in 45 CFR 170.555, developers of certified health IT may use newer versions of these adopted standards on a voluntary basis. Given the flexibility available for use of the minimum standard code sets, we believe finalizing expiration dates for certain releases of RxNorm may lead to confusion as we have finalized the use of expiration dates in other instances where we are seeking to ensure health IT developers utilize a new standard beginning on a certain date. However, as stated, under our policy for minimum standards code sets in 45 CFR 170.555, health IT

developers may voluntarily move to updated RxNorm releases. (3) Revised Electronic Prescribing Certification Criterion

In the HTI-2 Proposed Rule, we proposed to update the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3) (89 FR 63524). The proposed updates included updating the core standard for electronic prescribing to NCPDP SCRIPT standard version 2023011,\410\ which was cross-referenced in 45 CFR 170.205(b)(2) in the proposed text in 45 CFR 170.315(b)(3)(ii)(A). We also proposed revisions to the transactions within the SCRIPT standard that would be required for the updated certification criterion and proposed to remove a number of transactions that are currently identified as optional for the criterion. Finally, we proposed to remove 45 CFR 170.315(b)(3)(i) from the CFR upon the effective date of this rule and reserve it as this version of the certification criterion is no longer valid for use in the Certification Program.

\410\ See https://standards.ncpdp.org/Access-to-Standards.aspx.

(a) Electronic Prescribing Standard

In the Part D and Health IT Standards Final Rule, which appeared in the Federal Register on June 17, 2024 (89 FR 51238 through 51265), we adopted NCPDP SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2). We also finalized an expiration date for NCPDP SCRIPT standard version 2017071 of January 1, 2028, in 45 CFR 170.205(b)(1), which reflected a delay of one year from the expiration date we had proposed (88 FR 78501). We also finalized the removal of the NCPDP SCRIPT standard version 10.6, which was located in 45 CFR 170.205(b)(2) (89 FR 51258 and 51259). The finalization of these policies in the Part D and Health IT Standards Final Rule, and CMS' finalization of cross references to 45 CFR 170.205(b) in their requirements for the Part D Program, reflects a unified approach to aligning standards adoption across HHS programs that impact a common set of participants (88 FR 78486 through 78494).

In the HTI-2 Proposed Rule (89 FR 63524), we noted that we previously proposed to adopt NCPDP SCRIPT standard version 2022011 and made other proposals in the “Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, Medicare Parts A, B, C, and D Overpayment Provisions of the Affordable Care Act and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications” proposed rule (2024 Part C/D Proposed Rule), which appeared in the Federal Register on December 27, 2022 (87 FR 79555). However, we subsequently withdrew these proposals in the “Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications” proposed rule (2025 Part C/D Proposed Rule), which appeared in the Federal Register on November 15, 2023 (88 FR 78476), and instead proposed to adopt the NCPDP SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2) (88 FR 78501 through 78502).

In the HTI-2 Proposed Rule, we proposed in 45 CFR 170.315(b)(3)(ii)(A) that for the time period up to and including December 31, 2027, a Health IT Module certified to the “electronic prescribing” certification criterion at 45 CFR 170.315(b)(3) must enable a user to perform certain prescription-related electronic transactions in accordance with the standard specified in 45 CFR 170.205(b)(1) (NCPDP SCRIPT standard version 2017071) or 45 CFR 170.205(b)(2) (NCPDP SCRIPT standard version 2023011) (89 FR 63524). We also proposed that on and after January 1, 2028, a Health IT Module certified to the “electronic prescribing” certification criterion must enable a user to perform the following prescription-related electronic transactions in accordance with only the standard specified in 45 CFR 170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011). We stated that this means that a health IT developer may continue to maintain health IT certification conformance to NCPDP SCRIPT standard version 2017071 (in 45 CFR 170.205(b)(1)) for the time period up to and including December 31, 2027. We noted that on and after January 1, 2028, consistent with our policy in 45 CFR 170.402(b), developers of certified health IT with Health IT Modules certified to the “electronic prescribing” certification criterion would need to update those Health IT Modules to the standard in 45 CFR 170.205(b)(2) and provide them to customers. This is consistent with the date of January 1, 2028, that we finalized for the expiration of NCPDP SCRIPT standard version 2017071 in 45 CFR 170.205(b)(1) in the Part D and Health IT Standards Final Rule (89 FR 51259).

The following is a summary of the comments we received on the HTI-2 Proposed Rule and our responses:

Comment: Commenters supported our proposal to require the use of NCPDP SCRIPT standard version 2023011 in an updated version of the “electronic prescribing” criterion. Commenters stated that this version of the standard includes several new elements that will enhance the usability of the standard and add important functionality. Other commenters stated this update will enhance interoperability, improve patient safety and streamline prescription processes. A commenter highlighted features of this version of the standard that will be beneficial for pediatric populations.

Response: We thank the commenters for their support. We agree that the proposed version of the NCPDP SCRIPT standard includes important enhancements that will improve the interoperability of electronic prescription information.

Comment: Many commenters supported the proposal that health IT developers may maintain health IT certification conformance with the current version of NCPDP SCRIPT standard version 2017071 for the time period up to and including December 31, 2027, and must, by January 1, 2028, use NCPDP SCRIPT standard version 2023011. Commenters appreciated the alignment of this date with the requirement for Medicare Part D plan sponsors to implement the NCPDP SCRIPT standard version 2023011 by January 1, 2028, stating that this alignment will improve the functionality and overall interoperability of clinicians' electronic prescribing systems. Commenters also supported the proposal to allow health IT developers time to update their systems while maintaining certification for the current version of the SCRIPT standard. Another commenter stated that the proposed timeline would ensure developers and clinicians can adequately plan and prepare for these updates.

Response: We thank commenters for their support. We believe that the proposed timeline requiring health IT developers to update Health IT Modules certified to the “electronic prescribing criterion to NCPDP SCRIPT standard version 2023011 by January 1, 2028, will provide a reasonable amount of time for health IT developers to develop updated products and provide these products to customers.

Comment: A commenter recommended that ASTP/ONC extend the timeline by one year and require use of the NCPDP SCRIPT standard version 2023011 by January 1, 2029. The commenter suggested that while the standards are fully developed, the standards are not yet integrated into health IT vendor systems. The commenter stated the transition to the updated standard will take time, and health plan IT resources are invested in working toward the launch of CMS APIs in January 2027, which do not incorporate prescription drug requirements.

Response: We disagree with the commenter that the deadline for updating Health IT Modules to the updated version of the “electronic prescribing” criterion should be extended for an additional year. In the Part D and Health IT Standards Final Rule, we adopted NCPDP SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2). We also finalized an expiration date for NCPDP SCRIPT standard version 2017071 of January 1, 2028, in 45 CFR 170.205(b)(1), which reflected a delay of one year from the expiration date we had proposed (88 FR 78501). We believe this period will provide health IT developers with sufficient time for development and implementation of an updated version of an existing criterion. We further clarify that the proposals in this final rule will affect health IT developers with Health IT Modules certified to the “electronic prescribing” criterion under the Certification Program.

After consideration of the public comments, we are finalizing our proposals with modifications. Specifically, we are revising and reorganizing 45 CFR 170.315(b)(3)(ii)(A) to increase clarity around the timelines for use of standards in the “electronic prescribing” criterion. We are finalizing in 45 CFR 170.315(b)(3)(ii)(A)(1) that a Health IT Module certified to the “electronic prescribing” certification criterion at 45 CFR 170.315(b)(3) must enable a user to perform specified prescription-related electronic transactions in accordance with the standard specified in 45 CFR 170.205(b)(1) (NCPDP SCRIPT standard version 2017071) or 45 CFR 170.205(b)(2) (NCPDP SCRIPT standard version 2023011) for the time period up to and including December 31, 2027. We are also finalizing in 45 CFR 170.315(b)(3)(ii)(A)(2) that a Health IT Module certified to the “electronic prescribing” criterion may only use the standard specified in 45 CFR 170.205(b)(2) on and after January 1, 2028. (b) Proposed Transactions

In the HTI-2 Proposed Rule (89 FR 63524 through 63526), we proposed the following updates and changes to the transactions identified for the “electronic prescribing” criterion in 45 CFR 170.315(b)(3)(ii). (i) New Prescriptions (NewRx) (45 CFR 170.315(b)(3)(ii)(A)(3)(i))

We proposed in 45 CFR 170.315(b)(3)(ii)(A)(1) to revise the name used for the NewRx transaction in our regulations from “Create New Prescriptions (NewRx)” to “New Prescriptions (NewRx).” We proposed this change to align with updated terminology used by NCPDP within the SCRIPT standard.

The following is a summary of the comments we received and our responses:

Comment: Commenters supported the revision of the name used for the NewRx transactions from “Create New Prescriptions (NewRx)” to “New Prescriptions (NewRx)” to align with the updated terminology used in NCPDP SCRIPT standard version 2023011.

Response: We thank commenters for their support.

After consideration of the comments and due to the reorganization we are finalizing of 45 CFR 170.315(b)(3)(ii)(A), we are finalizing our proposal to update the name of the transaction to “New Prescriptions (NewRx)” in 45 CFR 170.315(b)(3)(ii)(A)(3)(i). (ii) Request and Receive Medication History (45 CFR 170.315(b)(3)(ii)(A)(3)(vi))

We proposed to remove the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) as a requirement for the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3)(ii)(A)(6) and reserve this section.

In the ONC Cures Act Final Rule, ONC finalized the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) in the “electronic prescribing” certification criterion (85 FR 25682). Since the final rule was published, health IT developers and health care providers have described several challenges meeting this requirement, including development burden; lower than expected adoption and use; and duplicative, overlapping, and sometimes contradictory data from multiple sources. Due in part to these challenges and market forces that have prevented some developers from adopting this functionality natively, developers have had to rely on third-party applications to achieve certification, and in some cases, are unable to achieve certification for electronic prescribing altogether. As such, in the HTI-2 Proposed Rule (89 FR 63525), we proposed these transactions would no longer be required for certification to the “electronic prescribing” criterion in 45 CFR 170.315(b)(3)(ii)(A)(6). We also proposed to reserve 45 CFR 170.315(b)(3)(ii)(A)(6).

In the HTI-2 Proposed Rule (89 FR 63525), we encouraged developers to continue to support these transactions where possible and to follow industry efforts to advance the exchange of patient medication histories through various means such as health information exchanges, health information networks, and prescription drug monitoring programs. We further noted that (if our proposals were finalized) health IT developers would not be required to demonstrate compliance with these transactions in order for a Health IT Module to be certified to the updated version of the “electronic prescribing” criterion, but that CMS still requires use of these transactions when appropriate for electronic exchange of prescription-related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals (88 FR 78486). In other words, despite not needing to demonstrate technical conformance for certification, health IT developers would still need to support these transactions for customers who utilize these transactions in order to exchange electronic Part D medication history information among Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals in compliance with requirements at 42 CFR 423.160(b)(1)(i)(U).

The following is a summary of the comments we received and our responses:

Comment: A commenter supported the proposal to remove the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) as a requirement for the “electronic prescribing” certification criterion and reserve this section.

Response: We thank commenters for their support.

Comment: Several commenters opposed the removal of request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) from the electronic prescribing certification criterion. A commenter noted that medication history is a critical piece of information for episodic

treatment as well as identifying lapses or gaps in care with medication changes over a period of time. Several commenters noted the proposal seems potentially harmful to patient safety as medication history queries are crucial for safe electronic prescribing and medication reconciliation. A commenter acknowledged the existing challenges with adoption and implementation of the request and receive medication history transactions, but believed the transaction should not be removed if it will support the ultimate goal of achieving seamless access to this data in the EHR for clinicians. A commenter disagreed that the rationale that some developers were unable to achieve certification for electronic prescribing was sufficient for removal of the transactions, stating that health IT certification criteria should be determined based on impact to patient care rather than burden for health IT developers. Other commenters suggested separating this transaction into a distinct criterion to address developer concerns and providing additional support or guidance to vendors struggling with this implementation, rather than removing the requirement entirely.

Response: We appreciate commenters' feedback, and we agree that the ability for providers to easily obtain medication histories is crucial to patient care including for patient safety and medication reconciliation. We appreciate commenters' concerns about the rationale we included as part of the proposal. While we believe it is important to consider the burden on health IT developers and challenges that developers may experience in meeting Certification Program requirements, we seek to balance these concerns with the potential for use of certified health IT to improve patient care and advance the exchange of information across participants in the health care system. We agree with commenters that there is significant value to patients and health care providers of continuing to require support for medication history, which must be weighed against the issues identified in the proposed rule. Regarding the recommendation to adopt a separate criterion focused on this transaction, we note that we did not propose such a criterion, and believe that developing multiple certification criteria which require conformance with the NCPDP SCRIPT standard could increase administrative complexity for health IT developers and users of certified health IT.

After consideration of the public comments received, we are not finalizing our proposal to remove the request and receive medication history transactions (RxHistoryRequest and RxHistoryResponse) as required for the “electronic prescribing” criterion. Due to the reorganization we are finalizing of 45 CFR 170.315(b)(3)(ii)(A), we are retaining the transactions for RxHistoryRequest and RxHistoryResponse in 45 CFR 170.315(b)(3)(ii)(A)(3)(vi). We recognize the need for Health IT Modules to support capabilities related to medication history, and we are keeping these transactions in the Certification Program at this time, as supported by commenters. We will continue to monitor the request and receive medication history transactions for ongoing use, interest and value. (iii) Electronic Prior Authorization Transactions (45 CFR 170.315(b)(3)(ii)(A)(3)(x))

In the HTI-2 Proposed Rule (89 FR 63525), we proposed to require support for the following transactions for electronic prior authorization as part of the “electronic prescribing” criterion, at the time a health IT developer presents a Health IT Module for certification using the standard in 45 CFR 170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011): PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification.

In the ONC Cures Act Final Rule, ONC adopted these transactions in 45 CFR 170.315(b)(3)(ii)(B)(9) as optional for the “electronic prescribing” criterion (85 FR 25678). We stated that we adopted these transactions to support alignment with the “Medicare Program; Secure Electronic Prior Authorization for Medicare Part D” proposed rule (84 FR 28450), in which CMS proposed to require Part D sponsors to support NCPDP SCRIPT standard version 2017071 for four electronic prior authorization transactions, and proposed that prescribers would be required to use that standard when performing electronic prior authorization transactions for Part D covered drugs they wish to prescribe to Part D eligible individuals (85 FR 25685). CMS subsequently finalized in the “Medicare Program; Secure Electronic Prior Authorization for Medicare Part D” final rule in 42 CFR 423.160(b)(8)(ii) that beginning January 1, 2022, Part D sponsors and prescribers must use the NCPDP SCRIPT standard version 201701 (85 FR 86832). The ONC Cures Act Final Rule allowed health IT developers seeking certification to support these transactions through optional testing but did not require developers to certify health IT to these transactions.

In the HTI-2 Proposed Rule (89 FR 63525), we stated we received feedback from the public in support of requiring these transactions, most recently in response to the “Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (Electronic Prior Authorization RFI), which appeared in the Federal Register on January 24, 2022 (87 FR 3475). Commenters stated that requiring these transactions in the certification criterion would help to advance interoperability and reduce administrative burden around prior authorization processes for medications. We agreed with this input, and in the HTI-2 Proposed Rule we proposed to remove PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse in 45 CFR 170.315(b)(3)(ii)(B)(9) as optional, and to require these transactions in 45 CFR 170.315(b)(3)(ii)(A)(10) for the “electronic prescribing” certification criterion at the time a health IT developer presents a Health IT Module for certification using NCPDP SCRIPT standard version 2023011.

ONC also charged the HITAC to establish a Task Force in order to provide input and recommendations in response to the Electronic Prior Authorization RFI; the Task Force's recommendations were approved and submitted to ONC on March 10, 2022.\411\ In the HTI-2 Proposed Rule (89 FR 63525), we stated that if finalized, the proposals would implement the Task Force's recommendation to update these prior authorization transactions from “optional” in the current version of the “electronic prescribing” certification criterion to “mandatory,” to better support electronic prior authorization processes for drugs covered under a prescription benefit.

\411\ https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf.

We also proposed to adopt the PANotification transaction in 45 CFR 170.315(b)(3)(ii)(A)(10) as a required transaction for the “electronic prescribing” criterion to further support the exchange of electronic prior authorization information. We noted that PANotification is a new transaction introduced since NCPDP SCRIPT standard version 2017071. The PANotification transaction is used to alert the pharmacist or prescriber when

a prior authorization has been requested or when a prior authorization determination has been received. The PANotification transaction is intended to improve electronic communication between prescribers and pharmacists, and to reduce duplicate submissions of prior authorization requests to payers. Notification may occur via a NewRx, RxChange or RxRenewal transaction, or as a standalone PANotification. We stated that we believe that requiring the PANotification transaction is an important complement to the other proposals related to electronic prior authorization described above.

The following is a summary of the comments we received and our responses:

Comment: Many commenters supported the proposal to require support for the electronic prior authorization transactions as part of the “electronic prescribing” criterion. A commenter stated that requiring prior authorization transactions as part of the criterion would help advance interoperability and reduce administrative burden associated with medication prior authorization processes and improve access to systems enabling electronic prior authorization. Other commenters stated that requiring these transactions would help ensure pharmacy data systems communicate consistently with certified health IT modules, thereby mitigating the need to build different prior authorization processes for different certified health IT systems. Another commenter believed that greater use of electronic prior authorization would address transparency and affordability gaps in the healthcare ecosystem.

Response: We appreciate commenters' support for our proposal to require electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification) as part of the “electronic prescribing” criterion. We agree with commenters that electronic prior authorization is an important capability for reducing the administrative burden associated with prior authorization processes for medications. We also agree that adopting these transactions will support interoperability between prescriber and payer systems and can lead to more efficient investments in technical infrastructure to support electronic exchange of prior authorization information.

Comment: A commenter noted it was unclear if the electronic prior authorization transactions have been tested in the real world to verify that they will achieve the intended goal of automating prior authorizations without also causing serious consequences, such as increasing prescriber burden or driving further consolidation in the EHR market toward a few large developers. The commenter noted that real world testing is critical to ensuring that health IT is effective and interoperable for the physicians, clinical staff, and other end-users that rely on EHRs.

Response: We appreciate commenters' interest in testing of these electronic prior authorization transactions and agree that ongoing testing and evaluation is important to improving standards. We note that the Council for Affordable Quality Healthcare found that in a survey of medical providers that 38 percent of respondents used the NCPDP standard to conduct electronic prior authorization transactions in 2023, an increase of eight percentage points from 2022,\412\ indicating that the electronic prior authorization transactions specified in the NCPDP SCRIPT standard are being used in practice. ASTP/ONC will continue to work with implementers and the standards development community to evaluate findings from the implementation of these transactions. We also note that CMS finalized a requirement that Part D plan sponsors support certain electronic prior authorization transactions in the NCPDP SCRIPT standard version 2017071 in the “Medicare Program; Secure Electronic Prior Authorization for Medicare Part D” which appeared in the Federal Register on December 31, 2020 (85 FR 86824).

\412\ See https://www.caqh.org/hubfs/Issue%20Briefs/CAQH_Insights_NCPDP_SCRIPT_Issue_Brief.pdf.

Finally, we acknowledge the commenters' concerns about provider burden that may be associated with adopting workflows based on these transactions and consolidation in the EHR market that may result from adding regulatory requirements to the “electronic prescribing” criterion. At this time, we believe the potential value of advancing electronic prior authorization and decreasing the administrative burden associated with prior authorization processes outweighs these concerns. However, we will continue to monitor public feedback and available data sources to track the impact of implementation of these transactions.

Comment: A commenter stated that requiring electronic prior authorization transactions was premature without sufficient assurances that the payer community will be ready to support the same standards and enable end-to-end electronic prior authorization for prescriptions. A commenter suggested payers should be the first to adopt electronic prior authorization standards in order to set the standard effectively. Another commenter recognized there are already many payers supporting these transactions, but did not believe that implementing electronic prior authorization would provide value until there is a specific criterion under the Certification Program defining standards for payer adherence. A commenter stated that requirements for payers should mandate the use of codified question sets as part of electronic prior authorization, ensuring that these solutions are not simply digitizing a paper-based process but effectively streamlining it. A commenter suggested ASTP/ONC create a separate criterion for electronic prior authorization functionality.

Response: We appreciate the importance of ensuring that all entities participating in exchange of electronic prior authorization information are using common standards. We note that CMS finalized a requirement that Part D plan sponsors support certain electronic prior authorization transactions in the NCPDP SCRIPT standard version 2017071 in the “Medicare Program; Secure Electronic Prior Authorization for Medicare Part D” which appeared in the Federal Register on December 31, 2020. CMS subsequently updated the version of the NCPDP SCRIPT standard required for electronic prescribing and electronic prior authorization to NCPDP SCRIPT standard version 2023011 by January 1, 2028.

Thus, requirements for Part D plan sponsors to support electronic prior authorization transactions were finalized in advance of the requirements for developers of certified health IT that we are finalizing in this rule, and we believe Part D plan sponsors already have experience supporting these transactions. We agree the availability of a certification criterion for health IT used by Part D plan sponsors may have benefits, for instance, increasing conformance with the standard through required testing. However, we also believe that the combination of the current requirement for Part D plan sponsors to support the NCPDP SCRIPT standard in 42 CFR 423.160 and our requirements for health IT developers will effectively enable interoperability between provider and payer systems when conducting electronic prior authorization for medications.

Regarding the use of codified question sets, we agree with the commenter that

consistent use of question sets by payers, which are supported as part of the electronic prior authorization transactions in the NCPDP SCRIPT standard, could help to further reduce burden for implementers. While requirements for how Part D plan sponsors support electronic prior authorization are out of scope for this rule, we are sharing these comments with the Part D program for consideration.

We do not agree with the commenter that we should create a separate criterion to address electronic prior authorization transactions under the NCPDP SCRIPT standard, as we believe consolidating certification requirements for all transactions specified in the NCPDP SCRIPT standard under a single criterion will minimize burden for health IT developers seeking to support electronic prescribing capabilities within a single Health IT Module.

After consideration of public comments, we are finalizing our proposal to require the transactions PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse and moving these transactions to 45 CFR 170.315(b)(3)(ii)(A)(3)(x), due to the revisions we are finalizing to reorganize 45 CFR 170.315(b)(3)(ii)(A). We are also finalizing our proposal to remove the above mentioned electronic prior authorization transactions from 45 CFR 170.315(b)(3)(ii)(B)(9), where they are identified as optional. We are also finalizing our proposal to include the PANotification transaction as part of the required electronic prior authorization transactions at 45 CFR 170.315(b)(3)(ii)(A)(3)(x). We are finalizing these transactions as required for the “electronic prescribing” certification criterion at the time a health IT developer presents a Health IT Module for certification using the standard finalized at 45 CFR 170.205(b)(2), where we adopted NCPDP SCRIPT standard version 2023011. (iv) Optional Transactions (NewRxRequest, NewRxResponseDenied, RxFillIndicatorChange, GetMessage, Resupply, DrugAdministration, RxTransferRequest, RxTransferResponse, RxTransferConfirm, Recertification, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse) (45 CFR 170.315(b)(3)(ii)(B)(1)-(8))

In the HTI-2 Proposed Rule (89 FR 63526), we proposed to remove the transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)-(8) which are currently identified as “optional” for the “electronic prescribing” certification criterion. We proposed to revise 45 CFR 170.315(b)(3)(ii)(B) to include requirements related to the exchange of race and ethnicity information in 45 CFR 170.315(b)(3)(ii)(B)(1)-(4), which is discussed in greater detail later in this section.

Specifically, we proposed to remove the following transactions in 45 CFR 170.315(b)(3)(ii)(B) upon the effective date of the final rule:

NewRxRequest, NewRxResponseDenied (45 CFR 170.315(b)(3)(ii)(B)(1))

RxFillIndicatorChange (45 CFR 170.315(b)(3)(ii)(B)(2))

GetMessage (45 CFR 170.315(b)(3)(ii)(B)(3))

Resupply (45 CFR 170.315(b)(3)(ii)(B)(4))

DrugAdministration (45 CFR 170.315(b)(3)(ii)(B)(5))

RxTransferRequest, RxTransferResponse, RxTransferConfirm (45 CFR 170.315(b)(3)(ii)(B)(6))

Recertification (45 CFR 170.315(b)(3)(ii)(B)(7))

REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse (45 CFR 170.315(b)(3)(ii)(B)(8))

For completeness, we noted that 45 CFR 170.315(b)(3)(ii)(B) currently has transactions listed in 45 CFR 170.315(b)(3)(ii)(B)(9) related to electronic prior authorization. However, we proposed in the section above to remove 45 CFR 170.315(b)(3)(ii)(B)(9) and add the electronic prior authorization transactions currently in 45 CFR 170.315(b)(3)(ii)(B)(9) as required transactions in 45 CFR 170.315(b)(3)(ii)(A)(10).

We noted that in reviewing data from the Certification Program, we found that very few developers have elected to certify to the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)-(9). We stated that we believe that the low rate of certification to these certification criteria indicates that health IT developers do not see a benefit in obtaining optional certification to these criteria. Accordingly, we stated that removing these optional transactions from the program would reduce the complexity and cost of the Certification Program with minimal impact on health IT developers.

We further noted that CMS requires use of these transactions when appropriate for electronic exchange of prescriptions and prescription- related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals. In other words, despite not needing to demonstrate technical conformance for certification, developers would still need to support these transactions for customers who utilize these transactions in order to exchange information electronically between prescribers and dispensers of Part D drugs for Part D eligible individuals in compliance with requirements in 42 CFR 423.160(b)(1)(i).

We requested comment on our proposal to remove the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)-(8) from the “electronic prescribing” certification criterion. We also stated that alternatively, we considered proposing to require the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)-(8) rather than removing them from the criterion. However, in the HTI-2 Proposed Rule, we did not identify additional reasons to propose to require any of these optional transactions (89 FR 63526). We requested comment on this alternative, including whether commenters believe requiring any of the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)-(8) proposed for removal from the “electronic prescribing” certification criterion would be important to supporting interoperability between certified Health IT Modules and entities subject to Part D electronic prescribing requirements at 42 CFR 423.160.

We referred readers to Table 1A in the HTI-2 Proposed Rule (89 FR 63529) for a comparison of transactions identified in the existing NCPDP SCRIPT standard version 2017071 and the proposed certification criterion based on NCPDP SCRIPT standard version 2023011.

The following is a summary of the comments we received and our responses:

Comment: Many commenters supported removing the transactions in (45 CFR 170.315(b)(3)(ii)(B)(1)-(8)) identified as optional. Some commenters noted removal would streamline the certification process and

promote consistency across certified health IT modules. Commenters noted RxTransfer transactions are not used by physicians but are instead used to transfer prescriptions between pharmacies. Other commenters stated Resupply, DrugAdministration, and Recertification are communications between a long-term or post-acute care facility and a pharmacy, excluding the prescriber system.

Response: We thank commenters for their support. We agree with many of the justifications offered by commenters to remove optional transactions identified as optional, including commenters who indicated that removal would streamline certification processes and promote consistent implementation of Health IT Modules certified to 45 CFR 170.315(b)(3). We further appreciate commenters' feedback regarding specific transactions that are not useful for physicians. Due to the low rate of certification to these optional transactions among health IT developers, we believe that removing certification for these transactions will have minimal impact on prescribers.

Comment: A commenter specifically recommended that the following transactions remain as optional: NewRxRequest, RxFillIndicatorChange, GetMessage and REMS.

Response: We appreciate the continued interest in certain optional transactions in 170.315(b)(3)(ii)(B)(1)-(8). However, commenters did not provide, and we have not identified, reasons to retain these specific optional transactions as part of the certification criterion that outweigh the rationale we provided for proposing to remove these optional transactions related to streamlining the Certification Program and reducing regulatory burden. We will continue to evaluate how these capabilities evolve and may consider whether to propose to require these transactions as part of the “electronic prescribing” criterion in the future.

After consideration of public comments, we are finalizing our proposal to remove the transactions identified as optional in 45 CFR 170.315(b)(3)(ii)(B)(1)-(8) in order to reduce the complexity and cost of the Certification Program. (c) Additional Proposals (i) Signatura (Sig) (45 CFR 170.315(b)(3)(ii)(D))

In 45 CFR 170.315(b)(3)(ii)(D), we proposed that a Health IT Module certified to the “electronic prescribing” criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in 45 CFR 170.205(b)(2) (NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011.

We stated that the Signatura or Sig is the information provided with a prescription to communicate how a prescriber intends for a patient to take a medication. These directions for use are essential for accurate prescription labeling, appropriate patient counseling and education from a pharmacist, and optimal medication use. The NCPDP Structured and Codified Sig Format Implementation Guide,\413\ which is embedded in the NCPDP SCRIPT standard, is intended to standardize the portion of an electronic prescription containing the directions for use using existing, accepted electronic transmission standards, such as NCPDP SCRIPT. A “structured and codified” Sig conveys instructions in a consistent manner by mapping these directions to a defined set of elements representing the different components of these directions (for instance, dosing schedules and administration instructions). We stated that the Structured and Codified Sig Format includes 15 segments, each containing distinct fields to capture potential elements of patient instructions. This is intended to facilitate communication between prescribers and pharmacists, to improve the efficiency of prescribing and dispensing activities, and to help reduce the opportunity for errors. The NCPDP Structured and Codified Sig Format Implementation Guide contains the technical specifications and guidance for implementation of a structured and codified Sig.

\413\ See https://standards.ncpdp.org/Access-to-Standards.aspx.

When conducting electronic prescribing, prescribers frequently transmit the Sig Text segment as unstructured free text, which introduces inconsistency and limits reusability of the directions contained in the Sig, with potential impacts on patient safety and clinical outcomes.\414\ Moreover, when unstructured free text is used, prescribers and pharmacists may have to engage in back-and-forth communication to clarify what is intended in the Sig instructions, increasing burden. In the HTI-2 Proposed Rule (89 FR 63527), we noted that research has shown more than half of all Sig directions sent in an ambulatory setting can be accurately represented by only 25 standardized concepts (for example, the directions “take 1 tablet by oral route every day” and “Take one (1) tablet by mouth once a day” can both be represented as the same Sig concept “Take 1 tablet by mouth once daily”), indicating significant opportunities to reduce variation by expressing these directions through the structured and codified Sig format.\415\

\414\ Schiff, G., Mirica, M.M., Dhavle, A.A., Galanter, W.L., Lambert, B., & Wright, A. (2018). A prescription for enhancing electronic prescribing safety. Health Affairs (Project Hope), 37(11), 1877-1883. doi:https://doi.org/10.1377/hlthaff.2018.0725.

\415\ Yang, Y., Ward-Charlerie, S., Dhavle, A.A., Rupp, M.T., & Green, J. (2018). Quality and Variability of Patient Directions in Electronic Prescriptions in the Ambulatory Care Setting. Journal of managed care & specialty pharmacy, 24(7), 691-699. https://doi.org/10.18553/jmcp.2018.17404.

Previously, in the 2015 Edition Final Rule, we did not finalize our proposal to require a Health IT Module certified to the “electronic prescribing” criterion to enable a user to enter, receive, and transmit codified Sig instructions in a structured format, based on commenters' concerns regarding the readiness of the standard and other issues such as limitations on the length of a Sig within the version of the NCPDP SCRIPT Structured and Codified Sig Format v1.2 available at the time of the proposal (80 FR 62643). We stated that we would reconsider this stance for future rulemaking based on newer versions of the NCPDP SCRIPT Standard Implementation Guide that may provide implementation improvements and finalized an optional certification provision that technology must be able to receive and transmit the reason for the prescription using the indication elements in the SIG segment in 45 CFR 170.315(b)(3)(i) (80 FR 62643). In the ONC Cures Act Final Rule, we also finalized this optional provision in 45 CFR 170.315(b)(3)(ii)(D) (85 FR 25686).

Since the 2015 Edition Final Rule, NCPDP has further advanced the structured and codified Sig format. The most recent version available is the NCPDP Structured and Codified Sig Implementation Guide version 2.2. The structured and codified Sig segment within the NCPDP SCRIPT standard has also been modified; changes to the Sig element from NCPDP SCRIPT standard version 2017017 are discussed in the NCPDP SCRIPT standard version 2023011 Implementation Guide.\416\ As a result of additional improvements made to the structured and codified Sig format, as well as the additional time that industry has had to grow familiar with this functionality, we stated in the HTI-2 Proposed Rule (89 FR 63527) that

we believe that it is appropriate to propose in 45 CFR 170.315(b)(3)(ii)(D) to require that a Health IT Module certified to the “electronic prescribing” criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in 45 CFR 170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using NCPDP SCRIPT standard version 2023011. We proposed to remove the optional provision that is currently in 45 CFR 170.315(b)(3)(ii)(D).

\416\ See https://standards.ncpdp.org/Access-to-Standards.aspx.

The following is a summary of the comments we received on this proposal and our responses:

Comment: Many commenters expressed support for our proposal that a health IT module certified to the “electronic prescribing” criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with NCPDP SCRIPT standard version 2023011. Commenters agreed that communicating how a prescriber intends for a patient to take a medication is critical for delivering safe and effective care, and therefore standardizing prescription directions via a codified and structured Sig field has the potential to reduce medication errors and improve patient care. Another commenter noted use of Structured Sig will minimize inefficiencies that result from ambiguous prescriber-pharmacist communications and manual prescription entry into pharmacy management systems, which are prone to errors. Other commenters supported the codified Sig format instructions, stating they are essential for accurate prescription labeling, appropriate patient counseling and education from a pharmacist, increasing interoperability, providing data for research, and optimal medication use. A commenter noted that use of free text Sigs can lead to errors and recommended structuring as much of this information as possible to support safer transitions of care.

Response: We thank commenters for their support and agree with comments that use of structured Sigs support safer and more accurate prescriptions than free text Sigs when feasible.

Comment: Several commenters supported the proposal but requested clarification. A commenter noted that the statement in the HTI-2 Proposed Rule that the Structured and Codified Sig Format contains 15 segments did not reflect the complexity of the format, which contains approximately 180 distinct elements used to capture patient instructions. Another commenter stated that the Structured and Codified Sig format does not contain segments.

Response: We appreciate commenters' feedback. In the proposed rule we inadvertently referred to groupings of elements containing distinct fields to capture potential elements of patient instructions in the Structured and Codified Sig Format as “segments.” We agree with commenters' characterization of the Structured and Codified Sig format as including approximately 180 distinct elements, excluding repetitions and extensions, used to capture patient instructions.\417\

\417\ https://www.ncpdp.org/.

Comment: Commenters stated that the Structured and Codified Sig format is embedded in the required NCPDP SCRIPT standard and recommended that we remove separate reference to the Structured and Codified Sig Format.

Response: Regarding the proposal that a Health IT Module enable a user to enter, receive, and transmit structured and codified prescribing instructions in 45 CFR 170.315(b)(3)(ii)(D), we agree with commenters that, as noted in the proposed rule (89 FR 63526), that the Structured and Codified Sig Format is embedded within the NCPDP SCRIPT standard version 2023011. Therefore, we believe that if a Health IT Module implements NCPDP SCRIPT standard version 2023011 in a manner consistent with the requirements in the updated “electronic prescribing” criterion, it will implement the capability to transmit prescriptions according to the Structured and Codified Sig Format. Separately identifying a need to support these capabilities within the criterion would be redundant to requirements to support the NCPDP SCRIPT standard version 2023011.

Comment: A commenter supported the proposal but noted that not every prescription Sig can be accurately structured and codified due to the complexity and variability of medication instructions. To address this challenge, the commenter urged ASTP/ONC to support the inclusion of free text alongside structured and codified prescriptions. Allowing for free text will enable healthcare providers to convey essential nuances and specific patient needs that may not be captured in standardized formats. The commenter stated this approach helps to preserve flexibility while avoiding situations where the use of the same code to represent multiple terms can create significant challenges for the backward translation of prescription Sigs.

Response: We appreciate the commenter's input. We note that the capacity to transmit free text Sigs continues to be supported in NCPDP SCRIPT standard version 2023011. Nothing in the final “electronic prescribing” criterion would prohibit a prescriber from utilizing Sig free text elements as needed in order to provide information about a prescription.

Comment: A commenter recommended that ASTP/ONC not finalize the Sig proposal. The commenter stated that the proposed requirement was vague and could be interpreted as requiring all Sigs to be sent in a codified manner, which would impose significant burdens on health IT developers while resulting in diminishing returns for therapies requiring less common, complex instructions that are more easily communicated through free text. The commenter stated that the value of mapping uncommon Sigs decreases significantly, given how infrequently prescribers may issue such patient directions. The commenter also expressed doubt about the value of exchanging structured Sigs when other organizations, such as pharmacy groups, are not subject to requirements to support this standard. The commenter recommended that ASTP/ONC indicate more clearly the expectations regarding the implementation of structured Sigs.

Response: We thank the commenter for their input. The intent of our proposed requirement in 45 CFR 170.315(b)(3)(ii)(D) was not to require all Sigs to be sent in a structured and codified format, but rather to enable a user to utilize this functionality in accordance with NCPDP SCRIPT standard version 2023011. As the commenter's concern relates to the language of the proposed requirement in 45 CFR 170.315(b)(3)(ii)(D), we believe our decision to not finalize this provision addresses the commenter's concerns regarding the ambiguity of the proposed language.

After consideration of public comments, we are not finalizing the provision we proposed in 45 CFR 170.315(b)(3)(ii)(D) that a Health IT Module must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in Sec. 170.205(b)(2) (NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011. We believe that finalizing this provision in the text of the regulation is unnecessary as this functionality will be implemented as part of requirements to

implement the NCPDP SCRIPT standard version 2023011.

We did not receive any comments on our proposal to remove the existing optional provision in 45 CFR 170.315(b)(3)(ii)(D) related to the ability to receive and transmit the reason for prescription using the Indication for use element in the SIG segment and we are finalizing to remove this provision and reserve 45 CFR 170.315(b)(3)(ii)(D) for future notice-and-comment rulemaking. (ii) RxNorm and National Drug Codes (NDC)

In 45 CFR 170.315(b)(3)(ii)(A) we require that a Health IT Module certified to the “electronic prescribing” criterion enable a user to perform specified prescription-related electronic transactions in accordance with a specified minimum version of the RxNorm code set for coding medications, among other standards. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine (RxNorm), is a drug terminology providing a set of normalized medication names and codes based on a collection of commonly used public and commercial vocabularies of drug names and their ingredients. In section III.B.5. of the HTI-2 Proposed Rule (89 FR 63519 and 63520), we proposed to adopt an updated release of RxNorm, specifically, the December 4, 2023, Full Monthly Release, in 45 CFR 170.207(d)(1)(ii). We also proposed to reorganize 45 CFR 170.207(d) to include the versions of RxNorm adopted in 45 CFR 170.207(d)(1), (2), and (3), under 45 CFR 170.207(d)(1).

In the HTI-2 Proposed Rule, for the “electronic prescribing” certification criterion, we proposed in 45 CFR 170.315(b)(3)(ii)(A) to remove the existing reference to RxNorm, September 8, 2015, Release in 45 CFR 170.207(d)(3), and require use of at least one of the versions of the standard adopted in 45 CFR 170.207(d)(1) (89 FR 63527). We stated that if finalized, this reference to 45 CFR 170.207(d)(1), where we adopted multiple versions of RxNorm, would permit a health IT developer to use any version of RxNorm that is listed in 45 CFR 170.207(d)(1) and for which adoption has not expired. We noted that this proposal would result in a requirement to use progressively more recent releases of the RxNorm code set as the baseline version of RxNorm which Health IT Modules must use for the “electronic prescribing” certification criterion.

Under NCPDP SCRIPT standard version 2020011 and greater, including NCPDP SCRIPT standard version 2023011, the National Drug Codes (NDC) element is required on all non-compounded medication electronic prescriptions (89 FR 63527).\418\ National Drug Codes (NDC) provide a unique identifier for products such as vaccines or medications. Each product is assigned a unique 10- or 11-digit, 3-segment number that identifies the labeler, product, and trade package size. We adopted NDC in 45 CFR 170.207(d)(4) in the HTI-1 Final Rule (89 FR 1226) via a cross-reference to 45 CFR 162.1002(b)(2) as referenced in 45 CFR 162.1002(c)(1). In the HTI-2 Proposed Rule, we proposed to relocate this cross-reference from 45 CFR 170.207(d)(4) to 45 CFR 170.207(d)(2) as part of our reorganization of this section (89 FR 63519 and 63520). Consistent with the requirement in the NCPDP SCRIPT standard version 2023011 to include NDC with prescriptions, we proposed in 45 CFR 170.315(b)(3)(ii)(A) that a Health IT Module certified to the criterion must enable a user to perform specified prescription-related electronic transactions in accordance with NDC in 45 CFR 170.207(d)(2). We proposed that use of NDC would be required at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011 adopted in 45 CFR 170.205(b)(2).

\418\ For more information about the updates to NDC in the NCPDP SCRIPT standard see https://ncpdp.org/NCPDP/media/images/Resources%20Items/NDC-Use-eRx-Fact-Sheet.pdf?ext=.pdf.

The following is a summary of the comments we received and our responses:

Comment: Commenters expressed support for our proposal to revise the existing reference to RxNorm, September 8, 2015, Release, in 45 CFR 170.207(d)(3), and instead require use of at least one of the versions of the standard adopted in 45 CFR 170.207(d)(1), in which we proposed to include updated releases of RxNorm. A commenter agreed with ASTP/ ONC's approach to use progressively more recent releases of the RxNorm code set as baseline version of RxNorm for the “electronic prescribing” certification criterion. Another commenter supported use of the more current RxNorm release, stating that this would ensure Health IT Modules use the same code sets and enable more effective communications with pharmacy data systems, benefiting prescribers, pharmacists, payers, and patients.

Response: We thank commenters for their support. We note that in the HTI-2 Proposed Rule, we inadvertently described the reference to RxNorm in 45 CFR 170.315(b)(3)(ii)(A) as referencing RxNorm, September 8, 2015, Release, in 45 CFR 170.207(d)(3) in preamble (89 FR 63527). This should have referred to RxNorm, July 5, 2022, in 45 CFR 170.207(d)(1) as stated in the text of the regulation.

As discussed in section XI.B.4.b.(3) of this final rule, we are not finalizing the expiration dates for releases of RxNorm that we proposed in 45 CFR 170.207(d)(1). We further remind readers that, pursuant to the policy in 45 CFR 170.555 regarding “minimum standards” code set updates, developers of certified health IT are able to use newer versions of these minimum adopted standards on a voluntary basis. In order to maintain alignment with the “minimum standards” code set policy in 45 CFR 170.555, we are finalizing the language proposed in 45 CFR 170.315(b)(3)(ii)(A) with a modification to retain the phrase “at a minimum.” Under this revision, we are conveying that any of the versions of the code set in 45 CFR 170.207(d)(1) (RxNorm) may serve as a baseline, but that, consistent with our “minimum standards” code sets policy, health IT developers may move to later versions of these code sets and maintain certification.

Comment: Commenters supported the use of NDCs in the “electronic prescribing” certification criterion. A commenter agreed that the use of NDC for drugs is beneficial for specific product identification in research, dispensing, and administrative workflows.

Response: We thank commenters for their support.

Comment: A commenter stated that requiring the use of a code set that is not adopted as an official standard seems contrary to the concept of conforming to standards. A commenter opposed the proposal to require both RxNorm and NDC. The commenter noted the value sets are duplicative, that the majority of the industry uses NDC to identify prescriptions, and that selecting one value set will improve interoperability.

Response: We disagree that referencing NDC would be contrary to the concept of conforming to standards. NDC is a standard that is maintained by HHS. While ASTP/ONC has not adopted NDC directly, it has been adopted by the Secretary in 45 CFR 162.1002 and we believe it reduces confusion to cross-reference these existing codes rather than separately adopting the standard.

We acknowledge the commenter's feedback regarding preference for use of one code set, but we disagree that these code sets are duplicative. RxNorm is used to identify a brand or generic

medication, dose form and strength and is commonly used when ordering a medication. Additionally, an NDC code is used when the exact manufacturer and package size are known and identified to be dispensed and/or administered. We believe it is important to support both code sets as both are specified in the NCPDP SCRIPT standard version 2023011.

After consideration of public comments, we are finalizing our proposal to revise our reference to RxNorm in the “electronic prescribing” criterion in 45 CFR 170.315(b)(3)(ii)(A), with modification. Pursuant to our reorganization of the paragraph at 45 CFR 170.315(b)(3)(ii)(A), we are finalizing cross-references to 45 CFR 170.207(d)(1), where we have adopted versions of RxNorm, in both 45 CFR 170.315(b)(3)(ii)(A)(1)(i) and 45 CFR 170.315(b)(3)(ii)(A)(2)(i). We are revising our previous requirement specifying use of the standard at 45 CFR 170.207(d)(1) with a requirement to use, at a minimum, at least one of the standards adopted in 45 CFR 170.207(d)(1). We are finalizing this language for consistency with our policy in 45 CFR 170.555 regarding minimum standard code sets, discussed in section XI.B.4.b.(1) of this final rule. This revised reference clarifies that the “electronic prescribing” criterion requires the use of an RxNorm release that we include in 45 CFR 170.207(d)(1) as a baseline for certification.

We are also finalizing our proposed requirement in the “electronic prescribing” criterion to use the standard in 45 CFR 170.207(d)(2), where we have cross referenced NDC, with modification. Pursuant to our reorganization of the paragraph at 45 CFR 170.315(b)(3)(ii)(A), we are finalizing in 45 CFR 170.315(b)(3)(ii)(A)(1)(ii) a requirement to use NDC if using the standard in 45 CFR 170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011) in the period before December 31, 2027. We are finalizing a requirement for use of NDC after January 1, 2028 in 45 CFR 170.315(b)(3)(ii)(A)(2)(ii). (iii) Diagnoses (45 CFR 170.315(b)(3)(ii)(C))

In 45 CFR 170.315(b)(3)(ii)(C) we require that a Health IT Module “must be able to receive and transmit the reason for prescription using the diagnosis elements: or ” for the set of prescription-related transactions identified in 45 CFR 170.315(b)(3)(ii)(C)(1)-(2).

In the HTI-2 Proposed Rule (89 FR 63527 and 63528), we proposed to make changes to the list of required and optional transactions in 45 CFR 170.315(b)(3)(ii)(C) to reflect the proposed required transactions for the updated version of the certification criterion in 45 CFR 170.315(b)(3)(ii)(A), and our proposal to remove certain optional transactions from the updated version of the criterion in 45 CFR 170.315(b)(3)(ii)(B). Specifically, we proposed in 170.315(b)(3)(ii)(C)(1) to rename “Create New Prescriptions (NewRx)” to “New Prescriptions (NewRx).” We proposed in 45 CFR 170.315(b)(3)(ii)(C)(1)(vi) to remove the transaction “Receive medication history” (RxHistoryResponse) and reserve this section. We proposed in 45 CFR 170.315(b)(3)(ii)(C)(1)(vii) to require the following electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse, PANotification) if using NCPDP SCRIPT standard version 2023011 (adopted in 45 CFR 170.205(b)(2)). Lastly, we proposed to remove the optional transactions in 45 CFR 170.315(b)(3)(ii)(C)(2)(i) through (iv) and reserve this section. We referred readers to Table 1A in the HTI-2 Proposed Rule (89 FR 63529) for a comparison of required and optional transactions identified in the current certification criterion based on NCPDP SCRIPT standard version 2017071 and the proposed updated criterion based on NCPDP SCRIPT standard version 2023011.

The following is a summary of the comments we received and our responses:

Comment: A commenter supported the inclusion of the Diagnosis field as proposed.

Response: We thank the commenter for their support.

Comment: A few commenters recommended updating the regulatory text to align with the new diagnosis structure in the NCPDP SCRIPT Standard Version 2023011, which allows for an unlimited number of diagnoses to be sent in prescription-related transactions. They proposed certifying only the diagnosis associated with the medication being dispensed, located in the MedicationPrescribed/Diagnosis element, and not certifying the Patient diagnosis found in Patient/HumanPatient/ Diagnosis. They noted that this approach would ensure the focus remains on the medication-specific diagnosis rather than broader patient diagnoses.

Response: We appreciate commenters' feedback regarding the proposed regulation text at 45 CFR 170.315(b)(3)(ii)(C). We agree with commenters that the NCPDP SCRIPT Standard Version 2023011 accommodates an unlimited number of diagnoses to be sent in prescription-related transactions and that this updated version of the standard no longer utilizes the current or diagnosis elements previously identified in the 45 CFR 170.315(b)(3)(ii)(C).

After consideration of the public comments, we are finalizing in 45 CFR 170.315(b)(3)(ii)(C) that a Health IT Module must be able to receive and transmit the diagnosis or diagnoses that are the reason for the prescription. We believe this language reflects the potential for multiple diagnoses as well as clarifying the requirement to support the diagnosis or diagnoses associated with the medication being prescribed. We further clarify that we are not finalizing any requirements under the “electronic prescribing” criterion that Health IT Modules must support diagnosis elements that are not related to the medication being prescribed. (iv) Race and Ethnicity

In 2023, the Pharmacy Interoperability and Emerging Therapeutics Task Force provided a recommendation to the HITAC to support interoperability between pharmacy constituents by including race and ethnicity in the “electronic prescribing” certification criterion (PhIET-TF-2023_Recommendation 26).\419\ The Task Force stated that demographic data is not always made available through reporting such as case reporting to public health agencies. Yet, in order to support the ability to perform analytics, all data feeds should have relevant race and ethnicity data, and other key demographic data, when available. The Task Force recommended that various prescribing and laboratory results reporting capabilities need to be able to support sharing of the relevant data when an alternative source is not consistently available. Additionally, the Task Force acknowledged that a prescriber will likely already have patient race or ethnicity documented. Exchanging this information through available transactions, such as those included in electronic prescribing, is one way to improve consistency in

documentation of demographic data across provider types.

\419\ See https://www.healthit.gov/sites/default/files/page/2023-11/2023-11-09_PhIET_TF_2023_Recommendations_Transmittal_Letter_508.pdf.

Specifically, the Task Force recommended ONC include the ability to capture and exchange race and ethnicity as part of the “electronic prescribing” certification criterion and point to USCDI v4,\420\ which references the CDC Race & Ethnicity Code System--CDCREC 1.2 (July 2021).\421\ The CDC Race & Ethnicity Code System--CDCREC 1.2 code set facilitates use of federal standards for classifying data on race and ethnicity when these data are exchanged, stored, retrieved, or analyzed in electronic form. The NCPDP SCRIPT standard version 2023011, which we proposed to incorporate in the “electronic prescribing” certification criterion in the HTI-2 Proposed Rule (89 FR 63528), references reporting of race and ethnicity using the CDCREC 1.2 associated value set “PHVS_Race_CDC” version 2 (December 2018 \422\) from the code system code “PH_RaceAndEthnicity_CDC” as optional for certain transactions within the standard. This aligns with the code system code in CDCREC 1.2 which is “PH_RaceAndEthnicity_CDC,” and is available on the Public Health Information Network (PHIN) Vocabulary Access and Distribution System (PHIN VADS).\423\

\420\ See https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.

\421\ See https://www.cdc.gov/phin/resources/vocabulary/.

\422\ See https://phinvads.cdc.gov/vads/ViewValueSet.action?id=9152A536-AEEC-E711-ACD6-0017A477041A.

\423\ See https://phinvads.cdc.gov/vads/ViewCodeSystemConcept.action?oid=2.16.840.1.113883.6.238&code=1579-2.

Given the importance of the issues described by the Task Force, and the alignment between the recommendation and NCPDP SCRIPT standard version 2023011, we stated that we believe that it is appropriate to implement the Task Force recommendation through updates to the “electronic prescribing” certification criterion. Therefore, we proposed in 45 CFR 170.315(b)(3)(ii)(B) that a Health IT Module certified to the “electronic prescribing” certification criterion must enable a user to exchange race and ethnicity information for a patient when performing the following prescription-related electronic transactions, if using NCPDP SCRIPT standard version 2023011:

Receive fill status notifications (RxFill).

Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).

Request to cancel prescriptions (CancelRx).

Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).

We stated we believe the transactions listed previously are an appropriate starting place to include race and ethnicity in the electronic prescribing certification criterion. We noted that we will continue to monitor changes to the NCPDP SCRIPT standard for additional updates to transactions to include race and ethnicity data fields.

We invited comments on this proposal and requested information on whether there are other SCRIPT transactions that include data fields for race and ethnicity we should consider specifying to enable exchange of race and ethnicity data with providers in pharmacy settings.

The following is a summary of the comments we received and our responses:

Comment: Several commenters supported our proposal to require that Health IT Modules certified to the “electronic prescribing” criterion enable users to capture race and ethnicity in the specific transactions. Commenters stated that expanding data collection requirements across certified health IT, including options for disaggregated coding of race, ethnicity and preferred language, would help to extend contextual understanding for electronic prescribing information.

Response: We thank the commenters for their support. We agree that enabling exchange of this information will increase its availability and can add useful information to electronic prescriptions.

Comment: A commenter stated that ASTP/ONC should consider the potential misuse of race and ethnicity information captured using certified Health IT Modules, while another commenter recommended making race and ethnicity data collection and sharing optional, so pharmacy staff on the ground can make informed decisions on when it is appropriate to ask questions on demographics.

Response: We appreciate commenters' feedback on the use of race and ethnicity data and agree that there are many important considerations around the collection and use of these data. The potential misuse of data is not unique to data elements of race and ethnicity. Users of certified health IT should comply with existing laws and regulations governing the use of health information (for instance, see the HIPAA Security and Privacy Rules in 45 CFR part 160 and subparts A, C and E of part 164). Additionally, organizations may establish their own data policies to support the accuracy of data. We note that the proposed requirement that Health IT Modules certified to the updated “electronic prescribing” criterion must enable a user to exchange this information would not establish a requirement for end users of Health IT Modules certified to the “electronic prescribing” criterion to capture and share this information. This proposal does not require the collection or disclosure of demographic information nor does it address the voluntary nature of patient disclosures of race and ethnicity data.

Comment: A commenter stated that ASTP/ONC should work with other agencies to ensure policies to support the collection and exchange of demographic data are patient-centric, respect patient privacy, and promote patient autonomy. Commenters recommended that all race and ethnicity information should be provided voluntarily by the patient and that ASTP/ONC and other agencies should work with stakeholders to implement feasible workflows, identify appropriate ways to share data, and ensure that patients always have an option to decline to respond.

Another commenter encouraged ASTP/ONC to more clearly identify specific uses for these data to reduce health inequities. A commenter recommended ASTP/ONC provide more rationale for requiring this information be captured as other areas of medicine are pushing to take race and ethnicity out of consideration when prescribing medications.

Response: We agree with commenters that prescribers should think carefully about how to ensure patient-centered principles are followed when designing workflows around collection of this information, and that patients must have a voice in the data that they choose to share and how that data is shared with others. We will continue to collaborate with other agencies to ensure that such principles are considered in efforts around data collection as appropriate.

Regarding additional rationale for our proposal, we refer readers to the findings of the 2023 HITAC Pharmacy Interoperability and Emerging Therapeutics Task Force report \424\ that race and ethnicity data are crucial for public health reporting and analytics. Gaps in the completeness of case reporting necessitate additional means to capture and share these data, so they

may be included in public health reporting. Finally, we note that this requirement for certified Health IT Modules would not establish any requirements that end users must consider race and ethnicity data when making prescribing decisions.

\424\ https://www.healthit.gov/sites/default/files/page/2023-11/2023-11-09_PhIET_TF_2023_Recommendations_Transmittal_Letter_508.pdf.

Comment: Several commenters noted the most common transaction in the NCPDP SCRIPT standard, NewRx, does not currently support race and ethnicity information, which limits the potential impact of exchanging race and ethnicity using the standard. Another commenter noted that ASTP/ONC should clarify the requirement is only to send race and ethnicity data to a pharmacy and not receive it back, as health systems are unlikely to want pharmacy data to overwrite information gathered during their check-in processes.

Response: We acknowledge the comment regarding the lack of inclusion of race and ethnicity data in the NewRx transaction, and will continue to work with interested parties to further explore transactions where inclusion of this data may be useful. We confirm that our final rule requirement only specifies that the health IT module must enable a user to exchange this information. We did not propose any requirement for a Health IT Module to modify data or overwrite existing data based on information received from pharmacies.

Comment: A commenter recommended the proposed timelines for certification should parallel those set forth in OMB's recent Statistical Policy Directive No. 15: Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15) \425\ regarding the collection of race and ethnicity data, which identified an implementation date of March 28, 2029. The commenter stated that federal agencies are required to plan for implementation of OMB's race and ethnicity data policy over the next five years, so aligning with this delayed date would provide an opportunity to move towards standardization and alignment of race and ethnicity data across healthcare and government.

\425\ https://www.federalregister.gov/documents/2024/03/29/2024-06469/revisions-to-ombs-statistical-policy-directive-no-15-standards-for-maintaining-collecting-and.

Response: We appreciate commenters' input, however it is not necessary to parallel the timelines in OMB's SPD 15 directive with our policies in this final rule for the “electronic prescribing” criterion. OMB's SPD 15 directive provides the standards for maintaining, collecting, and presenting race and ethnicity data for all Federal information collection and reporting purposes. The SPD 15 standards do not require any agency or program to collect race and ethnicity data; rather they provide a common language for uniformity and comparability in the collection and use of race and ethnicity data by Federal agencies.\426\ Our proposed update to the “electronic prescribing” criterion aims to enable the electronic exchange of race and ethnicity information when performing certain prescription-related electronic transactions, and does not establish requirements for how that information may be initially collected and recorded. We are working closely with OMB and other partners on the implementation of this directive and we will revisit this and other elements of the Certification Program as needed to align with the directive.

\426\ See https://www.federalregister.gov/documents/2024/03/29/2024-06469/revisions-to-ombs-statistical-policy-directive-no-15-standards-for-maintaining-collecting-and.

Comment: Another commenter noted that NCPDP SCRIPT standard version 2023011, references reporting of race and ethnicity using the CDCREC 1.2 associated value set “PHVS_Race_CDC” version 2 (December 2018 \427\) and stated that this value set includes over 900 codes. The commenter recommended that ASTP/ONC instead adopt OMB's revised race/ ethnicity data policy directive that was finalized in March 2024, as it will be more feasible to implement these broader OMB race and ethnicity categories while the system gains experience using the updated standard.

\427\ See https://phinvads.cdc.gov/vads/ViewValueSet.action?id=9152A536-AEEC-E711-ACD6-0017A477041A.

Response: We appreciate the commenter's feedback. As noted by the commenter, the PHVS_Race_CDC value set is referenced in the NCPDP SCRIPT standard version 2023011 and we are requiring Health IT Modules to support exchange of race and ethnicity data consistent with this standard. Moreover, we note that this value set is not misaligned with the broader OMB categories but provides for the capability to capture more fine-grained information about race and ethnicity to better support patient care. We did not propose any restriction on a health IT module to additionally supporting the OMB categories on a voluntary basis.

After consideration of public comments, we are finalizing our proposal in 45 CFR 170.315(b)(3)(ii)(B) that a Health IT Module must enable a user to exchange race and ethnicity information when performing certain prescription-related electronic transactions, if using the standard in 45 CFR[thinsp]170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011). The relevant transactions are RxFill, RxChangeRequest, RxChangeResponse, CancelRx, RxRenewalRequest, and RxRenewalResponse.

We note that we have further evaluated this proposal in light of guidance released since the publication of the HTI-2 Proposed Rule. Specifically, we have reviewed Executive Order 14151, “Ending Radical and Wasteful Government DEI Programs and Preferencing,” and have determined the proposal we are finalizing is not in conflict with the Executive Order. While this policy would potentially make additional data about populations available to public health agencies, this requirement for certified health IT would not mandate that users of this technology or this data take any actions identified as part of the Executive Order. (v) Base EHR Definition

In the HTI-2 Proposed Rule (89 FR 63528), given our proposal in section III.B.9.b. to include the proposed “real-time prescription benefit” certification criterion in 45 CFR 170.315(b)(4) in the Base EHR definition in 45 CFR 170.102, we also proposed to add the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3) to the Base EHR definition. Please see section III.B.9.b. of the HTI-2 Proposed Rule (89 FR 63930 through 63932) for further details on this proposal.

Please see the “New Real-Time Prescription Benefit Criterion” section XI.B.4.b.(4) of the preamble of this final rule for a summarization of the public comments received to add the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3) to the Base EHR definition. As discussed in section XI.B.4.b.(4) of the preamble of this final rule, we are not finalizing this proposal, as ASTP/ONC is seeking to limit the Base EHR definition to elements of the Qualified EHR definition in PHSA section 3000 where possible. (vi) Multi-Factor Authentication

In the HTI-2 Proposed Rule (89 FR 63528), we proposed in 45 CFR 170.315(b)(3)(ii)(G), that on and after January 1, 2028, a Health IT Module certified to 45 CFR 170.315(b)(3) must meet the multi-factor authentication requirements specified in 45 CFR 170.315(d)(13)(ii) for user-facing authentication. We stated that we believe this update is in line with industry information security best practice for an important authentication

use case in health IT, and that it is necessary to help better protect electronic health information. We referred readers to section III.B.17 of the HTI-2 Proposed Rule (89 FR 63574) for our proposal to revise the “multi-factor authentication” certification criterion 45 CFR 170.315(d)(13) and for background on the user level authentication use case targeted by this proposed requirement.

The following is a summary of the comments we received and our responses:

Comment: A commenter supported the proposal that after January 1, 2028, a certified health IT module must meet the multi-factor requirements specified for user-facing authentication. The commenter agreed with ASTP/ONC that this update is in line with industry information security best practices and will better protect electronic health information.

Response: We thank commenters for their support.

Comment: Another commenter suggested that ASTP/ONC should not finalize this requirement as written. The commenter noted that electronic prescribing for controlled substances already requires multi-factor authentication according to Drug Enforcement Administration (DEA) regulations. The commenter suggested that it is unclear what ASTP/ONC is additionally proposing to require, given these protections are already in place.

Response: We agree that requirements for use of this functionality are already in place and that prescribers are subject to requirements to use multi-factor authentication when electronically prescribing controlled substances. We further agree that finalizing such requirements as part of the “electronic prescribing” certification criterion is not necessary to ensure use of multi-factor authentication by clinicians, due to existing requirements.

After consideration of public comments, we are not finalizing the proposed requirement for multi-factor authentication in 45 CFR 170.315(b)(3)(ii)(G).

In summary, after consideration of the public comments, we are finalizing the proposed update to the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3)(ii) with the following modifications:

As discussed in the preamble of this final rule, we are finalizing revisions to and a reorganization of the text of the regulation in 45 CFR 170.315(b)(3)(ii)(A) to increase clarity regarding our timelines for the use of standards for the “electronic prescribing” criterion, and renumbering subsequent paragraphs.

We are finalizing revised language in 45 CFR 170.315(b)(3)(ii)(A)(1)(i) and (A)(2)(i) requiring the use, at a minimum, of at least one of the versions the standard specified in 45 CFR 170.207(d), where we adopted multiple versions of RxNorm.

We are moving the required prescription-related electronic transactions listed at 45 CFR 170.315(b)(3)(ii)(A)(1-9) to 45 CFR 170.315(b)(3)(ii)(A)(3)(i-x), and renumbering the transactions as follows: (i) New prescriptions (NewRx), (ii) Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse), (iii) Request and respond to cancel prescriptions (CancelRx, CancelRxResponse), (iv) Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse), (v) Receive fill status notifications (RxFill), (vi) Request and receive medication history (RxHistoryRequest, RxHistoryResponse), (vii) Relay acceptance of a transaction back to the sender (Status), (viii) Respond that there was a problem with the transaction (Error), (ix) Respond that a transaction requesting a return receipt has been received (Verify), and (x) Electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification).

We are not finalizing the removal of the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) in 45 CFR 170.315(b)(3)(ii)(A)(6), and retaining these transactions in 45 CFR 170.315(b)(3)(ii)(A)(3)(vi).

We are finalizing revised language regarding the requirement to transmit the diagnosis or diagnoses that are the reason for the prescription in certain transactions in 45 CFR 170.315(b)(3)(ii)(C).

We are not finalizing the provision requiring that a Health IT Module must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in Sec. 170.205(b)(2) proposed in 45 CFR 170.315(b)(3)(ii)(D), as structured and codified Sig functionality is already embedded in the NCPDP SCRIPT standard version 2023011 and we do not believe a dedicated requirement is necessary.

We are not finalizing the proposal in 45 CFR 170.315(b)(3)(ii)(G) to reference the proposed “multi-factor authentication” certification criterion in 45 CFR 170.315(d)(13) as part of the updated “electronic prescribing” criterion.

We are not finalizing the proposal to add the “electronic prescribing” criterion to the Base EHR definition beginning on January 1, 2028. Please see the “New Real-Time Prescription Benefit Criterion” section XI.B.4.b.(4). of the preamble of this final rule for a summarization of the public comments received to add the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3) to the Base EHR definition.

We have updated the table we originally presented in the HTI-2 Proposed Rule (89 FR 63529) to provide a comparison of transactions identified in the existing version of the criterion based on the NCPDP SCRIPT standard version 2017071, and the updated certification criterion we are finalizing in 170.315(b)(3)(ii) based on NCPDP SCRIPT standard version 2023011.

[GRAPHIC] [TIFF OMITTED] TR04AU25.318

(4) New Real-Time Prescription Benefit Criterion (a) Background

The increasing costs of prescription drugs have long been a concern for patients, providers, and policymakers.\428\ Increased drug costs can have several negative consequences for patients, including limited access to healthcare,\429\ lower healthcare use,\430\ medication nonadherence \431\ \432\ and financial stress, especially among underserved,\433\ uninsured, and underinsured \434\ populations. Merely having health insurance coverage does not necessarily confer medication affordability on patients.\435\ These challenges continue to be the focus of legislation, such as the Inflation Reduction Act of 2022 (Pub. L. 117-169, August 16, 2022), which includes several provisions that are expected to decrease prescription drug costs and improve access to prescription drugs for the more than 68 million Americans enrolled in the Medicare program,\436\ including allowing Medicare to directly negotiate prescription drug prices for the first time, eliminating cost sharing for certain adult vaccines under Part D, capping out-of-pocket costs for insulin, and capping Part D enrollee out-of-pocket spending annually starting in 2025 (see sections 11406, 11401, 1194, and 11201). E. O. 14087, Lowering Prescription Drug Costs for Americans, directed further actions to lower the cost of prescription drugs.

\428\ A.S. Kesselheim, J. Avorn, A. Sarpatwari, The high cost of prescription drugs in the United States: origins and prospects for reform. JAMA, 316 (8) (2016), pp. 858-871.

\429\ Daher, Al Rifai, M., Kherallah, R.Y., Rodriguez, F., Mahtta, D., Michos, E.D., Khan, S.U., Petersen, L.A., & Virani, S.S. (2021). Gender disparities in difficulty accessing healthcare and cost-related medication non-adherence: The CDC behavioral risk factor surveillance system (BRFSS) survey. Preventive Medicine, 153, 106779-106779. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9291436/.

\430\ Roebuck, Liberman, J.N., Gemmill-Toyama, M., & Brennan, T.A. (2011). Medication adherence leads to lower health care use and costs despite increased drug spending. Health Affairs, 30(1), 91-99. https://doi-org.ezproxyhhs.nihlibrary.nih.gov/10.1377/hlthaff.2009.1087.

\431\ SG Morgan, A. Lee. Cost-related non-adherence to prescribed medicines among older adults: a cross-sectional analysis of a survey in 11 developed countries. BMJ Open, 7 (1) (2017), Article e014287.

\432\ DiMatteo MR, Giordani PJ, Lepper HS, Croghan TW. Patient adherence and medical treatment outcomes: a meta-analysis. Med Care. 2002; 40 (9): 794-811.

\433\ Whaley C, Reed M, Hsu J, Fung V (2015) Functional Limitations, Medication Support, and Responses to Drug Costs among Medicare Beneficiaries. PLoS ONE 10(12): e0144236. https://doi.org/10.1371/journal.pone.0144236.

\434\ Collins SR, Rasmussen PW, Beutel S, Doty MM. The problem of underinsurance and how rising deductibles will make it worse: findings from the Commonwealth Fund Biennial Health Insurance Survey, 2014. New York: Commonwealth Fund; 2015.

\435\ Zhao, J., Zheng, Z., Han, X., Davidoff, A.J., Banegas, M.P., Rai, A., Jemal, A., & Yabroff, K.R. (2019). Cancer History, Health Insurance Coverage, and Cost-Related Medication Nonadherence and Medication Cost-Coping Strategies in the United States. Value in health: the journal of the International Society for Pharmacoeconomics and Outcomes Research, 22(7), 762-767. https://doi.org/10.1016/j.jval.2019.01.015.

\436\ See https://data.cms.gov/tools/medicare-enrollment-dashboard.

Research also suggests provider-patient discussions during clinical encounters about costs and affordability may lead to an overall reduction in out-of-pocket costs.\437\ Real-time prescription benefit tools empower providers and their patients to compare the patient- specific cost of a drug to the cost of a suitable alternative, compare prescription costs at different pharmacy locations, view information about out-of-pocket costs, and learn whether a specific drug is subject to utilization management restrictions such as prior authorization, step therapy, or quantity

limits. In the HTI-2 Proposed Rule (89 FR 63530), we stated that, when appropriate, use of these tools can allow the provider and patient to choose among clinically acceptable alternative medication treatments while weighing coverage and point-in-time costs. We also noted that access to this data within the electronic prescribing workflow may help to reduce provider burden associated with coverage determination and prior authorization appeals. We additionally stated that widespread adoption of such tools, along with increased awareness of drug cost information among patients and providers will likely spur more robust evaluations over time.

\437\ Carroll JK, Farah S, Fortuna RJ, et al. Addressing medication costs during primary care visits: a before-after study of team-based training. Ann Intern Med. 2019;170(suppl 9): S46-S53. doi:10.7326/M18-2011.

Section 1860D-4(o) of the Act, as added by section 119 of Title I, Division CC of the Consolidated Appropriations Act of 2021, (Pub. L. 116-260) (CAA, 2021), requires sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. Section 1860D-4(o)(3) of the Act requires that a qualifying RTBT must meet technical standards named by the Secretary, in consultation with ONC. Section 119(b) of the CAA, 2021 also amended the definition of a “qualified electronic health record” in section 3000(13) of the PHSA to specify that a qualified electronic health record “includes, or is capable of including, a real-time benefit tool that conveys patient-specific real-time cost and coverage information with respect to prescription drugs that, with respect to any health information technology certified for electronic prescribing, the technology shall be capable of incorporating the information described in clauses (i) through (iii) of paragraph (2)(B) of section 1860D-4(o) of the Act.” The information specified in (2)(B)(i) through (iii) of section 1860D-4(o) of the Act, as added by section 119(a) of the CAA, 2021, is:

A list of any clinically appropriate alternatives to a covered Part D drug included in the formulary of such plan;

Cost-sharing information and the negotiated price for a covered Part D drug and such alternatives at multiple pharmacy options, including the individual's preferred pharmacy and, as applicable, other retail pharmacies and a mail order pharmacy; and

The formulary status of a covered Part D drug and such alternatives and any prior authorization or other utilization management requirements applicable to such drug and such alternatives included in the formulary of such plan.

The provision further specifies that the change to the definition of a “qualified electronic health record” shall be implemented “at a time specified by the Secretary but not before the Secretary adopts a standard for such tools.”

In the HTI-1 Proposed Rule (88 FR 23848 through 23855), we included a request for information (RFI) about issues related to establishing a real-time prescription benefit certification criterion utilizing the NCPDP Real-Time Prescription Benefit (RTPB) standard, and ways in which the Certification Program could ensure real-time prescription benefit capabilities are implemented effectively for providers. We received many comments on this RFI and appreciate the input provided by commenters.

In the HTI-2 Proposed Rule (89 FR 63530), in order to implement section 119(b) of the CAA, 2021, we proposed to establish a “real-time prescription benefit” health IT certification criterion in 45 CFR[thinsp]170.315(b)(4) and to include this certification criterion in the Base EHR definition in 45 CFR[thinsp]170.102(3)(iv). (b) Revision to the Base EHR Definition and Health IT Module Dependent Criteria Requirements

As noted previously, section 119(b) of the CAA, 2021, amended the definition of a “qualified electronic health record” (Qualified EHR) in section 3000(13) of the PHSA to specify that a qualified electronic health record “includes, or is capable of including, a real-time benefit tool that conveys patient-specific real-time cost and coverage information with respect to prescription drugs.” In the 2014 Edition Final Rule, we established the term “Base EHR,” based on the Qualified EHR definition in PHSA section 3000(13), for use within the Certification Program (77 FR 54262). We define Base EHR in 45 CFR 170.102, and this definition currently includes certification criteria under the Certification Program that align with the elements of the Qualified EHR definition in the PHSA.

Given that the statutory definition of Qualified EHR is implemented in regulation through the Base EHR definition in 45 CFR 170.102, in the HTI-2 Proposed Rule (89 FR 63531), we stated that we believe it is necessary to propose to update the Base EHR definition consistent with Congress' modification of the statutory definition of Qualified EHR to address real-time benefit tool functionality. Specifically, consistent with PHSA section 3000(13), as amended by section 119(b) of the CAA, 2021, we proposed to revise the Base EHR definition in 45 CFR 170.102 to add paragraph (3)(iv) to include the real-time prescription benefit certification criterion proposed in 45 CFR 170.315(b)(4) on and after January 1, 2028. We also stated that we believe including the “real- time prescription benefit” certification criterion as part of the Base EHR definition will increase the use of real-time prescription benefit tools and promote widespread adoption, which will help to lower drug costs for Medicare beneficiaries, consistent with section 119 of the CAA, 2021. We noted that use of real-time prescription benefit tools enables Medicare providers and enrollees to make cost-informed decisions about prescriptions, and a standardized approach will ensure that critical drug and drug price data is available to providers when they need it.

In the Part D and Health IT Standards Final Rule, CMS finalized the requirement that Part D plan sponsors adhere to NCPDP RTPB standard version 13 as part of requirements to provide a prescriber real-time benefit tool by January 1, 2027 (89 FR 51259 and 51260). We requested comment on whether we should seek to align the date when the “real- time prescription benefit” certification criterion in 45 CFR 170.315(b)(4) would be effective for the Base EHR definition (proposed to be January 1, 2028) with the date finalized in the Part D and Health IT Standards Final Rule for Part D plan sponsors' real-time benefit tools to adhere to the NCPDP RTPB standard version 13 (January 1, 2027) (89 FR 51260).

We noted that the amended definition of a Qualified EHR in PHSA section 3000(13)(c) further specifies that “with respect to any health information technology certified for electronic prescribing, the technology shall be capable of incorporating the information described in clauses (i) through (iii) of paragraph (2)(B).” In the HTI-2 Proposed Rule (89 FR 63531), we stated that we interpret this provision to mean, for the purposes of the Certification Program, that any health IT presented for certification for electronic prescribing capabilities should also be capable of incorporating the real-time benefit information specified in clauses (i) through (iii) of paragraph (2)(B) of section 1860D-4(o) of the Act, as described previously.

We stated that real-time prescription benefit functionality is closely related to electronic prescribing functionality, which provides the basic workflow within which a provider may seek to identify information about a patient's coverage for a certain prescription before transmitting that electronic prescription to the pharmacy. We noted

that in most cases, we expect health IT developers seeking certification to 45 CFR 170.315(b)(4) will already be certified to 45 CFR 170.315(b)(3), though there will be some variation due to the modularity of the Certification Program criteria. Accordingly, we proposed to revise 45 CFR 170.550(g) to add paragraph (g)(6) in order to require that any developer that obtains certification for the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3) must also obtain certification for the proposed “real- time prescription benefit” criterion in 45 CFR 170.315(b)(4).

While we proposed to establish this dependency with the “electronic prescribing” certification criterion, the “electronic prescribing” certification criterion is not included as part of the current Base EHR definition in 45 CFR 170.102. We noted that although electronic prescribing is a widely used and fundamental capability of health IT, we have, to date, not included this certification criterion in the Base EHR definition for several reasons. First, the Qualified EHR definition in section 3000(13) of the PHSA does not specify electronic prescribing as a required element of a Qualified EHR and we have generally sought to limit the Base EHR definition in 45 CFR 170.102, which implements the Qualified EHR definition, to those capabilities that are required for the Qualified EHR definition by statute. Second, many health care providers have historically been required to adopt certified health IT for electronic prescribing in order to meet the requirements of the Medicare EHR Incentive Programs and their successors, the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. Objectives and measures for eligible professionals (now MIPS eligible clinicians \438\), eligible hospitals, and CAHs under these programs have included measures related to electronic prescribing since the implementation of the Medicare EHR Incentive Programs and we have maintained such measures in their successors. Specifically, for the MIPS Promoting Interoperability performance category, section 1848(o)(2)(A)(i) of the Act requires a MIPS eligible clinician to demonstrate that they use CEHRT in a meaningful manner, which includes the use of electronic prescribing as determined appropriate by the Secretary.

\438\ We define this term in our regulations at 42 CFR 414.1405 for purposes of MIPS.

However, given the proposal to include the proposed “real-time prescription benefit” certification criterion in 45 CFR 170.315(b)(4) in the Base EHR definition, we stated our belief that it was also appropriate to add the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3) to the Base EHR definition. While we previously did not include this capability in the Base EHR definition for the reasons we described, we noted that we believe that the inclusion of closely related “real-time prescription benefit” functionality in 45 CFR 170.315(b)(4) necessitated the inclusion of electronic prescribing functionality. We therefore proposed to include the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3) within the Base EHR definition in 45 CFR 170.102. We further proposed to specify that this criterion would be effective for the Base EHR definition on and after January 1, 2028, which aligns with the date when the proposed “real-time prescription benefit” certification criterion in 45 CFR 170.315(b)(4) would be effective for the Base EHR definition.

We requested comment on these proposals, especially regarding the impact of these proposals on health IT developers seeking to ensure their products meet the Base EHR definition that are not currently separately certified to the “electronic prescribing” criterion. We sought information on the added burden to developers of requiring the “electronic prescribing” certification criterion as part of the Base EHR definition in addition to the proposed “real-time prescription benefit” certification criterion. We also requested comment on the implications for interoperability of electronic prescribing if we were to finalize our proposal to include the “real-time prescription benefit” certification criterion within the Base EHR definition but not finalize our proposal to include the “electronic prescribing” certification criterion in the Base EHR definition.

Lastly, we requested comment on the impact this proposed policy would have on any healthcare providers participating in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category who have historically been able to claim an exclusion from electronic prescribing measures in these programs, and, as a result have not adopted certified health IT for electronic prescribing in order to complete the actions associated with these measures. The definitions of certified EHR technology at 42 CFR 495.4 and 42 CFR 414.1305, which define technology requirements for these programs, cross-reference the Base EHR definition at 45 CFR 171.102. Thus, we noted that as a result of the statutory change enacted by Congress, and if the HTI-2 Proposed Rule proposals to add these certification criteria to the Base EHR definition were finalized, all providers and clinicians participating in these programs would, at a minimum, have to have health IT certified to the proposed “real-time prescription benefit” certification criterion and the “electronic prescribing” certification criterion. This would include participants that currently successfully participate in these programs without possessing certified health IT that supports these capabilities. We requested comment on whether finalizing these proposals would impose significant burden on these healthcare providers and clinicians.

The following is a summary of the comments we received and our responses on the HTI-2 Proposed Rule and our responses:

Comment: Many commenters supported our proposal to establish a “real-time prescription benefit” health IT certification criterion. Commenters stated that the ability to obtain real-time information about prescription benefits improve the care experience for patients and their care teams, allow for more informed and timely decision- making, enable informed cost-related conversations during clinical encounters, reduce administrative burden for both patients and providers (for example, calls to a physician's office when a medication is unaffordable, return trips to the clinic and/or the pharmacy), reduce care delays and patient frustration, and lead to improved medication adherence and clinical outcomes. Commenters also stated that these capabilities may benefit health plans by reducing the number of prior authorization requests from providers, and by steering providers toward recommending in-formulary, lower-cost medication options.

Response: ASTP/ONC thanks commenters for their support and agrees that real-time prescription benefit technology has the potential to empower providers and their patients to compare the patient-specific cost of a drug to the cost of a suitable alternative, compare prescription costs at different pharmacies, view information about out- of-pocket costs, and learn whether prior authorization for a specific drug is required.

Comment: Most commenters supported our proposal to include the “real-time prescription benefit” certification criterion in the Base EHR definition in 45 CFR 170.102(3)(iv). They noted that including the “real-time prescription benefit” certification criterion in the Base EHR definition will

support broader availability of certified health IT with these capabilities.

Response: ASTP/ONC thanks commenters for their support.

Comment: Some commenters opposed including the “real-time prescription benefit” criterion in the Base EHR definition at this time. Commenters stated that requiring technology that is not fully ready could increase burden on physicians. A commenter preferred for the “real-time prescription benefit” criterion to not be required as part of the Base EHR definition as the industry continues to improve on the technology. A commenter thought it was not necessary to include the “real-time prescription benefit” criterion in the Base EHR definition because the availability of the “real-time prescription benefit” criterion would be sufficient to ensure adoption of this capability.

Response: ASTP/ONC thanks the commenters for their concerns regarding the inclusion of the “real-time prescription benefit” criterion in the Base EHR definition in 45 CFR 170.102. While we recognize these concerns, we proposed to include the “real-time prescription benefit” criterion in the Base EHR definition in order to fulfill the statutory requirements of section 119(b)(3) of the CAA, 2021 (Pub. L. 116-260), which added RTBT functionality to the definition of a qualified EHR in section 3000 of the PHSA. We also note that RTBTs are already widely implemented across US provider organizations and practices, with about two-thirds of hospitals reporting access to an RTBT.\439\ Given this degree of adoption, we anticipate that many physicians would not notice a change in their practice or workflow as a result of including the “real-time prescription benefit” criterion in the Base EHR definition.

\439\ See https://www.healthit.gov/data/quickstats/hospital-adoption-real-time-benefit-tools.

Comment: Many commenters supported our proposal to include the “real-time prescription benefit” criterion in the Base EHR definition as of January 1, 2028. Commenters stated this date would allow payers, developers, and providers time to prepare, thus ensuring a smoother and more effective implementation. Some commenters supported this proposal due to the fact that it is a year after the compliance date of January 1, 2027, finalized by CMS for Part D plan sponsors to establish an RTBT that meets NCPDP standard version 13. Commenters stated that this staggering of dates will allow health IT developers to more effectively develop Health IT Modules based on real-world implementations by Part D plan sponsors.

Response: ASTP/ONC thanks the commenters for their support. We agree with commenters regarding the benefits of the proposed date of January 1, 2028, for including the “real-time prescription benefit” criterion in the Base EHR definition. The proposed date for inclusion in the Base EHR definition of January 1, 2028 would provide a window of more than 24 months from the publication of this final rule for health IT developers to make Health IT Modules certified to the criterion at 45 CFR 170.315(b)(4) available to their customers in order to meet the Base EHR definition. ASTP/ONC agrees that staggered compliance dates would provide more opportunities for developers to test Health IT Modules against standard-compliant RTBTs implemented by Part D plan sponsors prior to release, thus ensuring that Health IT Modules are able to successfully interact with the technology implemented by Part D plan sponsors.

Comment: Some commenters supported aligning the effective date of the Base EHR definition revision with the January 1, 2027, compliance date by which Part D plan sponsors must implement RTBTs compliant with NCPDP RTPB standard version 13. Commenters expressed concern that if the dates are not aligned, there may be challenges in implementation, increased administrative burden, or negative consequences for the quality and cost of healthcare. Some commenters requested clarification on whether the deadline finalized by CMS for Part D plan sponsors applies universally or if there are specific exemptions.

Response: ASTP/ONC appreciates this feedback. We acknowledge the discrepancy between the date we proposed for the “real-time prescription benefit” criterion to be included in the Base EHR definition and the deadline for Part D sponsors to offer an RTBT conformant with the NCPDP RTPB standard version 13. However, we do not believe this discrepancy will result in significant challenges for health care providers using certified health IT. While health care providers may use health IT that includes RTBTs as part of their participation in certain federal programs, we note that there is currently no HHS requirement for health care providers to use RTBTs as part of care delivery; for instance, there is no associated measure specifying the use of RTBTs in the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. Thus, health care providers will not face additional penalties if their health IT developer does not provide a Health IT Module certified to the “real-time prescription benefit” criterion prior to the deadline for inclusion of the criterion in the Base EHR definition.

We further note that health IT developers may certify to the criterion beginning as soon as the testing tools are available subsequent to the effective date of this final rule. They are not required to wait until January 1, 2028, to update certified technology and provide it to their customers. In addition, health IT developers that already incorporate RTBTs or provide access to RTBTs may work with payers and other intermediaries to complete any updates necessary to ensure seamless access to existing tools.

Regarding the commenters' question about the applicability of the deadline CMS has finalized for payer RTBTs to conform to NCPDP RTPB standard version 13, we note that CMS finalized in 42 CFR 423.160(b)(5) that beginning January 1, 2027, Part D sponsors' RTBT must comply with a standard in 45 CFR 170.205(c) (where we adopted the NCPDP RTPB standard version 13). This deadline is specific to the requirements for RTBTs established by Part D plan sponsors.

Comment: A few commenters noted that ASTP should ensure that the requirements in this proposed rule are consistent with the requirements finalized for Part D plan sponsors in the Part D and Health IT Standards Final Rule.

Response: We appreciate commenters' input on the intersection between this final rule and regulations for Part D plan sponsors. We agree that HHS should support consistency across regulations, and we have worked closely with CMS to ensure our regulations are complementary. For instance, our adoption of the NCPDP RTPB standard version 13 in 45 CFR 170.205(c) is cross-referenced by CMS in 42 CFR 423.160(b)(5).

Comment: Several commenters requested the adoption of a complementary “role-based” certification criterion focused on the health IT used by payers to participate in RTBT workflows. Commenters stated that without this foundation, developers and healthcare providers are at risk of spending time and money on functionality that provides little value. These commenters requested that ASTP work with CMS to develop separate “real-time prescription benefit” criterion for providers and payers, similar to the approach for electronic prior authorization transactions

proposed in the HTI-2 Proposed Rule. A few commenters recommended only including the “real-time prescription benefit” criterion in the Base EHR definition once a corresponding “role-based” criterion for technology used by payers has been adopted and successfully implemented. They argued that without a role-based criterion, developers and providers might invest in functionality that does not get fully utilized or might not be ready to contribute to the system's functionality.

Response: We appreciate the suggestion to adopt a complementary “role-based” certification criterion for payer health IT used to support RTBTs. We have collaborated closely with CMS to advance alignment between regulations impacting Part D plan sponsors and our regulations for health IT developers participating in the Certification Program. Through that collaboration, ASTP/ONC adopted the NCPDP RTPB standard version 13 in a joint rulemaking in which CMS finalized a cross-reference that includes this standard in its requirements for Part D plan sponsors (42 CFR 423.160(b)(5)). ASTP/ONC subsequently proposed to incorporate this standard within the “real-time prescription benefit” criterion.

ASTP/ONC did not propose a certification criterion focused on health IT used by Part D plan sponsors, so finalizing a “role-based” certification criterion for payers would be out of scope for this final rule. However, we believe that requiring RTBTs established by Part D plan sponsors and certified Health IT Modules to adhere to the same implementation specification (NCPDP RTPB standard) will ensure a substantial degree of interoperability between provider and health plan systems, in the absence of certification of technology used by Part D plan sponsors. While we may explore with CMS whether the availability of a “role-based” certification criterion would provide additional benefits in the future, we believe the degree of interoperability that can be achieved under the current and proposed regulatory approach will provide value to health care providers and patients and implementation based on inclusion in the Base EHR definition should not be delayed further.

We also appreciate the comment that “role-based” certification criteria would ensure that developers and providers are investing in functionality that can be fully utilized by all parties. However, even without a “role-based” certification criterion for payers at this time, we believe it is necessary to include the “real-time prescription benefit” criterion in the Base EHR definition in order to fulfill the statutory requirements of section 119(b)(3) of the CAA, 2021 (Pub. L. 116-260), which added RTBT functionality to the definition of a qualified EHR in section 3000 of the PHSA.

Comment: Many commenters supported our proposal to add the “electronic prescribing” certification criterion to the Base EHR definition, noting that electronic prescribing reduces administrative burden for clinicians and pharmacists and improves medication adherence for patients. A commenter recommended including the “electronic prescribing” criterion in the Base EHR definition, without the “real- time prescription benefit” criterion.

Response: We thank commenters for their support. We agree that electronic prescribing reduces administrative burden for clinicians and pharmacists and can improve medication adherence for patients among other benefits. We have advanced certification criteria for electronic prescribing for more than a decade and have updated our criteria to maintain conformance to the latest available standards. However, given the near universal adoption of the criterion and the baseline requirements under CMS programs, we believe that adding the criterion to the Base EHR definition creates administrative burden on developers in the certification process without adding benefit to providers, pharmacies, or patients. In order to avoid unnecessary developer burden, which might be passed on to users in higher costs, we are not finalizing the inclusion of the criterion in the Base EHR definition. Regarding the recommendation to include the “electronic prescribing” criterion in the Base EHR definition but not the “real-time prescription benefit” criterion, we note that we believe it is necessary to include the “real-time prescription benefit” criterion in order to ensure that the Base EHR definition is aligned with the requirements of a qualified EHR in PHSA section 3000, as amended by section 119(b)(3) of the CAA, 2021.

Comment: A commenter did not believe there was a need for electronic prescribing to be added to the Base EHR definition because electronic prescribing is already widely adopted as a criterion. Adding this criterion to the Base EHR definition will add work for developers without being of much benefit to users.

Response: We agree with commenters that electronic prescribing functionality has reached a high level of adoption and is unlikely to further benefit from being included in the Base EHR definition. We had proposed to add the “electronic prescribing” criterion to the Base EHR due to its close intersection with the functionality in “real-time prescription benefit” criterion which we are finalizing in this rule. However, we believe the benefits for doing so are limited. In addition, we believe it is preferable to limit the criteria referenced in the Base EHR definition to those criteria required under the qualified EHR definition in section 3000 of the PHSA where possible.

Comment: Several commenters noted the importance of minimizing the burden of RTBTs on clinicians and healthcare organizations. They recommended that EHR vendors integrate this new criterion with minimal disruption to EHR usability. They also recommended that developers prioritize clinical efficiency and minimizing potential alert fatigue when developing and implementing RTBTs. Another commenter expressed concern that the higher performance capacities needed may create challenges for smaller, rural practices with poor broadband capabilities, resulting in computer screens freezing, slow response times to data entry, and interruptions for the entire clinical practice team. They requested that ASTP work with CMS to establish flexibilities for these practices.

Response: We appreciate commenters' concerns with the potential workflow implications of these capabilities and effects these capabilities may have on EHR products. As part of the proposed “real- time prescription benefit” criterion, we did not address issues related to design, usability, or alert burden as certification to this capability is new to the Certification Program and we do not yet have information about how we should incorporate these elements into the criterion. ASTP/ONC welcomes further input from the public about these topics and may consider them in future rulemaking.

ASTP/ONC recognizes that RTPB transactions may be impacted by broadband challenges that generally impact information exchange, and that such issues may disproportionately impact healthcare providers in rural areas. Regarding the commenter's request that ASTP/ONC work with CMS to establish flexibilities for these providers, we note that for the MIPS Promoting Interoperability performance category, CMS has established flexibilities that may apply to rural providers at 42 CFR 414.1380(c)(2), such as flexibilities that apply to small practices defined in 42 CFR 414.1305 as further specified at 42 CFR 414.1380(c)(2)(i)(C)(9). Additionally, we

encourage developers to implement Health IT Modules certified to the “real-time prescription benefit” criterion in a manner that gives provider organizations the flexibility to decide how frequently RTBT alerts should be triggered. Providers in areas with poor broadband capabilities could then limit the frequency of these alerts (for example, only when potential cost savings are substantial).

Comment: Several commenters emphasized the importance of making RTBTs available at no cost to healthcare organizations. A commenter cautioned that RTBTs should not be an option in the EHR but should rather be a required feature, because EHR vendors might then charge healthcare organizations to add the RTBT option, thus shifting the financial burden of RTBT development and adherence to the NCPDP RTPB standard to providers.

Response: We acknowledge that adopting Health IT Modules certified to the “real-time prescription benefit” criterion may have associated costs for providers and provider organizations. We expect that health IT developers seeking to offer health IT products that meet the Base EHR definition, where we proposed to include the real-time prescription benefit” criterion” would include this criterion in future offerings. However, we note that the ONC Health IT Certification Program is voluntary, and ASTP/ONC does not have the authority to direct health IT developers to include certain certified health IT capabilities in their products. We note that health IT developers that include Health IT Modules on the Certified Health IT Product List must publicly describe certain information about cost structure and included elements of their products, which may be helpful to customers.

Comment: Several commenters recommended that ASTP/ONC take steps to ensure that the information displayed to users in the EHR is accurate and consistent with patient-facing RTBT systems that are available through some plans, as well as cost estimates available to pharmacists working at retail pharmacies. These commenters note that inaccurate information could reduce the utility of this technology and increase burden for clinicians. They recommend that: (1) cost estimates come directly from the payer, rather than from representative data created by third parties that are not connected to payer data and that might include averaged claims data; and (2) EHR vendors create a structure to ensure the accuracy of information.

Response: We agree with the commenters about the importance of prioritizing accuracy of the RTBT information delivered to healthcare providers. We recognize that clinicians have previously expressed concerns about the accuracy of RTBT cost estimates, though we do not have further information about the extent of accuracy issues of RTBT cost estimates. We understand that if clinicians cannot trust this information, then they are less likely to use RTBTs in clinical practice. We will continue to explore these issues in collaboration with CMS, which sets requirements for Part D plan sponsors to implement RTBTs.

Comment: A commenter requested ASTP/ONC establish a standard process for including new criteria in the Base EHR Definition that would progress from modular criterion without inclusion in the Base EHR Definition to addition to Base EHR Definition depending on developers' ability to meet the criterion and market demand. A commenter expressed concern that adding several new items to the Base EHR definition at once may increase the burden on physicians and risk driving consolidation in the EHR market.

Response: ASTP/ONC appreciates this suggestion, however, we note that we did not propose the creation of a standard process for including new criterion in the Base EHR definition in the HTI-2 Proposed Rule and such a process is out of scope for this final rule. We may consider this suggestion as we explore updates to the Base EHR definition in future notice-and-comment rulemaking. We appreciate these concerns regarding the effect of adding items to the Base EHR definition. We agree that it is important to consider factors such as provider burden and impact on the market for health IT products when determining whether to add items to the Base EHR definition. We must balance these considerations with both the need to align the Base EHR definition with the elements of the qualified EHR definition in section 3000 of the PHSA and potential benefits from increasing the availability of certain certified Health IT Modules through additions to the Base EHR definition.

After consideration of public comments, we are finalizing to include the “real-time prescription benefit” health IT certification criterion (45 CFR 170.315(b)(4)) in the Base EHR definition in 45 CFR 170.102(3)(iv). We are further finalizing in 45 CFR 170.102(3)(iv) to include the “real-time prescription benefit” criterion the Base EHR definition as of January 1, 2028. We are not finalizing our proposal to add the “electronic prescribing” criterion (45 CFR 170.315(b)(3)) to the Base EHR definition.

We note that we did not receive any comments on our proposal in 45 CFR 170.550(g)(6) to require that a developer that obtains certification for the “electronic prescribing” certification criterion in 45 CFR 170.315(b)(3) must also obtain certification for the proposed “real-time prescription benefit” criterion in 45 CFR 170.315(b)(4), and we are finalizing as proposed. (c) Real-Time Prescription Benefit Standard

In the HTI-2 Proposed Rule we proposed in 45 CFR 170.315(b)(4)(i) that a Health IT Module certified to the “real-time prescription benefit” certification criterion must enable a user to perform certain real-time prescription benefit electronic transactions in accordance with at least one of the versions of the standard adopted in 45 CFR 170.205(c). Under this paragraph, ONC adopted the NCPDP RTPB standard version 13 \440\ on behalf of HHS in 45 CFR 170.205(c)(1) in the Part D and Health IT Standards Final Rule, which appeared in the Federal Register on June 17, 2024 (89 FR 51238 through 51265). We stated in the HTI-2 Proposed Rule (89 FR 63532) that if we adopt subsequent versions of the NCPDP RTPB standard in 45 CFR[thinsp]170.205(c), we believe our proposal to require the use of at least one of the versions of the standard adopted in 45 CFR[thinsp]170.205(c) would enable health IT developers to use any version of the standard adopted under this paragraph, unless we specify an adoption “expiration” date which indicates a certain version of the standard may no longer be used after that date.

\440\ See https://standards.ncpdp.org/Access-to-Standards.aspx.

The NCPDP RTPB standard version 13 enables the exchange of patient eligibility, product coverage, and benefit financials for a chosen product and pharmacy, and identifies coverage restrictions and alternatives when they exist. The benefits of the more recent NCPDP RTPB standard version 13 relative to NCPDP RTPB standard version 12 include improvements to the NCPDP RTPB Patient Segment, Product and Alternative Product Segments, and new elements, new values, and updated values to the schema, as well as administrative corrections that support consistency and clarity.

Because the NCPDP RTPB standard is relatively new and not yet widely implemented, we stated that we expect additional enhancements and improvements to the standard over time as more health IT developers adopt and implement the standard and more

exchange partners engage in the standards development process with NCPDP. We also stated that we encourage developers to remain familiar with updates occurring in newer versions of the NCPDP RTPB standard.

The following is a summary of the comments we received and our responses:

Comment: Many commenters supported our proposal to require use of the NCPDP RTPB standard version 13 for certification to the “real-time prescription benefit” certification criterion. Commenters believed that adoption of the standard would lead to wider adoption and increased utilization of RTBTs.

Response: ASTP/ONC thanks the commenters for their support.

Comment: A commenter encouraged ASTP/ONC to monitor for developments in the RTPB standard and explore requiring the most up-to- date and relevant features when available.

Response: ASTP/ONC recognizes the importance of implementers' ability to utilize improved versions of the standards we require for use in the Certification Program. We also understand that the regulatory process can be lengthy and may delay the adoption of updated standards requirements in a timely fashion. We continue to monitor updates to standards including the NCPDP RTPB standard, as well as receiving input from the public and through bodies such as the Health IT Standards Advisory Committee on updated versions of standards recommended for adoption in regulation. We also note that we have implemented measures under the Certification Program providing added flexibility for implementers, such as the Standards Version Advancement Process (SVAP). SVAP permits health IT developers to voluntarily update health IT products certified under the Certification Program to newer versions of adopted standards as part of real world testing Condition and Maintenance of Certification requirements under the Certification Program in 45 CFR 170.405.

Comment: A commenter expressed concerns regarding the applicability of NCPDP RTPB standard version 13 in long-term care settings.

Response: We note the commenter's concerns and will work with interested parties to ensure that standards continue to evolve to support all care settings, including long-term care and post-acute care facilities.

After consideration of public comments, we are finalizing our proposal in 45 CFR 170.315(b)(4)(i) to require that a Health IT Module certified to the “real-time prescription benefit” certification criterion enable a user to perform specified transactions in accordance with at least one of the versions of the standards adopted in 45 CFR[thinsp]170.205(c) (where we adopted NCPDP RTPB standard version 13). We clarify that under the final version of the criterion, only a version of the standard in 45 CFR[thinsp]170.205(c) that is not expired would be allowed for the conformance with the certification criterion. (d) Sending and Receiving Real-Time Prescription Benefit Information

In order to execute real-time prescription benefit checks in accordance with the NCPDP RTPB standard version 13, a provider originates the request for prescription benefit information for a specific patient from within their health IT. In return, a processor, pharmacy benefit manager, or adjudicator provides the appropriate response. In the HTI-2 Proposed Rule (89 FR 63532), we proposed in 45 CFR 170.315(b)(4)(i) that a Health IT Module certified to the “real- time prescription benefit” criterion must enable a user to perform specified transactions in accordance with at least one of the versions of the standard adopted in 45 CFR[thinsp]170.205(c) (where we adopted NCPDP RTPB standard version 13), as well as one of the versions of the standard in 45 CFR[thinsp]170.207(d)(1) (where we adopted RxNorm) and the standard in 45 CFR[thinsp]170.207(d)(2) (where we have cross- referenced National Drug Codes (NDC)).

We proposed in 45 CFR 170.315(b)(4)(i)(A) that a Health IT Module certified to the proposed criterion must enable a user to request patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives, in accordance with the RTPBRequest transaction. We proposed in 45 CFR 170.315(b)(4)(i)(B) that a Health IT Module certified to the proposed criterion must enable a user to receive patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives in response to a request, in accordance with the RTPBResponse transaction. RTPBRequest and RTPBResponse transactions are determined by patient, benefit, and product-specific information. Each request and response are unique with information conditioned on factors associated with each transaction. We noted that Health IT Modules certified to the proposed certification criterion should support transaction segments and associated data elements necessary to reflect both the information needed for a successful RTPBRequest and the information contained in a detailed RTPBResponse. As such, a Health IT Module must have the capability to send and receive both mandatory and situational transaction segments and associated data elements for RTPBRequests and RTPBResponse transactions as specified in NCPDP RTPB standard version 13. Finally, we proposed in 45 CFR 170.315(b)(4)(i)(C) that a Health IT Module certified to the proposed criterion must enable a user to be notified of errors when there is a problem with a real-time prescription benefit transaction, in accordance with the RTPBError transaction.

We requested comments on these proposals and whether we should consider other capabilities for the certification criterion in the future. The following is a summary of the comments we received and our responses:

Comment: A commenter noted the limitations of RxNorm and cautioned against its use. The commenter cautioned that using RxNorm may lead to inaccuracies in formulary and benefit information presented by RTBTs, because (1) some medications that are actively in the pharmacy supply chain are erroneously listed as “archived” (that is, no longer in supply) in the RxNorm lexicon and so may be listed as not covered by the RTBT; (2) it is not clear how frequently the RxNorm lexicon is updated when new medications enter the market; and (3) conversion between other medication lexicons used by insurers and pharmacies (for example, RxCUI and NDC) is imperfect. For example, the commenter noted that if an insurer uses RxCUI to place medication A in tier 1 and medication B in tier 2, an imperfect conversion may lead an RTBT to list both medication A and medication B in tier 1. The commenter cautioned that these problems may create inaccuracies in cost estimations, data quality checks, and formulary lookup databases. The commenter suggested more extensive testing of RxNorm lexicon conversions to ensure that they are accurate.

Response: ASTP/ONC appreciates the inputs provided regarding the challenges associated with the use of RxNorm. We recognize that instances may occur where RTBTs present inaccurate cost estimates or coverage information due to these issues and that such occurrences could lead to discouraging experiences. We encourage further testing of the accuracy of the RxNorm lexicon as well as the NDC-RxCUI conversion and may explore ways to advance further progress in this area. Despite these issues, these standards are necessary components of the “real- time prescription benefit”

criterion and are widely adopted across the health IT industry. For example, RxNorm codes are used by Health IT Modules certified to the “electronic prescribing” criterion at 45 CFR 170.315(b)(3), and are deployed across the majority of hospitals and office physicians in the US.

Comment: A commenter requested clarification on whether the “estimate cost information” referenced in 45 CFR 170.315(b)(4)(i)(A) and (i)(B) pertains to patient out-of-pocket costs, overall plan costs, or both.

Response: The estimated cost information referred to in the proposed language related to the RTPBRequest and RTPBResponse transactions only pertains to patient out-of-pocket costs. Prescribers using RTBTs that use NCPDP RTPB standard version 13 also have the capability to request and receive information on overall costs (field names are “estimated net plan cost” and “estimated combined plan and patient savings”) but only when allowed and provided by the plan.

Comment: A commenter discussed the term “therapeutic alternative” used in the proposed language in 45 CFR 170.315(b)(4)(i)(A), (i)(B), and (ii). The commenter requested this term be expanded or a definition added clarifying that it is inclusive of “clinically equivalent therapeutic alternatives.” The commenter stated that it was important to convey that “therapeutic alternatives” should not only be similar in terms of therapeutic effects, but also considered interchangeable based on clinical guidelines and patient needs.

Response: We respectfully disagree with the recommendation to clarify that the term “therapeutic alternative” is inclusive of the term “clinically equivalent therapeutic alternative.” Therapeutic alternatives are suggested based on the rules outlined by a PBM, responding organization, or their third-party drug compendia. Therefore, a medication identified as a therapeutic alternative may produce a similar therapeutic response, but not be equivalent based on pharmaceutical active ingredient, dosage form, route of administration or safety profiles.

We further note that the NCPDP RTPB standard version 13 uses the terminology “alternative product,” which is more inclusive of medications and other products. We believe that using this term, instead of the proposed term “therapeutic alternative.” In order to provide additional consistency between our regulation text and the language used in the NCPDP RTPB standard we are finalizing a modification of the term “therapeutic alternative” as proposed in 45 CFR 170.315(b)(4)(i)(A) and (B) to “alternative product.”

Comment: Several commenters noted that the NCPDP RTPB Standard Version 13 does not contain an RTPBError transaction, as referenced in proposed 45 CFR[thinsp]170.315(b)(4)(i)(C). Instead, the name of the transaction for a plan to notify a prescriber that a system error occurred is “Error.” Some commenters also noted that errors are flagged when RTPBResponse is returned as a reject code and recommended not requiring the “Error” transaction as part of the certification criterion. A commenter stated that displaying the Error transaction to end-users would be inappropriate since end-users cannot resolve errors and displaying this information could contribute to alert fatigue. The commenter recommended making the error transaction only available to system administrators.

Response: ASTP/ONC appreciates commenters' concerns with our proposal to require a Health IT Module certified to the “real-time prescription benefit” criterion enable a user to be notified of errors when there is a problem with a real-time prescription benefit transaction. We also acknowledge that we inadvertently referred to an “RTPBError” transaction within NCPDP RTPB standard version 13. We further agree with commenters that it is not necessary to finalize a separate requirement related to this capability within the certification criterion. Health IT developers that implement the transactions in the NCPDP RTPB standard version 13 we have specified would already be implementing the capability to receive a reject code-- also called “Error” as noted by the commenter--in response to the RTPBRequest transaction as part of fully implementing the requirements in NCPDP RTPB standard version 13. We also agree with commenters that it would be more appropriate for health IT developers to determine how errors are received or presented by a Health IT Module, which will allow developers to determine what is most useful for their customers.

Comment: A commenter disagreed with the statement in the proposed rule that a Health IT Module be capable of sending and receiving all situational segments and data elements specified in NCPDP RTPB standard version 13. The commenter noted that the standard states that “situational or optional fields and segments may be added to or deleted from the transmission as necessary to accommodate changing needs” and that health IT developers should have flexibility in how, when, and what to display to users based on feedback from those users on what is most valuable.

Response: We thank the commenter for their concerns. In the HTI-2 Proposed Rule, we stated that a Health IT Module must have the capability to send and receive both mandatory and situational transaction segments and associated data elements for RTPBRequest and RTPBResponse transactions (89 FR 63532). This statement was intended to convey that health IT developers must implement products that are able to transmit information in segments with these designations, consistent with the required implementation of NCPDP RTPB standard version 13. The NCPDP RTPB standard provides additional details on which situations require which situational fields for each transaction type. This statement was not intended to require specific expectations related to how, when, or what to display to users. We also note that we did not propose requirements to support optional field segments.

Comment: Commenters provided a number of additional recommendations related to the proposals in this section. Several commenters suggested incorporating standards that would provide clinicians and patients with information on availability of ordered medications at the selected pharmacy (that is, on their formulary, in stock, time to delivery or pick-up) to prevent delays in access to medications. Other commenters suggested considering additional standards that would facilitate visibility into potential cost savings attributable to drug discount programs. Several commenters requested consideration of real-time price transparency capabilities for other types of care in the future, including medications covered under the medical benefit. Finally, a commenter recommended making data from real-time benefit transactions accessible to third party clinical decision support tools that could then configure their medication recommendations to take cost and coverage into account or eventually integrate such information and display it alongside a clinical decision support recommendation. Another commenter requested that ASTP/ONC implement protections to prevent the use of data submitted or received as part of real-time prescription benefit activities for purposes besides electronic prescribing or to monetize the data.

Response: ASTP/ONC thanks commenters for their additional recommendations to improve RTBT functionality. Regarding availability of

ordered medications at the selected pharmacy, we note that standards development organizations are currently pursuing activities in this area and invite commenters to learn more about these initiatives. Regarding incorporation of out-of-pocket cost information related to drug discount programs, we agree incorporation of this information could provide additional price transparency and additional opportunities for cost savings for patients. We will continue to monitor developments to support queries to all drug discount programs. Regarding transparency for medications under a medical benefit, we note that while prescription medications are often one of the most expensive aspects of patient care, patients could also benefit from access to easily accessible, real-time cost estimates for other aspects of their care (for example, procedures, imaging, laboratory tests, and medications covered under Part B) and we will work with partners across HHS on efforts to address these capabilities through future rulemaking and other initiatives. Finally, we appreciate the comments about the benefits of making RTBT data accessible to third-party clinical decision support tools. The recommendations made by RTBTs for lower- cost alternatives are currently based on insurer formularies and preferred pharmacies, without accounting for other clinically important information. For example, if a clinician prescribes an antidepressant that is not preferred on a patient's insurance formulary, the RTBT's recommendations for alternatives in the same therapeutic class will not account for medications that the patient has previously tried and failed, or the possibility of interactions with other medications the patient is currently prescribed. We appreciate commenters' concerns about data privacy and will continue to closely monitor public feedback and developments in data privacy in collaboration with other HHS partners, including OCR.

Comment: A commenter requested that ASTP/ONC clarify expectations for the amount of time it should take for queried information to be returned.

Response: Given the time pressures on clinicians, we agree that it is important for queried information to be returned promptly. The amount of time it takes for queried information to be returned may be based on a number of factors, including the systems of the Part D sponsor, PBM, or other third-party vendor providing the information, as well as local broadband capabilities. We recognize that health IT developers have limited ability to control these factors as part of certified Health IT Modules, but we encourage developers to consider features that can mitigate the impact of variable response times on users' experience.

Comment: A commenter expressed concern that one potential unintended consequence of out-of-pocket cost availability is that clinicians and patients will engage in excessive cost-based scrutiny of clinically appropriate treatment.

Response: We understand that a potential impact of price transparency policy is that patients will engage in cost-based scrutiny. We note, however, that there is robust evidence that patients frequently use cost-based scrutiny outside of the clinic already. For example, a fifth of patients forgo prescribed medications due to cost and do so at high cost to their health.441 442 Patients generally make decisions about which medications to forgo when they are at the pharmacy, without input from their physician. We believe the availability of real-time prescription benefit information provides patients and clinicians with the opportunity to engage in more appropriate cost-based scrutiny. By discussing both financial and clinical tradeoffs at the time of the clinic visit, clinicians can help patients find the treatment that is both most clinically appropriate for the patient and financially affordable. These interactions can also help clinicians to ensure that they fully understand a patient's circumstances when using real-time prescription benefit information to inform recommendations to the patient.

\441\ Dusetzina, Stacie B., et al. “Cost-related medication nonadherence and desire for medication cost information among adults aged 65 years and older in the US in 2022.” JAMA Network Open 6.5 (2023): e2314211-e2314211.

\442\ Nekui, Farrah, et al. “Cost-related medication nonadherence and its risk factors among Medicare beneficiaries.” Medical care 59.1 (2021): 13-21.

After consideration of public comments, we are finalizing our proposed requirements in 45 CFR 170.315(b)(4)(i)(A)-(B) with modifications. Specifically, we are finalizing a modification of the term “therapeutic alternative” as proposed in 45 CFR 170.315(b)(4)(i)(A), (i)(B), 45 CFR 170.315(b)(4)(ii) to “alternative product.” We are not finalizing our proposal at 45 CFR[thinsp]170.315(b)(4)(i)(C) that a Health IT Module certified to the proposed criterion must enable a user to be notified of errors when there is a problem with a real-time prescription benefit transaction, in accordance with the “RTPBError transaction” referred to in the proposed rule. (i) Use of XML Format

We proposed in 45 CFR 170.315(b)(4)(i) that a Health IT module certified to the criterion must enable a user to perform the specified transactions using the XML format. While the NCPDP RTPB standard version 13 supports both EDI and XML formats, in response to the RFI included in the HTI-1 Proposed Rule (88 FR 23746), we received many comments in support of testing the XML format of the RTPB standard alone or with the EDI format as optional. Additionally, commenters recommended that ONC should test the format each individual health IT developer has chosen for its own system to be tested in. Some commenters also shared a desire to move away from XML and EDI altogether, preferring the JSON format instead, noting industry plans for the future retirement of XML and EDI. A commenter suggested certification in either format, with requirements that health IT be capable of demonstrating translation capabilities between EDI and XML. We stated in the HTI-2 Proposed Rule (89 FR 63532) that we believe that proposing to only require use of the XML format will simplify testing for health IT developers. We noted that ONC will continue to monitor syntax and format updates and development for real-time benefit transactions and associated standards.

The following is a summary of the comments we received and our responses:

Comment: Several commenters supported the proposal that a Health IT module certified to the “real-time prescription benefit” criterion must enable a user to perform the specified transactions using the XML format, arguing that this would simplify testing for health IT developers, increase standardization, and enhance interoperability. Commenters recommended that ASTP/ONC monitor developments in this area since NCPDP is in the process of transitioning its standards to JSON, which may present enhanced interoperability capabilities in the future. A commenter recommended offering the flexibility to choose between XML and JSON, arguing that allowing for either option would accommodate a broader range of use cases and preferences among developers and organizations, would promote innovation, and would ensure that systems are more adaptable to varying technical environments.

Response: We thank the commenters for their support of the proposal to require a Health IT Module certified to the “real-time prescription benefit”

criterion to enable users to perform specified transactions using the XML format and agree that this is the most appropriate format for inclusion as part of the “real-time prescription benefit” criterion. We appreciate the comments regarding the use of JSON; however, NCPDP RTPB standard version 13 does not currently support JSON. We will consider requiring support for the JSON format in future rulemaking as it is incorporated into future versions of the NCPDP RTPB standard. As discussed in the proposed rule, NCDP's RTPB Standard Version 13 supports only XML and EDI formats (89 FR 63532). We did not propose to require support for EDI because it is an older format that is being used with less frequency by developers.

After consideration of public comments, we are finalizing our proposal in 45 CFR 170.315(b)(4)(i) to require that a Health IT Module certified to the “real-time prescription benefit” criterion must enable users to perform the specified transactions using the XML format. (e) Additional Topics (i) Display

We proposed in 45 CFR 170.315(b)(4)(ii) that a Health IT Module certified to the criterion must display to a user in human readable format patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives in accordance with at least one of the versions of the standard in 45 CFR[thinsp]170.205(c) (where we adopted NCPDP RTPB standard version 13). We noted that the ability to display RTPB data provides access to this information and is essential for a user to be able to use the information to inform shared decision-making as the provider and patient determine the treatment that will be best for them.

Comment: A commenter supported the proposal that a Health IT Module certified to the “real-time prescription benefit” criterion must display to a user in human readable format patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives. A commenter noted that lack of usability of real-time benefit information particularly impacts patients who are dually insured.

Response: We thank the commenters for their support. We encourage health IT developers to continue to improve the usability of how real- time benefit information is displayed to end users, including for patients with more complex coverage.

After consideration of public comments, we are finalizing our proposal in 45 CFR 170.315(b)(4)(ii) regarding the display of benefit information in a human readable format with modification. We are changing the term “therapeutic alternative,” which was used in proposed in 45 CFR 170.315(b)(4)(ii), to “alternative products” for consistency with the revisions to similar proposed language that we are finalizing in 45 CFR 170.315(b)(4)(i)(A)-(B). We describe the reasons for revising this term in section XI.B.4.b.(4)(d). of this final rule. (ii) Scope

The NCPDP RTPB standard version 13 supports real-time prescription benefit requests and responses for a variety of items manufactured for sale such as medications, vaccines, and medical devices or supplies.\443\ While the majority of products covered by an individual's pharmacy benefit will be medications, Part D drugs, as defined at 42 CFR 423.100, can include prescription medications, vaccines, and supplies associated with the injection of insulin (for example, syringes, alcohol pads, gauze), and are represented by RXCUIs \444\ on the formulary file.

\443\ See https://www.ncpdp.org/Access-to-Standards.aspx.

\444\ An RXCUI is a machine-readable code or identifier that points to the common meaning shared by the various source names grouped and assigned to a particular concept. More information can be found at https://www.nlm.nih.gov/research/umls/rxnorm/overview.html.

In the HTI-1 Proposed Rule we requested comment on the appropriate scope for a “real-time prescription benefit” certification criterion, including whether a “real-time prescription benefit” certification criterion should require support for products that are not defined as medications but may also be included in a RTPB transaction, namely vaccines and medical devices or supplies (87 FR 23853). We received several comments in response to our request for information on this topic, with several commenters encouraging an initial focus on medications for the certification criterion.

In the HTI-2 Proposed Rule (89 FR 63533), we stated that, in addition to medications, we believe it is important to require Health IT Modules certified to the “real-time prescription benefit” criterion to be able to support vaccines, and note that under Part D regulations and guidance, plans include most commercially available vaccines on their formularies.\445\ However, we stated that we are not proposing to include devices and supplies in the proposed certification criterion at this time. We noted that the NCPDP RTPB standard version 13 does yet not support the FDA Unique Device Identification System unique device identifiers (UDIs), which are identified as the standard for the Unique Device Identifier--Implantable data element in the Medical Devices data class in the USCDI.\446\ Additionally, we noted that devices covered under a pharmacy benefit may be defined as a drug under Section 201(g) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 321(g)) rather than a device under Section 201(h) and therefore are not assigned a Unique Device Identifier for Implantable Devices. We stated that ONC will continue to monitor advancements to the NCPDP RTPB standard to support unique identifiers for devices, any related developments at the FDA, and updates to the standardization and exchange of device and supplies data.

\445\ See “Medicare Prescription Drug Benefit Manual: Chapter 6--Part D Drugs and Formulary Requirements” 30.2.7 at https://www.cms.gov/medicare/prescription-drug-coverage/prescriptiondrugcovcontra/downloads/part-d-benefits-manual-chapter-6.pdf.

\446\ See USCDI v4: https://www.healthit.gov/isa/taxonomy/term/821/uscdi-v4.

In summary, we proposed in 45 CFR 170.315(b)(4)(iii) that the scope of the criterion is limited to medications and vaccines covered by a pharmacy benefit. We invited comments on this proposal.

The following is a summary of the comments we received and our responses:

Comment: Many commenters agreed that vaccines should be included in the scope for the “real-time prescription benefit” criterion, as proposed. A commenter believed that vaccine cost estimation capabilities were not necessary, noting that it is atypical for clinicians to write prescriptions for vaccines. A commenter requested clarification on whether providers should be expected to receive a message if a vaccine is not covered.

Response: We recognize that clinicians do not commonly write prescriptions for vaccines. Additionally, the Inflation Reduction Act of 2022 (Pub. L. 117-169) eliminated cost sharing and deductibles for adult vaccines recommended by the Advisory Committee on Immunization Practices (ACIP) covered under Medicare Part D. However, Part D-covered vaccines are included in insurance formularies with other Part D- covered medications. Therefore, we did not propose and are not finalizing to exclude vaccines from the scope of the criterion, even though clinicians may be unlikely to seek out benefit information on vaccines.

Regarding whether a response is generated in response to a request regarding a vaccine, we note that when a RTPBRequest segment is processed, the RTPBResponse provides information on whether the product is covered, not covered, or covered with restrictions.

Comment: Regarding supplies, several commenters disagreed with the statement in the proposed rule that NCPDP RTPB standard version 13 does not yet support FDA Unique Device Identification System unique device identifiers (UDIs) (89 FR 63533). Commenters stated that the RTPB standard version 13 supports the communication of the mandatory, fixed Device Identifier portion of the UDI as issued by FDA Accredited Issuing Agencies, enabling support for information related to products and services covered under the pharmacy benefit, including medications, vaccines, supplies, devices, and prescription digital therapeutics. A commenter emphasized the importance of providing cost estimates for diabetes supplies, which comprise a substantial proportion of diabetes- related expenses. A few commenters supported limiting the RTPB scope to just medications and supplies.

Response: We appreciate the feedback from commenters. We agree with commenters that the NCPDP RTPB standard version 13 supports the exchange of information using the FDA UDI system. We also agree that there are important applications for real-time benefit services for supplies, which can be an important source of out-of-pocket costs for patients, such as the diabetes supplies noted by a commenter. Being able to understand costs for supplies has the potential to improve patients' financial security and access.

After consideration of the public comments, we are not finalizing the proposed language at 45 CFR 170.315(b)(4)(iii) specifying a scope for the “real-time prescription benefit” certification criterion as we believe that it is unnecessary to limit the scope of the criterion. In the absence of this limitation, we expect that Health IT Modules certified to the “real-time prescription benefit” criterion will enable the exchange of information for any product and service covered under a pharmacy benefit consistent with the specifications in the NCPDP RTPB standard version 13. (iii) Formulary and Benefit

In the HTI-1 Proposed Rule, we requested comment on whether we should further explore capabilities for Health IT Modules to support access to formulary and benefits information and provided detail about how access to formulary and benefits information was previously supported within the Certification Program. We noted that in the 2015 Edition Final Rule, ONC included a “Drug-formulary and preferred drug list checks” certification criterion in 45 CFR 170.315(a)(10). However, ONC did not adopt the proposed NCPDP Formulary and Benefit standard version 3.0 to support this criterion due to comments received in response to the 2015 Edition Proposed Rule (80 FR 16821). The drug formulary and preferred drug list checks 45 CFR 170.315(a)(10) certification criterion was later removed from the Certification Program in the ONC Cures Act Final Rule (85 FR 25660) because this functionality was widely available, and there was not sufficient reason to justify the burden on developers and providers of meeting Certification Program compliance requirements specific to this criterion. We noted that updates, enhancements, and corrections have been made to the NCPDP Formulary and Benefit standard since we considered adopting version 3.0, and many of these updates addressed concerns commenters expressed previously (87 FR 23854).

Subsequently, in the Part D and Health IT Standards Final Rule, we finalized adoption of NCPDP Formulary and Benefit standard version 60 in 45 CFR 170.205(u) (89 FR 51260), reflecting an aligned approach with the Part D Program to adoption of standards that support electronic prescribing. In the same rulemaking, CMS finalized, in 42 CFR 423.160(b)(3), a cross-reference to a standard in 45 CFR 170.205(u), which includes NCPDP Formulary and Benefit standard version 60, as part of the requirements for transmitting formulary and benefit information between prescribers and Part D sponsors (89 FR 51250 through 51251). However, we did not make any updates to the Certification Program to incorporate the proposed Formulary and Benefit standard as part of certification criteria.

In response to our request for comment in the HTI-1 Proposed Rule, some commenters supported incorporation of capabilities to access formulary and benefits information within the Certification Program based on the NCPDP Formulary and Benefit standard. However, many stated that a certification criterion based on the standard is not necessary as this functionality is already widespread in the industry due to existing CMS regulatory requirements. Furthermore, these commenters stated that a criterion based on the NCPDP Formulary and Benefit standard may limit innovation around other approaches to obtaining formulary and benefit information currently being explored by the industry.

In the HTI-2 Proposed Rule (89 FR 63533), we stated we considered the comments received in response to the RFI and have determined not to propose new functionality related to formulary and benefits information within the Certification Program at this time. We also noted that we proposed to adopt the HL7 FHIR Da Vinci--Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1--STU 2, in 45 CFR 170.215(m)(i) in the HTI-2 Proposed Rule. In this final rule, we are finalizing adoption of this IG in 45 CFR 170.215(m)(i). Use of the PDex Drug Formulary IG supports the availability of a payer's drug formulary via a FHIR interface, providing an alternative pathway for making this information available for those payers that have not implemented the NCPDP Formulary and Benefit standard.

The following is a summary of the comments we received and our responses:

Comment: Several commenters noted the importance of providing formulary and benefit information to clinicians to aid in decision making, reduce delays in care, and reduce administrative burden. A commenter requested that ASTP/ONC work to ensure accuracy of formularies and identified several concerns related to formulary accuracy. They further recommended steps to improve formulary accuracy, including standardizing and harmonizing search scopes across formularies, ensuring availability and interoperability of additional information that may be contained in formularies, and requiring the use of and dissemination of a standardized public identifier for each distinct formulary an insurer maintains.

Response: We thank commenters for their feedback. While we did not make any proposals related to formulary information in the proposed rule, we will continue to work with CMS and other HHS partners on issues around improving formulary accuracy. We acknowledge that for RTBTs to be valuable and trustworthy, the cost and coverage information they present must be accurate. Part D plan sponsors should ensure that formulary files are updated in a timely manner, so that when RTPB transactions are sent, they return accurate coverage information.

We did not make and are not finalizing any proposals related to formulary and benefits.

(iv) Negotiated Price

Section 1860D-4(o)(2)(B)(ii) of the Act, as added by section 119(a) of the CAA, 2021, specifically requires real-time benefit tools capable of providing information on “cost-sharing information and the negotiated price” for drugs and alternatives. In the HTI-2 Proposed Rule (89 FR 63533), we noted that we have not proposed to include negotiated price in the proposed 45 CFR 170.315(b)(4) certification criterion. We stated the NCPDP RTPB standard version 13 does not include fields to support the exchange of negotiated price. We solicited comments regarding negotiated price in response to the RFI, and commenters expressed strong disapproval for the inclusion of negotiated price in RTBTs. Additionally, we noted concerns were shared that plan negotiated prices may be confusing to providers and patients and are not likely to assist or improve the utility or usability of technology certified to a real-time prescription benefit certification criterion. We also noted that the exchange of negotiated price by Part D sponsors when implementing an electronic real-time benefit tool is not currently supported by the NCPDP RTPB standard version 13. NCPDP RTPB standard version 13, which we proposed to incorporate into the proposed “real-time prescription benefit” certification criterion, is the best available standard for use currently to provide patient specific cost-sharing information. Unfortunately, we have not identified a standard or any consistent approach to deliver reliable negotiated price information in real-time. We stated that ONC will continue to work with CMS and other interested parties to determine how negotiated price information may be made available and what technical approaches exist to support transparency in negotiated prices of drugs.

The following is a summary of the comments we received and our responses:

Comment: A commenter noted that NCPDP RTPB Standard Version 13 does not currently contain negotiated price fields. Several commenters expressed disappointment that the standard does not include negotiated price, and that including negotiated price would enhance transparency and ensure that all stakeholders have a clear understanding of the financial implications of medical decisions.

Response: In prior rulemaking, some commenters have requested a display of full negotiated price, while others have expressed concerns that disclosing negotiated prices would have anticompetitive effects (89 FR 51249). We appreciate the interest in this information and acknowledge the requirement in section 119(b) of Subtitle B of Title I of Division CC of the CAA, 2021 that a qualified electronic health record (as defined in in section 3000(13) of the Public Health Service Act) include an RTBT capable of transmitting cost sharing information and the negotiated price of a drug and its formulary alternatives, among other requirements. As noted in the HTI-2 Proposed Rule, at this time, NCPDP RTPB standard version 13, which we have incorporated in the “real-time prescription benefit” criterion, lacks fields that support the exchange of negotiated prices, but it is the best available standard and otherwise meets the statutory requirements for RTBTs (89 FR 63533 through 63534). CMS and ASTP/ONC will continue to work with other interested parties to determine how and at what time negotiated price information may be made available in RTBTs and certified Health IT Modules supporting access to real-time benefit information.

We did not make and are not finalizing any proposals related to negotiated price.

In summary, after consideration of the public comments, we are finalizing adoption of the proposed “real-time prescription benefit” certification criterion in 45 CFR 170.315(b)(4) with the following modifications:

We are replacing the term “therapeutic alternatives” in 45 CFR 170.315(b)(4)(i)(A), (i)(B), and (ii) with the term “alternative products.”

We are clarifying that a Health IT Module must enable a user to conduct transactions in accordance with one of the versions of RxNorm “at a minimum” to ensure alignment with the existing minimum standards code set policy in the Certification Program in 45 CFR 170.555.

We are not finalizing the proposed requirement 45 CFR 170.315(b)(4)(i)(C) that a Health IT Module enable a user to be notified of errors when there is a problem with a real-time prescription benefit transaction.

We are not finalizing the provision at 45 CFR 170.315(b)(4)(iii) to limit the scope of the criterion to medications and vaccines covered by a pharmacy benefit. (5) New Certification Criteria for Modular API Capabilities (a) Background

In the HTI-2 Proposed Rule, we proposed to add a new paragraph (j) to 45 CFR 170.315 titled “modular API capabilities.” We stated that this new certification criteria category would promote the Certification Program's modular certification approach and, importantly, would enable different combinations of capabilities across Health IT Modules depending on future use case needs. We noted in the HTI-2 Proposed Rule (89 FR 63567) that, in general, we expect the capabilities in 45 CFR 170.315(j) to be standards-based and include a combination of new and existing standards, many of which are currently referenced in 45 CFR 170.315(g)(10). Additionally, we stated we anticipate that the proposed capabilities in 45 CFR 170.315(j) would enable the Certification Program to better support a growing number of clinical, public health, and administrative use cases over the long- term, as well as foster innovation and competition in these spaces by providing flexibility for modular development approaches among developers of certified health IT.

We discussed in the HTI-2 Proposed Rule (89 FR 63567) that since 2020, the standards development community has undertaken work to: (1) update existing standards and implementation specifications (for example, US Core IG from version 3.1.1 to 7.0.0 \447\); (2) formalize previously functional capabilities as part of implementation specifications (for example, token introspection is now part of SMART App Launch 2.0 \448\); and (3) support new and revised capabilities that are modular and use case agnostic (for example, HL7 CDS Hooks \449\, FHIR Subscriptions \450\, and UDAP Security FHIR IG \451\, among other implementation specifications). These developments have changed the heath IT landscape and helped support a wider range of potential technical solutions for healthcare use cases that previously may not have been supported, or were ineffectively supported, by health IT.

\447\ https://hl7.org/fhir/us/core/history.html.

\448\ https://hl7.org/fhir/smart-app-launch/STU2/token-introspection.html.

\449\ https://cds-hooks.hl7.org/.

\450\ https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/.

\451\ https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/index.html.

We noted that by using the term “modular” we mean certification criteria in the Certification Program that are scoped to limited capabilities to enable health IT developers to certify to the specific certification criteria that apply to Health IT Modules they wish to certify, rather than large, multi-functionality, and all-encompassing certification criteria that would give

developers less flexibility for certifying in the Certification Program.

Based on our analysis of the continued evolution of standards and the real-world implementation scenarios for certified health IT to enable FHIR-based APIs, we proposed in the HTI-2 Proposed Rule (89 FR 63568) to adopt new certification criteria as modular API capabilities proposed as certification criteria in 45 CFR 170.315(j).

Under the narrow focus for this final rule, we are only finalizing two criteria proposed in 45 CFR 170.315(j) that we proposed to reference within the proposed “prior authorization API--provider” criterion in 45 CFR 170.315(g)(34). Specifically, we are finalizing the “workflow triggers for decision support interventions--clients” criterion that supports workflow triggers for decision support interventions client capabilities in 45 CFR 170.315(j)(20), and the “subscriptions--client” criterion that supports subscriptions client capabilities in 45 CFR 170.315(j)(21) (proposed in 45 CFR 170.315(j)(24)). At this time, we are not finalizing any of the other certification criteria we proposed in 45 CFR 170.315(j). However, we may consider finalizing these criteria in future notice-and-comment rulemaking. (b) Modular API Capabilities Certification Criteria (i) Workflow Triggers for Decision Support Interventions--Client

In the HTI-2 Proposed Rule, we proposed to adopt the CDS Hooks Release 2.0 implementation specification (CDS Hooks IG) in 45 CFR 170.215(f)(1) to support the Certification Program requirements for the proposed certification criterion in 45 CFR 170.315(j)(20), which establishes requirements for “clients” participating in API-based workflow triggers for decision support (89 FR 63570).

CDS Hooks is a specification that describes a “hook”-based pattern for invoking or triggering decision support from within a clinician's workflow (typically the “client” side of this pattern). We described that this pattern facilitates a clinician's ability to either pull in results from decision support directly into a clinician's workflow or can be used to launch an interactive application (89 FR 63571).

We proposed that a Health IT Module presented for certification to 45 CFR 170.315(j)(20) support the requirements of the implementation specification in 45 CFR 170.215(f)(1) (where we proposed to adopt CDS Hooks Release 2.0) as a “CDS Client,” including support for the registration of “CDS Services” according to the implementation specification in 45 CFR 170.215(f)(1), in 45 CFR 170.315(j)(20)(i), and support for authentication and authorization \452\ according to the implementation specification in 45 CFR 170.215(f)(1), in 45 CFR 170.315(j)(20)(ii) (89 FR 63570).

\452\ CDS Hooks Release 2.0 includes authentication and authorization of endpoints and identity of the CDS Client. We direct readers to the implementation specification for more detail.

We also proposed in 45 CFR 170.315(j)(20)(iii) that Health IT Modules certified to 45 CFR 170.315(j)(20) support the execution of decision support workflow triggers in accordance with the implementation specification in 45 CFR 170.215(f)(1), as well as demonstrate the ability to send a decision support request to a CDS Service according to the implementation specification in 45 CFR 170.215(f)(1), in 45 CFR 170.315(j)(20)(iv) (89 FR 63570).

As part of the capability to send a decision support request to a CDS Service, we proposed in 45 CFR 170.315(j)(20)(iv)(A) that a Health IT Module support the ability to deliver a CDS Hook request with pre- fetched information according to the “Pre-fetch Template” section of the implementation specification in 45 CFR 170.215(f)(1). We also proposed that the Health IT Module support access to HL7 FHIR Resources via a RESTful API to support decision support intervention workflows according to the “FHIR Resource Access” section of the implementation specification in 45 CFR 170.215(f)(1), in 45 CFR 170.315(j)(20)(iv)(B). Finally, we proposed that a Health IT module support the receipt of a decision support response according to the implementation specification in 45 CFR 170.215(f)(1), in 45 CFR 170.315(j)(20)(iv)(C), including support for the display of the contents of a decision support response to an end-user and support for the ability to launch internal apps and SMART apps from decision support responses according to the implementation specification in 45 CFR 170.215(f), including support for the “Link” field “appContext,” in 45 CFR 170.315(j)(20)(iv)(C)(1) and 45 CFR 170.315(j)(20)(iv)(C)(2), respectively.

In the HTI-2 Proposed Rule, we noted that the proposed workflow triggers criterion in 45 CFR 170.315(j)(20) did not define or propose specific workflows associated with decision support, including how and when clinicians use decision support capabilities (89 FR 63571). Rather, we proposed to include standards-based interfaces in 45 CFR 170.315(j)(20) to enable clinical systems to call other systems offering decision support services in a standardized manner to support the exchange and use of these services.453 454 455

\453\ Bradshaw, R.L., Kawamoto, K., Kaphingst, K.A., Kohlmann, W.K., Hess, R., Flynn, M. C., . . . Del Fiol, G. (2022). GARDE: a standards-based clinical decision support platform for identifying population health management cohorts. Journal of the American Medical Informatics Association: JAMIA, 29(5), 928-936. doi:10.1093/ jamia/ocac028.

\454\ Morgan, K.L., Kukhareva, P., Warner, P.B., Wilkof, J., Snyder, M., Horton, D., . . . Kawamoto, K. (2022). Using CDS Hooks to increase SMART on FHIR app utilization: a cluster-randomized trial. Journal of the American Medical Informatics Association: JAMIA, 29(9), 1461-1470. doi:10.1093/jamia/ocac085.

\455\ Watkins, M., & Eilbeck, K. (2020). FHIR Lab Reports: using SMART on FHIR and CDS Hooks to increase the clinical utility of pharmacogenomic laboratory test results. AMIA Summits on Translational Science proceedings, 2020, 683-692.

We requested comment on these proposals. The following is a summary of the comments received on the HTI-2 Proposed Rule and our responses:

Comment: Several commenters supported our proposal to adopt the “workflow triggers for decision support interventions--client” certification criterion at 45 CFR 170.315(j)(20) to enable clinical systems to call other systems offering decision support services in a standardized manner, leveraging the CDS Hooks standard proposed for adoption at 45 CFR 170.215(f)(1). Many commenters supported our proposed requirements to reference the “workflow triggers for decision support interventions--client” criterion in the proposed “prior authorization API--provider” criterion in 45 CFR 170.315(g)(34) to facilitate prior authorization workflows. Other commenters highlighted broader benefits of CDS Hooks to support adherence to clinical guidelines, reduce medical errors, and support real-time notifications for patient visits.

Response: We thank commenters for their support.

Comment: Several commenters offered recommendations on whether and which “hooks” the Certification Program should require Health IT Modules to support in the “workflow triggers for decision support interventions--client” criterion. Many commenters supported the number and types of hooks we proposed to be supported by Health IT Modules in the Certification Program. Other commenters recommended we finalize support for fewer hooks and that we finalize a policy of flexibility that would enable developers of certified health IT

to support at least one hook based on what will provide the most value for their particular customer base. Some commenters recommended the Certification Program require Health IT Modules to support “order- select” as a required hook for initial implementation to support earlier decision support in workflows and reduce interruptions. Other commenters suggested the Certification Program also require support for the “order-sign,” “patient-view,” and “appointment book” hooks. One of these commenters additionally recommended that the Certification Program add required support for the “suggestions” and “feedback” capabilities of the CDS Hooks standard. Still other commenters supported the adoption of specified hooks only when an IG exists to support a specific use case, noting that any hook will need to be use case-specific in order to provide industry value.

Response: We thank commenters for their input regarding whether and which hooks to require support for across the Certification Program. We note that within our proposals for the certification criterion in 45 CFR 170.315(j)(20) we did not specify which hooks Health IT Modules would be required to support. Rather, we specified hooks within proposed criteria referencing 45 CFR 170.315(j)(20), including the proposed “prior authorization API--provider” certification criterion, at 45 CFR[thinsp]170.315(g)(34)(i)(B). As described in the “Coverage Requirements Discovery” section IX.B.4.b.(6) of this final rule we are finalizing one required hook (the “order-sign” hook) as part of “provider prior authorization API--coverage requirements discovery” criterion at 45 CFR 170.315(g)(31)(i)(B). We are not finalizing any specific hooks in 45 CFR 170.315(j)(20). We understand commenters' concerns regarding the scope of requirements for this new specification and, consistent with these concerns, we are finalizing only one required hook in the Certification Program at this time.

Comment: Some commenters questioned whether proposed timelines for implementation were appropriate and requested more emphasis on testing and validation of CDS Hooks.

Response: We did not propose and are not finalizing an implementation timeline or other deadlines for Health IT Modules to be certified to 45 CFR 170.315(j)(20).

Comment: Some commenters requested more specific guidance on “pre- fetch templates” while others recommended that ASTP/ONC finalize that certified health IT is not required to support any pre-fetch templates.

Response: We appreciate commenters' concerns with our proposals related to “pre-fetch templates.” We are not finalizing the “pre- fetch” requirements proposed at 45 CFR 170.315(j)(20)(iv)(A) to provide industry additional time to refine the specifications and capabilities supporting “pre-fetch.” We anticipate that given the complexity and potential value of “pre-fetch” capabilities, the standards development community and other interested parties will continue to improve standards and guidance in this area, and we will monitor this work for potential future inclusion in the Certification Program.

After consideration of the public comment, we are finalizing our proposal to adopt the CDS Hooks implementation specification under 45 CFR 170.215(f) by adopting the CDS Hooks Implementation Guide, Version 2.0.1--STU 2 Release 2 at 45 CFR 170.215(f)(1), and incorporating it by reference in 45 CFR 170.299(g). We note that we proposed to adopt CDS Hooks Release 2.0; however, since the publication of the proposal a newer version of the implementation specification, CDS Hooks Version 2.0.1, was published on March 12, 2025. CDS Hooks Implementation Guide, Version 2.0.1 is an errata release that does not introduce substantive changes to the specification from Release 2.0. Rather, version 2.0.1 updates the publishing mechanism and formatting of the implementation guide. We believe adoption of this errata release will benefit Certification Program compliance by referencing a version of the implementation specification with the same substantive content as the proposed release but in an improved publication format. Adoption of version 2.0.1 of this specification will also support consistent implementation across industry because it is the latest and most correct version of the CDS Hooks implementation guide.

We are also finalizing our proposal to adopt a “workflow triggers for decision support interventions--client” criterion at 45 CFR 170.315(j)(20) with modification. We are finalizing adjustments to the proposed language to streamline and clarify the regulation text without introducing substantive changes to the proposal with the exceptions of the removal of the requirements to support “pre-fetch” proposed at 45 CFR 170.315(j)(20)(iv)(A) and the removal of the requirement proposed at 45 CFR 170.315(j)(20)(iv)(C)(2) to support the “Link” field “appContext”. Non-substantive changes to the proposed language include revising specification references from 45 CFR[thinsp]170.215(f)(1) to 45 CFR[thinsp]170.215(f) to consistently reference the CDS Hooks specification, consolidating several proposed references to the specifications at 45 CFR[thinsp]170.215(f) into a single reference in the paragraph at 45 CFR 170.315(j)(20), and rephrasing the required registration capabilities in 45 CFR 170.315(j)(20)(i) in terms of “CDS Clients.” The structure of 45 CFR 170.315(j)(20) that we are finalizing remains largely the same as the proposal except for the addition of two subparagraphs under 45 CFR 170.315(j)(20)(ii) to specify authentication and authorization requirements with additional clarity, and the removal of the requirements to support “pre-fetch” proposed at 45 CFR 170.315(j)(20)(iv)(A). The requirements we are finalizing at 45 CFR 170.315(j)(20)(ii)(A) and (B) clarify that client authentication must be supported using JSON web tokens (JWT), and data access authorization of a “CDS Service” using access tokens must be supported, respectively. This additional specificity resolves potential ambiguity regarding whether certain authentication and authorization capabilities from the CDS Hooks IG are required to be supported for the “workflow triggers for decision support interventions--client” criterion. Finally, we are finalizing 45 CFR 170.315(j)(20) without the regulation text proposed at 45 CFR 170.315(j)(20)(iv)(C)(2). We did not receive any comments regarding our proposal at 45 CFR 170.315(j)(20)(iv)(C)(2) to support the ability to launch internal apps and SMART apps from decision support responses according to the implementation specification 45 CFR[thinsp]170.215(f)(1), including support for the “Link” field “appContext.” We have removed this requirement from the regulation text in our finalization of 45 CFR 170.315(j)(20) to provide health IT developers certifying to the 45 CFR 170.315(j)(20) criterion with the flexibility to support this optional CDS Hooks capability as applicable to their workflows. (ii) Subscriptions--Client

In the HTI-2 Proposed Rule, we discussed the HL7 FHIR Subscriptions Framework, which describes a standardized method for clients to subscribe to notifications from servers based on pre-negotiated criteria (89 FR 63572). Once the subscription is established, servers can proactively notify a client when new information has been added or existing information has been updated in its system. Once a notification has been received by a

client, the client can take appropriate action, including querying the server for the desired information. The HL7 FHIR Subscriptions Framework also describes methods to transmit payloads with notifications, which may help simplify some interorganizational transactions by enabling real-time updates, selective data transmission, and interoperability, making data exchange between organizations more efficient and effective.

We anticipated that API-based subscriptions would support several use cases across clinical, public health, administrative, and research domains. Specific to public health use cases, we envisioned that future implementation guides could leverage the HL7 FHIR Subscriptions Framework for case reporting processes, immunization reporting processes, syndromic surveillance, reportable laboratory tests and values, and transmitting cancer case information to state cancer registries, among others. We welcomed comments on this approach, particularly with respect to the readiness of this standard to support public health reporting and any potential benefits or limitations to this approach that should be considered.

We stated that the HL7 FHIR Subscriptions Framework has undergone a significant redesign during the development of the HL7[supreg] FHIR[supreg] Release 5 (R5) standard, including the use of “SubscriptionTopic” HL7 FHIR Resources that define the criteria for standardized subscription notifications. We noted that we structured our proposal in 45 CFR 170.315(j)(23) to best accommodate health IT developers' and the industry's maturity so that API-based subscriptions can be more easily implemented in the current health IT landscape. While the HL7 FHIR Subscriptions Framework in HL7[supreg] FHIR[supreg] R5 is well developed, the health IT industry is largely using HL7[supreg] FHIR[supreg] Release 4, Version 4.0.1 (HL7[supreg] FHIR[supreg] R4), for HL7 FHIR standards-based exchange. We stated that updating all the criteria in the Certification Program to HL7[supreg] FHIR[supreg] R5 to accommodate the updated HL7 FHIR Subscriptions Framework would not be practicable nor prudent given the full-scale industry redesign that would be necessary to do so and impacts on users. In order to enable health IT developers using HL7[supreg] FHIR[supreg] R4, to support the improvements made in the HL7 FHIR Subscriptions Framework in HL7[supreg] FHIR[supreg] R5, the HL7 standards community created the Subscriptions R5 Backport Implementation Guide version 1.1.0, which specifies some of the HL7[supreg] FHIR[supreg] R5 Subscriptions Framework enhancements in a way that is compatible with HL7[supreg] FHIR[supreg] R4.

We proposed that a Health IT Module presented for certification to the “subscriptions--client” criterion in 45 CFR 170.315(j)(24) support API-based subscriptions according to HL7 FHIR Subscriptions Framework included in the HL7 FHIR Subscriptions R5 Backport Implementation Guide version 1.1.0 (hereafter referred to as “Subscriptions IG”), which we proposed to adopt in 45 CFR 170.215(h)(1). We described that the proposals in 45 CFR 170.315(j)(24) specify constraints on the implementation specification proposed in 45 CFR 170.215(h)(1), which intended to ensure that Health IT Modules certified to 45 CFR 170.315(j)(24) could conform to separate but related aspects and functions of the implementation specification in 45 CFR 170.215(h).

Recognizing the importance of reducing burden on health IT developers while also striving to improve nationwide interoperability, we proposed to adopt the Subscriptions IG in 45 CFR 170.215(h)(1) to support the certification criterion for API-based subscriptions in 45 CFR 170.315(j)(24) “subscriptions--client” requirements. We described that the Subscriptions IG includes API-based subscription functionality that goes beyond the scope of FHIR R4, but for the purposes of the Certification Program, we proposed in 45 CFR 170.315(j)(24)(i) that Health IT Modules support the requirements specified in section “1.6 Topic-Based Subscriptions--FHIR R4” of the implementation specification in 45 CFR 170.215(h)(1).

Additionally, we proposed in 45 CFR 170.315(j)(24)(ii) that Health IT Modules support the “R4/B Topic-Based Subscription” profile as specified in the Subscriptions IG. We noted that while this profile is compatible with both HL7[supreg] FHIR[supreg] R4.0.1, and HL7[supreg] FHIR[supreg] R4B, we proposed it for use with HL7[supreg] FHIR[supreg] R4, at this time.

We proposed in 45 CFR 170.315(j)(24)(iii) that Health IT Modules support the accompanying client capabilities for the minimum requirements included in the “R4 Topic-Based Subscription Server Capability Statement” of the implementation specification in 45 CFR 170.215(h)(1), including support for “create,” “update,” and “delete” interactions for HL7 FHIR Subscription Resources according to the implementation specification in 45 CFR 170.215(h)(1).

Finally, we proposed in 170.315(j)(24)(iv) that Health IT Modules support the ability to receive subscription notifications, according to the “1.6 Topic-Based Subscriptions--FHIR R4” section of the implementation specification in 45 CFR 170.215(h)(1). We proposed to include in 45 CFR 170.315(j)(24)(iv)(A) that support for “id-only” Payload Types is required as specified in the “Payload Types” section of the implementation specifications in 45 CFR 170.215(h)(1). We noted there are three options available when specifying contents of a notification: empty, id-only, and full-resource. We stated we believe that id-only provides a good balance between security and performance.

We noted that proposals in 45 CFR 170.315(j)(24) included in this section reflected public feedback we received in the HTI-1 Proposed Rule. We described that the REST-hook channel uses the RESTful model which is extensively used in FHIR standard and is considered to present the lowest bar for implementation. We proposed to include in 45 CFR 170.315(j)(24)(iv)(B) required support for consuming notifications via the “REST-Hook” channel as specified in the “Channels” section of the implementation specifications in 45 CFR 170.215(h)(1).

We noted that we included a reference to the proposed certification criterion in 45 CFR 170.315(j)(24) in the proposed “prior authorization API--provider” certification criterion in 45 CFR 170.315(g)(34) and referred readers to that section for more information on the proposals.

We stated we believe our proposal and alternative proposals 45 CFR 170.315(j)(24) reflected the public feedback we received during the HTI-1 rulemaking process. We acknowledged that the standards may have matured beyond the prior recommended feedback from the HTI-1 Proposed Rule and requested comment on these proposals and whether interested individuals and organizations would prefer to implement other standards listed in the Subscriptions IG, including API-based subscriptions based on HL7 FHIR R5.

The following is a summary of the comments we received and our responses:

Comment: Many commenters supported our proposal to incorporate the modular API capabilities from the Subscriptions IG Version 1.1.0 into certified health IT.

Response: We thank commenters for their support.

Comment: A few commenters supported the subscription proposal with modification requesting that ASTP/ONC adopt the FHIR R4B

standard to simplify implementation and reduce complexity to ensure consistency across different systems and leverage enhanced backport for security reasons.

Response: We thank commenters for their recommendation. However, we are finalizing our proposal to only require support for the “R4/B Topic-Based Subscription” profile according to HL7[supreg] FHIR [supreg] Release 4.0.1 at 45 CFR 170.315(j)(21)(ii), rather than require support for the broader FHIR R4B standard. Requiring broader support for R4B is not necessary to support the Subscriptions IG Version 1.1.0. Further, requiring support for the broader FHIR R4B standard would represent a significant and complex undertaking across all Health IT Modules supporting criteria that reference IGs that use FHIR R4.

Comment: A commenter expressed uncertainty about the overarching subscriptions proposals citing that the subscriptions specification could benefit from more real-world use experience before being adopted as a standard for certification.

Response: We thank commenters for their concern and are finalizing a simplified version of our proposals in response to concerns over implementation experience in the real world. Specifically, we are not requiring support for the “id-only” payload type at this time. We believe that requiring a specific payload type in the “subscriptions-- client” criterion in 45 CFR 170.315(j)(21) is premature. This flexibility will give developers of certified health IT the option to choose the most appropriate payload types when certifying to this criterion.

Comment: Many commenters expressed concerns regarding both the proposed “subscriptions--server” criterion in 45 CFR 170.315(j)(23) and “subscriptions--client” criterion at 45 CFR 170.315(j)(24). However, the concerns raised included technical feedback involving topic complexity, implementation burden, and subscription delivery methods applied specifically to the server-side functionality proposed under 45 CFR 170.315(j)(23). Several commenters also expressed confusion about the distinction between client and server responsibilities, with some mistakenly referring to 45 CFR 170.315(j)(24) as the server requirement. A few commenters requested clearer delineation between the roles to avoid misinterpretation.

Response: We thank commenters for their concern. In this final rule we are only finalizing the “client” capabilities described in our subscription proposals. We anticipate that “server” capabilities will be a necessary component of the ecosystem for prior authorization workflows, as well as other potential uses for subscriptions capabilities, and we anticipate that some developers of certified health IT may support server capabilities currently. However, we are not finalizing such server capabilities in the Certification Program at this time, and we reiterate that we are only requiring support for “client” capabilities for subscriptions at 45 CFR 170.315(j)(21).

Comment: A few commenters raised issues that are out of scope for this final rule, including modular API capabilities for subscription proposals specific to Public Health Agencies (PHAs) and the feasibility and resources needed to support the PHA use cases.

Response: We thank commenters for their feedback specific to PHAs and as stated previously, we have limited our focus to those criteria in 45 CFR 170.315(j) that relate to the “prior authorization API-- provider” criterion we proposed in 45 CFR 170.315(g)(34). We will consider the commenters' suggestions in future rulemaking.

After consideration of the public comment, we are finalizing adoption of the Subscriptions IG Version 1.1.0 at 45 CFR 170.215(h)(1) and incorporating it by reference in 45 CFR 170.299(g). We are also finalizing the “Subscriptions--client” certification criterion at 45 CFR 170.315(j)(21), which corresponds to the criterion proposed at 45 CFR 170.315(j)(24), with modifications. We are finalizing a simplified version in recognition of comments regarding need for real-world experience with implementation. Specifically, we are finalizing 45 CFR 170.315(j)(21) without support for “id-only” Payload Types as specified in the “Payload Types” section of the implementation specifications in 45 CFR[thinsp]170.215(h)(1) as proposed in 45 CFR 170.315(j)(24)(iv)(A). Since we are not finalizing support for “id- only” Payload Types, we consolidated paragraph 45 CFR 170.315(j)(24)(iv)(B) into 45 CFR 170.315(j)(21)(iv) without substantive changes. (6) New Certification Criteria for Electronic Prior Authorization (a) Overview

In section III.B.20. of the HTI-2 Proposed Rule we proposed to adopt a set of certification criteria in 45 CFR 170.315(g)(30)-(36) to support data exchange between healthcare payers, providers, and patients (89 FR 63580 through 63594). We stated that these proposed certification criteria would enable the exchange of data including clinical and coverage information, drug formulary information, and prior authorization information between patients, providers, and payers as appropriate to each exchange. We noted that these proposed certification criteria were based on a series of policies finalized by CMS (89 FR 63580). We stated that these certification criteria, if finalized, would be available for health IT developers (which may include payers and other developers providing technology to payers) seeking voluntary certification for health IT products supporting these use cases. We also proposed to adopt a set of API implementation specifications on behalf of the Secretary, in 45 CFR 170.215(j), (k), (m), and (n), for HHS use, which we proposed to reference in the proposed certification criteria. We noted that the proposed implementation specifications included recommended implementation specifications identified in CMS' finalized policies for payer API requirements (89 FR 8945).

In this final rule, we are finalizing a subset of the proposals in section III.B.20 of the HTI-2 Proposed Rule. Specifically, we are adopting electronic prior authorization criteria in 45 CFR 170.315(g)(31), (32), and (33) based on the capabilities originally proposed for the “prior authorization API--provider” certification criterion in 45 CFR 170.315(g)(34), and finalizing related proposals extending the applicability of certain Condition and Maintenance of Certification and real world testing provisions under the Certification Program to these electronic prior authorization criteria. We are also adopting a series of implementation specifications for HHS use that support these criteria, as well as other exchange use cases between payers, providers, and patients. We may consider finalizing other proposals in section III.B.20. of the HTI-2 Proposed Rule in future rulemaking. (b) Background (i) Background on CMS Interoperability Rulemaking

On May 1, 2020, the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage (MA) Organization 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) appeared in the Federal Register (hereinafter referred to as the “CMS Interoperability and Patient

Access Final Rule”). CMS required impacted payers \456\ to implement and maintain a FHIR-based Patient Access API to allow patients, through the health application of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, and provider remittances and enrollee cost-sharing pertaining to such claims, if maintained by the impacted payer (85 FR 25559). CMS also required impacted payers to maintain a Provider Directory API to make available information such as contracted provider names, addresses, and phone numbers (85 FR 25563).

\456\ For the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).

On February 8, 2024, 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” (CMS Interoperability and Prior Authorization Final Rule) appeared in the Federal Register (89 FR 8758). Final policies in this rule included: expanding the content available via the existing Patient Access API to include information about prior authorizations; requiring impacted payers to implement and maintain a Provider Access API to make patient data available to in-network providers with whom the patient has a treatment relationship; and requiring impacted payers build and maintain a Payer-to-Payer API to exchange patient data when a patient moves between payers or has concurrent payers. CMS also required impacted payers to implement and maintain a Prior Authorization API to facilitate electronic prior authorization processes. Finally, the rule added the Electronic Prior Authorization measures to the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category (89 FR 8909 through 8926).

In the CMS Interoperability and Patient Access Final Rule (85 FR 25510 through 25640) and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758 through 8988), CMS required impacted payers to use certain standards and implementation guides, as well as the USCDI standard, which ASTP/ONC has adopted on behalf of HHS in 45 CFR[thinsp]170.215 and 45 CFR[thinsp]170.213 respectively. Specifically, CMS finalized technical requirements for the following APIs: Patient Access API (85 FR 25558 through 25559, 89 FR 8784 through 8787), Provider Access API (89 FR 8817 through 8820), Payer-to-Payer API (89 FR 8855 through 8856), Prior Authorization API (89 FR 8897 through 8901), and the Provider Directory API (85 FR 25563 through 25564). In the CMS Interoperability and Prior Authorization Final Rule, CMS also recommended a number of implementation guides that may be used to support effective implementation of the required payer APIs (89 FR 8945). (ii) Background on Electronic Prior Authorization

In the HTI-2 Proposed Rule, we stated that prior authorization processes \457\ have contributed significantly to patient and provider burden, for instance, through delays experienced by patients and clinicians as they seek to satisfy the requirements associated with prior authorization rules set by payers (89 FR 63587).\458\ ONC's Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs,\459\ released in 2020, identified challenges associated with the prior authorization process faced by patients and healthcare providers, including: (i) difficulty in determining whether an item or service requires prior authorization; (ii) difficulty in determining payer-specific prior authorization requirements for those items and services; (iii) inefficient use of provider and staff time to navigate communications channels such as fax, telephone, and various web portals; and (iv) unpredictable and lengthy amounts of time to receive payer decisions. The Strategy noted that payers and health IT developers have addressed prior authorization in an ad hoc manner with interfaces that reflect individual payer technology considerations, payer lines of business, and customer- specific constraints. We described a 2022 physician survey conducted by the American Medical Association that demonstrated significant negative impacts associated with the current prior authorization and beneficiary information exchange processes.\460\ Nearly 94 percent of physicians reported care delays associated with prior authorization, and 80 percent reported that issues related to the prior authorization process can sometimes lead to treatment abandonment. In addition, survey respondents reported that physicians and their staff spend almost two business days each week completing prior authorizations, with nearly 35 percent of physicians retaining staff who work exclusively on prior authorizations. Today, hospitals and provider practices widely continue to use telephone and fax to conduct prior authorization processes. According to the Council for Affordable Quality Healthcare, only 28 percent of 228 million prior authorization contacts were fully electronic in 2022.\461\

\457\ Generally defined as rules imposed by healthcare payers that require approval for a medication, procedure, device, or other medical service be obtained prior to payment for the item or service.

\458\ Office of the National Coordinator for Health Information Technology. Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs [PDF file]. February 2020. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.

\459\ Office of the National Coordinator for Health Information Technology. Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs [PDF file]. February 2020. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.

\460\ https://www.ama-assn.org/practice-management/prior-authorization/prior-authorization-research-reports.

\461\ https://www.caqh.org/sites/default/files/2023-05/2022-caqh-index-report.pdf.

In 2020, ONC charged the HITAC to establish the Intersection of Clinical and Administrative Data (ICAD) Task Force to produce information and considerations related to the merging of clinical and administrative data for electronic prior authorization. The ICAD Task Force's final report,\462\ approved in November 2020, recommended that ONC work with CMS, other federal actors, and standards development organizations to “establish standards for prior authorization workflows.” Specifically, the Task Force recommended that entities should develop API specifications “such that the authorization and related documentation may be triggered in workflow in the relevant workflow system where the triggering event for the authorization is created.”

\462\ https://www.healthit.gov/sites/default/files/facas/ICAD_TF_FINAL_Report_HITAC_2020-11-06_508_0.pdf.

In January 2021, ONC published an RFI titled “Request for Information:

Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” to seek input from the public regarding electronic prior authorization standards, implementation specifications, and certification criteria that could be adopted within the ONC Health IT Certification Program (87 FR 3475). ONC received approximately 130 responses to this RFI from a wide range of entities. Comments on the RFI broadly supported the incorporation of electronic prior authorization capabilities within the Certification Program, while highlighting concerns about the current readiness and maturity of available implementation specifications to support these capabilities. Commenters also provided input on how certification criteria related to electronic prior authorization should be structured and how certification criteria should address other federal requirements around the use of standards for electronic prior authorization transactions. Finally, commenters provided input on the benefits of improving electronic prior authorization for patients, providers, health IT developers and payers, as well as potential challenges associated with implementation.

ONC also charged the HITAC to establish a Task Force in order to provide input and recommendations in response to the RFI; the Task Force's recommendations were approved and submitted to ONC on March 10, 2022.\463\ We noted that the proposals in section III.B.20. of the HTI- 2 Proposed Rule would implement several recommendations from the Task Force, specifically recommendations to:

\463\ https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf.

Create a suite of electronic prior authorization health IT certification criteria for health IT systems supporting both providers and payers that can enable health IT developers to certify to one or more specific functional capabilities that together, across participating health IT systems, enable the full electronic prior authorization workflow.

Ensure new certification criteria for electronic prior authorization provide for health IT systems that perform prior authorization on behalf of payers to ensure that their solutions are compliant to consensus-based standards for electronic prior authorization and are able to send and receive information needed to meet the prior authorization business case.

Work with the Da Vinci Project and key healthcare stakeholders (for example, providers, developers, patients) to develop appropriate health IT certification criteria that incorporate key functional capabilities for prior authorization.

Ensure certification requirements that allow a FHIR- enabled process for prior authorization transactions do not require translation to X12.

Prioritize criteria based on the Da Vinci Prior Authorization Support (PAS) IG that allow data, C-CDA, or FHIR documents to be provided in a FHIR construct. (c) Standards and Certification Criteria for Electronic Prior Authorization (i) Implementation Specifications for Prior Authorization

We proposed to adopt a “prior authorization API--provider” certification criterion in 45 CFR[thinsp]170.315(g)(34) to establish requirements for Health IT Modules that can be used to facilitate a provider's request of coverage information and request for a prior authorization decision. We stated that this certification criterion would help support real-time access for providers to payer approval requirements, documentation, and rules at point of service, as well as enable providers to request and receive authorization. We noted that technology certified to these capabilities would help to automate and streamline the prior authorization process for healthcare providers and payers, ensure treatment decisions are made in a timely fashion, avoid delays in care, and reduce administrative burden on healthcare providers and payers associated with assembling and reviewing required documentation.

We proposed to adopt three HL7 FHIR Da Vinci Burden Reduction IGs in 45 CFR[thinsp]170.215(j) as the basis for the proposed “prior authorization API--provider” criterion and incorporate these IGs by reference in 45 CFR[thinsp]170.299(g):

HL7 FHIR Da Vinci--Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1--STU 2 (proposed in 45 CFR[thinsp]170.215(j)(1)(i)).\464\

\464\ See https://hl7.org/fhir/us/davinci-crd/STU2/.

HL7 FHIR Da Vinci--Documentation Templates and Rules (DTR) Implementation Guide, Version 2.0.1--STU 2 (proposed in 45 CFR[thinsp]170.215(j)(2)(i)).\465\

\465\ See https://hl7.org/fhir/us/davinci-dtr/STU2/.

HL7 FHIR Da Vinci--Prior Authorization Support (PAS) Implementation Guide, Version 2.0.1--STU 2 (proposed in 45 CFR[thinsp]170.215(j)(3)(i)).\466\

\466\ See https://hl7.org/fhir/us/davinci-pas/STU2/.

Taken together, these implementation specifications support a comprehensive workflow for conducting electronic prior authorization transactions. These specifications are based upon HL7[supreg] FHIR[supreg] Release 4, Version 4.0.1: R4. In concert with CMS, ASTP/ ONC has led or participated in a variety of activities related to monitoring and evaluating the standards and implementation specifications identified in the proposed rule, utilizing available mechanisms for gathering input on these standards from a wide variety of experts. The Da Vinci Project \467\ is a private sector initiative that brings together payers, health IT developers, providers, and other public participants to facilitate the definition, design, and creation of use case specific reference implementations of solutions based upon the HL7 FHIR platform that involve managing and sharing clinical and administrative data between industry partners. Because the Da Vinci Project is aligned with HL7, solutions developed through the project may become industry standards. The Da Vinci Project's use case requirements, test scenarios, and test data, as well as the resulting implementation guides and reference implementations, are available without licensing requirements (89 FR 63581).

\467\ For more information about the Da Vinci Project, please visit https://www.hl7.org/about/davinci/.

We proposed to adopt these implementation specifications under PHSA section 3004 and make them available for HHS use. We further noted that the proposed certification criterion included proposals that required the use of at least one version of each of the implementation specifications adopted in 45 CFR[thinsp]170.215(j)(1)-(3) (89 FR 63588). We noted that if we were to adopt subsequent versions of the implementation specifications in 45 CFR[thinsp]170.215(j)(1) (CRD IG), (j)(2) (DTR IG), and (j)(3) (PAS IG), respectively, proposals that require the use of at least one implementation specification adopted in one of these locations would enable health IT developers to use any version adopted at the specified location, unless we specified an adoption “expiration” date which indicates a certain version of the specification may no longer be used after that date (89 FR 63588).

The following is a summary of the comments received on the HTI-2 Proposed Rule and our responses:

Comment: Many commenters supported our proposals to adopt

certification criteria and implementation specifications for health IT to enable electronic prior authorization. In general, commenters believed that electronic prior authorization activities enabled by technology meeting the proposed “prior authorization API--provider” criterion would address burdensome manual prior authorization processes, and that widespread adoption of such technology solutions has the potential to reduce the time that clinicians and other staff must spend on administrative tasks related to prior authorization. Commenters further stated that finalization of this criteria would be an important mechanism for ensuring health IT developers include such functionality in certified health IT products.

Response: We thank commenters for their support of the proposed “prior authorization API--provider” criterion. We agree with commenters about the benefits that may be realized from incorporating standardized electronic prior authorization capabilities into their workflows.

Comment: Several commenters expressed concerns about the implementation challenges and other burdens that healthcare providers may experience implementing certified health IT for electronic prior authorization. Commenters noted that while under-resourced healthcare providers are impacted by the administrative burden associated with current prior authorization processes, such practices would also bear significant burden associated with implementation of new prior authorization functionality and associated workflows. Commenters urged ASTP/ONC and HHS to ensure any new functionality would be available at an affordable cost for small practices.

Response: We appreciate commenters' concerns about the potential for additional burden associated with adopting certified health IT for electronic prior authorization. We acknowledge that healthcare providers may incur costs acquiring health IT certified to these new criteria, and that integrating this new functionality may require development of new workflows and updates to existing workflows. However, we believe that by automating the prior authorization process providers of all sizes, but especially small practices, will benefit greatly from resource and administrative burden reductions. We refer readers to regulatory impact analysis in Appendix A section I.G.13. of this final rule for detailed discussion of costs and benefits of our finalized policies. While ASTP/ONC does not have authority to limit the costs of adopting new Health IT Modules, including for small practices, health IT developers must make information about material types of costs and limitations available for their products via the Certified Health IT Product List (CHPL) website.\468\

\468\ See: https://chpl.healthit.gov/#/search.

Comment: Many commenters did not support our proposals to adopt the Da Vinci CRD, DTR, and PAS IGs and incorporate them into the “prior authorization API--provider” criterion. Commenters stated that the implementation guides are not mature enough to be included as required standards at this time and that additional iterations of the proposed versions of the implementation guides would be needed before they were ready for adoption. Commenters stated that the implementation guides reflect the contributions of a limited group of industry partners, are not well-grounded in real-world use at this time, and have not undergone sufficient testing and piloting. Commenters also noted that there are a number of unresolved issues in the current versions of the implementation guides and provided examples of these issues. For instance, a commenter noted that the current versions of the IGs do not account for the full complexity of electronic prior authorization interactions focusing on binary responses and failing to account for less common scenarios that may arise in conducting these activities. Another commenter stated that the three IGs lack common data definitions, which may impede these functions from successfully working together as intended, and identified issues with a foundational specification which informs these IGs that may introduce unnecessary complexity as part of the workflow.

Response: We acknowledge the concerns raised by commenters regarding the maturity and readiness of the Da Vinci CRD, DTR, and PAS IGs. However, we emphasize the significant progress these guides represent in addressing longstanding challenges in a primarily manual prior authorization process. We believe adoption of these IGs, as proposed, is a critical step toward reducing administrative burden and improving care delivery with interoperable prior authorization workflows. Further, we note that iterations and refinements to the versions of CRD, DTR, and PAS IGs we proposed in the HTI-2 Proposed Rule have now been balloted by HL7 and will be available for use in the Certification Program, as described in more detail later in this section, via the Standards Version Advancement Process (SVAP).\469\ These refinements and enhancements address common data definitions by supporting USCDI v3 and better support the full complexity of prior authorization workflows.

\469\ See Standards Version Advancement Process (SVAP): https://www.healthit.gov/topic/standards-version-advancement-process-svap.

While acknowledging commenters' concerns about the maturity of the proposed versions of the CRD, DTR, and PAS IGs (versions 2.0.1), and the existence of unresolved issues in the proposed versions of the guides, it is important to note that these guides continue to evolve and improve based on real-world implementation feedback. For example, since publication of the HTI-2 Proposed Rule in August 2024, HL7 has published Version 2.1.0 of all three IGs. These updates have addressed gaps identified during early implementations and enhanced functionality to improve the interoperability of data necessary to enable electronic prior authorization workflows. Notably:

HL7 FHIR Da Vinci--Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.1.0--STU 2.1 \470\ includes more than 20 changes setting clearer expectations for handling failure states, correcting contexts for order-dispatch, clarifying expectations for mandatory hook support, and setting expectations for endpoints and endpoint discovery.

\470\ See https://hl7.org/fhir/us/davinci-crd/STU2.1/.

HL7 FHIR Da Vinci--Documentation Templates and Rules (DTR) Implementation Guide, Version 2.1.0--STU 2.1 \471\ includes more than 30 updates from Version 2.0.1, such as aligning endpoint discovery language with CRD IG requirements, addressing CMS enforcement discretion regarding the use of X12, and requiring DTR Clients to appropriately manage access to data that is sensitive per policy and regulatory requirements when responding to queries from a DTR application.

\471\ See https://hl7.org/fhir/us/davinci-dtr/STU2.1/.

HL7 FHIR Da Vinci--Prior Authorization Support (PAS) Implementation Guide, Version 2.1.0--STU 2.1 \472\ includes more than 50 updates, including: clarifying how to cancel an entire Prior Auth Claim instead of cancelling individual items, addressing concerns about required fields that are specified in the license restricted X12 TRN03 guide (which is

referenced within the PAS IG), and updating the guide to be compliant with US Core v3.1.0, v6.0.1, and v7.0.0.

\472\ See https://hl7.org/fhir/us/davinci-pas/STU2.1/.

As noted previously, HL7 has iterated new versions for each IG in the months since we first proposed to adopt these IGs, and we anticipate future iterations to continue. We intend to continue to monitor the evolution of the standards and make subsequent versions of the adopted IGs available for use in the Certification Program when appropriate via the SVAP as discussed further in section IX.B.4.b.(6)(e) of this final rule. Through SVAP, developers of certified health IT will have the flexibility to use subsequent versions of these IGs in Health IT Modules certified to 45 CFR 170.315(g)(31), (g)(32) and (g)(33) and maintain their certification status based on use of an updated version of the adopted standard. This approach balances the need for immediate action to address prior authorization inefficiencies by ensuring certification is available upon the effective date of this final rule, while continuing to support use of the best available standard on an ongoing basis. We note that CMS has finalized similar provisions allowing impacted payers to use updated versions of HHS-adopted standards when implementing CMS' payer API requirements under certain circumstances, including standards approved for use by the National Coordinator under SVAP (see 89 FR 8935 for more details). Together, these policies enable both providers and payers to use health IT aligned with the most recent and advanced standards for purposes related to prior authorization.

The assertion that the IGs reflect contributions from a limited group of industry partners overlooks the collaborative nature of the IGs' development. The HL7 Da Vinci Project has engaged a broad spectrum of stakeholders, including providers, payers, and health IT developers, to ensure the guides address real-world needs.\473\ The guides are grounded in real-world experiences and have been tested in both controlled settings and in real world pilot implementations, demonstrating their applicability and value.\474\ We encourage all interested parties to participate in the processes managed by HL7 to continue to evolve and improve these IGs.

\473\ See Da Vinci Project Members at https://confluence.hl7.org/spaces/DVP/pages/144978522/Da+Vinci+Project+Members.

\474\ See HIPAA Exception Pilot Report at https://confluence.hl7.org/download/attachments/113675673/HL7%20Da%20Vinci%20Exception%20Report_Final%20(June%2025%2C%202024).p df?version=1&modificationDate=1731382945836&api=v2.

Comment: As an alternative to adopting and requiring use of the Da Vinci CRD, DTR, and PAS IGs, commenters recommended that ASTP/ONC finalize a functional criterion and recommend, but not require, use of the proposed IGs. Commenters pointed to the CMS Interoperability and Prior Authorization final rule, in which CMS recommended the use of the Da Vinci CRD, DTR, and PAS IGs, as well as other IGs, but did not require their use (89 FR 8937). Commenters expressed concern that requiring use of the current versions of the IGs would not allow industry the flexibility to address issues likely to be corrected or further developed in future versions, and that developers would be “locked” into an immature version of the IG. While commenters acknowledged that the SVAP is intended to provide flexibility to health IT developers who wish to use subsequent versions of a standard approved by ASTP/ONC within certified Health IT Modules, some commenters believed that the SVAP would not be rapid enough to provide assurances to developers that updated versions of the Da Vinci IGs were approved for use in a timely manner. Commenters stated that this delay would create confusion for developers around knowing which version of the IG a developer must certify to. Commenters also noted that in the case of IGs in earlier stages of development, including the Da Vinci CRD, DTR, and PAS IGs, subsequent versions may include breaking changes, and older versions may not be implementable as written.

Response: We appreciate comments suggesting that we finalize a functional criterion and recommend, rather than require, the use of the Da Vinci CRD, DTR, and PAS IGs. However, we believe that adopting these IGs and requiring their use in health IT certification criteria is essential to achieving the goals of interoperability, reducing administrative burden, and streamlining the prior authorization process. While flexibility is important, the absence of required standards for prior authorization capabilities risk perpetuating the fragmentation and manual inefficiencies that have long plagued prior authorization workflows. Moreover, a functional criterion does not support interoperability or adherence to standardized capabilities. Recommending the use of IGs without requiring them would likely result in inconsistent implementations, as developers may choose different approaches to meet functional requirements. This fragmentation would undermine the goal of creating a seamless and efficient prior authorization process. As discussed in more detail in this section, we are finalizing adoption of three certification criteria at 45 CFR 170.315(g)(31)-(33) that are standards-based, rather than functional.

We recognize commenters' concerns about the timeliness of the SVAP for approving updated versions of the IGs, including those who believed SVAP may not be rapid enough to keep pace with IG development. However, we note that SVAP has a proven track record of enabling developers of certified health IT to voluntarily use newer versions of HHS-adopted standards on an annual cadence, closely mirroring HL7's biannual balloting cycle. This cadence and process ensures that developers of certified health IT are not “locked” into older versions of IGs, and the voluntary nature of SVAP provides flexibility to industry to choose whether a newer version is sufficiently mature to use in production. While we believe that commenters' concerns that newer versions of adopted standards may include breaking changes are valid, we will consider this possibility for each standard when we determine whether a standard (including these implementation guides) should be approved for SVAP.

We note that while the CMS Interoperability and Prior Authorization Final Rule recommended the use of the Da Vinci IGs without requiring them, our approach reflects the distinct needs of the Certification Program and reflects our goal to advance standards-based interoperability. The adoption of required IGs creates testable expectations of conformance to these IGs and ensures that all stakeholders are aligned on a common set of implementation specifications. This reduces variability in deployed technology and enhances the efficiency of prior authorization workflows. We further note that while CMS determined at the time of the CMS Interoperability and Prior Authorization Proposed Rule that it was most appropriate to recommend the versions of the implementation specifications available at that time, CMS also stated that it intends to evaluate future versions of these specifications and will consider proposing to require conformance to versions of these implementation specifications in future rulemaking (89 FR 8921).

While commenters' recommendation to finalize a functional criterion and recommend the use of IGs reflects a desire for flexibility, it does not address the critical need for standardization and

interoperability in prior authorization workflows.

After consideration of the comments, for this and other stated reasons, we are finalizing our proposals to adopt the proposed Da Vinci CRD, DTR, and PAS IGs at 45 CFR 170.215(j)(1)(i), (j)(2)(i), and (j)(3)(i), respectively, and are incorporating them by reference in 45 CFR[thinsp]170.299(g). We reiterate that SVAP provides flexibility for developers to adopt updated versions of these standards, while mechanisms for managing breaking changes ensure that the transition to newer versions is smooth and effective. We encourage stakeholders to support the further development of these IGs, as needed, through the process managed by HL7 and the Da Vinci Project. (ii) Organization of the Proposed Prior Authorization API Criteria

In the January 2021 “Request for Information: Electronic Prior Authorization Standards, Implementation Specifications and Certification Criteria,” we requested comment on the most appropriate way to structure health IT certification criteria enabling a health care provider to conduct electronic prior authorization transactions (87 FR 3480). We received a wide range of input on this topic with commenters noting that different types of systems, including EHRs, revenue cycle and patient management systems, and third-party applications may be responsible for different elements of the electronic prior authorization workflow. Some commenters recommended that ONC consider proposing individual criteria that map to each of the Da Vinci IGs (the CRD, DTR, and PAS IGs), which we discussed in the RFI. Other commenters suggested creating more granular certification criteria which reflect specific capabilities and key interactions within the prior authorization workflow, so that these capabilities can be implemented as stand-alone solutions to provide incremental value. The Task Force charged by the HITAC to provide a response to the January 2021 RFI also provided recommendations on this topic.\475\

\475\ https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf.

In the HTI-2 Proposed Rule (89 FR 63590), we proposed a single “prior authorization API--provider” certification criterion in 45 CFR[thinsp]170.315(g)(34). However, we noted that existing guidance in the Certification Program could provide flexibility around the use of distinct technology products that may be utilized to perform the capabilities that were outlined in the proposed certification criterion. Specifically, we described that health IT developers are permitted to use “relied upon software” (76 FR 1276) to demonstrate compliance with certification criteria adopted at 45 CFR part 170, subpart C.\476\ Relied upon software is typically third-party software that is not developed by the health IT developer presenting its health IT for testing and certification. Relied upon software may be used to demonstrate compliance with a portion of an adopted certification criterion or an entire certification criterion. When a health IT developer relies upon software to demonstrate compliance with a certification criterion, such relied upon software must be included in the scope of the certification issued to the Health IT Module. In cases where a Health IT Module may be paired with multiple “relied upon software” products for the same capability, it must be tested with at least one such product to demonstrate compliance with a certification criterion's requirements. Afterwards, the Health IT Module developer is permitted to list all additional “relied upon software” products for the same capability paired with the certified Health IT Module without having to test each one with the ONC-Authorized Testing Laboratory (ATL). A health IT developer always remains responsible for its product's conformance to a certification criterion even when the “relied upon software” contributes to, or is the cause of, a non- conformity.

\476\ For more guidance on relied upon software, see: https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf.

We invited additional comments on the most appropriate way to structure the proposed “prior authorization API--provider” certification criterion. Specifically, we were interested in the public's input on how organization of the proposed certification criteria would affect the ability of developers to effectively offer certified health IT products that meet the criteria, and what impact the organization of the proposed criteria would have on customers who may already possess technology products that can be used to conduct electronic prior authorization transactions. We also requested comment on whether or to what degree existing guidance for the Certification Program, such as the relied upon software policy described previously, would address scenarios in which distinct health IT products are used to support different elements of the prior authorization workflow. Finally, we invited comments on alternative approaches to organizing the “prior authorization API” certification criteria.

Comment: Several commenters stated that combining different functions under the single proposed “prior authorization API-- provider” criterion, rather than allowing for modular certification of different functions, does not recognize that different systems may be involved in these transactions. They noted that the prior authorization process combines both administrative and clinical transactions depending on the step in the process. While clinical transactions may take place in EHRs, other administrative steps may take place in systems such as revenue cycle management systems. Commenters believed that by combining these functions under a single criterion, ASTP/ONC was assuming that an EHR would be performing each of the identified functions in the workflow specified in the proposed “prior authorization API--provider” criterion. Commenters stated that such an assumption would require combinations of products that may not exist at present, compelling collaboration among vendors in order to meet the workflow integration required for the criterion that does not currently exist in the market. Commenters stated that there are only a small number of EHR systems currently sold with a fully integrated revenue cycle management system, and that many healthcare providers prefer to combine EHR and RCM systems from different vendors. Other commenters noted that there are currently vendors in the market that specialize in only performing certain steps included as part of the electronic prior authorization workflow reflected in the proposed IGs. As a result of these observations, several commenters recommended that ASTP/ONC separately certify Health IT Modules to the functionality represented by each of the three proposed IGs.

Response: We appreciate commenters' feedback on our proposal for a single criterion to support the functionality represented by the three proposed IGs. We acknowledge that our proposal for a single criterion assumed that most Health IT Modules would be performing all of the functions specified by the CRD, DTR, and PAS IGs, and in instances where a developer of certified health IT did not support a functionality, the developer could use relied upon software. Comments received have persuaded us to revisit these assumptions and we agree that establishing multiple criteria could more effectively support a diverse

marketplace of developers, including those that specialize in only certain steps in the electronic prior authorization workflow. We further believe that such an approach would not inhibit certified health IT developers to support end-to-end workflows for providers as described in the CRD, DTR, and PAS IGs, as such developers could certify Health IT Module(s) to individual certification criteria reflecting different components of the prior authorization workflow.

Comment: A commenter suggested that ASTP/ONC allow developers to certify to both the complete workflow and components of the workflow, at least during an initial period as healthcare providers and gain an understanding of how they will comply with the certification requirements. For instance, the commenter suggested that a developer who only offers a solution focused on the functionality represented in the CRD IG should be able to certify to a criterion reflecting this functionality, while a second developer certifying to the complete workflow reflected in the CRD, DTR, and PAS IGs should be able to obtain certification reflecting those complete capabilities.

Response: We appreciate commenters' recommendation to certify both the complete workflow and individual criteria. However, we believe that an approach which certifies the complete workflow may constrain future needs to support dynamic workflows for prior authorization. We heard from commenters that multiple information systems may be involved in the prior authorization process, and while we reiterate that these criteria are intended for use by care providers and healthcare delivery organizations, systems certifying to these certification criteria need not be constrained only to clinical systems. For instance, and as is described in more detail later in this section, a Health IT Module certified to the criterion we are finalizing in 45 CFR 170.315(g)(32), which is required to support the DTR IG through cross-reference to 45 CFR 170.215(j)(2), may be part of an existing, deployed information system, or it may be a standalone information system that can be integrated with an existing system.

Comment: Several commenters supported our reference to the use of the “relied upon software” feature of the Certification Program in implementing the proposed “prior authorization API--provider” criterion. Commenters stated use of this flexibility would lead to cost savings and would eliminate the need for developers to build solutions from the ground up.

Response: We appreciate commenters' support for the relied upon software feature of the Certification Program. We agree this program element can support flexibility for developers to determine the best approach to developing Health IT Modules by leveraging partnerships with other vendors and products. However, we believe that this approach may be limited in its ability to support a dynamic health IT marketplace, which enables developers to certify to only those aspects of the electronic prior authorization workflow they believe best suits their circumstances.

Comment: Other commenters disagreed that the “relied upon software” element of the Certification Program would effectively address relevant issues. Specifically, commenters stated that this aspect of the program has compelled specific vendor collaboration and combinations of products that would not have otherwise occurred, and that such activities may displace combinations of products that have been developed in response to customer interest.

Response: We thank commenters for their views on the value of the relied upon software aspect of the Certification Program. We disagree that relied upon software has had a negative impact across the market for health IT products and services. Relied upon software has had the opposite impact by allowing developers with incomplete functionality to certify products under the Certification Program. Based on data from the CHPL as of May 1, 2025, about 60 percent of all Health IT Modules certified under the Certification Program since the 2015 Edition have used relied upon software to fulfill the requirements of one or more certification criteria.

However, we agree with commenters that relied upon software may not adequately address issues discussed in the HTI-2 Proposed Rule related to this topic (89 FR 63591). For example, in scenarios where a health care provider may already be using health IT products to support a specific exchange or interaction in the prior authorization workflow, it may be difficult for such a provider to find or use distinct health IT products to support the remaining interactions of the prior authorization workflow. In this scenario, there is no guarantee that a health IT developer would agree to use the provider's existing health IT product as relied upon software. As a result, we agree that additional flexibility within the Certification Program beyond relied upon software may be necessary to address certification for electronic prior authorization.

Comment: Many commenters recommended that ASTP/ONC allow developers to phase in availability of Health IT Modules meeting different parts of the electronic prior authorization workflow over time. Commenters stated that the workflow envisioned in the CRD, DTR, and PAS IGs is highly complex, and relies on advanced features such as CDS Hooks and Clinical Quality Language (CQL). Commenters noted that the Electronic Prior Authorization measures finalized for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category focused on the submission of a prior authorization request, suggesting that the functionality described in the PAS IG and the CRD IG will be the most immediately relevant to healthcare providers. Several commenters suggested that implementation of the CRD IG should be required first, followed by the DTR and PAS IGs. Several commenters identified the DTR IG as likely to include the most novel implementation challenges.

Response: We appreciate commenters recommendations regarding the sequencing and phased availability of Health IT Modules certified to electronic prior authorization workflows. We agree that the workflow envisioned in the CRD, DTR, and PAS IGs seeks to comprehensively address prior authorization processes, and that these IGs rely on advanced features such as CDS Hooks and Clinical Quality Language (CQL). We acknowledge that there may be potential benefits of a phased approach identified by commenters, for instance, beginning with implementation of the CRD and PAS IGs. This approach may allow health IT developers to focus more intensively on development of more advanced capabilities over a longer time period.

We note that, as discussed in section IX.B.4.b.(6)(f) of this final rule, we are not finalizing our proposal to include the “prior authorization API--provider” criterion in 45 CFR 170.315(g)(34) in the Base EHR definition by a certain date. We are also not finalizing to include criteria in 45 CFR 170.315(g)(31)-(33) in the Base EHR definition. We are, therefore, not defining a specific date by which these criteria must be certified and provided to customers. Instead, developers may begin certification as soon as testing is available after the effective date of this final rule and work with their customers to implement in the manner most appropriate for their needs.

However, we note that requirements in other HHS, federal, state or local

programs for adoption and use of health IT certified to ONC health IT certification criteria may include dates impacting health IT developers' ability to sequence the rollout of certified health IT functionality to customers. For instance, developer timelines may be impacted by requirements to use technology certified to the finalized criteria for reporting of the Electronic Prior Authorization measures finalized for inclusion in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category beginning with the EHR reporting period in CY 2027 and CY 2027 performance period/2029 MIPS payment year, respectively (89 FR 8926). We believe our approach of supporting certification as soon as possible after the effective date of the rule--without inclusion of a compliance timeline through the Base EHR definition--will allow for a transition period with implementation testing while also supporting timelines for use under other HHS programs.

After consideration of the public comments, we are finalizing an alternative structure for certification criteria for electronic prior authorization. Specifically, we are finalizing separate criteria in 45 CFR 170.315(g)(31), (g)(32), and (g)(33) to support the CRD, DTR, and PAS IGs, respectively, rather than finalizing a single criterion at 45 CFR 170.315(g)(34), as proposed. Finalizing separate certification criteria aligned with the capabilities described in each IG will support a more dynamic health IT marketplace by allowing Health IT Modules to demonstrate conformance to the three required IGs individually, in combination, or as a group. A more detailed discussion of how we are finalizing the proposals in 45 CFR 170.315(g)(34) as part of certification criteria in 45 CFR 170.315(g)(31) through (33) is provided below. As noted previously, we are finalizing the same versions of the IGs to support the criteria in 45 CFR 170.315(g)(31) through (33) as we identified in the HTI-2 Proposed Rule, with the important proviso that these standards are eligible for SVAP, thus enabling developers to certify Health IT Modules to these criteria using newer versions of these adopted standards. (iii) Coverage Requirements Discovery

In the HTI-2 Proposed Rule, we proposed in 45 CFR[thinsp]170.315(g)(34)(i) that the “prior authorization API-- provider” certification criterion must support capabilities related to coverage discovery (89 FR 63588). We noted that these proposals were intended to facilitate the automation of both information exchange and prior authorization and reduce the need for provider-end manual intervention. We stated that Health IT Modules certified to this certification criterion would be able to request coverage information from a payer, for instance when a future encounter is being scheduled for a patient, and to initiate prior authorization electronically when a treatment decision has been made. We stated that these requirements would ensure that providers can request and receive a wide variety of information including updates to coverage information, alternative services or products, documentation requirements and rules related to coverage, forms, and templates to complete, and indications of whether prior authorization is required.

In 45 CFR[thinsp]170.315(g)(34)(i), we proposed that a Health IT Module certified to the criterion must support capabilities to initiate and exchange information with payer systems as a client to support the identification of coverage requirements (89 FR 63588 and 63589). In 45 CFR[thinsp]170.315(g)(34)(i)(A) we proposed that the Health IT Module must support the requirements described in the “Privacy, Security, and Safety” section of at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(j)(1) (where we proposed to adopt the CRD IG version 2.0.1--STU 2). In 45 CFR[thinsp]170.315(g)(34)(i)(B), we proposed that the Health IT Module must support capabilities in 45 CFR 170.315(j)(20) (where we proposed to adopt the “workflow triggers for decision support interventions” certification criterion) to enable workflow triggers to call decision support services, including support for “appointment-book,” “encounter-start,” “encounter-discharge,” “order-dispatch,” “order-select,” and “order-sign” CDS Hooks, according to at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(j)(1) and requirements in 45 CFR[thinsp]170.315(j)(20).

In 45 CFR[thinsp]170.315(g)(34)(i)(C), we proposed that the Health IT Module must support the requirements applicable to “CRD Clients” in at least one of the versions of the implementation specification in 45 CFR[thinsp]170.215(j)(1) including, as proposed in 45 CFR[thinsp]170.315(g)(34)(i)(C)(1), the requirements in the “CRD Client CapabilityStatement,” and, as proposed in 45 CFR[thinsp]170.315(g)(34)(i)(C)(2), support for the “SHOULD” requirements applicable to “CRD Clients” in Section 5.8 “Additional Data Retrieval.” We requested public input on whether to instead finalize a policy that these “SHOULD” requirements should be treated as “SHALL” requirements.

The following is a summary of the comments we received and our responses:

Comment: Several commenters offered general support for our requirements for the use of the CRD IG as the basis for the criterion elements in 45 CFR[thinsp]170.315(g)(34)(i). Commenters noted that feedback from early implementations of the CRD IG have shown that the functionality reflected in the IG can provide substantial value in facilitating prior authorization workflows.

Response: We thank commenters for their support for our proposal to require support for the CRD IG.

Comment: Several commenters supported our proposal in 45 CFR[thinsp]170.315(g)(34)(i)(C)(2) to require support for “SHOULD” requirements applicable to Coverage Requirements Discovery (CRD) Clients for additional data retrieval. These commenters stated that implementing a pre-fetch query functionality is critical for a CDS server to fully determine coverage requirements and reduce the need for manual intervention by clinicians.

Response: We thank commenters for their support.

Comment: Other commenters expressed concerns with our proposal to require support for “SHOULD” requirements applicable to CRD clients for additional data retrieval, and our discussion of treating these requirements as “SHALL” requirements. Commenters stated that the IG includes several ambiguous requirements, such as automatic parsing of clinical decision support (CDS) discovery endpoints and limited coverages returned in search based on payer client, and recommended that additional development time should be provided in order to resolve these ambiguities. Another commenter recommended that, while developers may choose to include such functionality in Health IT Modules, ASTP/ONC should not require implementation of these requirements for certification.

Response: We appreciate the comments regarding our proposal in 45 CFR[thinsp]170.315(g)(34)(i)(C)(2) to require the “SHOULD” requirements applicable to “CRD Clients” in the “Additional Data Retrieval” section of the CRD IG. While we believe these capabilities may result in a more efficient and timely CRD workflow for users, we acknowledge and agree with the feedback that these requirements are currently optional in

the CRD IG and may not currently provide sufficient technical detail needed for implementation. As a result, we are not finalizing this proposed requirement. However, we encourage developers to consider implementation of these capabilities and encourage the standards community to continue to iterate upon and refine these capabilities in future versions of the CRD IG.

Comment: Regarding our proposal that a Health IT Module certified to the “prior authorization API--provider” support the six different hooks identified in the proposed rule, several commenters recommended that ASTP/ONC provide additional flexibility regarding what hooks developers are required to support. Commenters stated that the proposed requirements represented demands on Health IT Modules over and above the requirements in the IGs and recommended ASTP/ONC consider focusing on an initial core set of hooks that can expand over time as workflows develop.

Response: We thank commenters for their feedback on our proposal in 45 CFR[thinsp]170.315(g)(34)(i)(B) to require support for the “appointment-book”, “encounter-start”, “encounter-discharge”, “order-dispatch”, “order-select,” and “order-sign” CDS Hooks. We appreciate commenter feedback requesting additional flexibility regarding the proposed requirements, particularly that not all Health IT Modules would be used in the workflows corresponding to the proposed CDS Hooks. Furthermore, we agree with commenters' recommendation to focus on a smaller set of hooks for initial implementation. We also acknowledge that many of the proposed CDS Hooks are indicated by the CDS Hooks IG as low maturity. We believe requiring only the “order- sign” CDS Hook will provide a relatively mature and impactful CDS Hook for initial baseline criterion requirements for provider systems. The “order-sign” CDS Hook is one of the “primary hooks” of the CRD IG and, according to the CDS Hooks IG, the most mature of the six CDS Hooks proposed. We encourage industry to explore opportunities to implement other CDS Hooks to reduce provider burden.

Comment: Several commenters noted that implementers are currently evaluating if a regular FHIR operation or a CDS hook could best execute the actions identified under the CRD IG. These commenters stated that if developers are required to certify Health IT Modules to CDS Hooks, opportunities for innovation and iteration on the IGs may be slowed, which are important given the evolving nature of the IG. Other commenters stated that they did not see a compelling need to require CDS Hooks as the only mechanism to invoke a payer service. Instead, the commenters recommended that ASTP/ONC define an operation definition that MAY be supported and only finalize requirements for the use of CDS Hooks as “SHOULD” requirements.

Response: We appreciate commenters' recommendations. We note that CDS Hooks is a central component within the CRD IG workflow, and we believe it is an important and extensible functionality for industry to pursue. We do not agree that requiring CDS Hooks will slow innovation on the IG; rather, the widespread use and deployment of CDS Hooks will result in more robust interoperability and dynamic information workflows to send and receive data in support of electronic prior authorization, among many other potential use cases. Where there may be opportunities to improve the CDS Hooks IG, such widespread deployment will allow for more rapid revision and improvement of the IG. While we are aware of alternatives to CDS Hooks to invoke a payer service, we note that only the CDS Hooks IG is cross-referenced in the CRD IG for this purpose. Thus, we are finalizing only the use of the CDS Hooks IG for this purpose to be consistent with the CRD IG. Also, we are finalizing a limited scope of “SHOULD” requirements with specific support requirements in 45 CFR 170.315(g)(31)(i)(B) to call decision support services including support for the “order-sign” CDS Hook.

Comment: Commenters noted that the triggers included in the CRD IG capability statement assume that an encounter has occurred. However, there are numerous scenarios in which the prior authorization workflow may be initiated in the absence of a patient encounter. Commenters recommended that ATSP/ONC finalize an expanded set of trigger events including those that are not dependent upon a patient encounter.

Response: We thank commenters for their input, but we decline to articulate a list of triggers necessary to initiate a prior authorization workflow at this time. We expect implementers to work with standards developers to refine aspects of the CRD IG, leveraging real-world experience, to achieve more consistent and effective implementation of coverage requirements discovery workflows. These refinements may include expanding the scenarios under which a prior authorization workflow must be initiated.

After consideration of the public comments, we are finalizing the proposed requirements in 45 CFR[thinsp]170.315(g)(34)(i) as part of the “provider prior authorization API--coverage requirements discovery” certification criterion in 45 CFR[thinsp]170.315(g)(31), with modifications. We describe how the proposed requirements map to the requirements we are finalizing below.

In general, we are finalizing technical requirements in 45 CFR[thinsp]170.315(g)(31)(i) to require the capabilities associated with the “CRD Client” system actor defined in the CRD IG to enable users to request and receive coverage requirements. The regulation text we are finalizing in 45 CFR[thinsp]170.315(g)(31) reorganizes, rephrases, and reduces the scope of the requirements proposed in 45 CFR[thinsp]170.315(g)(34)(i).

We proposed to require in 45 CFR[thinsp]170.315(g)(34)(i)(B) and 45 CFR[thinsp]170.315(g)(34)(i)(B)(1) to require support for the capabilities in 45 CFR[thinsp]170.315(j)(20) to enable workflow triggers to call decision support services, including support for “appointment-book”, “encounter-start”, “encounter-discharge”, “order-dispatch”, “order-select,” and “order-sign” CDS Hooks, according to at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(j)(1) and requirements in 45 CFR[thinsp]170.315(j)(20) of this section. We are finalizing with modification these requirements in 45 CFR[thinsp]170.315(g)(31)(i)(B) to enable workflow triggers to call decision support services, to streamline the text, and limit the required CDS Hooks to only “order- sign.”

We proposed in 45 CFR[thinsp]170.315(g)(34)(i)(C) and 45 CFR[thinsp]170.315(g)(34)(i)(C)(1) and (2) to require support for the requirements applicable to “CRD Clients” in at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(j)(1), including the requirements in the “CRD Client CapabilityStatement” and the “SHOULD” requirements applicable to “CRD Clients” in Section 5.8 “Additional Data Retrieval.”

We are finalizing requirements in 45 CFR[thinsp]170.315(g)(31)(i)(C) to support all requirements and capabilities applicable to a “CRD Client,” with modification to combine and rephrase the proposed paragraphs of 45 CFR[thinsp]170.315(g)(34)(i)(C) and 45 CFR[thinsp]170.315(g)(34)(i)(C)(1) for more streamlined text and clarity. While not explicitly stated in the paragraph we are finalizing at 45 CFR[thinsp]170.315(g)(31)(i)(C), Health IT Modules will be required to

support the “CRD Client CapabilityStatement” as part of supporting all required capabilities applicable to “CRD Clients,” according to at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(j)(1) (where we are adopting the CRD IG version 2.0.1--STU 2). We are not finalizing proposals at 45 CFR[thinsp]170.315(g)(34)(i)(C)(2) for reasons discussed in our response to comments.

We are finalizing 45 CFR[thinsp]170.315(g)(31)(i)(A) to clarify required support for registration capabilities applicable to “CRD Clients.” This subparagraph clarifies a requirement proposed at 45 CFR[thinsp]170.315(g)(34)(i)(C) for “CRD Clients” that is stated in the CRD IG but was not explicitly identified in the regulation text proposed at 45 CFR 170.315(g)(34). We note that a “CRD Client” must register with a “CDS Service” as a prerequisite to enable other required “CRD Client” FHIR API data capabilities. Registration requirements are described in the CDS Hooks and CRD IGs, thus we are finalizing the requirement in 45 CFR[thinsp]170.315(g)(31)(i)(A) to remove potential ambiguity regarding required support for these critical capabilities in the Certification Program.

We clarify that for the purposes of this requirement, “registration” includes registration and configuration necessary to exchange data for the purposes of coverage requirements discovery using workflows in accordance with CDS Hooks and CRD IGs we are finalizing at 45 CFR 170.215(f) and 45 CFR 170.215(j), respectively. See the section “Security and Safety” in the CDS Hooks IG \477\ and the section “Enabling a CRD Server” in the CRD IG \478\ for additional details about the registration processes described in those IGs.

\477\ See https://cds-hooks.hl7.org/#security-and-safety.

\478\ See https://hl7.org/fhir/us/davinci-crd/STU2/foundation.html#enabling-a-crd-server.

We are also finalizing a paragraph for documentation requirements for the “provider prior authorization API--coverage requirements discovery” criterion in 45 CFR[thinsp]170.315(g)(31)(ii), which states that supported API server capabilities of “CRD Clients” from the CRD IG must include complete accompanying technical documentation. The requirements we are finalizing are based on the documentation requirements we proposed in the HTI-2 Proposed Rule at 45 CFR[thinsp]170.404(a)(2)(i) and its subparagraphs (89 FR 63592 through 89 FR 63593).

In the HTI-2 Proposed Rule, we proposed to include additional documentation requirements in 45 CFR[thinsp]170.404(a)(2)(i) and proposed that provisions of the API Condition and Maintenance of Certification requirements at 45 CFR[thinsp]170.404, including the proposed documentation requirements in 45 CFR[thinsp]170.404(a)(2)(i), would be applicable to the proposed “prior authorization API-- provider” criterion in 45 CFR[thinsp]170.315(g)(34) (89 FR 63592 through 63593).

However, we proposed the documentation requirements in 45 CFR[thinsp]170.404(a)(2)(i) in tandem with proposals to remove similar language around documentation requirements from the “standardized API for patient and population services” criterion in 45 CFR[thinsp]170.315(g)(10). Under the narrow scope of this final rule, we are not finalizing any proposals in 45 CFR[thinsp]170.315(g)(10), and therefore we are not finalizing the related documentation requirements in 45 CFR[thinsp]170.404(a)(2)(i). Instead, we are finalizing references to “complete accompanying technical documentation” as part of the criteria in 45 CFR[thinsp]170.315(g)(31)(ii) and 45 CFR[thinsp]170.315(g)(33)(ii).

For the purposes of the requirement in 45 CFR[thinsp]170.315(g)(31)(ii), we clarify that the following is expected to be included as part of complete accompanying technical documentation as applicable: (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 that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and (3) all applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server. The expectation for technical documentation is consistent with what is currently required at 45 CFR 170.315(g)(10)(viii). Pursuant to the API Condition and Maintenance of Certification requirements at 45 CFR[thinsp]170.404, which we are finalizing to apply to the “provider prior authorization API--coverage requirements discovery” criterion in section XI.B.4.b.(6)(c) of this final rule, the complete accompanying technical documentation required by 45 CFR[thinsp]170.315(g)(31)(ii) must be publicly published as part of the Certified API Developer's complete business and technical documentation. We discuss revisions to 45 CFR 170.404 with implications for certified health IT developers that have Health IT Modules certified to 45 CFR 170.315(g)(31), (g)(32), and (g)(33) in section XI.B.4.b.(6)(d) of this final rule. (iv) Documentation Templates and Rules

In 45 CFR[thinsp]170.315(g)(34)(ii) we proposed requirements related to documentation and rules exchange (89 FR 63589). The DaVinci DTR and CRD IGs utilize Clinical Quality Language (CQL) to allow payers to inspect a patient's record for the necessary information related to the required documentation for a proposed item (such as durable medical equipment), medication, procedure, or other service. The DTR IG details the use of a payer provided Questionnaire resource and results from CQL execution to generate a QuestionnaireResponse resource containing the necessary information. We noted that this IG can allow payer APIs to specify how rules may be executed in a provider context so that documentation requirements are met, while at the same time reducing provider burden by reducing manual data entry.

We proposed in 45 CFR[thinsp]170.315(g)(34)(ii) that a Health IT Module certified to the “prior authorization API--provider” certification criterion must support the ability to request and populate prior authorization documentation templates and rules from payer systems according to at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1--STU 2).

We noted at 89 FR 63589 that “Light” DTR capabilities are applicable to EHRs that rely on a SMART on FHIR application to handle the form filling function of DTR. This requires the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources. In 45 CFR[thinsp]170.315(g)(34)(ii)(A)(1), we proposed the Health IT Module must support the capabilities included in the “Light DTR EHR” CapabilityStatement according to at least one versions of the implementation specification adopted in 45 CFR 170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1--STU 2). In 45 CFR[thinsp]170.315(g)(34)(ii)(A)(2)(i), we proposed that the Health IT Module must support functional registration of the “DTR SMART Client” according to the requirements included in 45 CFR 170.315(j)(1) (where we proposed to

adopt a “functional registration” criterion). We also proposed in 45 CFR[thinsp]170.315(g)(34)(ii)(A)(2)(ii) that the Health IT Module must support dynamic registration of the “DTR SMART Client” according to the requirements included in 45 CFR 170.315(j)(2) (where we proposed to adopt a certification criterion for “dynamic registration”).

In 45 CFR[thinsp]170.315(g)(34)(ii)(A)(3), we proposed that the Health IT Module must support launching the “DTR SMART Client” according to at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1--STU 2) to allow providers to launch an app to complete documentation for prior authorization according to at least one of the versions of the implementation specification in 45 CFR[thinsp]170.215(j)(2). In 45 CFR[thinsp]170.315(g)(34)(ii)(A)(3)(i) we proposed that the Health IT Module must support authentication and authorization during the process of granting access to patient data to users according to the requirements in 45 CFR 170.315(j)(10) (where we proposed to adopt a certification criterion for “SMART clinician access for EHR launch”). In 45 CFR[thinsp]170.315(g)(34)(ii)(A)(3)(ii) we proposed that the Health IT Module must support asymmetric certificate-based authentication according to the requirements in 45 CFR 170.315(j)(11) for the “Light DTR Client” dynamically registered using the capabilities in 45 CFR 170.315(g)(34)(ii)(A)(2)(ii).

We stated that in contrast to “Light DTR EHR” capabilities, “full” DTR capabilities are relevant to EHRs that manage the form filling functions of DTR internally. In 45 CFR[thinsp]170.315(g)(34)(ii)(B), we proposed that the Health IT Module must support the capabilities included in the “Full DTR EHR” CapabilityStatement according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(2) (where we proposed to adopt the DTR IG version 2.0.1--STU 2). Such EHRs need only support client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations.

We requested comments on our proposals. The following is a summary of the comments we received and our responses:

Comment: We received numerous comments on our proposal in 45 CFR 170.315(g)(34)(ii) to require Health IT Modules certified to the “prior authorization API--provider” certification criterion to support both the capabilities included in the “Light DTR EHR” CapabilityStatement and the “Full DTR EHR” CapabilityStatement. Some commenters supported our proposal to finalize both requirements, stating that requiring all EHRs to comply with both sets of requirements will ensure market readiness, as some payers may not be ready to support the “full” DTR requirements initially and may need to rely upon a DTR SMART App in an EHR or practice management system to support implementation. Other commenters recommended that ASTP/ONC should allow developers to choose whether to support either the “light” or “full” DTR requirements, stating that a requirement to support both would be duplicative. Finally, numerous commenters recommended that ASTP/ONC, if it finalizes the criterion, should only require support for the “full” DTR capabilities. Commenters stated that the “full” DTR functionality has more potential for automation and improved performance, whereas implementation of “light” capabilities, while providing a faster path to adoption, may result in an inconsistent end-user experience. By contrast, commenters believed that requiring developers to implement the “full” DTR process would result in a superior user experience for clinicians and availability of the complete suite of functions including the ability to automate the completing of clinical templates. Moreover, commenters stated that the “light” functionality would not provide all of the information needed by payers and would not provide value to clinicians. Availability of the “full” DTR functionality would ultimately encourage increased adoption of prior authorization APIs.

Response: We thank commenters for their feedback on our proposal to require support for both “Full DTR EHR” and “Light DTR EHR” capabilities in the proposed “prior authorization API--provider” criterion. We agree with commenters that requiring support for “Full DTR EHR” capabilities would require certified API technology to support DTR capabilities that can reduce prior authorization burden through payer questionnaire retrieval and population. We also agree with commenters that “Light DTR EHR” capabilities alone would not result in substantial reduction of prior authorization burden and that requiring both “Light DTR EHR” and “Full DTR EHR” support simultaneously could burden developers with supporting a duplicative DTR workflow. Thus, we believe requiring support for the “Full DTR EHR” promotes industry adoption of substantial burden reduction capabilities from the DTR IG while also giving developers implementation flexibility. We note that under the “Full DTR EHR” requirements, health IT developers could develop the required DTR capabilities themselves or choose to integrate DTR apps with such capabilities into their Health IT Modules. For purposes of certification to DTR requirements, DTR apps could be integrated into certified health IT as “relied upon software,” which is permitted to be used by health IT developers to demonstrate compliance with certification criteria requirements.

After consideration of the public comment, we are finalizing the proposed requirements in 45 CFR 170.315(g)(34)(ii) as part of the “provider prior authorization API--documentation templates and rules” certification criterion in 45 CFR 170.315(g)(32), with modifications. Specifically, we are finalizing in 45 CFR 170.315(g)(32) that certified Health IT Modules must support all requirements and required capabilities applicable to a “Full DTR EHR” according to at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(j)(2) (where we are adopting the DTR IG version 2.0.1--STU 2). We are not finalizing proposed requirements to support capabilities specific to a “Light DTR EHR.”

As part of finalizing our proposal to require support for the capabilities included in the “Full DTR EHR” CapabilityStatement under the “provider prior authorization API--documentation templates and rules” criterion in 45 CFR[thinsp]170.315(g)(32), we have made additional modifications to the language proposed in 45 CFR[thinsp]170.315(g)(34)(ii). We are finalizing three separate paragraphs at 45 CFR[thinsp]170.315(g)(32)(i)-(iii) to clarify and refine the requirements we initially proposed.

The paragraph we are finalizing in 45 CFR[thinsp]170.315(g)(32)(iii) includes similar language to proposed 45 CFR[thinsp]170.315(g)(34)(ii)(B) and requires support for all requirements and required capabilities applicable to a “Full DTR EHR.” This revised version of the proposed language provides clarity by rephrasing the requirement using plain language while maintaining the same scope. We note that while the “Full DTR EHR” CapabilityStatement artifact is not specifically referenced in the requirement language we are finalizing, health IT developers must support the capabilities required by the “Full DTR EHR” CapabilityStatement. Specifically, the requirement to support all requirements and required capabilities applicable to a “Full DTR

EHR” would also include support for the “Full DTR EHR” CapabilityStatement artifact. We also reiterate general Certification Program policy that all applicable conformance requirements expressed by a standard or implementation guide referenced in certification criteria are required to be supported for the purposes of certification unless otherwise specified. For example, for the 45 CFR[thinsp]170.315(g)(32) criterion, all “SHALL” and “Must Support” requirements applicable to the “Full DTR EHR” system actor are required to be supported for the purposes of certification.

The paragraph we are finalizing in 45 CFR[thinsp]170.315(g)(32)(i) specifies required support for registration capabilities applicable to a “Full DTR EHR.” This language clarifies a component of the requirement proposed at 45 CFR[thinsp]170.315(g)(34)(ii)(B) that is included as part of support for requirements applicable to a “Full DTR EHR” in the DTR IG. Specifically, a “Full DTR EHR” must register with a “DTR Payer Service” as a prerequisite necessary to enable other required “Full DTR EHR” FHIR API data capabilities. Registration requirements for a “Full DTR EHR” are specified in the DTR IG, and we are finalizing requirements in 45 CFR[thinsp]170.315(g)(32)(iii) to remove ambiguity that such registration requirements must be supported. See section “Configuring App/EHR to Payer Connectivity” in the DTR IG \479\ for additional details about registration requirements for a “Full DTR EHR.”

\479\ https://hl7.org/fhir/us/davinci-dtr/STU2/specification.html#configuring-appehr-to-payer-connectivity.

The paragraph we are finalizing in 45 CFR[thinsp]170.315(g)(32)(ii) includes language to clarify a component of the requirement proposed at 45 CFR[thinsp]170.315(g)(34)(ii)(B) to support requirements applicable to a “Full DTR EHR.” The paragraph at 45 CFR[thinsp]170.315(g)(32)(ii) specifies required support for system authentication and authorization as a client in accordance with the “Backend Services” section of a version of the SMART App Launch IG adopted under 45 CFR[thinsp]170.215(c). We include this language to clarify potential ambiguity in the DTR IG regarding “Full DTR EHR” requirements to support authentication and authorization in accordance with the SMART on FHIR Backend Services specification as well as to provide clarity and consistency to implementers regarding which versions of the SMART on FHIR Backend Services specification are available for the purposes of certification.

The “Authenticating DTR client to payer API” section of the DTR IG we are adopting in 45 CFR 170.215(j)(2) specifies the requirement for payers to require DTR EHRs to use SMART on FHIR Backend Services to authenticate to payer DTR API endpoints. As stated in the DTR IG in section “Authenticating DTR client to payer API,” \480\ this requirement is framed to apply to the payer DTR API endpoint and does not require a specific version of the SMART on FHIR Backend Services specification. The language we are finalizing in 45 CFR[thinsp]170.315(g)(32)(ii) clarify this element of the IG by (1) describing the effective requirement in the DTR IG explicitly, rather than implicitly through payer conformance requirements, to require the Health IT Module to support authentication and authorization according to SMART on FHIR Backend Services; and (2) requiring support for one of the versions of the SMART on FHIR Backend Services specification contained within the SMART App Launch implementation specifications adopted at 45 CFR[thinsp]170.215(c).

\480\ https://hl7.org/fhir/us/davinci-dtr/STU2/specification.html#authenticating-dtr-client-to-payer-api.

(v) Prior Authorization Support

Finally, in 45 CFR[thinsp]170.315(g)(34)(iii) we proposed that the “prior authorization API--provider” certification criterion must support capabilities related to the submission of a prior authorization request (89 FR 63588).

For the “prior authorization API--provider” certification criterion, we proposed in 45 CFR[thinsp]170.315(g)(34)(iii)(A) that the Health IT Module must support the ability to submit a prior authorization request to a payer system according to at least one of the versions of the implementation specification adopted in 170.215(j)(3) (where we proposed to adopt the PAS IG version 2.0.1--STU 2). Specifically, we proposed in 45 CFR[thinsp]170.315(g)(34)(iii)(A)(1) that the Health IT Module include support for the “EHR PAS Capabilities” CapabilityStatement according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(3).

We proposed in 45 CFR[thinsp]170.315(g)(34)(iii)(A)(2) that the Health IT Module support the ability to include documentation created in 45 CFR 170.315(g)(34)(ii) in a prior authorization request to a payer system according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(3). We proposed in 45 CFR[thinsp]170.315(g)(34)(iii)(A)(3) that the Health IT Module support the ability to consume and process a “ClaimResponse” according to at least one of the versions of the implementation specification adopted in 45 CFR 170.215(j)(3). Finally, we proposed in 45 CFR[thinsp]170.315(g)(34)(iii)(A)(4) that the Health IT Module support subscriptions as a client according to the requirements in 45 CFR 170.315(j)(24) (where we proposed to adopt a “subscriptions-- client” certification criterion) and an implementation specification in 45 CFR 170.215(j)(3), in order to support “pended authorization responses.”

Comment: Several commenters highlighted specific technical issues with the PAS IG which commenters have identified as part of ongoing development work on the IG.

Response: We appreciate commenters' highlighting of these issues. We note that several of these issues have been resolved since the publication of the HTI-2 Proposed Rule. We acknowledge that, as with the other Burden Reduction IGs we are adopting in this section, the PAS IG continues to evolve. We appreciate the continued collaboration of interested parties across the standards development community in improving these specifications and will seek to utilize flexibility under the Certification Program to ensure updated versions of the implementation specifications are available for use by health IT developers in a timely manner.

After consideration of the public comments, we are finalizing the proposed requirements in 45 CFR 170.315(g)(34)(iii) as part of the “provider prior authorization API--prior authorization support” criterion in 45 CFR 170.315(g)(33), with modifications. The “provider prior authorization API--prior authorization support” criterion requires a Health IT Module to submit a prior authorization request as a client in accordance with at least one of the versions of the standard adopted in 45 CFR 170.215(j)(3) (where we are adopting the PAS IG version 2.0.1--STU 2). In comparison to proposed 45 CFR 170.315(g)(34)(iii) and its subparagraphs, the “provider prior authorization API--prior authorization support” criterion in 45 CFR 170.315(g)(33) has three categories of technical API requirements at and under 45 CFR 170.315(g)(33)(i).

The paragraph we are finalizing in 45 CFR 170.315(g)(33)(i)(C) and its subparagraphs describe requirements to

support prior authorization transactions as a client and include similar language to proposed 45 CFR 170.315(g)(34)(iii)(A) and its subparagraphs, with the exception of the proposed ability in 45 CFR 170.315(g)(34)(iii)(A)(2) to include documentation created in 45 CFR[thinsp]170.315(g)(34)(ii) in a prior authorization request to a payer system, according to at least one of the versions of the implementation specifications adopted in 45 CFR[thinsp]170.215(j)(3). That proposed requirement would have required the Health IT Module to support including documentation created using DTR IG capabilities in a prior authorization request to a payer system according to the PAS IG. We are not finalizing this proposed requirement in the “provider prior authorization API--prior authorization support” criterion since we are finalizing DTR IG capabilities in a distinct criterion in 45 CFR 170.315(g)(32). We anticipate that developers and implementers of certified health IT will combine capabilities of the CRD, DTR, and PAS IGs to reduce provider burden. This may occur because a certified health IT developer has chosen to certify to all three criteria at 45 CFR 170.315(g)(31) through (g)(33) or because a health IT developer with a Health IT Module certified to one or two of those criteria are working with other certified health IT developers' Health IT Modules to complete the electronic prior authorization workflow.

The paragraphs we are finalizing in 45 CFR 170.315(g)(33)(i)(A) and (B) specify required registration and authentication and authorization capabilities. Paragraph 45 CFR 170.315(g)(33)(i)(A) requires support for registration capabilities applicable to a client system and is a prerequisite capability required to enable authentication and authorization requirements we are finalizing in 45 CFR 170.315(g)(33)(i)(B). Paragraph 45 CFR 170.315(g)(33)(i)(B) requires system authentication and authorization as a client in accordance with the “Backend Services” section of at least one of the versions of the implementation specification adopted in 45 CFR[thinsp]170.215(c).

These paragraphs clarify components of the requirement we proposed in 45 CFR 170.315(g)(34)(iii)(A) to support the ability to submit a prior authorization request to a payer system according to at least one of the implementation specifications adopted in 45 CFR 170.215(j)(3) (where we are finalizing adoption of the PAS IG version 2.0.1--STU 2). The PAS IG requires in section “Privacy & Security” that the provider system supports authentication to the payer system or an intermediary, and recommends servers (e.g., payer systems) support the OAuth standard in a server to server capacity. While the PAS IG does not reference a specific version of the OAuth standard, the latest published version of the OAuth standard is OAuth 2.0 Authorization Framework (RFC 6749) \481\ (OAuth 2.0) published October 2012. OAuth 2.0 is one of the foundational standards upon which the SMART Backend Services specification is based. Furthermore, the PAS IG requires all client (e.g., provider) systems comply with the “Security and Privacy” section of the Da Vinci Health Record Exchange (HRex) IG, without specifying a version of that IG. The “Security and Privacy” section of the latest published version of the Da Vinci HRex IG,\482\ published December 10, 2024, recommends OAuth server to server authentication as defined in the SMART Backend Services specification as one option when the identity of the requesting or receiving party is important.

\481\ https://datatracker.ietf.org/doc/html/rfc6749.

\482\ https://hl7.org/fhir/us/davinci-hrex/STU1.1/security.html.

Of the options recommended by the Da Vinci HRex IG, we believe the SMART Backend Services specification aligns most closely with the authentication recommendation from the PAS IG and is a specification already widely supported in a server capacity by developers of certified health IT in accordance with the requirements in the 45 CFR 170.315(g)(10) “standardized API for patient and population services” criterion. We believe clarifying a requirement for this otherwise optional authentication specification is necessary to establish a consistent baseline authentication and authorization mechanism in the Certification Program for provider systems to authenticate with and receive authorization from payer systems when using prior authorization transaction capabilities from the PAS IG.

We further note that according to our proposal in 45 CFR 170.315(g)(34)(ii)(B), Health IT Modules certified to 45 CFR 170.315(g)(34) would have been required to support the “Full DTR EHR” capabilities from the DTR IG (89 FR 63589 through 63590). As discussed in a previous comment response, supporting the SMART Backend Services specification as a client is part of implementing the “Full DTR EHR” capabilities from the DTR IG, and thus would have been required as part of the proposal at 45 CFR 170.315(g)(34)(ii)(B). Since we are finalizing DTR IG and PAS IG capabilities from the 45 CFR 170.315(g)(34) proposal in distinct criteria at 45 CFR 170.315(g)(32) and (33) respectively, we finalize paragraphs 45 CFR 170.315(g)(32)(ii) and 45 CFR 170.315(g)(33)(i)(B) in those criteria to establish consistent requirements to support the SMART Backend Services specification as a client.

In addition to the technical requirements we are finalizing at and under paragraph 45 CFR 170.315(g)(33)(i), we are also finalizing a paragraph for documentation requirements for the 45 CFR[thinsp]170.315(g)(33) criterion in 45 CFR[thinsp]170.315(g)(33)(ii). This paragraph requires that supported subscriptions client endpoint capabilities for the “REST-Hook” channel from the PAS IG must include complete accompanying technical documentation. These requirements complement existing requirements in the “Transparency conditions” at 45 CFR 170.404(a)(2) in lieu of finalizing the revisions to 45 CFR[thinsp]170.404(a)(2)(i) and its subparagraphs that were proposed in the HTI-2 proposed rule.

For the purposes of this requirement, we clarify that the following is expected to be included as part of complete accompanying technical documentation as applicable: (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 that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and (3) all applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server. Pursuant to the API Condition and Maintenance of Certification requirements at 45 CFR[thinsp]170.404, the documentation required by 45 CFR[thinsp]170.315(g)(33)(ii) must be publicly published as part of the Certified API Developer's complete business and technical documentation. We discuss the finalization of including 45 CFR[thinsp]170.315(g)(33) in the 45 CFR[thinsp]170.404 API Condition and Maintenance of Certification requirements in section IX.B.4.b.(6)(d) of this final rule.

In summary, after consideration of the public comment, we are finalizing the following three certification criteria based on the “prior authorization API--provider” criterion we proposed in in 45 CFR[thinsp]170.315(g)(34):

Provider prior authorization API--coverage requirements discovery (45 CFR[thinsp]170.315(g)(31)).

Provider prior authorization API--documentation templates and rules (45 CFR[thinsp]170.315(g)(32)).

Provider prior authorization API--prior authorization support (45 CFR[thinsp]170.315(g)(33)).

These criteria include additional modifications to the proposals for the “prior authorization API--provider” criterion that we are finalizing in response to public comments, and in order to streamline and clarify requirements in the final criteria. We have discussed these modifications in detail above. (vi) Support for CMS Requirements

In the HTI-2 Proposed Rule (89 FR 63591) we noted that the “prior authorization API--provider” certification criterion proposed in 45 CFR[thinsp]170.315(g)(34), if finalized, would support the availability of certified health IT that can enable health care providers to interact with the Prior Authorization APIs established pursuant to CMS payer API requirements, using certified health IT. CMS also finalized Electronic Prior Authorization measures for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability Performance Category in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8926). These measures are intended to incentivize eligible hospitals, CAHs, and eligible clinicians to use Prior Authorization APIs to submit their prior authorization requests (89 FR 8946). We stated that if we finalized our proposal for the “prior authorization API--provider” certification criterion, adopting and using technology certified to this criterion would enable MIPS eligible clinicians, eligible hospitals and CAHs to complete the prior authorization request actions associated with these measures using certified health IT.

We also noted in the HTI-2 Proposed Rule that, at that time, CMS had not identified health IT certified to specific criteria to complete the actions specified for finalized Electronic Prior Authorization measures in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category (89 FR 63581 through 63582, 63591). We discussed how, if the proposed “prior authorization API--provider” certification criterion was finalized, we would work with CMS on appropriate steps within the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category to identify health IT certified to this criterion as an element of CEHRT necessary to report on the Electronic Prior Authorization measures. As CMS noted in the Interoperability and Prior Authorization Final Rule, use of health IT certified to support electronic prior authorization transactions can help to ensure that the actions associated with these measures are executed in a consistent fashion across the health care providers participating in these programs (89 FR 8926).

Comment: Commenters stated that enabling providers to interact with APIs that payers are developing will be important for the uptake of these payer APIs and realizing the potential benefits of electronic prior authorization. Commenters also believed that the availability of health IT certified to the “prior authorization API--provider” criterion would ensure that healthcare providers participating in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category will be able to meet requirements for reporting the Electronic Prior Authorization measures CMS has finalized.

Response: We thank commenters for their support and will collaborate with CMS on steps to identify the criteria in 45 CFR[thinsp]170.315(g)(31), (32), and (33) that we are finalizing in this rule as necessary to support reporting of the Electronic Prior Authorization measures finalized for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category.

Comment: Commenters expressed concerns about alignment between the Da Vinci CRD, DTR, and PAS IGs proposed for incorporation in the “prior authorization API--provider” criterion and the versions of the USCDI standard and US Core IG proposed for adoption in the HTI-2 Proposed Rule. Commenters stated that the proposed versions of the Da Vinci IGs have not yet been updated to reference proposed versions of the USCDI standard and US Core IG, creating potential misalignment across requirements. Commenters also expressed concerns about the timeline for adoption of updated versions of these standards relative to deadlines that have been established by CMS for establishment of APIs meeting the requirements in the Interoperability and Prior Authorization final rule by impacted payers.

Response: We appreciate commenters' concerns regarding alignment of CRD, DTR, and PAS IGs with USCDI and US Core IG versions. We agree that there are degrees of misalignment between Version 2.0.1 of the CRD, DTR, and PAS IGs with the versions of USCDI and the US Core IG we proposed for adoption in the HTI-2 Proposed Rule. We note that we are not finalizing USCDI Version 4 and US Core IG Version 7 as part of this final rule. Thus, developers will not encounter potential misalignment if they certify to criteria we are finalizing in this rule that reference the Da Vinci standards using USCDI Version 3 and US Core IG 6.1. Further, we note that the 2.1.0 versions of the CRD, DTR, and PAS IGs have been updated to cover USCDI Version 4 and US Core IG Version 7. Taken together, this means that developers certifying Health IT Modules to certification criteria that reference these IGs may do so using USCDI Version 3 and US Core IG Version 6 or, by using SVAP, certify using subsequent versions of USCDI and US Core IG (up to Version 7, currently) and avoid misalignment. Regarding CMS requirements for payer APIs, as we are not finalizing USCDI Version 4 and US Core IG Version 7 in this final rule, payers would not be subject to challenges related to misalignment based upon these proposed versions at this time. We will continue to work closely with CMS to manage issues of alignment across adopted standards.

Comment: We received numerous comments on issues related to CMS policies around prior authorization, including comments on the Prior Authorization API requirements finalized in the Interoperability and Prior Authorization final rule, and comments around other policies related to prior authorization that CMS could seek to advance as part of programs.

Response: We value these recommendations and will ensure that these inputs are shared with CMS. We will work together with CMS to further explore opportunities to address these issues. (vii) Administrative Simplification Requirements Under HIPAA

We noted that, pursuant to the administrative simplification rules established under HIPAA, the Secretary must adopt electronic standards for use by “covered entities,” which is defined as including health plans, healthcare clearinghouses, and certain healthcare providers.\483\ We noted that the two standards adopted for referral certification and authorization transactions under the HIPAA administrative simplification rules (45 CFR 162.1302) include: NCPDP Version

D.0 for retail pharmacy drugs; and X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional request for review and response for items and services. HHS has also proposed to adopt the X12 275 standard, which is used to transmit additional documentation to support the exchange of the additional information that is required for prior authorization, in the “Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard” proposed rule (87 FR 78438).

\483\ For more information, see https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification.

We stated that nothing in our proposed certification criteria related to electronic prior authorization would alter requirements for covered entities to use adopted HIPAA transaction standards. Moreover, the FHIR specifications we proposed to adopt for these certification criteria would not conflict with the use of the adopted HIPAA standard, and we stated we would expect covered entities using technology certified to these criteria to ensure compliance with applicable requirements.

We noted that in March 2021, the CMS National Standards Group (NSG), on behalf of HHS, approved an application \484\ from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards for Da Vinci payers and their trading partners when using the FHIR standard for prior authorization. Under this exception, the group tested a prior authorization exchange using the HL7 FHIR Da Vinci standard without the X12 278 standard to determine whether this alternative standard for prior authorization could improve efficiency. HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the CMS HIPAA administrative simplification website.\485\

\484\ See https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception?preview=/113675673/113675685/Approval%20%232021031001.pdf.

\485\ Centers for Medicare & Medicaid Services (2022). Go-to- Guidance, Guidance Letters. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/subregulatory-guidance/letters.

On February 28, 2024, CMS NSG, on behalf of HHS, announced an application of enforcement discretion for HIPAA covered entities that implement FHIR-based Prior Authorization APIs as described in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758).\486\ HHS stated that this action was in response to feedback received on multiple notices of proposed rulemaking and extensive stakeholder outreach and is intended to promote efficiency in the prior authorization process. Specifically, HHS stated that HIPAA Administrative Simplification enforcement action will not be taken against HIPAA covered entities that choose not to use the X12 278 standard as part of an electronic FHIR prior authorization process. We stated that HHS will continue to evaluate the HIPAA prior authorization transaction standards, including continuing to seek stakeholder input and evaluating the results of testing an all-FHIR-based transaction.

\486\ See https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf.

We received numerous comments on our discussion of the intersection between our proposals and standards adopted by CMS for administrative simplification transactions.

Comment: Several commenters raised concerns about the intersection between the proposed “prior authorization API--provider” criterion and the existing standards landscape for electronic prior authorization, which includes adoption and use of the X12 278 standard. Commenters stated that it is unclear how healthcare providers, if using Health IT Modules certified to the proposed “prior authorization API-- provider” criterion, would be able to interact with health plans that continue to use the X12 278 standard. A commenter cited the 2023 CAQH Index Report, noting that while industry adoption of the X12 278 is low at 31 percent, it has increased from 13 percent in 2019. Commenters stated that they expect there will be a significant length of time beyond the January 1, 2027, compliance date for impacted payers when healthcare providers will continue to use the X12 278 standard. Commenters expressed concerns that adoption of these certified Health IT Modules would create a bifurcated approach between the use of X12 and FHIR approaches to completing prior authorization requests, and that physician practices would need to contract with intermediaries in order to continue to use the X12 278 standard where necessary. Commenters believed that covered entities would effectively be prohibited from using the mandated X12 transactions, particularly for the prior authorization submission step, and that under the proposals in the HTI-2 Proposed Rule and the final policies in the Interoperability and Prior Authorization final rule, ASTP/ONC and CMS would create a scenario in which covered entities have no option to use the legally mandated transaction standard. Commenters further argued that this approach seems contrary to the Congressional mandate set out in the HIPAA electronic healthcare transactions. Commenters encouraged ASTP/ONC to work with CMS to clarify the use of X12 transactions within electronic prior authorization workflows.

Response: We appreciate commenters' concerns regarding the intersection of different HHS policies addressing standards for electronic prior authorization. We continue to work closely with CMS to address ongoing regulatory strategy around such standards. While our finalization of certification criteria at 45 CFR 170.315(g)(31), (32), and (33) would support the availability of health IT enabling healthcare providers to conduct electronic prior authorization activities using the FHIR standards that we are adopting in this final rule, these final policies would not limit providers to exclusive use of technology using these standards for electronic prior authorization.

Comment: Commenters acknowledged the availability of enforcement discretion issued by CMS as discussed in the proposed rule (89 FR 63591 through 63592) and stated their appreciation for this flexibility. However, commenters raised concerns that this enforcement discretion could be revoked at any time. Commenters also noted that the administrative simplification exception provided for use of Da Vinci standards has been completed but the findings from the exceptions process have not yet been made available to the public and suggested that this would be an important resource for the public to be able to use when evaluating the proposed prior authorization approaches.

Response: We acknowledge commenters' concerns regarding reliance on CMS' enforcement discretion. We believe this enforcement discretion provides significant flexibility to healthcare providers and payers to pursue innovative approaches to electronic prior authorization at the present time. However, we continue to support CMS' efforts to establish long-term regulatory strategies in this area that support these goals. We note that the findings from the exception granted to the Da Vinci project are now

available.\487\ We refer readers to the notice that appeared in the Federal Register on April 29, 2025, regarding the availability and location of the HL7 International Da Vinci Project Report (90 FR 17827). The report found that participants were able to successfully use standards-based FHIR APIs to conduct prior authorization transactions, and indicates that scaling adoption of this approach to information sharing is likely to deliver significant benefits to entities currently facing administrative burden associated with prior authorization processes. The findings from this report will continue to inform policy development and future implementation of the policies we are finalizing in this final rule.

\487\ See https://confluence.hl7.org/spaces/DVP/pages/113675673/Da+Vinci+HIPAA+Exception.

Comment: Several commenters discussed whether the proposed certification criterion should also address exchange of prior authorization information using the X12 standard. Some commenters recommended that certified health IT should be required to support both an option using X12 as well as an option using FHIR. However, other commenters stated that inclusion of the X12 278 transaction as part of the proposed API would result in needless burden and cost for both providers and health plans, and that exchange partners should leverage the enforcement discretion provided by CMS to avoid mapping the X12 278 transaction as part of the electronic prior authorization API workflow.

Response: We did not propose, and are not finalizing, requirements for Health IT Modules certified to the certification criteria at 45 CFR 170.315(g)(31), (32), and (33) to demonstrate conformance or mapping to the X12 278 transaction. We agree with commenters that requiring all such Health IT Modules to include this functionality would increase costs and burden without an associated benefit, as healthcare providers may conduct electronic prior authorization activities without mapping requests to the X12 278 transaction at this time. However, this would not restrict health IT developers, payers, or other intermediaries, from providing for this mapping where such mapping may be necessary to complete electronic prior authorization transactions with payers via the X12 278 transaction.

Comment: Commenters noted that CMS has proposed to adopt the X12 275 standard and Consolidated Clinical Document Architecture (C-CDA) as relevant standards for healthcare attachments. Commenters expressed concern that there would be redundancy between this proposal, if finalized, and the proposed use of the Da Vinci FHIR PAS IG proposed for use in the “prior authorization API--provider” criterion. This IG references the Da Vinci Clinical Data Exchange (CDex) IG for attachments, rather than the X12 275 standard and C-CDA proposed by CMS. Commenters believed that these concurrent policies, if finalized, would create confusion for those implementing electronic prior authorization.

Response: We recognize that CMS has proposed the use of the C-CDA for attachment information accompanying the X12 275 transaction, including for prior authorization information, in the Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard proposed rule (87 FR 78438), which appeared in the Federal Register on December 21, 2022. This rule has not been finalized as of the publication of this final rule. We will continue to work with CMS on addressing any potential intersection between the policies in this rulemaking and policies which CMS may finalize in the future around HIPAA administrative simplification standards. (d) Revision and Addition of API Condition and Maintenance of Certification Requirements (i) Background

In the HTI-2 Proposed Rule, we made proposals to extend the applicability of the API Conditions of Certification in 45 CFR 170.404(a) and certain API Maintenance of Certification requirements in 45 CFR 170.404(b) to Certified API Developers with Health IT Modules certified to the criteria proposed for adoption in in 45 CFR[thinsp]170.315(g)(7) through (10), 45 CFR 170.315(g)(20), 45 CFR 170.315(g)(30)-(36), and 45 CFR 170.315(j). In this final rule, we are only finalizing policies related to one of these proposed criteria, specifically the criterion in 45 CFR 170.315(g)(34). Therefore, in this section, we limit our focus to proposals from the HTI-2 proposed rule relevant to the proposed criterion in 45 CFR 170.315(g)(34). Specifically, we focus on proposals to amend the applicability of the following: the introductory text to 45 CFR 170.404, 45 CFR 170.404(b)(1), 45 CFR 170.404(b)(1)(i), and certain definitions in 45 CFR 170.404(c).

In addition to proposals in the HTI-2 Proposed Rule extending the applicability of 45 CFR 170.404, we also made proposals to update the requirements in 45 CFR 170.404. These proposals were made in tandem with proposals to update other elements of the Certification Program, including proposals to update to the “standardized API for patient and population services” criterion in 45 CFR 170.315(g)(10), which we are not finalizing in this final rule. Accordingly, we are not finalizing any of the updates proposed to the requirements in 45 CFR 170.404 in the HTI-2 Proposed Rule, except for changes to the applicability of 45 CFR 170.404 with respect to the specific certification criteria that we are finalizing in this final rule.

However, we note that, with respect to proposals in the HTI-2 Proposed Rule to 45 CFR 170.404(a)(2)(i) regarding the technical documentation that a Certified API Developer must make available (89 FR 63592), we are finalizing related requirements within certification criteria being finalized in this rule in 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33). Our proposal in the HTI-2 proposed rule, if finalized, would have included language regarding technical documentation in 45 CFR 170.404(a)(2)(i), which would have been applicable to the proposed “prior authorization API--provider” criterion in 45 CFR 170.315(g)(34), pending the finalization of the proposals to expand the applicability of 45 CFR 170.404 to the criterion in 45 CFR 170.315(g)(34). We believe these technical documentation requirements are important to transparency around the APIs in the criteria we are finalizing in 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33) that are based on the 45 CFR 170.315(g)(34) proposal. Thus, we are finalizing a reference to complete accompanying technical documentation, as proposed in 45 CFR 170.404(a)(2)(i), within the text of the relevant certification criteria in 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33). We direct readers to the finalization of those criteria in this section for more information. (ii) Proposals

In the HTI-2 Proposed Rule we proposed to add several proposed certification criteria to the existing list of criteria for which the requirements in 45 CFR 170.404 would apply, unless otherwise specified, which included the criterion in 45 CFR 170.315(g)(34). We stated that if our proposals were finalized, this would mean that the API Condition and Maintenance of Certification requirements would apply to developers of Health IT Modules certified to 45 CFR 170.315(g)(34). We stated we believe this approach is

essential to continue to fulfill the statutory requirements set forth in PHSA section 3001(c)(5)(D)(iv), in particular the statutory requirement that a developer of certified health IT has published application programming interfaces and allows health information from such technology to be accessed, exchanged, and used without special effort. As we described in the ONC Cures Act Final Rule (84 FR 7476 through 7477), we established the API Condition and Maintenance of Certification requirements to, among other outcomes, promote transparency and pro-competitive business practices among Certified API Developers in pursuit of a policy that would result in access, exchange, and use of EHI “without special effort.” We stated we believe that these same requirements should apply to developers of new API-related certification criteria, and that the proposals to reference additional API certification criteria in 45 CFR 170.404 (inclusive of the criterion in 45 CFR 170.315(g)(34)) would continue to adhere to our statutory charge to advance nationwide interoperability.

In the HTI-2 Proposed Rule, we proposed that the authenticity verification and registration requirements currently in 45 CFR 170.404(b)(1) should apply to Certified API Developers with a Health IT Module certified to one or more specified certification criteria, including the criterion proposed in 45 CFR 170.315(g)(34).

Similarly, we proposed in 45 CFR 170.404(b)(1)(i) that this provision should apply to an expanded set of specified certification criteria, which included proposed 45 CFR 170.315(g)(34). Under 45 CFR 170.404(b)(1)(i), a Certified API Developer is permitted to institute a process to verify the authenticity of API Users so long as such process is objective and the same for all API Users and completed within ten business days of receipt of an API User's request to register their software application for use with the Certified API Developer's Health IT Module certified to any of a set of specified certification criteria.

Finally, we proposed revisions to two key terms in 45 CFR 170.404(c). We proposed to revise certified API technology to mean the capabilities of Health IT Modules that are certified to any of the API- focused certification criteria, including the criterion adopted in 45 CFR 170.315(g)(34). We noted that this revision would support our proposed application of requirements in 45 CFR 170.404 to the proposed APIs in 45 CFR 170.315(g) and the proposed modular API capabilities in 45 CFR 170.315(j). We also proposed to revise Certified API Developer to mean a health IT developer that creates “certified API technology.” We stated we believe this simplified definition for Certified API Developer will similarly support this term's application to the proposed API capabilities in 45 CFR 170.315(g) and proposed modular API capabilities in 45 CFR 170.315(j).

The following is a summary of the comments we received and our responses:

Comment: Commenters were mixed in their support for our proposals to add the “prior authorization API--provider” criterion in 45 CFR 170.315(g)(34) to the API Conditions and Maintenance of Certification requirements in 45 CFR 170.404. While they supported the transparency requirements, some commenters stated they are duplicative of requirements in the Interoperability and Prior Authorization final rule which include similar transparency requirements. Other commenters noted concerns about applying Fees Conditions to these APIs. They noted that the prior authorization APIs are not simple query and retrieve functions. Rather, they are a complex, multi-step, bidirectional conversation between multiple parties. They claimed that prohibiting developers from generating revenue from these complex, orchestration- heavy APIs will significantly impact the willingness of vendors to build and supply these APIs, which will stymie innovation. They recommended that if we finalize the proposals, we should not apply the Fees Conditions to these APIs.

Response: We appreciate commenters' feedback. The regulations we are finalizing reflect a more targeted approach to apply requirements proposed in 45 CFR 170.404 to specific certification criteria in 45 CFR 170.315(g), including the certification criteria at 45 CFR 170.315(g)(31), (g)(32), and (g)(33) we are finalizing in this rule related to electronic prior authorization. For example, we believe that certified health IT developers with Health IT Modules certified to any of the criteria (g)(31) through (g)(33) ought to abide existing requirements at 45 CFR 170.404(a)(4) for openness and pro-competitive conditions. However, as we discuss further below, we believe that service base URL publication requirements at 45 CFR 170.404(b)(2) should not be applied to the criterion at 45 CFR 170.315(g)(32). We believe this targeted approach will address commenters who saw value in some of the requirements in 45 CFR 170.404, such as the transparency requirements, but were concerned with other requirements.

While we understand there are transparency requirements in the recent CMS Interoperability and Prior Authorization rule for specified payers, we do not believe our requirements for certified health IT developers subject to requirements at 45 CFR 170.404 are duplicative. Primarily, we believe there is no duplication because we are not, at this time, finalizing proposed requirements for Health IT Modules intended for use by payers covered by the CMS Interoperability and Prior Authorization rule. The requirements at 45 CFR 170.404(a)(2) for transparency are applicable to Certified API Developers with Health IT Modules certified in 45 CFR 170.315(g)(7) through (10), and, as we are finalizing in this rule, (g)(31), (g)(32), and (g)(33). These criteria are not intended for certification of health IT used by payers subject to the CMS Interoperability and Prior Authorization rule.

In regard to concerns with the fees conditions we acknowledge and agree that the electronic prior authorization criteria are not simple query and retrieve functions but rather complex, multi-step, bidirectional conversation between multiple systems. However, we disagree that the fee conditions would prohibit developers from generating revenue to a degree that would deter developers from building and supplying these APIs to customers. We note that several fees are explicitly permitted in 45 CFR 170.404(a)(3)(ii) through (iv) to recover costs associated with deployment, API usage, and value-added services. We refer interested parties to the finalized policies related to these permitted fees and the wider set of fees conditions at 45 CFR 170.404(a)(3) in the ONC Cures Act Final Rule (85 FR 25755).

Comment: Other commenters supported ASTP/ONC's extension of new capabilities to the Conditions of Certification and Maintenance of Certification requirements as a means of ensuring Health IT Modules not only implement capabilities, but continue to maintain these capabilities and ensure patients, providers, and payers are able to take advantage of their benefits.

Response: We thank commenters for their support.

After consideration of the public comment, we are finalizing our proposals, with modification. We are finalizing regulation text at 45 CFR 170.404 to include the phrase “unless otherwise specified in this section,” as proposed. This amendment enables the Certification Program to specify requirements in different subparagraphs

to pertain to different API-based certification criteria. Given that we are adopting in this final rule API-based certification criteria that require Health IT Module support for server capabilities at 45 CFR 170.315(g)(31) and client capabilities at 45 CFR 170.315(g)(32) and (33), not all requirements in 45 CFR 170.404 are relevant or would be appropriate for both types of capabilities. For example, the requirements at 45 CFR 170.404(b)(2) for publicly publishing FHIR endpoints belonging to a developer of certified health IT's customers is not relevant for Health IT Modules that support client capabilities, such as certified health IT that is certified to the criterion in 45 CFR 170.315(g)(32).

We are finalizing to add references to the certification criteria at 45 CFR 170.315(g)(31), (g)(32), and (g)(33) to the introductory text at 45 CFR 170.404. Consistent with prior discussion of finalizing multiple criteria to represent the capabilities we proposed in a single criterion in 45 CFR 170.315(g)(34), adding 45 CFR 170.315(g)(31), (g)(32), and (g)(33) to this introductory text would be equivalent to our proposal to include 45 CFR 170.315(g)(34) in the regulation text at 45 CFR 170.404. The addition of these references to the introductory text of 45 CFR 170.404 means that Health IT Modules certified to 45 CFR 170.315(g)(31), (g)(32), and (g)(33) are subject to all requirements listed in 45 CFR 170.404(a)(1) through (4), including fees conditions and openness and pro-competitive conditions, unless otherwise specified.

We are finalizing the addition of 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33) at 45 CFR 170.404(b)(1) and 45 CFR 170.404(b)(1)(i). This is similar to what we proposed in the HTI-2 Proposed Rule because the relevant API Condition and Maintenance of Certification requirements in 45 CFR 170.404 will apply to Health IT Modules certified to the new certification criteria for API technology being finalized in 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33) that reflect capabilities included in the originally proposed “prior authorization API--provider” criterion in 45 CFR 170.315(g)(34).

However, we are not finalizing to apply the API Condition and Maintenance of Certification requirements in 45 CFR 170.404(b)(1) to the new certification criterion in 45 CFR 170.315(g)(32) because the authenticity verification and registration for production use requirements under 45 CFR 170.404(b)(1) are not applicable to Health IT Modules certified to 45 CFR 170.315(g)(32). A Health IT Module certified to 45 CFR 170.315(g)(32) supports only client capabilities and is not publishing an API endpoint for applications to register with as part of supporting the “Full DTR EHR” capabilities in at least one of the IGs adopted at 45 CFR 170.215(j)(2).

We did not receive any substantive comments regarding our revisions to the definitions for the terms certified API technology and Certified API Developer. However, we are finalizing a revision to the key term as proposed for “Certified API developer,” by removing the duplicative references to criteria in the key term for “certified API technology.” We are also finalizing the key term for “certified API technology,” consistent with what we proposed by including capabilities of Health IT Modules that are certified to certification criteria adopted in 45 CFR 170.315(g)(31), (32), and (33). This will ensure consistent application of these key terms throughout regulation text in 45 CFR 170.404.

We are not finalizing any of the other proposals in the HTI-2 proposed rule for changes to the regulatory text at 45 CFR 170.404(a) and 45 CFR 170.404(b) at this time. (e) Revisions to Real World Testing Requirements

The Cures Act requires, as Condition and Maintenance of Certification requirements under the Certification Program, that health IT developers successfully test the real world use of the technology for interoperability \488\ in the type of setting in which such technology would be marketed. As discussed in the ONC Cures Act Final Rule, the objective of real world testing is to verify the extent to which certified health IT deployed in production contexts continues to demonstrate conformance to the full scope of applicable certification criteria and functions with the intended use cases as part of the overall maintenance of a health IT's certification (85 FR 25766).

\488\ Interoperability is defined in statute in section 3000 of the Public Health Service Act (as modified by section 4003 of the Cures Act) and defined in regulation at 45 CFR 170.102.

In the HTI-2 Proposed Rule (89 FR 63594) we discussed that for reasons similar to our proposal to expand requirements in 45 CFR 170.404 to the proposed certification criteria in 45 CFR 170.315(g)(20), (g)(30) through (36), and 170.315(j), we proposed to revise the real world testing requirements in 45 CFR 170.405 by adding these proposed certification criteria in 45 CFR 170.405(a). Given that each of these proposed new certification criteria is focused on interoperability and data exchange, we stated we believe it is important that developers of certified health IT with Health IT Module(s) certified to these criteria participate in both Condition and Maintenance of Certification requirements. Per requirements in 45 CFR 170.405(b), we also proposed that developers of certified health IT with Health IT Modules certified to any one or more of the certification criteria in 45 CFR 170.315(g)(20), (g)(30) through (36), and 170.315(j) also submit annual real world testing plans as well as annual real world testing results, which applies to any one or more of the criteria referenced in 170.405(a). We noted that by including these criteria in 45 CFR 170.405(a) that health IT developers may voluntarily avail themselves of SVAP flexibility so long as they ensure that their annual real world testing plans and real world testing results submissions address all the versions of all the standards and implementation specifications to which each Health IT Module is certified. Under the narrow scope of this final rule, we are only finalizing policies based on our proposal to reference the criterion at 45 CFR 170.315(g)(34) (which was included in our proposal to reference criteria in (g)(30) through (36) in 45 CFR 170.405(a)), and our proposals to reference criteria in 45 CFR 170.315(j)(20) and 45 CFR 170.315(j)(24) (included in our proposal to reference criteria in 170.315(j) in 45 CFR 170.405(a)), to the real world testing requirements in 45 CFR 170.405.

The following is a summary of the comments we received and our responses:

Comment: Comments were mixed on the inclusion of certification criteria related to prior authorization as part of real world testing requirements at 45 CFR 170.405. Some commenters supported our proposal to include prior authorization criteria as part of real world testing because they believed real world testing requirements are critical to ensure products and standards facilitate the intended uses without negative, unintended uses. Other commenters did not believe that real world testing requirements should be applied to electronic prior authorization criteria, noting that payers are already required under the CMS Interoperability and Prior Authorization rule to report annual metrics.

Response: We thank commenters for their support and acknowledge those commenters who considered real world testing requirements at 45 CFR 170.405 duplicative of CMS requirements for impacted payers subject to the CMS

Interoperability and Prior Authorization rule. Respectfully, we disagree that requirements at 45 CFR 170.405 are duplicative of CMS requirements. Certification criteria established at 45 CFR 170.315(g)(31) through (33) are intended to support providers engaging in prior authorization workflows and real world testing requirements apply to Health IT Modules specified at 45 CFR 170.405(a) and the performance of these Health IT Modules in real-world clinical settings. These requirements do not overlap with the metrics CMS finalized for impacted payers to report on how payers are conducting prior authorization processes (89 FR 8889).

After consideration of public comments, we are finalizing updates to 45 CFR 170.405(a) to include the criteria in 45 CFR 170.315(g)(31), (g)(32), and (g)(33). We did not receive any comments regarding the proposed inclusion of criteria in 45 CFR 170.315(j)(20) and 45 CFR 170.315(j)(24) (which we are finalizing in this rule in 45 CFR 170.315(21)) as part of real world testing requirements at 45 CFR 170.405, and we are finalizing our proposal to include these criteria. We remind interested parties that inclusion of these criteria at 45 CFR 170.405(a) makes it possible for developers of certified health IT with Health IT Modules certified to these certification criteria to use SVAP to certify their Health IT Modules to newer versions of adopted standards referenced in these criteria. (f) Addition of Criteria to the Base EHR Definition

In the HTI-2 Proposed Rule, we noted that the “prior authorization API--provider” certification criteria in 45 CFR 170.315(g)(34) pertains to certified Health IT Modules intended for use by healthcare providers. We stated we believe this certification criterion reflects fundamental capabilities, which would be appropriate for adoption by any healthcare provider using certified health IT. We noted that technology certified to the “prior authorization API--provider” criterion would enable a healthcare provider to conduct prior authorization requests and related interactions with payers that are widely used today.

We proposed to include the certification criterion 45 CFR 170.315(g)(34) to the set of certification criteria adopted by the Secretary that are necessary to meet the Base EHR definition. For the “prior authorization API--provider” certification criterion in 45 CFR 170.315(g)(34), we proposed that this criterion would be necessary to meet the Base EHR definition on and after January 1, 2027. We stated that this date is consistent with the Electronic Prior Authorization measures CMS finalized for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, which program participants must report beginning with the CY 2027 EHR reporting period and CY 2027 performance period/2029 MIPS payment year, respectively (89 FR 8910).

The following is a summary of the comments we received and our responses:

Comment: A number of commenters supported our proposal to add the “prior authorization API--provider” to the Base EHR definition in 45 CFR 170.102, stating that developers must provide and support these Health IT Modules in order for clinicians to experience the benefits of electronic prior authorization. Some commenters also supported our proposal to add the “prior authorization API--provider” as of January 1, 2027, stating this would be necessary in order to align with CMS reporting requirements for the Electronic Prior Authorization measures finalized for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category.

Response: We appreciate commenters' support.

Comment: Other commenters did not agree with our proposal to include the proposed “prior authorization API--provider” criterion in the Base EHR definition. These commenters stated that inclusion in the Base EHR definition would be premature, requiring the functionality as part of certified health IT before some providers are ready to use the functionality. Commenters recommended that ASTP/ONC only add the “prior authorization API--provider” criterion to the Base EHR definition once APIs based on the relevant standards have been widely adopted across payers.

Response: We appreciate commenters' concerns with our proposal to add the “prior authorization API--provider” criterion to the Base EHR definition at 45 CFR 170.102. We agree with commenters that healthcare providers' ability to use the functionality represented by these criteria is contingent upon payers implementing corresponding APIs that can exchange prior authorization information with healthcare providers. In addition, while CMS has finalized requirements for impacted payers to establish Prior Authorization APIs in the Interoperability and Prior Authorization final rule, it is possible that some healthcare providers that purchase a health IT product meeting the Base EHR definition would not submit prior authorization requests to any of the impacted payers under the CMS rule. We further agree that given current usage of these solutions, it may be more appropriate to add this criterion to the Base EHR definition once payer APIs meeting CMS' requirements have been widely implemented. Finally, we note that electronic prior authorization is not identified as a required capability for a “qualified EHR” under the definition of that term in section 3000 of the PHSA, which serves as the basis for the Base EHR definition as currently established by ASTP/ONC (77 FR 54262).

Comment: A number of commenters did not support our proposal to include the “prior authorization API--provider” criterion in the Base EHR definition as of January 1, 2027. Commenters that opposed this proposal noted that implementation of the capabilities reflected in the criterion will require a significant amount of development work for health IT developers, as well as substantial time to roll out new functionality to customers. Another commenter noted that the IGs we proposed to reference in the criterion contain ambiguous requirements, and that resolving this ambiguity will require additional development time, recommending that ASTP/ONC delay the deadline for inclusion in the Base EHR definition to January 1, 2028. Commenters acknowledged that the January 1, 2027, deadline was chosen in order to align with the January 1, 2027, deadline that CMS has finalized for impacted payers to establish the API requirements finalized in the Interoperability and Prior Authorization final rule. However, they contended that due to the challenges described in meeting this deadline, ASTP/ONC should work with CMS to delay these deadlines to January 1, 2028.

Response: We appreciate commenters' concerns regarding the proposed deadline of January 1, 2027, for inclusion of the “prior authorization API--provider” criterion in the Base EHR definition. We acknowledge that the proposed date of January 1, 2027 was intended to align with both CMS requirements for the implementation of Prior Authorization APIs by impacted payers, and that implementation of these electronic prior authorization capabilities may require novel development work for health IT developers.

As discussed previously, CMS has finalized that participants in the Medicare Promoting Interoperability

Program and the MIPS Promoting Interoperability performance category must report on the respective Electronic Prior Authorization measure included in these programs in an EHR reporting period in CY 2027 or the CY 2027 performance period/2029 MIPS payment year, respectively. The criteria we are finalizing in this rule in 45 CFR 170.315(g)(31), (32), and (33) specify requirements for certified Health IT Modules to enable eligible hospitals, CAHs, and eligible clinicians to interact with the payer Prior Authorization APIs from which these providers and clinicians must request prior authorization in order to complete the action specified in the measures. We will work with CMS to continue to monitor timelines related to the use of certified health IT in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category.

After consideration of the public comment, we are not finalizing the proposed inclusion in the Base EHR definition of the “prior authorization API--provider” criterion. We further clarify that we are also not finalizing to add to the Base EHR definition the three electronic prior authorization criteria in 45 CFR 170.315(g)(31), (32), and (33) that we are finalizing in this rule based on the proposed “prior authorization API--provider” criterion. As a result of not finalizing any updates to the Base EHR definition, we are also not finalizing a date of January 1, 2027, for inclusion in the Base EHR definition. (g) Additional Implementation Specifications for Provider, Patient, and Payer APIs

In the HTI-2 Proposed Rule, we proposed to adopt API implementation specifications, on behalf of the Secretary, in 45 CFR 170.215(k), (m), and (n), and make these specifications available for HHS use. At the same time, we proposed health IT certification criteria in 45 CFR 170.315(g)(30) through (36) which incorporated these implementation specifications into certification requirements under the Certification Program. In this final rule we are only finalizing criteria (at 45 CFR 170.315(31), (32), and (33)) based on the proposed “prior authorization API--provider” criterion in 45 CFR 170.315(34). However, as discussed in the proposed rule, these implementation specifications address certain use cases for exchange of health information independent of inclusion in a certified Health IT Module, and we therefore proposed to adopt these implementation specifications under PHSA section 3004 to make them available for HHS use.\489\

\489\ See, for example, 89 FR 63582 for discussion of the proposed criterion at 45 CFR[thinsp]170.315(g)(30) and the benefits of the IG proposed for adoption in 45 CFR[thinsp]170.215(m).

In the HTI-2 Proposed Rule (89 FR 63582), we proposed to adopt the HL7 FHIR[supreg] Da Vinci--Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1--STU 2 (PDex US Drug Formulary IG) \490\ in 45 CFR[thinsp]170.215(m)(1) and incorporate it by reference in 45 CFR[thinsp]170.299(g). We proposed to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. We stated that this implementation specification can enable consumers, members, and patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans.

\490\ See https://hl7.org/fhir/us/davinci-drug-formulary/STU2.0.1/.

We proposed to adopt the HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.0.0--STU2 \491\ in 45 CFR[thinsp]170.215(k)(2)(i) and incorporate it by reference in 45 CFR[thinsp]170.299(g) (89 FR 63582 and 63583). We proposed to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. This implementation specification enables a payer to create a member's health history using clinical resources based on US Core profiles. We noted that a version 2.1.0 of the PDex IG was under development and available for interested parties to review at the time of the proposed rule.\492\ We proposed as an alternative to adopt PDex IG version 2.1.0 if the standard is balloted and published before the issuance of this final rule. We noted several important enhancements in the PDex IG version 2.1.0 to align with the Interoperability and Patient Access Final Rule (85 FR 25522 through 25569) and the Interoperability and Prior Authorization Final Rule (89 FR 8768 through 8946). For example, we noted that version 2.1.0 supports US Core 6.1.0, which supports USCDI v3, as well as drops required support for aspects of prior authorization that are viewed as unnecessary or complicating to successful execution of the transaction in version 2.0.0 of the PDex IG. We also stated that version 2.1.0 includes an important use case for bulk data access based on the finalization of the Bulk Data Access IG as a required standard under the Payer API requirements finalized in CMS' rules. We stated that continued alignment among industry, government, and standards development organizations involved with the payer data exchange use cases is necessary and we stated that if PDex IG version 2.1.0 was balloted and published before issuance of this final rule, adoption of version 2.1.0 would support such alignment.

\491\ See https://hl7.org/fhir/us/davinci-pdex/STU2/.

\492\ See https://build.fhir.org/ig/HL7/davinci-epdx/.

We further proposed to adopt the HL7 FHIR[supreg] CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button[supreg]) Implementation Guide version 2.0.0--STU 2 \493\ in 45 CFR[thinsp]170.215(k)(1)(i) and incorporate it by reference in 45 CFR[thinsp]170.299(g) (89 FR 63583-63584). We proposed to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. We stated that this implementation specification supports providing a set of resources that payers can display to consumers, primarily financial (claims and encounter) data, with some limited associated clinical data.

\493\ See https://hl7.org/fhir/us/carin-bb/.

We proposed to adopt the HL7 FHIR Da Vinci Payer Data Exchange Plan Net implementation specification in 45 CFR[thinsp]170.215(n)(1) and incorporate it by reference in 45 CFR[thinsp]170.299(g) (89 FR 63592). We proposed to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. Use of this implementation specification can enable third parties to develop applications through which consumers and providers can query the participants in a payer's network that may provide services that address their healthcare needs.

The following is a summary of the comments we received and our responses.

Comment: A commenter expressed support for our proposal to adopt the CARIN IG for Blue Button, stating that the IG brings value to consumers seeking to access their health information and to payers working to provide such access, and noting that the CARIN IG for Blue Button has already been identified as part of meeting federal requirements. Another commenter supported the use of the CARIN IG for Blue Button as well as the proposed Da Vinci PDex IG to support standardization and effective data exchange across payers, providers, and patients, noting that these implementation guides could enable better data access that will be beneficial for children and families with complex care and coverage circumstances. A

commenter supported the adoption of the PDex US Drug Formulary IG. Several commenters expressed support for ASTP/ONC's proposal to adopt the PDex Plan Net IG, stating that this IG would help to improve the interoperability of provider directory information.

Response: We appreciate the support from commenters for these proposals.

Comment: Several commenters recommended adopting new versions of the IGs proposed in the HTI-2 Proposed Rule. Specifically, commenters recommended adopting the PDex IG version 2.1.0 and version 2.1.0 of the CARIN IG for Blue Button. A commenter recommended that ASTP/ONC work with CMS and standards development bodies to ensure that the most updated versions of the standards are adopted and to develop an ongoing versioning strategy.

Response: We appreciate commenters' recommendations regarding the adoption of newer versions of certain proposed specifications that have been released subsequent to the HTI-2 proposed rule.

We have been anticipating publication of version 2.1.0 of the PDex IG and described its many important benefits in the HTI-2 Proposed Rule.\494\ Given the number of substantial and important updates included in the version 2.1.0 of the PDex IG, and the several commenters supportive of our alternative proposal to adopt 2.1.0, we believe there are strong reasons to finalize adoption of version 2.1.0. In addition to the benefits afforded by the newer version, finalization of the 2.1.0 version of the PDex IG will help avoid industry burden and sunk costs in comparison to our proposed adoption of version 2.0.0 of the IG, which was the version of the IG available at the time of the publication of the proposed rule. Finally, the 2.1.0 version of the PDex IG includes important updates to better implement requirements finalized by CMS in the Interoperability and Prior Authorization final rule. While CMS currently recommends use of the PDex IG in the final rule, CMS has stated that they may consider requiring this and other recommended standards in the future, similar to current requirements to use standards adopted in 45 CFR 170.215 and 45 CFR 170.213 (89 FR 8939 through 8941). We believe that adopting the 2.1.0 version of the IG at this time could support future CMS requirements.

Regarding updates to the other proposed standards, we note that an updated 2.1.0 version of the CARIN IG for Blue Button, which was also identified by commenters, was published on February 18, 2025. We agree with commenters that updated versions of these specifications may include important updates to align with newer versions of supporting standards, and ongoing changes that reflect the standards development community's efforts to incrementally improve these specifications. Unlike the PDex IG proposal, we did not propose an alternate proposal to adopt the CARIN IG for Blue Button version 2.1.0. We only proposed version 2.0.0. Accordingly, we believe it is most appropriate to adopt the versions of the CARIN IG and the other specifications that we proposed in the HTI-2 Proposed Rule. We note that ASTP/ONC will monitor future versions of these specifications.

After consideration of the public comment, we are adopting the following implementation specifications in 45 CFR 170.215 and incorporating them by reference in 45 CFR 170.299(g):

HL7 FHIR[supreg] CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button[supreg]) Implementation Guide, Version 2.0.0--STU 2 US (45 CFR[thinsp]170.215(k)(1)(i).

HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.1.0--STU 2.1 (45 CFR[thinsp]170.215(k)(2)(i)).

HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1--STU2 (45 CFR[thinsp]170.215(m)(1)).

HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0--STU1.1 US (45 CFR 170.215(n)(1)).

We reiterate that at this time we are not finalizing the health IT certification criteria we proposed in the HTI-2 Proposed Rule that referenced these implementation specifications. Rather, as proposed, we are finalizing adoption of these implementation specifications under PHSA section 3004 for HHS use. (7) Corrections for HTI-2 Final Rule

In Federal Register document 2024-29163 (89 FR 101772) final rule titled “Health Data, Technology, and Interoperability: Trusted Exchange Framework and Common Agreement” (HTI-2) (hereinafter referred to as the HTI-2 Final Rule), we identified certain technical and typographical errors following publication in the Federal Register on December 16, 2024. a. Summary of Errors

In the ONC Cures Act Final Rule, we finalized 45 CFR 170.550(m) “time-limited certification and certification status for certain 2015 Edition certification criteria,” which provided that for five specific certification criteria, an ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for a specified time period (85 FR 25952). The five criteria with time-limited certification and certification status were “drug-formulary and preferred drug list checks” certification criterion (45 CFR 170.315(a)(10)), “patient-specific education resources” (45 CFR 170.315(a)(13)), “data export” certification criterion (45 CFR 170.315 (b)(6)), “secure messaging” certification criterion (45 CFR 170.315(e)(2)), and “application access--data category request” (45 CFR 170.315(g)(8)). Because the specified time periods for certification to these criteria have elapsed, we noted in the preamble of the HTI-2 Proposed Rule that we proposed to remove all of the certification criteria referenced in 45 CFR 170.550(m) in one action by removing 45 CFR 170.550(m) in its entirety (89 FR 63615 through 63616). In the HTI-2 Final Rule, we also removed and reserved these aforementioned certification criteria from the specific CFR locations in which they were adopted (89 FR 101776 through 101777). However, we inadvertently included a reference to 45 CFR 170.315(g)(2) to remove and reserve in the amendatory instructions for 45 CFR 170.315 (89 FR 101809) when it should read 45 CFR 170.315(g)(8). We also inadvertently omitted from amendatory instruction for 45 CFR 170.550(m) (89 FR 101810), an instruction to remove 45 CFR 170.550(m).

In the HTI-2 Final Rule (89 FR 101776) preamble, we intended to finalize as proposed removal and reservation of 45 CFR 170.315(g)(8). However, we erroneously included a reference to 45 CFR 170.315(g)(2) instead of 45 CFR 170.315(g)(8) in the amendatory instructions, which resulted in the removal of 45 CFR 170.315(g)(2) and retention of 45 CFR 170.315(g)(8) (89 FR 101809). We therefore add 45 CFR 170.315(g)(2) back into the CFR and remove 45 CFR 170.315(g)(8) to address this error. Section 170.315(g)(2) refers to automated measure calculation. The language to be inserted into the CFR is “Automated measure calculation. For each Promoting Interoperability Programs percentage- based measure that is supported by a capability included in a technology, record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable measure.”

In the HTI-2 Final Rule (89 FR 101776) preamble, we also intended to finalize as proposed the removal of 45

CFR 170.550(m). However, we omitted the amendatory language instructing the Office of the Federal Register to remove 45 CFR 170.550(m) in the regulatory text. b. Waiver of Proposed Rulemaking, Comment Period, and Delay in Effective Date

Under 5 U.S.C. 553(b) of the Administrative Procedure Act (APA), the agency is required to publish a notice of the proposed rulemaking in the Federal Register before the provisions of a rule take effect. In addition, section 553(d) of the APA mandates a 30-day delay in effective date after issuance or publication of a rule. Sections 553(b)(B) and 553(d)(3) of the APA provide for exceptions from the notice and comment and delay in effective date requirements. Section 553(b)(B) of the APA provides an exception to the requirement that an agency publish a notice of proposed rulemaking in the Federal Register for good cause if the agency makes and incorporates a finding, to include a brief statement of reasons, that the notice and comment process are impracticable, unnecessary, or contrary to the public interest. In addition, section 553(d)(3) of the APA allows the agency to avoid the 30-day delay in effective date for good cause and where the agency includes a statement of support.

We believe this correction does not constitute a rule that would be subject to the APA notice and comment or delayed effective date requirements. This document corrects technical and typographical errors in the preamble and regulation text of the HTI-2 Final Rule, but it does not make substantive changes to the policies that were adopted in the HTI-2 Final Rule. As a result, this correction is intended to ensure that the information in the HTI-2 Final Rule accurately reflects the policies adopted in that document.

In addition, even if this were a rule to which the notice and comment procedures and delayed effective date requirements applied, we find that there is good cause to waive such procedures and requirements. Undertaking further notice and comment procedures to incorporate the corrections in this document into the HTI-2 Final Rule would be contrary to the public interest because it is in the public's interest for entities to receive accurate information regarding the relevant policies, and these corrections ensure the HTI-2 Final Rule reflects the policies laid out in the ONC Cures Act and HTI-2 Final Rules. This correction is intended solely to ensure that the HTI-2 Final Rule accurately reflects applicable law, and the policies finalized in the HTI-2 Final Rule. Therefore, we believe we have good cause to waive the notice and comment and effective date requirements. (8) Incorporation by Reference

The Office of the Federal Register has established requirements for materials (for example, standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). Specifically, Sec. 51.5(b)(2) requires agencies to discuss, in the preamble of a final rule, the ways that the materials they incorporate by reference are reasonably available to interested parties and how interested parties can obtain the materials; and summarize, in the preamble of the final rule, the material they incorporate by reference.

To make the materials we intend to incorporate by reference reasonably available, we provide a uniform resource locator (URL) for the standards and implementation specifications. In many cases, these standards and implementation specifications are directly accessible through the URLs provided. In most of these instances, access to the standard or implementation specification can be gained through no-cost (monetary) participation, subscription, or membership with the applicable standards developing organization (SDO) or custodial organization. Alternatively, a copy of the standards may be viewed for free at the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201. Please call (202) 690-7171 in advance to arrange inspection.

The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A-119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. As discussed in section III.A.1 of the HTI-2 Proposed Rule, we have followed the NTTAA and OMB Circular A-119 in proposing standards and implementation specifications for adoption, including describing any exceptions in the proposed adoption of standards and implementation specifications (89 FR 63514). Over the years of adopting standards and implementation specifications for certification, we have worked with SDOs, such as HL7, to make the standards we propose to adopt, and subsequently adopt and incorporate by reference in the Federal Register, available to interested parties. As described previously, this includes making the standards and implementation specifications available through no-cost memberships and no-cost subscriptions.

As required by Sec. 51.5(b), we provide summaries of the standards we are adopting and incorporating by reference in the Code of Federal Regulations. We also provide relevant information about these standards and implementation specifications throughout the preamble.

We have organized the following standards and implementation specifications that we are adopting through this rulemaking according to the sections of the Code of Federal Regulations (CFR) in which they would be codified and cross-referenced for associated certification criteria and requirements that we are adopting. (a) Vocabulary Standards for Representing Electronic Health Information--45 CFR 170.207

RxNorm, December 4, 2023, Full Update Release.

URL: https://www.nlm.nih.gov/research/umls/rxnorm/docs/rxnormarchive.html Access requires a user account and license agreement. There is no monetary cost for a user account and license agreement.

Summary: RxNorm, a standardized nomenclature for clinical drugs, is produced by the National Library of Medicine. RxNorm's standard identifiers and names for clinical drugs are connected to the varying names of drugs present in many different controlled vocabularies within the Unified Medical Language System (UMLS) Metathesaurus, including those in commercially available drug information sources. These connections are intended to facilitate interoperability among the computerized systems that record or process data dealing with clinical drugs. (b) Application Programming Interface Standards--45 CFR 170.215

HL7 FHIR[supreg] CDS Hooks Implementation Guide, Version 2.0.1--STU 2 Release 2, March 12, 2025.

URL: https://cds-hooks.hl7.org/STU2/ This is a direct access link.

Summary: This HL7 FHIR[supreg] CDS Hooks Implementation Guide describes a “hook” based pattern for invoking clinical decision support (CDS) from within a clinician's workflow. The APIs described in the specification support synchronous, workflow-triggered CDS calls returning information and suggestions, and launching a user-facing SMART app when CDS requires additional interaction.

HL7 FHIR[supreg] Subscriptions R5 Backport Implementation Guide, Version 1.1.0--Standard for Trial Use, draft as of January 11, 2023.

URL: https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/ This is a direct access link.

Summary: The Subscription R5 Backport Implementation Guide enables servers running versions of FHIR earlier than R5 to implement a subset of R5 Subscriptions in a standardized way. During the development of FHIR R5, the Subscriptions Framework has gone through a significant redesign. Many implementers have expressed a need for functionality from the FHIR R5 version of Subscriptions to be made available in FHIR R4. The goal of publishing the Subscription R5 Backport Implementation Guide is to define a standard method of back-porting the R5 Subscriptions Framework for greater compatibility and adoption by systems leveraging an early version of FHIR (that is, FHIR R4).

HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.1.0--STU 2.1, June 18, 2025.

URL:https://hl7.org/fhir/us/davinci-pdex/STU2.1/ This is a direct access link.

Summary: The Payer Data Exchange (PDex) Implementation Guide is provided for payers/health plans to enable them to create a Member's Health History using clinical resources (based on US Core Profiles established from FHIR R4) which can be understood by providers and, if they choose to, committed to their Electronic Medical Records (EMR) System.

HL7 FHIR[supreg] Da Vinci--Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1--STU 2, January 8, 2024.

URL:https://hl7.org/fhir/us/davinci-crd/STU2/ This is a direct access link.

Summary: The Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide defines a workflow to allow payers to provide information about coverage requirements to healthcare providers through their provider systems at the time treatment decisions are being made. This will ensure that clinicians and administrative staff have the capability to make informed decisions and meet the requirements of the patient's insurance coverage.

HL7 FHIR[supreg] Da Vinci--Documentation Templates and Rules (DTR) Implementation Guide, Version 2.0.1--STU 2, January 11, 2024.

URL:https://hl7.org/fhir/us/davinci-dtr/STU2/ This is a direct access link.

Summary: The Da Vinci Documentation Templates and Rules (DTR) Implementation Guide provides a mechanism for payers to express their documentation requirements computably in a way that allows clinicians and other EHR users to navigate and quickly specify the needed information in a context-specific way. The guide allows rules to be written in a way that supports automatically extracting existing EHR information for review/confirmation and adjusting the information prompted for based on what data is already known or entered, minimizing impact on provider time, while expediting subsequent payer interactions.

HL7 FHIR[supreg] Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.0.1--STU 2, December 1, 2023.

URL: https://hl7.org/fhir/us/davinci-pas/STU2/ This is a direct access link.

Summary: The Da Vinci Prior Authorization Support (PAS) Implementation Guide enables direct submission of prior authorization requests from EHR systems using FHIR. The implementation guide also defines capabilities around the management of prior authorization requests, including checking the status of a previously submitted request, updating a previously submitted request, and canceling a request. Direct submission of prior authorization requests from the EHR can result in faster prior authorization decisions, reducing costs for both providers and payers and improving patient experience.

HL7 FHIR[supreg] CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button[supreg]) Implementation Guide, Version 2.0.0--STU 2 US, November 28, 2022.

URL: https://hl7.org/fhir/us/carin-bb/STU2/ This is a direct access link.

Summary: This implementation guide describes the CARIN for Blue Button[supreg] Framework and Common Payer Consumer Data Set (CPCDS), providing a set of resources that payers can display to consumers via a FHIR API. The CARIN for Blue Button IG was defined by the CARIN Alliance to meet the requirements in the CMS Interoperability and Patient Access final rule for impacted payers to make available claims and encounter data via a Patient Access API. This IG is primarily used to exchange financial (claims and encounter) data, with some limited associated clinical data.

HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1--STU 2, December 1, 2023.

URL: https://hl7.org/fhir/us/davinci-drug-formulary/STU2.0.1/ This is a direct access link.

Summary: This implementation guide defines a FHIR interface to a health insurer's drug formulary information for patients/consumers. The primary use cases for this FHIR interface enable consumers/members/ patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans.

HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0--STU1.1 US, April 4, 2022.

URL: https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.1/ This is a direct access link.

Summary: This implementation guide defines a FHIR interface to access information about a health insurer's insurance plans, their associated networks, and the organizations and providers that participate in these networks. Publication of this data through a standard FHIR-based API will enable third parties to develop applications through which consumers and providers can query the participants in a payer's network that may provide services that address their healthcare needs.

C. Finalization of Interim Final Action With Comment Period on the Changes to the Fiscal Year 2025 Hospital IPPS Rates Due to Court Decision (CMS-1808-IFC)

In the interim final action with comment period (IFC) (CMS-1808- IFC), that appeared in the October 3, 2024 Federal Register (89 FR 80405) (hereinafter referred to as the FY 2025 IFC), CMS implemented revised Medicare wage index values for FY 2025, established a transitional payment exception for low wage hospitals significantly impacted by those

revisions, and made conforming changes to the hospital IPPS payment rates for FY 2025. These changes reflect the removal of the low wage index hospital policy following the appellate court decision in Bridgeport Hosp. v. Becerra. That IFC also made conforming changes to IPPS rates and factors used to determine certain payments under the LTCH PPS for FY 2025. In this section of this final rule, we are responding to the public comments that we received on the FY 2025 IFC and finalizing the interim final policies established therein. 1. Provisions of the Interim Final Action With Comment Period a. Background

In the FY 2020 IPPS/LTCH PPS final rule (84 FR 42325 through 42339), we finalized a policy to address wage index disparities, based in part on comments we received in response to our request for information included in our FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20372 through 20377). In the FY 2020 IPPS/LTCH PPS final rule, based on those public comments and the growing disparities between wage index values for high- and low-wage-index hospitals, we explained that those growing disparities are likely caused, at least in part, by the use of historical wage data to prospectively set hospitals' wage indexes. That lag between when hospitals increase wages and when those wage increases are reflected in the historical data creates barriers to hospitals with low wage index values being able to increase employee compensation, because those hospitals will not receive corresponding increases in their Medicare payment for several years (84 FR 42327). Accordingly, we finalized a policy that provided certain low wage index hospitals with an opportunity to increase employee compensation without the usual lag in those increases being reflected in the calculation of the wage index (as they would expect to do if not for the lag).\495\ We accomplished this by temporarily increasing the wage index values for certain hospitals with low wage index values and doing so in a budget neutral manner through an adjustment applied to the standardized amounts for all hospitals. We increased the wage index for hospitals with a wage index value below the 25th percentile wage index value for a fiscal year by half the difference between the otherwise applicable final wage index value for a year for that hospital and the 25th percentile wage index value for that year across all hospitals (the low wage index hospital policy). As explained in the FY 2020 IPPS/LTCH PPS proposed rule (84 FR 19396) and final rule (84 FR 42329), we indicated that the Secretary has authority to implement the low wage index hospital policy proposal under both section 1886(d)(3)(E) of the Act and section 1886(d)(5)(I) of the Act.

\495\ In the FY 2020 IPPS/LTCH PPS proposed rule, we agreed with respondents to a previous request for information who indicated that some current wage index policies create barriers to hospitals with low wage index values from being able to increase employee compensation due to the lag between when hospitals increase the compensation and when those increases are reflected in the calculation of the wage index. We noted that this lag results from the fact that the wage index calculations rely on historical data. We also agreed that addressing this systemic issue did not need to wait for comprehensive wage index reform given the growing disparities between low and high wage index hospitals, including rural hospitals that may be in financial distress and facing potential closure (84 FR 19394 and 19395).

When we adopted the low wage index hospital policy in the FY 2020 IPPS/LTCH PPS final rule (84 FR 42326 through 42328), we stated our intention that this policy would be effective for at least 4 years, beginning in FY 2020, to allow employee compensation increases implemented by these hospitals sufficient time to be reflected in the wage index calculation. We also stated we intended to revisit the issue of the duration of this policy in future rulemaking as we gained experience under the policy. For FY 2024, we continued to apply the low wage index hospital policy and the related budget neutrality adjustment (88 FR 58977 through 58980). In the FY 2025 IPPS/LTCH PPS final rule (89 FR 69301 through 69308), we adopted an extension of the low wage index hospital policy and the related budget neutrality adjustment effective for at least three more years, beginning in FY 2025, in order for sufficient wage data from after the end of the COVID-19 Public Health Emergency to become available.

In that same FY 2025 IPPS/LTCH PPS final rule (89 FR 69302), we also noted that the FY 2020 low wage index hospital policy and the related budget neutrality adjustment are the subject of pending litigation in multiple courts, and that on July 23, 2024, the Court of Appeals for the D.C. Circuit held that the Secretary lacked authority under section 1886(d)(3)(E) of the Act or under the “adjustments” language of section 1886(d)(5)(I)(i) of the Act to adopt the low wage index hospital policy for FY 2020, and that the policy and related budget neutrality adjustment must be vacated. Bridgeport Hosp. v. Becerra, 108 F.4th 882, 887-91 & n.6 (D.C. Cir. 2024). We also stated that as of the date of that final rule's publication, the time to seek further review of the D.C. Circuit's decision in Bridgeport Hospital had not expired (see Fed. R. App. P. 40(a)(1)) and the government was evaluating the decision and considering options for next steps. b. Revised IPPS Wage Index Values for FY 2025 and Transitional Payment Exception for Low Wage Hospitals Significantly Impacted by Those Revisions

After considering the D.C. Circuit's decision in Bridgeport Hosp. v. Becerra, in the FY 2025 IFC we recalculated the IPPS hospital wage index to remove the low wage index hospital policy for FY 2025. Because we were now no longer applying the low wage index hospital policy in FY 2025, we also removed the low wage index budget neutrality factor from the FY 2025 standardized amounts. (89 FR 80407 through 80408).In the past, we have established temporary transition policies when there have been significant changes to payment policies, and we have limited the duration of each transition in order to phase in the effects of those payment policy changes. In taking this temporary approach in the past, we have sought to mitigate short-term instability and payment fluctuations that can negatively impact hospitals. For example, CMS has recognized that hospitals in certain areas may experience a negative impact on their IPPS payment due to the adoption of revised OMB delineations for wage index purposes and has finalized transition policies to mitigate negative financial impacts and provide stability to year-to-year wage index variations. We refer readers to the FY 2015 IPPS/LTCH PPS final rule (79 FR 49956 through 49962) for a discussion of the transition period finalized when CMS adopted revised OMB delineations after the 2010 decennial census. We stated in the FY 2025 IFC that for FY 2025, consistent with our past practice, we believe it is appropriate to establish a transition policy for hospitals significantly impacted by the removal of the FY 2025 low wage index hospital policy using our authority under section 1886(d)(5)(I) of the Act. Further, we discussed our current wage index cap policy at 42 CFR 412.64(h)(7), under which we apply a 5-percent cap on any decrease to a hospital's wage index from its wage index in the prior FY in a budget neutral manner, regardless of the circumstances causing the decline, so that a hospital's final wage index for the upcoming fiscal year will not be less than 95 percent of its final wage index from the prior fiscal year. In accordance with 42 CFR 412.64(e)(1)(ii), CMS applies a budget neutrality adjustment

to offset the increase in total payments resulting from the application of that cap (89 FR 80407).

As discussed in the FY 2025 IFC (89 FR 80407 through 80408), some hospitals that benefitted from the low wage index hospital policy previously will experience decreases of 5 percent or more from their FY 2024 wage index to the FY 2025 wage index established in that IFC. Similar to how 42 CFR 412.64(h)(7) operates, in that IFC we applied a one-time, transitional adjustment to create a narrow transitional exception to the calculation of FY 2025 payments. The wage index cap policy at 42 CFR 412.64(h)(7) would have mitigated these FY 2025 decreases but would have done so in a budget neutral manner under our current regulations. Because section 1886(d)(5)(I) of the Act lacks any general budget neutrality requirement, we stated that we are not required by the statute to budget neutralize this transition policy. In some circumstances CMS has exercised discretion under section 1886(d)(5)(I) of the Act twice over--first to adopt an exception or adjustment, and then again to make that exception and adjustment budget neutral.\496\ However, under the unique circumstances and due to the timing of the appellate court's decision so close to the beginning of FY 2025, we stated that we did not deem it appropriate to provide a second exception or adjustment that would budget neutralize the transition policy we were establishing in that IFC. Unlike most policies relevant to the calculation of the hospital wage index, the timing of the court's decision shortly before the beginning of the fiscal year necessitated swift action by the agency via an IFC, rather than providing for prior notice and opportunity for comment. We stated that the agency's action in the FY 2025 IFC was intended to promote certainty regarding FY 2025 IPPS payments in light of the reasoning of Bridgeport and its application to the low wage index hospital policy in FY 2025, which would create ongoing confusion for hospitals extending into FY 2025 about the amount of their IPPS payments and would constitute an inefficient use of agency resources. We stated that in this instance, the lack of an opportunity prior to the effective date for interested parties to comment on the transition policy weighs in favor of an approach that does not adversely affect the significant majority of hospitals. Because section 1886(d)(5)(I) lacks any general budget neutrality requirement, we stated that we are not required by the statute to budget neutralize this transition policy. For these reasons, we declined to budget neutralize the transition policy in this case.

\496\ For example, CMS has stated in the past that it would exercise its discretion under section 1886(d)(5)(I) of the Act to make the low wage index hospital policy budget neutral even if budget neutrality were not required by statute (88 FR 58979).

Therefore, in the FY 2025 IFC, we used our authority under section 1886(d)(5)(I)(i) of the Act to create a narrow transitional exception to the calculation of FY 2025 IPPS payments for low wage index hospitals significantly impacted by the removal of the low wage index hospital policy.497 498 The transitional exception policy established in that IFC applies to hospitals that benefitted from the FY 2024 low wage index hospital policy. For those hospitals, we compared the hospital's FY 2025 wage index established in the FY 2025 IFC to the hospital's FY 2024 wage index. If the hospital was significantly impacted by the removal of the low wage index hospital policy, meaning the hospital's FY 2025 wage index established in the FY 2025 IFC decreased by more than 5 percent from the hospital's FY 2024 wage index, then the transitional payment exception for FY 2025 for that hospital is equal to the additional FY 2025 amount the hospital would be paid under the IPPS if its FY 2025 wage index were equal to 95 percent of its FY 2024 wage index.\499\ For example, assume the FY 2024 wage index for a hospital that benefitted from the low wage index hospital policy was 0.7600, and the hospital's FY 2025 wage index established in the FY 2025 IFC was 0.7100. The hospital's FY 2025 wage index established in the FY 2025 IFC decreased by more than 5 percent from the hospital's FY 2024 wage index [that is, 0.7100 The outlier payment adjustment factor.

The portion of the budget neutrality adjustment factor for changes in the geographic adjustment factor (GAF) for the 5-percent cap on wage index decreases policy. (Under the provisions of the FY 2025 IFC, this factor would no longer reflect the low wage index hospital policy.)

In the FY 2025 IFC we discussed that, in general, these factors were calculated using the data and calculation methodology described in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69968 through 69971) with the FY 2025 IPPS/LTCH PPS final rule correction, except for the methodology for calculating the GAF budget neutrality factor which we modified to reflect the provisions of the IFC. We present a summary of these changes in the discussion that follows. For additional details, we refer readers to the FY 2025 IFC (89 FR 80411 through 80412). As discussed later in this section, we did not receive any comments on these changes and are finalizing them without modification. (1) Outlier Payment Adjustment Factor

A shared threshold is used to identify outlier cases for both inpatient operating and inpatient capital-related payments. In the FY 2025 IFC (89 FR 80411), we stated that based on the threshold discussed in section II.B. of that IFC, we estimated that prior to taking into account projected capital outlier reconciliation payments, outlier payments for capital-related costs will equal 4.26 percent of inpatient capital-related payments based on the capital Federal rate in FY 2025. We also stated that we estimate that taking into account projected capital outlier reconciliation payments will decrease the estimated percentage of FY 2025 capital outlier payments by 0.03 percent (as discussed in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69968). Therefore, accounting for estimated capital outlier reconciliation, the estimated outlier payments for capital-related PPS payments will equal 4.23 percent (4.26 percent-0.03 percent) of inpatient capital-related payments based on the capital Federal rate in FY 2025. Accordingly, in the FY 2025 IFC (89 FR 80411), we applied an outlier adjustment factor of 0.9577 in determining the capital Federal rate for FY 2025. As we noted in the FY 2025 IFC, although the unrounded FY 2025 outlier adjustment factor was revised because of the removal of the low wage index hospital policy and transitional payment exception, after rounding this factor to 4 decimal places, the rounded factor was unchanged from the final rule.

We received no comments on the FY 2025 outlier adjustment factor established in the FY 2025 IFC and are finalizing it in this final rule without modification. (2) Budget Neutrality Adjustment Factor for Changes in the GAF

The capital Federal rate is adjusted so that aggregate payments for the fiscal year based on the capital Federal rate, after any changes resulting from the annual DRG reclassification and recalibration and changes in the GAF, are projected to equal aggregate payments that would have been made on the basis of the capital Federal rate without such changes. In the FY 2025 IFC (89 FR 80412), we discussed that for FY 2025 we use a 2-step methodology for computing the budget neutrality factor for changes in the GAFs in light of the effect of wage index changes on the GAFs. In the first step, we first calculate a factor to ensure budget neutrality for changes to the GAFs due to the update to the wage data, wage index reclassifications and redesignations, and application of the rural floor policy, consistent with our historical GAF budget neutrality factor methodology. In the FY 2025 IFC, we stated that the provisions of the IFC did not impact this budget neutrality factor (0.9884). We also stated that the incremental adjustment factor for the FY 2025 MS-DRG reclassification and recalibration and for changes in the FY 2025 GAFs due to the update to the wage data, wage index reclassifications and redesignations, and application of the rural floor policy of 0.9854 is not impacted by the provisions of the FY 2025 IFC (89 FR 80412).

Due to the removal of the low wage index hospital policy (discussed previously and also referred to as the lowest quartile hospital wage index adjustment in the discussion of the 2-step methodology in the FY 2025 IPPS/

LTCH PPS final rule), in the FY 2025 IFC (89 FR 80412), we modified the second step of our 2-step methodology for computing the budget neutrality factor for changes in the GAFs in light of the effect of wage index changes on the GAFs. Specifically, we modified this budget neutrality factor to now ensure budget neutrality for changes to the GAFs due only to the 5-percent cap on wage index decreases policy. As discussed previously, we established a non-budget neutral transitional exception policy for hospitals that benefitted from the low wage index hospital policy during FY 2024. Hospitals that are eligible for the transitional exception policy are excepted from the wage index cap policy for FY 2025 under the provisions of the FY 2025 IFC. Therefore, due to the removal of the low wage index hospital policy, in the FY 2025 IFC (89 FR 80412), the second step of our calculation of the budget neutrality factor for changes in the GAFs in light of the effect of wage index changes on the GAFs only accounts for the application of the 5-percent cap on wage index decreases (for hospitals that did not receive the low wage index hospital policy adjustment in FY 2024). As described in that IFC, to achieve budget neutrality for the effects of the 5-percent cap on wage index decreases policy we calculated an incremental GAF budget neutrality adjustment factor of 0.9992.

We received no comments on the FY 2025 GAF budget neutrality adjustment factors established in the FY 2025 IFC and are finalizing them in this final rule without modification. (3) Capital Federal Rate for FY 2025

In the FY 2025 IFC (89 FR 80412), as a result of factors established in the FY 2025 IPPS/LTCH PPS final rule (89 FR 69971) with the FY 2025 IPPS/LTCH PPS final rule correction and the outlier adjustment factor and the budget neutrality factor for the effects of the 5-percent cap on wage index decreases established in that IFC (as discussed previously), we established a national capital Federal rate of $512.14 for FY 2025. We received no comments on the national capital Federal rate established in the FY 2025 IFC and are finalizing it in this final rule without modification. The national capital Federal rate for FY 2025 was calculated as shown in the following table. [GRAPHIC] [TIFF OMITTED] TR04AU25.320