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

Comment: Some commenters supported the measure concept of well- being. A commenter stated that the adoption of well-being would be beneficial in supporting patient care. A few commenters recommended CMS to work with nurses in quality reporting and the use of validated tools. Another commenter noted that well-being relates to SDOH and recommends CMS to consider and account for SDOH before implementing new measures.

Several commenters provided recommendations on assessing the concept of well-being. A few commenters noted that it will be difficult to define and measure the concept. The commenters also recommended that CMS consider a person-centered approach, a focus on supporting pathways in improving well-being, and mechanisms for auditing and transparency when considering well-being integration. Another commenter stated that well-being plays a key role in promoting health and recommends CMS to consider principles such as improving outcomes, meeting patient's needs and harmonized measures when considering new measures. A commenter recommended CMS to use malnutrition from the International Classification of Diseases, Tenth Revision, (ICD-10) coding, and available data on patient loneliness for consideration of the measure. The commenter also noted that CMS should consider mental and physical health of healthcare personnel. Another commenter offered a few recommendations on well-being including prioritizing patients and caregivers, focusing on outcomes important to patients, and allowing flexibility in measurement approaches. Another commenter recommended a technical expert panel to discuss the implementation of the well-being measure.

Some commenters were concerned about a well-being measure. A few noted that there is ambiguity in requirements and questioned how data for the measure will be used. A couple commenters noted that it was not clear how well-being would be assessed or how it is already captured under existing measures. Another commenter noted that the assessment of well-being would be better suited in community health outside of the hospital population. A commenter stated that well-being is a general concept and is difficult to assess without staff that are trained or have expertise in the concept. c. Nutrition

Comment: Several commenters stressed the importance of nutrition while also providing recommendations for CMS to consider. A commenter recommended that the measure should be evidence-based, actionable, and patient-centered. Another commenter recommended CMS to utilize the Malnutrition Care Score Electronic Clinical Quality Measure (eCQM)for the nutrition measure. A commenter noted that a nutrition-focus measure should reflect the role of Registered Dietitian Nutritionists (RDNs) in preventing and managing chronic diseases. A few commenters recommended CMS to consider SDOH elements when considering the nutrition measure. Another commenter recommended the nutrition measure to include patient's input, goals, and stage of life or illness. A commenter recommends that nutrition should include a screening for food insecurity and elements of SDOH. A commenter recommended using malnutrition ICD-10 codes and existing data to create a framework for nutrition while another commenter recommended CMS to use existing data elements to assess nutrition to reduce provider burden.

A few commenters voiced their concerns of a nutrition measure saying that nutrition is collected in the LCDS, or other existing measure assessments and a new measure would be redundant with the current data collection. d. Delirium

Comment: A few commenters voiced their support of the delirium measure, stating that the measure is a patient safety issue and impacts patients' health outcomes. A commenter noted that there are existing assessment items that can support the delirium measure such as the Confusion Assessment Method.

A few commenters opposed the measure, stating that the concept is captured in existing measures and protocol, potentially create additional provider burden. e. Other Suggestions on Future Measure Concepts

Comment: In addition to comments received on the four measure concepts of interoperability, well-being, nutrition, and delirium, we also received comments on concerns and recommendations on future measure concepts in this RFI. A couple of commenters stated that LTCH QRP should consider reducing provider burden, eliminating unnecessary measures and collaborating with stakeholder. A commenter suggested Universal Foundation measures when considering streamlining new measures.

Response: We thank all the commenters for responding to this RFI. While we are not responding to specific comments in response to the RFI in this final rule, we will take this feedback into consideration for our future measure development efforts for the LTCH QRP. 7. Potential Revision of the Final Data Submission Deadline Period from 4.5 Months to 45 Days--Request for Information

In the proposed rule, we requested feedback on this potential future reduction of the LTCH QRP data submission deadline from 4.5 months to 45 days that is under consideration. We refer readers to the proposed rule for the full text of the RFI (90 FR 18353). Specifically, we requested comment on--

How this potential change could improve the timeliness and actionability of LTCH QRP quality measures;

How this potential change could improve public display of quality information; and

How this potential change could impact LTCH workflows or require updates to systems.

The following is a summary of the comments we received.

Comments: A commenter supported reducing the data submission timeframe from 4.5 months to 45 days, stating that there is not an added burden by shortening the submission timeframe, as most LTCHs already submit within the 45-day window. A few commenters opposed reducing the data submission timeframe, citing risk for compromised quality of data and a decrease in the number of completed assessments. A commenter stated that this will be a risk in situations where reporting all required assessment information quickly is impossible (for example, emergency discharges and transfers). This commenter stated that the reduced timeframe could put providers at risk of failing to meet the minimum assessment data threshold, resulting in a 2 percent Annual Payment Update (APU) penalty. A commenter suggested that CMS conduct additional analyses and solicit further input from facilities on what timeframe would strike the best balance of feasibility and timeliness.

A few commenters cited special circumstances that could delay reporting, including system outages and changes of ownership (CHOW) where a new owner must obtain access and approvals to the internet Quality Improvement & Evaluation System (iQIES) for staff.

A commenter had concerns that current LTCH systems and workflows would not be able to sustain the change, especially with limited staffing and limited capacity of LTCH IT systems. This commenter noted that few LTCHs have fully automated, real-time reporting pipelines and urged CMS to take a more gradual approach to reducing the data submission timeline. A few commenters stated that CMS should not reduce the data submission timeframe to less than 90 days, stating that the change to 45 days is drastic in scope.

Response: We appreciate the input provided by commenters. While we will not be responding to specific comments submitted in response to this RFI in this final rule, we intend to use this input to inform our program improvement efforts. 8. Advancing Digital Quality Measurement in the LTCH QRP--Request for Information

As part of our effort to advance the digital quality measurement (dQM) transition, in the proposed rule, we issued an RFI to gather broad public input on the dQM transition in LTCHs. We also issued an RFI and sought input on the use of Health Level Seven[supreg] (HL7[supreg]) Fast Healthcare Interoperability Resources[supreg] (FHIR[supreg]) in certain CMS quality reporting and value-based purchasing programs. We refer readers to the FY 2026 IPPS/LTCH PPS proposed rule (90 FR 18354 and 18355). a. Background

We are committed to improving healthcare quality through measurement, transparency, and public reporting of quality data, and to enhancing healthcare data exchange by promoting the adoption of interoperable health IT that enables information exchange using FHIR[supreg] standards. We refer readers to the FY 2026 IPPS/LTCH PPS (90 FR 18354 and 18355) for additional background on the dQM transition.

We also sought input on future measures under consideration including applicability of interoperability as a future measure concept in post-acute care settings, including the LTCH QRP. Refer to section X.E.5. of this final rule for more information.

Any updates specific to the LTCH QRP program requirements related to quality measurement and reporting provisions would be addressed through separate and future notice-and-comment rulemaking, as necessary. b. Solicitation for Comment

We sought feedback on the current state of health IT use, including electronic health records (EHRs), in LTCH facilities:

To what extent does your LTCH use health IT systems to maintain and exchange patient records? If your facility has transitioned to using electronic records, in part or in whole, what types of health IT does your LTCH use to maintain patient records? Are these health IT systems certified by the Office of the National Coordinator for Health Information Technology (ONC Health IT) Certification Program? If your facility uses health IT products or systems that are not certified under the ONC Health IT Certification Program, please specify. Does your facility use EHRs or other health IT products or systems that are not certified under the ONC Health IT Certification Program? If no, what is the reason for not doing so? Do these other systems exchange data using standards and implementation specifications adopted by HHS? Does your facility maintain any patient records outside of these electronic systems? If so, are the data organized in a structured format, using codes and recognized standards, that can be exchanged with other systems and providers?

Does your LTCH submit patient assessment data to CMS directly from your health IT system without the assistance of a third- party intermediary? If a third-party intermediary is used to report data, what type of intermediary service is used? How does your facility currently exchange health information with other healthcare providers or systems, specifically between LTCHs and other provider types? What about health information exchange with other entities, such as public health agencies? What challenges do you face with electronic exchange of health information?

Are there any challenges with your current electronic devices (for example, tablets, smartphones, computers) that hinder your ability to easily exchange information across systems? Please describe any specific issues you encounter. Does limited internet or lack of internet connectivity impact your ability to exchange data with other healthcare providers, including community-based care services, or your ability to submit patient assessment data to CMS? Please specify.

What steps does your LTCH take with respect to the implementation of health IT systems to ensure compliance with applicable security and patient privacy laws, such as HIPAA and its implementing regulations (the HIPAA Privacy, Security, and Breach Notification Rules)?

Does your LTCH refer to the Safety Assurance Factors for EHR Resilience (SAFER) Guides (see newly revised versions published in January 2025 at https://www.healthit.gov/topic/safety/safer-guides) to self-assess EHR safety practices?

What challenges or barriers does your facility encounter when submitting quality measure data to CMS as part of the LTCH QRP? What opportunities or factors could improve your facility's successful data submission to CMS?

What types of technical assistance, guidance, workforce trainings, and/or other resources would be most beneficial for the implementation of FHIR[supreg]-based technology in your facility for the submission of the LCDS to CMS and other existing systems such as CDC's National Healthcare Safety Network (NHSN) for which LTCHs have current CMS reporting requirements? What strategies can CMS, HHS or other Federal partners take to ensure that technical assistance is both comprehensive and user-friendly? How could Quality Improvement Organizations (QIOs) or other entities enhance this support?

Is your facility using technology that utilizes APIs based on the FHIR[supreg] standard to enable electronic data sharing? If so, with whom are you sharing data using the FHIR[supreg] standard and for what purpose(s)? For example, have you used FHIR[supreg] APIs to share data with public health agencies? Does your facility use any Substitutable Medical Applications and Reusable Technologies (SMART) on FHIR[supreg] applications? If so, are the SMART on FHIR[supreg] applications integrated with your EHR or other health IT?

How do you anticipate the adoption of technology using FHIR[supreg]-based APIs to facilitate the reporting of patient assessment data could impact provider workflows? What impact, if any, do you anticipate it will have on quality of care?

What benefits or challenges have you experienced with implementing technology using FHIR[supreg]-based APIs? How can adopting technology using FHIR[supreg]-based APIs to facilitate the reporting of patient assessment data impact provider workflows? What impact, if any, does adopting this technology have on quality of care?

Does your facility have any experience using technology that shares electronic health information using one or more versions of the United States

Core Data for Interoperability (USCDI) standard? \377\

\377\ For more information about USCDI see https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi.

Would your LTCH and/or vendors be interested in participating in testing to explore options for transmission of assessments, for example testing the transmission of a FHIR[supreg]- based assessment to CMS?

How could the Trusted Exchange Framework and Common AgreementTM (TEFCATM) support CMS quality programs' adoption of FHIR[supreg]-based assessment submissions consistent with the FHIR[supreg] Roadmap (available here: https://rce.sequoiaproject.org/three-year-fhir-roadmap-for-tefca/)? How might patient assessment data hold secondary uses for treatment or other TEFCA exchange purposes?

What other information should we consider to facilitate successful adoption and integration of FHIR[supreg]-based technologies and standardized data for patient assessment instruments like the LCDS? We invited any feedback, suggestions, best practices, or success stories related to the implementation of these technologies.

We invited any feedback, suggestions, best practices, or success stories related to the implementation of these technologies and will use this input to inform our future dQM transition efforts. The following is a summary of the comments we received.

Comment: Several commenters were supportive of the transition to dQM for the LTCH QRP, stating that this will support more timely and actionable insights. A commenter stated that this transition will reduce the effort needed to develop measures and collect data as well as facilitate payers sharing with providers to inform care delivery in real time. A few of these commenters were supportive but encouraged a phased or “glide path” approach to implementation, along with pilot testing and technical assistance. Many commenters had concerns about barriers to dQM. A commenter was concerned that post-acute care (PAC) providers and vendors lack uniform technology capabilities and the IT workforce required for this transition. Another commenter recommended updates to CMS billing, CDC/NHSN and iQIES systems' technical capabilities to support consistency and direct transfer of data from providers. A few commenters recommended that CMS provide technical assistance and adequate timelines for LTCHs to transition. Another supported dQMs but suggested that national infrastructure should be developed first, so that EHRs contain all the necessary data elements specified in FHIR[supreg].

Several commenters recommended that CMS provide funding for LTCHs to update and modernize their systems for FHIR[supreg]. A few commenters stated that LTCHs were not included in Meaningful Use funding through the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009. A commenter stated that LTCHs have a lower level of IT maturity and may need considerable development resources to implement FHIR[supreg]-based APIs. This commenter cited costs related to program evaluation, technology development, and staffing, training, and certification costs, which are difficult for LTCHs with tight margins. Commenters recommended grants, direct funding, or incentive opportunities.

Response: We thank commenters for their feedback. While we will not be responding to specific comments submitted in response to this RFI in this final rule, we intend to use this information to inform future dQM transition work. 9. Form, Manner, and Timing of Data Submission Under the LTCH QRP a. Background

We refer readers to the regulatory text at Sec. 412.560(b) for information regarding the current policies for reporting specified data for the LTCH QRP.

b. Modification of Reporting Requirements for the Patient/Resident COVID-19 Vaccine Measure Beginning with the FY 2028 LTCH QRP.

As discussed previously in section X.E.3. of this final rule, we proposed to modify reporting requirements for the Patient/Resident COVID-19 Vaccine measure in the LTCH QRP to exclude patients who have expired in the LTCH beginning with the FY 2028 LTCH QRP. Specifically, we proposed that, beginning with patients admitted on or after October 1, 2026, LTCHs would no longer be required to submit the Patient/ Resident COVID-19 Vaccine item (O0350) on the LCDS with respect to patients who have expired in the LTCH. We also proposed to remove the Patient/Resident COVID-19 Vaccine item (O0350) from future LCDS forms that LTCHs use for expired patients. The remaining LCDS forms used for Planned Discharge and Unplanned Discharge would continue to include the Patient/Resident COVID-19 Vaccine item (O0350) for purposes of collecting and reporting data on the Patient/Resident COVID-19 Vaccine measure.

We invited public comment on our proposal to modify reporting requirements for the Patient/Resident COVID-19 Vaccine measure in the LTCH QRP to exclude patients who have expired in the LTCH beginning patients who have expired on or after October 1, 2026, for the FY 2028 LTCH QRP.

We have summarized the comments we received about modifying reporting requirements for the Patient/Resident COVID-19 Vaccine measure in section X.E.3. of this final rule and provided responses. After consideration of the public comments, we are finalizing our proposal to modify reporting requirements for the Patient/Resident COVID-19 Vaccine measure in the LTCH QRP to exclude patients who have expired in the LTCH beginning with the FY 2028 LTCH QRP. 10. Policies Regarding Public Display of Measure Data for the LTCH QRP

We did not propose any new policies regarding the public display of measure data in this final rule. For a more detailed discussion about our policies regarding public display of LTCH QRP measure data and procedures for the opportunity to review and correct data and information, we refer readers to the FY 2017 IPPS/LTCH PPS final rule (81 FR 57231 through 57236).

Sections 1886(b)(3)(B)(ix) and 1814(l)(4) of the Act (as amended by the Health Information Technology for Economic and Clinical Health Act, Title XII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (ARRA), (Pub. L. 111-5)) authorize downward payment adjustments under Medicare, beginning with FY 2015 for eligible hospitals and CAHs that do not successfully demonstrate meaningful use of certified electronic health record technology (CEHRT) for the applicable electronic health record (EHR) reporting periods. Section 602 of Title VI, Division O of the Consolidated Appropriations Act, 2016 (Pub. L. 114-113) added subsection (d) hospitals in Puerto Rico as eligible hospitals under the Medicare EHR Incentive Program and extended the participation timeline for these hospitals such that downward payment adjustments were authorized beginning in FY 2022 for section (d) Puerto Rico hospitals that do not successfully demonstrate meaningful

use of CEHRT for the applicable EHR reporting periods.

In addition to the policies discussed in this final rule, we also refer readers to the CY 2026 Physician Fee Schedule (PFS) proposed rule, where we have proposed to adopt a measure scoring suppression policy beginning with the EHR reporting period in CY 2026 and proposed to suppress the Electronic Case Reporting measure from scoring for the EHR reporting period in CY 2025 (90 FR 32732 through 32736). We invite public comment on those proposals through the CY 2026 PFS proposed rule.

Under the definition of “EHR reporting period for a payment adjustment year” at 42 CFR 495.4, for eligible hospitals and CAHs in the Medicare Promoting Interoperability Program, the EHR reporting period in CY 2025 is a minimum of any continuous 180-day period within CY 2025 as finalized in the FY 2024 IPPS/LTCH PPS final rule (88 FR 59259 through 59260). This applies to eligible hospitals and CAHs that are both new and returning participants in the Medicare Promoting Interoperability Program. We had previously maintained the EHR reporting period for a payment adjustment year as a minimum of any continuous 90-day period from CY 2015 through CY 2023 for eligible hospitals and CAHs for the Medicare Promoting Interoperability Program before increasing the length of the EHR reporting period to any continuous 180-days beginning with CY 2024. In the FY 2026 IPPS/LTCH PPS proposed rule (90 FR 18355 to 18356), we proposed to maintain the EHR reporting period for CY 2026 and subsequent years as a minimum of any continuous 180-days. 180-days would be the minimum length, and eligible hospitals and CAHs are encouraged to use longer periods, up to and including the full calendar year. This provides consistency with the EHR reporting period established for CY 2025 and would afford eligible hospitals and CAHs the flexibility they may need to work with their chosen EHR vendors on continuing to develop, update, implement, and test their EHR systems to maintain effective use of CEHRT. We proposed corresponding revisions to the definition of “EHR reporting period for a payment adjustment year” at 42 CFR 495.4.

In collaboration with the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ONC) (collectively referred to as ASTP/ONC),\378\ we stated we will continue to monitor CEHRT utilization by eligible hospitals and CAHs to determine if a longer EHR reporting period may be appropriate in the future.

\378\ On July 29, 2024, notice was posted in the Federal Register that ONC would be dually titled to the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ASTP) (89 FR 60903).

We invited public comment on the proposal to define the “EHR reporting period for a payment adjustment year” in CY 2026 and subsequent years as a minimum of any continuous 180-day period within that calendar year for eligible hospitals and CAHs participating in the Medicare Promoting Interoperability Program and to make corresponding revisions at 42 CFR 495.4.

Comment: Many commenters supported our proposal to maintain a 180- day EHR reporting period in CY 2026 for eligible hospitals and CAHs. Several commenters emphasized the importance of flexibility for eligible hospitals and CAHs to manage system upgrades, address technical issues, coordinate with vendors, and implement changes effectively. Several commenters appreciated the stability provided by the 180-day reporting period, citing benefits such as reduced resource strain, effective system implementation, and consistency in reporting timelines. A few commenters supported the 180-day EHR reporting period as a manageable timeframe that allows eligible hospitals and CAHs to focus on improving EHR use without risking penalties due to shorter reporting windows. A commenter stated that the proposal enables better planning and execution for eligible hospitals, CAHs, and organizations.

Response: We thank commenters for their support. We agree that maintaining the 180-day EHR reporting period provides consistency with the prior years' EHR reporting periods and provides eligible hospitals and CAHs the flexibility and stability they may need to develop and update their system, and coordinate with their EHR vendors as necessary. Furthermore, we note that many commenters agreed that the 180-day reporting period is a manageable timeframe to plan, execute, and improve their certified EHR use.

Comment: A few commenters urged CMS to maintain the 180-day EHR reporting period beyond CY 2026, emphasizing the need for sufficient time to safely deploy and test EHR upgrades before the EHR reporting period begins. A commenter recommended that CMS provide an additional year for implementation if the EHR reporting period is further expanded, citing insufficient time to adapt to such changes.

Response: We thank commenters for their comments. We note we proposed to use a 180-day EHR reporting period in CY 2026 and subsequent years, which would continue to be our policy unless we propose a change through future rulemaking. Continuing to improve the interoperability of health information exchange by enabling patients and providers to have more comprehensive and reliable data are key goals of the Medicare Promoting Interoperability Program. We will continue to monitor technological advancements and strive to maintain the consistency, flexibility, and stability of our policies for the EHR reporting period, providing sufficient time for eligible hospitals and CAHs to safely deploy and test EHR upgrades before the EHR reporting period begins. Additionally, we appreciate the recommendations regarding future EHR reporting periods and may consider this for future rulemaking.

Comment: A commenter did not support the proposal stating that a 180-day EHR reporting period may hinder their ability to leverage timely data and optimize certified EHR use. This commenter instead recommended that CMS revert to the 90-day EHR reporting period in CY 2026 because it would preserve flexibility, support data driven decision making, and better align with the Medicare Promoting Interoperability Program's goal to demonstrate meaningful use of CEHRT.

Response: After finalizing the 180-day EHR reporting period for CY 2024 in the FY 2022 IPPS/LTCH PPS final rule (86 FR 45460 through 45462), and for CY 2025 in the FY 2024 IPPS/LTCH PPS final rule (88 FR 59259 and 59260), eligible hospitals and CAHs have had more than 3 years of advance planning with their vendors to build upon and utilize investments already made within their infrastructure to meet site- specific needs for implementation. We also note that the EHR reporting period remained at 90-days from adoption for the EHR reporting period in CY 2011 through the EHR reporting period in CY 2023. When we adopted the 90-day EHR reporting period, we indicated that we did not believe a 90-day period would be appropriate in future years because potential delays in implementing CEHRT were limited to the initial implementation of CEHRT (75 FR 44320). Maintaining an EHR reporting period of 180-days for CY 2026 and subsequent years would not impact eligible hospitals' and CAHs' efforts to

update, implement, and test EHR systems. Reporting data from a longer period provides eligible hospitals and CAHs the opportunity to continuously monitor their performance and identify areas that may require investigation and corrective action. Maintaining the 180-day EHR reporting period in CY 2026 and subsequent years supports the continued improvement of interoperability and health information exchange by producing more comprehensive and reliable data for patients and providers.

After consideration of the public comments we received, we are finalizing our proposal to define the “EHR reporting period for a payment adjustment year” in CY 2026 and subsequent years as a minimum of any continuous 180-day period within that calendar year for eligible hospitals and CAHs participating in the Medicare Promoting Interoperability Program, and we are finalizing these proposed changes at 42 CFR 495.4.

The HIPAA Security Rule \379\ (45 CFR part 160 and subparts A and C of part 164) contains administrative safeguards that covered entities and business associates (45 CFR 160.103) must implement, such as the standard and implementation specifications for security management processes. Among those safeguards are implementation specifications that require covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) held by the covered entity or business associate (45 CFR 164.308(a)(1)(ii)(A)), and to implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with the general requirements of the HIPAA Security Rule at 45 CFR 164.306(a).

\379\ Under the Biden administration, the Department proposed to modify the HIPAA Security Rule to strengthen the cybersecurity of ePHI(90 FR 898). This proposed rule has not been finalized as of publication of this final rule.

For eligible hospitals and CAHs participating in the Medicare Promoting Interoperability Program, ensuring the privacy and security of ePHI is essential for demonstrating meaningful use of CEHRT. In both the Medicare and Medicaid Programs; Electronic Health Record Incentive Program-Stage 2 final rule (Stage 2 final rule) (77 FR 54002 through 54003) and the Medicare and Medicaid Programs; Electronic Health Record Incentive Program-Stage 3 and Modifications to Meaningful Use in 2015 through 2017 final rule (Stage 3 final rule) (80 FR 62793 through 62794), we discussed the benefits of safeguarding electronic health information and our determination that protecting electronic health information is essential to all aspects of meaningful use. We also noted that impermissible disclosures of protected health information, whether unintended, unlawful, or both, could diminish individuals' confidence in EHRs and electronic health information exchange and that ensuring that health information is adequately protected and secured would assist in addressing the unique risks and challenges that may be presented.

We previously adopted the Security Risk Analysis measure based on the HIPAA Security Rule risk analysis requirement in 45 CFR 164.308(a)(1). Information on the adoption of this measure can be found in several rules that established Medicare and Medicaid EHR Incentive Programs requirements, including the Medicare and Medicaid Programs; Electronic Health Record Incentive Program final rule (Stage 1 final rule) (75 FR 44369), Stage 2 final rule (77 FR 54002 and 54003), Stage 3 final rule (80 FR 62793 through 62794), and the FY 2019 IPPS/LTCH PPS final rule (83 FR 41644). In the Stage 3 final rule (80 FR 62793 through 62795 and 62829 through 62832), we adopted the Protect Patient Health Information objective and included the Security Risk Analysis measure.

Prior to the FY 2026 IPPS/LTCH PPS final rule, the Security Risk Analysis measure required eligible hospitals and CAHs to attest “yes” or “no” as to whether they had conducted or reviewed a security risk analysis, as required by the HIPAA Security Rule at 45 CFR 164.308(a)(1)(ii)(A). Eligible hospitals and CAHs were required to attest “yes” to the measure to be considered a meaningful EHR user and avoid a downward payment adjustment. The measure was not scored and did not contribute any points to the total score for the Protect Patient Health Information objective. An attestation of “no” resulted in the eligible hospital or CAH not meeting the requirements of the measure and not satisfying the definition of a meaningful EHR user under 42 CFR 495.4, subjecting the eligible hospital or CAH to a downward payment adjustment. b. Modification of the Security Risk Analysis Measure Beginning With the EHR Reporting Period in CY 2026

As of the EHR reporting period in CY 2025, the Security Risk Analysis measure does not require eligible hospitals and CAHs to manage their security risk conduct or to attest to having implemented security measures to manage their security risk. Codified at 45 CFR 164.308(a)(1)(ii)(B), the HIPAA Security Rule implementation specification for risk management requires the implementation of security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with 45 CFR 164.306(a). We note the HIPAA Security Rule does not prescribe a specific methodology for conducting and documenting a risk analysis or managing risk (45 CFR 164.308(a)(1)(ii) and 164.316(b)(1)). We refer readers to educational resources and information on conducting a HIPAA Security Rule risk analysis available in the U.S. Department of Health and Human Services (HHS) Office for Civil Rights' (OCR) cybersecurity newsletters,\380\ OCR's website\381\, and YouTube channel,\382\ the National Institute of Standard and Technology (NIST) special publication, Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide,\383\ and the HHS Administration for Strategic Preparedness and Response 405(d) Program and Task Group website.\384\

\380\ See generally https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html.

\381\ Guidance on Risk Analysis available at https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html.

\382\ See https://www.youtube.com/user/USGovHHSOCR.

\383\ See NIST SP 800-66, rev. 2. https://csrc.nist.gov/pubs/sp/800/66/r2/final.

\384\ See generally https://405d.hhs.gov/resources.

In the FY 2026 IPPS/LTCH PPS proposed rule (90 FR 18357 to 18359), we proposed to modify the Security Risk Analysis measure to require eligible hospitals and CAHs to attest “yes” to having conducted security risk management as required by the HIPAA Security Rule implementation specification for risk management. This proposed modification would be in addition to the current requirement under the measure for eligible hospitals and CAHs to attest “yes” to having conducted or reviewed a security risk analysis. Under the proposed modified measure, eligible hospitals and CAHs would be required to attest that they have implemented policies and procedures to support analyzing and

managing security risks to ePHI associated with the implementation and use of EHRs in accordance with the HIPAA Security Rule implementation specifications for risk analysis and risk management as described in 45 CFR 164.308(a)(1)(ii)(A) and (B). The modifications we proposed to the Security Risk Analysis measure would increase accountability among eligible hospitals and CAHs that have not taken steps to reduce risks and vulnerabilities to ePHI as required by the HIPAA Security Rule and would provide transparency regarding the efforts of eligible hospitals and CAHs that are already taking steps to manage this risk.

We proposed the following text for the modified measure, with proposed revised text (as compared to the prior measure text) in italics:

Conduct or review a security risk analysis and conduct security risk management activities, in accordance with the requirements under 45 CFR 164.308(a)(1)(ii)(A) and (B), including addressing the security of data created or maintained by CEHRT (to include encryption), in accordance with 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), implement security updates as necessary, and correct identified security deficiencies as part of the eligible hospital's or CAH's risk management process. Actions included in the security risk analysis measure may occur any time during the calendar year in which the EHR reporting period occurs.

To meet the requirements of the modified measure, we proposed that eligible hospitals and CAHs would need to separately attest “yes” to both components of the measure. An eligible hospital or CAH would be required to both attest “yes” that they have met the existing security risk analysis requirement component, and attest “yes” that they have met the security risk management component of the modified Security Risk Analysis measure to be considered a meaningful EHR user beginning with the EHR reporting period in CY 2026. This proposed modification would not impact the provision that actions included in the Security Risk Analysis measure may occur any time during the calendar year in which the EHR reporting period occurs and that an eligible hospital or CAH must use the capabilities and standards as defined for CEHRT at 42 CFR 495.4. The proposal to modify the Security Risk Analysis measure would not change the current scoring approach and would not contribute any points towards the eligible hospital or CAH's total score for the objective. An eligible hospital or CAH that attests “no” to either the risk analysis component or the risk management component, or to both components, would not meet measure requirements and would not satisfy the definition of a meaningful EHR user under 42 CFR 495.4, subjecting the eligible hospital or CAH to a downward payment adjustment.

We invited public comment on the proposal to modify the Security Risk Analysis measure to require eligible hospitals and CAHs to attest “yes” to having conducted security risk management in addition to the current requirement for eligible hospitals and CAHs to attest “yes” to having conducted or reviewed a security risk analysis as required by the HIPAA Security Rule. We also invited public comment regarding compliance with security risk management requirements and the potential impact the proposed modification to the Security Risk Analysis measure would have on risk management compliance and any potential burden from this proposal.

Comment: Many commenters supported our proposal. Several of these commenters emphasized that requiring eligible hospitals and CAHs to attest to having conducted security risk management activities in addition to security risk analysis aligns with the HIPAA Security Rule and strengthens cybersecurity preparedness. A commenter supported CMS' continued alignment of the Medicare Promoting Interoperability Program's interoperability objectives with national frameworks that advance trust, data integrity, and security. A few commenters agreed that requiring attestation to security risk management activities increases accountability for reducing risks and vulnerabilities to ePHI. They noted that many eligible hospitals and CAHs have already taken steps to prepare for and manage these risks with policies and procedures in place to address cybersecurity risks. They anticipate the additional requirement would help ensure ePHI is adequately protected in organizations that have not adopted such risk management practices. A few commenters noted that the proposal strikes an appropriate balance between safeguarding patient data and minimizing mandatory reporting requirements.

Response: We thank the commenters for their support. We agree that adding the security risk management attestation requirement to the Security Risk Analysis measure aligns with the HIPAA Security Rule and would assist eligible hospitals and CAHs to strengthen their cybersecurity preparedness. We also agree that the change to the Security Risk Analysis measure will increase accountability for reducing risks and vulnerabilities to ePHI while balancing the need to safeguard patient data with minimal reporting requirements. Eligible hospitals and CAHs are required to conduct security risk management activities by implementing security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with Sec. 164.306(a), as covered entities and business associates under the HIPAA Security Rule. We refer readers to the educational resources that the Department has published on performing security risk analyses and other activities for managing security risks, such as OCR's cybersecurity newsletters,\385\ OCR's website,\386\ and YouTube videos \387\ and other resources published by the HHS Administration for Strategic Preparedness and Response through the 405(d) Program and Task Group.\388\

\385\ See https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity/index.html.

\386\ Guidance on Risk Analysis,” available at https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html.

\387\ See https://www.youtube.com/user/USGovHHSOCR.

\388\ See https://405d.hhs.gov/resources.

Comment: Several commenters that supported the proposal offered recommendations for consideration. A commenter recommended a phased-in approach to implementation, that we offer technical assistance, and that we provide toolkits to support CAHs and rural hospitals. A few commenters recommended HHS issue guidance on performing security risk management activities. Another commenter recommended providing a voluntary reporting year to allow eligible hospitals and CAHs to integrate the new requirements into existing workflows.

Response: We thank the commenters for their support and feedback. We recognize that eligible hospitals and CAHs may sometimes need additional flexibility to work with external vendors to implement measure changes or to adjust their workload accordingly, however, we note that the HIPAA Security Rule required covered entities to assess and manage risks to ePHI beginning in CY 2003 (68 FR 8346 to 8348). When we adopted the Security Risk Analysis measure in the Stage 1 final rule (75 FR 44369), the HIPAA Security Rule already required risk management administrative safeguards under 45 CFR 164.308(a)(1) and had

done so for years. Therefore, we do not believe a phased-in approach, or a voluntary year of reporting are warranted for eligible hospitals and CAHs to attest to having conducted risk management activities that have been required activities since adoption of the HIPAA Security Rule.

Regarding the request for technical assistance, toolkits, and other guidance to support CAHs and rural hospitals, we refer readers to OCR's resources on performing security risk analyses and other related security risk management activities.\389\ The guidance materials OCR makes available would best inform all eligible hospitals and CAHs on how to meet the requirements of the measure, since we intend the modified measure to be aligned with the HIPAA Security Rule requirements.

\389\ https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity/index.html.

Comment: A commenter recommended specific refinements to the measure language to reduce ambiguity and enhance the focus on cybersecurity without unnecessarily increasing administrative burden. Another commenter recommended CMS provide guidance modeled after OCR's documentation expectations for demonstrating implementation of recognized security practice (RSP), to support consistent implementation.

Response: With respect to the recommendation to modify the measure language to reduce ambiguity, we appreciate the commenter's recommendations. To minimize any potential for confusion or ambiguity in the measure's requirements, we are providing technical and clarifying revisions to simplify the language of the proposed measure text as follows:

First, conduct or review a security risk analysis and second, conduct security risk management activities, in accordance with the requirements under 45 CFR 164.308(a)(1)(ii)(A) and (B). Security risk analysis and management activities include addressing the security of data created or maintained by CEHRT (to include encryption), in accordance with 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3). The encryption implementation specified at 45 CFR 164.312(a)(2)(iv) must be implemented if it is reasonable and appropriate; if encryption is not reasonable and appropriate, then the eligible hospital or CAH would adopt an equivalent alternative measure if it is reasonable and appropriate to do so. Actions included in the security risk analysis measure may occur any time during the calendar year in which the EHR reporting period occurs.

We note that the HIPAA Security Rule does not currently prescribe a specific methodology for conducting and documenting a risk analysis or managing risk, and we reiterate our proposal was not intended to exceed or extend beyond what is required under the HIPAA Security Rule. We have modified the measure text accordingly.

In addition, with respect to risk management documentation, we appreciate the recommendation to provide guidance modeled after OCR's documentation requirements for demonstrating implementation of RSPs; however, we note that the HIPAA Security Rule does not prescribe a specific methodology for conducting and documenting a risk analysis or managing risk (45 CFR 164.308(a)(1)(ii) and 164.316(b)(1)).

Comment: Many commenters did not support the security risk analysis measure modification for various reasons. Several commenters stated the proposed modification is duplicative because eligible hospitals and CAHs are already required by the HIPAA Security Rule to conduct regular security risk analyses and address identified vulnerabilities. A few commenters urged CMS to reconsider inclusion of the Security Risk Analysis measure altogether because they stated it is duplicative of the HIPAA Security Rule requirements and, therefore, believe removing the measure would reduce burden. A commenter stated the proposed modification would undermine established enforcement practices and place eligible hospitals and CAHs at an increased financial risk. Another commenter stated the Paperwork Reduction Act (PRA) prohibits duplicative federal information collections unless justified by clear, demonstrable benefit, and that requiring eligible hospitals and CAHs to re-attest to security risk management under the Medicare Promoting Interoperability Program may contradict the PRA's purpose.

A few commenters did not support the measure change and stated it creates an administrative burden without clear evidence of improved security outcomes. A few commenters expressed concern that the proposed modification to the Security Risk Analysis measure runs counter to the Administration's policy objective to reduce regulatory burden.

A few commenters did not support the proposal and stated it would create an additional compliance step for eligible hospitals and CAHs, raising concerns that compliance may be difficult to measure, and that implementing cybersecurity requirements can be financially challenging for some. A commenter recommended that CMS work with OCR to implement consistent requirements and provide funding, resources, guidance, and education for entities, particularly small, rural, and otherwise under- resourced eligible hospitals and CAHs.

Response: With respect to the relationship between the HIPAA Security Rule and the security risk analysis required by the Security Risk Analysis measure, we previously explained in the Stage 3 final rule (80 FR 62794), and discussed in greater detail in the Stage 3 proposed rule (80 FR 16746 to 16747), that our measure is narrower than what is required to satisfy the security risk analysis requirement under the HIPAA Security Rule at 45 CFR 164.308(a)(1). The security risk analysis required by the measure is limited to annually conducting or reviewing a security risk analysis to assess whether the technical, administrative, and physical safeguards and risk management strategies are sufficient to reduce the potential risks and vulnerabilities to the confidentiality, availability, and integrity of ePHI created by or maintained in CEHRT and to implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with 45 CFR 164.306(a). In contrast, the security risk analysis and risk management requirements under 45 CFR 164.308(a)(1) require covered entities and business associates to assess the potential risks and vulnerabilities to the confidentiality, availability, and integrity of all ePHI that an organization creates, receives, maintains, or transmits, including ePHI in all forms of electronic media, and to implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with 45 CFR 164.306(a) for all ePHI held by the covered entity or business associate.

As covered entities and business associates, eligible hospitals and CAHs are required to conduct security risk management activities under the HIPAA Security Rule. Therefore, we do not agree that the requirement to attest “yes” to having conducted risk management activities creates an additional administrative or regulatory burden, introduces an additional compliance step other than attesting “yes” or “no” once a year to CMS, adds significant technical complexity, places eligible hospitals and CAHs at financial risk, or contradicts the PRA's purpose.

The proposed security risk management attestation reflects an eligible hospital's or CAH's acknowledgment of having performed activities that also meet the requirements of the HIPAA Security Rule implementation specification for risk management at 45 CFR 164.308(a)(1)(ii)(B). Furthermore, non-compliance with the HIPAA Security Rule's requirements for security risk analysis and risk management could expose eligible hospitals and CAHs to greater financial and other risks in the event of a data breach.

We note that our intention with this attestation measure, including the new modification to require an affirmative attestation to having conducted security risk management as required under the HIPAA Security Rule implementation specification for risk management, is not to measure the level of HIPAA Security Rule compliance. Rather, we intend to augment our past efforts to incorporate security, including security risk analysis and risk management, as a fundamental structural component for the meaningful use of EHRs. Instead of being duplicative, we consider the modified Security Risk Analysis measure to be complementary to the HIPAA Security Rule. As we explained previously in the Stage 2 final rule (77 FR 54002 and 54003), we emphasize again that our discussion of the HIPAA Security Rule implementation specification for security risk analysis and 45 CFR 164.308(a)(1) is only relevant for purposes of the meaningful use requirements and is not intended to supersede what is separately required by the HIPAA Security Rule or other applicable laws.

We also explained in the Stage 3 final rule that OCR administers and enforces the HIPAA Rules, including the HIPAA Security Rule, to ensure the privacy and security of protected health information (PHI); however, we continue to believe it is important and necessary for eligible hospitals and CAHs to attest to certain actions required to protect ePHI created or maintained by CEHRT in order to meet the Medicare Promoting Interoperability Program requirements (80 FR 62830). The modification to the Security Risk Analysis measure demonstrates our continued commitment to ensuring that electronic health information created or maintained by CEHRT is protected and secured by eligible hospitals and CAHs given the unique risks and challenges that may be presented by EHRs, particularly at a time when cybersecurity threats are increasingly common and sophisticated.\390\

\390\ Healthcare and Public Health Sector Coordinating Council, Centers for Medicare and Medicaid Services, and U.S. Department of Health and Human Services. Hospital Cyber Resiliency Initiative Landscape Analysis. Washington, DC: April 17, 2023 at https://405d.hhs.gov/Documents/405d-hospital-resiliency-analysis.pdf.

Comment: A commenter was concerned that imposing parallel but independently administered requirements increases the likelihood of conflicting interpretations and audit standards across Federal agencies that would introduce significant technical complexity and risk.

Response: We explained previously in the Stage 2 final rule (77 FR 54002 and 54003) that the Security Risk Analysis measure is only relevant for purposes of the meaningful use requirements and is not intended to supersede the HIPAA Security Rule or other applicable laws that address cybersecurity, nor is it intended to introduce additional technical requirements other than what is already required under HIPAA. As we explained in the Stage 3 final rule (80 FR 62794), and described in greater detail in the Stage 3 proposed rule (80 FR 16746 to 16747), the Security Risk Analysis measure is narrower than what is required by the HIPAA Security Rule at 45 CFR 164.308(a)(1) because it only applies to ePHI created or maintained by CEHRT and excludes other forms of electronic media, such as hard drives. These statements continue to apply after the modification we proposed to the Security Risk Analysis measure.

Comment: A commenter expressed concern that the proposed modification to the measure is procedurally flawed because the commenter stated that it relies on the HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information proposed rule (90 FR 898) that has not been finalized.

Response: We disagree that the proposal to add a security risk management attestation requirement relies on OCR's HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information proposed rule. The proposed Security Risk Analysis measure modification refers to current requirements of the HIPAA Security Rule that are codified at 45 CFR 164.308(a)(1)(ii)(A) and (B), 164.312(a)(2)(iv), and 164.306(d)(3). The cross-references we proposed do not rely on any other proposed policies or proposed modifications to these provisions. We acknowledge that if the HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information proposed rule (90 FR 898) is finalized, we will consider whether we need to modify the Security Risk Analysis measure accordingly in future rulemaking.

Comment: A few commenters stated that the proposed measure modification would not prevent cyberattacks. A commenter recommended reevaluating existing metrics for the effects of the industry's move towards interoperability. A commenter recommended keeping the measure as-is and exploring other avenues to encourage risk mitigation. A few commenters expressed reservations around requiring “yes” attestations to receive full scoring credit.

Response: While we agree with commenters that an attestation by itself will not prevent cyberattacks, at this time it is important and necessary to use available levers to protect patients' health information, including the attestation of actions required to protect ePHI created or maintained by CEHRT to meet the Medicare Promoting Interoperability Program requirements. We note that we may consider re- evaluating existing metrics and other avenues to encourage risk mitigation in future rulemaking.

After consideration of the public comments we received, we are finalizing our proposal to modify the Security Risk Analysis measure, with modification, to require eligible hospitals and CAHs to attest “yes” to having conducted security risk management in addition to the current requirement under the measure for eligible hospitals and CAHs to attest “yes” to having conducted or reviewed a security risk analysis as required by the HIPAA Security Rule, with clarification of the specified measure language as discussed previously so that the finalized measure reads as follows:

First, conduct or review a security risk analysis and second, conduct security risk management activities, in accordance with the requirements under 45 CFR 164.308(a)(1)(ii)(A) and (B). Security risk analysis and management activities include addressing the security of data created or maintained by CEHRT (to include encryption), in accordance with 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3). The encryption implementation specified at 45 CFR 164.312(a)(2)(iv) must be implemented if it is reasonable and appropriate; if encryption is not reasonable and appropriate, then the eligible hospital or CAH would adopt an equivalent alternative measure if it is reasonable and appropriate to do so. Actions included in the security risk analysis measure may occur any time during the calendar year in which the EHR reporting period occurs.

4. Modifications to the Safety Assurance Factors for EHR Resilience (SAFER) Guides Measure a. Background on the SAFER Guides Measure

The SAFER Guides are an evidence-based set of recommendations in the form of nine stand-alone, subject-oriented chapters that present the health IT community, including eligible hospitals and CAHs that use health IT, with best practice recommendations to improve the safety and safe use of EHRs.\391\ The SAFER Guides were first released in 2014 and updated in 2016. In the FY 2022 IPPS/LTCH PPS final rule (86 FR 45479 through 45481), we adopted the SAFER Guides measure under the Protect Patient Health Information objective beginning with the EHR reporting period in CY 2022. In the FY 2024 IPPS/LTCH PPS final rule, we modified the requirements for the SAFER Guides measure beginning with the EHR reporting period in CY 2024 to require eligible hospitals and CAHs to attest “yes” to conducting an annual self-assessment using all nine of the 2016 SAFER Guides to be considered a meaningful EHR user (88 FR 59262 through 59266).

\391\ ASTP SAFER Guides--https://www.healthit.gov/topic/safety/safer-guides.

In January 2025, ASTP/ONC published an updated set of SAFER Guides (hereafter referred to as the 2025 SAFER Guides, located at https://www.healthit.gov/topic/safety/safer-guides). The 2025 SAFER Guides consist of eight guides organized into three broad groups of Foundational Guides, Infrastructure Guides, and Clinical Process Guides.\392\ All guides have been edited and contain new recommendations as well as the comprehensive consolidation of recommendations that were similar and overlap in function or intent with the 2016 SAFER Guides. For example, the “System Configuration” and “System Interfaces” chapters have been consolidated into a single chapter titled, “System Management.” The entirety of the content recommendations, bibliography, and implementation guidance have been organized into a comprehensive table, which promotes the adoption of best safety practices for health IT. This update represents the most comprehensive revision of the SAFER Guides since they were first released. Table X.F.-01 provides titles of the guides, and chapters within the guides, that collectively comprise the 2016 SAFER Guides and the 2025 SAFER Guides, respectively.

\392\ ASTP SAFER Guides--https://www.healthit.gov/topic/safety/safer-guides [GRAPHIC] [TIFF OMITTED] TR04AU25.282

In the FY 2026 IPPS/LTCH PPS proposed rule (90 FR 18358 to 18359), we proposed to modify the SAFER Guides measure by requiring eligible hospitals and CAHs to attest “yes” to completing an annual self- assessment using all eight 2025 SAFER Guides to be considered a meaningful EHR user, beginning with the EHR reporting period in CY 2026. Some commenters who submitted comments on the FY 2024 IPPS/LTCH PPS proposed rule believed the 2016 SAFER Guides were outdated and recommended that ONC review and update them. Some commenters questioned the relevancy of the 2016 SAFER Guides to patient safety in hospitals due to the rapid advancement of health IT (88 FR 59264 through 59265). Our proposal to update the SAFER Guides measure addresses these concerns and suggestions, because the 2025 SAFER guides have been updated and streamlined to focus on the highest risk, most commonly occurring issues that can be addressed through technology or practice changes to build system resilience and have been condensed into eight SAFER Guides rather than nine.

We proposed the following text for the measure:

Conduct an annual self-assessment using all eight of the 2025 SAFER Guides at any point during the calendar year in which the EHR reporting period occurs, beginning with the EHR reporting period in CY 2026 and subsequent years.

We noted that our proposed modification of the measure to reference the 2025 SAFER Guides would only be effective beginning with EHR reporting periods in CY 2026. We further noted that during EHR reporting period in CY 2025, eligible hospitals and CAHs should continue to use the 2016 SAFER Guides to complete their self- assessment. Both the 2016 and the 2025 SAFER Guides are available on the ASTP website: https://www.healthit.gov/topic/safety/safer-guides. We encourage eligible hospitals and CAHs to begin to familiarize themselves with the 2025 SAFER Guides during CY 2025.

We invited public comment on this proposal for eligible hospitals and CAHs to conduct an annual self-assessment using all eight of the 2025 SAFER Guides at any point during the calendar year in which the EHR reporting period occurs, beginning with the EHR reporting period in CY 2026 and subsequent years.

Comment: Many commenters expressed support for the proposal to

modify the SAFER Guides measure. A few of these commenters cited the importance of updating the guides to reflect advancements in health IT, cybersecurity, and clinical safety practices. A few commenters expressed appreciation for the streamlined and consolidated nature of the 2025 SAFER Guides.

Response: We thank the commenters for their support. We agree that the 2025 SAFER Guides reflect advancements in health IT, cybersecurity, and clinical safety practices in a streamlined and consolidated format.

Comment: Many commenters expressed concern about the proposed requirement to attest to completing an annual self-assessment using all eight of the 2025 SAFER Guides beginning in CY 2026. A few of these commenters stated the requirement to review an updated set of SAFER Guides would introduce substantial administrative burden, particularly for rural, under-resourced, and safety-net hospitals. Several commenters expressed concern around the duplicative nature of the SAFER Guides measure with the Security Risk Analysis measure, the resource- intensive nature of completing a self-assessment using all eight guides, and ambiguity in several recommended practices. A commenter felt there was a lack of strong evidence linking utilization of the SAFER Guides to improved safety outcomes.

A few commenters urged CMS to reconsider requiring the measure entirely, citing claims of the burden it may impose on eligible hospitals and CAHs with limited health IT staff and its potential overlap with existing regulatory measures. A commenter requested that CMS work with stakeholders to assess the burden and effectiveness of the SAFER Guides measure and explore alternative tools for assessing EHR safety.

Response: We thank commenters for sharing this feedback. Regarding concerns around burden or resource constraints from completing the self-assessment, we reiterate that the 2025 SAFER Guides have been updated and streamlined to focus on the highest risk, most commonly occurring issues that can be addressed through technology or practice changes. We remind readers that the SAFER Guides measure only requires eligible hospitals and CAHs to attest “yes” to having conducted an annual self-assessment using all eight SAFER Guides, at any point during the calendar year in which the EHR reporting period occurs. There are no requirements to meet a specific implementation status or implement any specific practices identified in the guides, and we defer to eligible hospitals and CAHs to evaluate the utility of adopting specific best practices contained within the SAFER Guides, on their own timeline. We therefore disagree that this measure update would introduce substantial administrative burden, particularly for rural, under-resourced, and safety-net hospitals, as there are fewer SAFER Guides to attest to, and much of the information between the 2016 and 2025 versions remains the same.

In response to concerns around the evidence base of the SAFER Guides, we note that the SAFER Guides are based on the best available evidence from literature and consensus expert opinion. Subject matter experts in patient safety, informatics, quality improvement, risk management, human factors engineering, and usability collaborated to update the guides. The SAFER Guides were reviewed by an external group of practicing clinicians, informaticians, and information technology professionals.\393\ The SAFER Guides are a valuable resource for eligible hospitals and CAHs using EHRs, as they can help identify potential risks, prioritize safety concerns, and implement strategies to mitigate those risks. Most importantly, the 2025 SAFER Guides were published largely in response to stakeholder concerns that the 2016 SAFER Guides were outdated and no longer relevant (88 FR 59264 through 59265). Considering the rapid advancement of health IT, the information in the 2025 SAFER Guides reflects the current state of health IT, making the self-assessments more relevant. Therefore, we disagree that requiring the measure should be reconsidered altogether.

\393\ https://www.healthit.gov/sites/default/files/topiclanding/2025-01/4.%20High%20Priorities%20Final.pdf.

We acknowledge the concerns raised by commenters regarding the potential overlap between the SAFER Guides measure and the Security Risk Analysis measure. While both measures aim to assess and enhance areas such as patient safety and security, there are notable differences. The SAFER Guides are a set of tools and recommendations focused on optimizing the safety and safe use of EHRs that help eligible hospitals and CAHs identify and address potential risks by providing a distinct framework to proactively identify and mitigate those risks. The SAFER Guides include clinical process guides targeting recommendations focused on patient identification, computerized provider order entry with decision support, test results reporting and follow-up, and clinician communication, which are important patient safety topics not included in, nor are the focus of, security risk analysis. The SAFER Guides' foundational guide focuses on high priority practices and organizational responsibilities, and the infrastructure guide focuses on contingency planning and system management. These are useful and complementary to conducting a security risk analysis, but do not duplicate or replace it. The security risk analysis, consistent with the HIPAA Security Rule requirements, is a comprehensive assessment of all potential risks to the confidentiality, integrity, and availability of ePHI created or maintained by CEHRT. A self- assessment using the SAFER Guides would not constitute a complete security risk analysis, nor would a security risk analysis, lacking any guidance for appropriate approaches to clinical processes using EHRs, constitute a self-assessment using the complete set of SAFER Guides.

We appreciate the suggestion to work with stakeholders to assess the burden and effectiveness of the SAFER Guides and explore alternative tools for assessing EHR safety. We are committed to engaging with hospitals, health IT vendors, and other stakeholders to ensure the SAFER Guides are practical, effective, and aligned with industry needs.

Comment: Many commenters provided recommendations to address concerns about the SAFER Guides measure. These commenters suggested allowing hospitals to submit evidence of participation in recognized EHR safety programs or certifications as an alternative to attestation, phasing in the implementation of the 2025 SAFER Guides over multiple years or offering partial credit to reduce the burden on small or under-resourced hospitals, and providing flexibility for hospitals to choose between the 2016 and 2025 guides during CY 2025 to facilitate the transition.

Several commenters highlighted the importance of targeted education, streamlined tools, and technical assistance to help eligible hospitals and CAHs to complete the self-assessments more effectively. A few commenters recommended expanding access to technical assistance resources, exploring grant opportunities for resource-limited institutions, and collecting data on completion of self-assessments using the SAFER Guides, disaggregated by hospital size, location, and ownership types. A few commenters requested CMS clarify the timeline for transitioning from the 2016 to 2025

SAFER Guides and suggested allowing eligible hospitals and CAHs to earn bonus points for early adoption of the updated guides.

A few commenters emphasized the need to balance safeguarding patient data with minimizing administrative burden, particularly for rural and resource-constrained hospitals.

Response: We appreciate the feedback and recommendations provided by commenters regarding the SAFER Guides measure. Based on our general understanding of recognized EHR safety programs and certifications, we believe the suggested approach to allow hospitals to submit evidence of participation in these programs as an alternative to attestation would not be as comprehensive as the topics covered in the SAFER Guides, nor would it be less burdensome to report the information to CMS. We recognize the importance of ensuring the SAFER Guides measure is both effective in promoting EHR safety and that it is feasible for eligible hospitals and CAHs across varying resource levels to meet measure requirements.

We reiterate that during the EHR reporting period in CY 2025, eligible hospitals and CAHs should continue to use the 2016 SAFER Guides for their self-assessment. Both the 2016 and the 2025 SAFER Guides are available on the ASTP website at: https://www.healthit.gov/topic/safety/safer-guides. We encourage eligible hospitals and CAHs to begin to familiarize themselves with the 2025 SAFER Guides during CY 2025. We appreciate commenters' eagerness to begin using the 2025 SAFER Guides earlier than the EHR reporting period in CY 2026, however, allowing one full year for the industry to review the updated guides will allow for uniform adoption beginning with the EHR reporting period in CY 2026 and subsequent years.

We acknowledge the importance of targeted education, streamlined tools, and technical assistance to help eligible hospitals and CAHs complete assessments effectively, as highlighted by several commenters. In response to prior feedback from the public, the 2025 version of the SAFER Guides has been updated and streamlined compared to the 2016 version. First, there was a reduction from nine guides to eight guides, with each guide organized into one of three broad categories focused on foundational best practices, infrastructure best practices, and clinical process best practices. Each of the eight individual guides includes an extensive set of references offering additional detailed information and evidence. There are also public resources available to eligible hospitals and CAHs that are completing the self- assessments.\394\ We appreciate the emphasis placed by commenters on balancing the need to safeguard patient data with minimizing administrative burden, particularly for rural and resource-constrained hospitals. We remain committed to engaging with stakeholders and consider the feasibility of implementation strategies that address the concerns raised. We appreciate the continued collaboration and input from stakeholders.

\394\ One such source of information about the 2025 SAFER Guides is an academic paper titled, “Guidelines for US Hospitals and Clinicians on Assessment of Electronic Health Record Safety Using SAFER Guides,” written by the authors of the SAFER Guides. This paper is available to download or use at https://jamanetwork.com/journals/jama/article-abstract/2788984.

After consideration of the public comments we received, we are finalizing our proposal to modify the SAFER Guides measure to require eligible hospitals and CAHs to conduct an annual self-assessment using all eight of the 2025 SAFER Guides at any point during the calendar year in which the EHR reporting period occurs, beginning with the EHR reporting period in CY 2026 and in subsequent years. 5. Modification to the Public Health and Clinical Data Exchange Objective: Adoption of an Optional Bonus Measure for Public Health Reporting Using the Trusted Exchange Framework and Common Agreement\TM\ (TEFCA) a. Background on the Public Health and Clinical Data Exchange Objective

The Medicare Promoting Interoperability Program for eligible hospitals and CAHs encourages health information exchange for public health purposes through the Public Health and Clinical Data Exchange objective. Effective and efficient responses to public health events require rapid, accurate exchange of electronic health information between health care providers, including eligible hospitals and CAHs, and Federal, State, Tribal, local, and territorial public health agencies (PHAs). Health care providers, including eligible hospitals and CAHs, collect this electronic health information for patient care, and PHAs use the information for public health purposes such as tracking a disease, initiating contact tracing, or pinpointing the source of a disease or outbreak of foodborne illness.

There are currently eight measures under the Public Health and Clinical Data Exchange objective: Immunization Registry Reporting, Syndromic Surveillance Reporting, Electronic Case Reporting, Electronic Laboratory Reporting, Antimicrobial Use Surveillance, Antimicrobial Resistance Surveillance, Public Health Registry Reporting, and Clinical Data Registry Reporting. Six of these measures are required under the objective, while two, the Public Health Registry Reporting and Clinical Data Registry Reporting, are optional bonus measures. Eligible hospitals and CAHs may receive a total of 5 bonus points for reporting on one or both optional bonus measures.

Measures under the Public Health and Clinical Data Exchange objective promote the exchange of health information for specific public health use cases with PHAs and other entities using CEHRT. However, one difficulty with the electronic exchange of health information for many different public health purposes is that exchanging data between PHAs and eligible hospitals and CAHs requires different processes. For instance, health information exchange for Electronic Case Reporting may be based on several point-to-point connections among eligible hospitals, CAHs, intermediaries, and PHAs, but these connections and agreements are different for other use cases such as Electronic Laboratory Reporting or Syndromic Surveillance. We anticipate that participation in TEFCA could help reduce the difficulty of public health information exchange over time by creating a common governance and technical framework for health information exchange. Facilitating health information exchange with PHAs through the TEFCA framework has the potential to increase standardization of connections to PHAs and reduce reporting burden for eligible hospitals, CAHs, and PHAs. b. Background on TEFCA

Section 4003(b) of the 21st Century Cures Act, enacted in 2016, amended section 3001(c) of the Public Health Service Act and required HHS to take steps to ensure full network-to-network exchange of health information. Specifically, in section 3001(c)(9)(A) of the Public Health Service Act, Congress directed the National Coordinator, in collaboration with NIST and other agencies within HHS, to “develop or support a trusted exchange framework, including a common agreement among health information networks nationally.” Since the enactment of the 21st Century Cures Act, HHS has pursued development of the TEFCA framework.

By standardizing health information exchange across many different networks, TEFCA helps to ensure

nationwide network-to-network exchange of health information. Standardization across networks simplifies health information exchange by reducing the number of connections that health care providers, including eligible hospitals and CAHs, PHAs, and other interested parties need to make to send and receive health information. TEFCA supports this standardization by creating baseline governance, legal, and technical requirements that enable secure health information exchange across different networks nationwide, including: a common method for authenticating trusted network participants, a common set of rules for trusted exchange, organizational and operational policies to enable the exchange of health information among networks, and a process for filing and adjudicating noncompliance with the terms of the Common Agreement.\395\ We anticipate that TEFCA can help expand the nationwide availability of secure health information exchange capabilities in public health reporting.

\395\ Additional information on TEFCA can be found on the ASTP website, available at: https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca.

CMS, the Centers for Disease Control and Prevention (CDC), and ASTP/ONC have been working closely with PHAs and other interested parties to expand the use of TEFCA for sharing health information for public health purposes. TEFCA is an important part of a shared vision for building a modernized public health infrastructure that connects previously siloed public health and health care systems. Early efforts to enable public health reporting through TEFCA exchange have focused on electronic case reporting, which is likely to be the primary mechanism of public health information exchange supported by entities that are part of TEFCA during CY 2026. c. Adding an Optional Bonus Measure Under the Public Health and Clinical Data Exchange Objective Beginning with the EHR Reporting Period in CY 2026

In the FY 2026 IPPS/LTCH PPS proposed rule (90 FR 18359 through 18361), we proposed to add a third optional bonus measure under the Public Health and Clinical Data Exchange objective for health information exchange with a PHA that occurs using TEFCA. Specifically, beginning with the EHR reporting period in CY 2026, we proposed the following optional bonus measure:

Public Health Reporting Using TEFCA. The eligible hospital or CAH: (1) participates as a signatory to a Framework Agreement (as that term is defined by the Common Agreement for Nationwide Health Information Interoperability as published in the Federal Register and on ASTP/ONC's website) \396\; (2) is not suspended; (3) submits health information using TEFCA to a PHA consistent with one or more of the measures under the Public Health and Clinical Data Exchange objective; (4) is in active engagement Option 2 (validated data production) with a PHA to transfer health information for one or more of the measures under the Public Health and Clinical Data Exchange objective; and (5) uses the functions of CEHRT to exchange data with the PHA.

\396\ See Common Agreement for Nationwide Health Information Interoperability Version 2.1 November 2024 at: https://www.healthit.gov/sites/default/files/2024-11/Common_Agreement_2.1.pdf.

As previously finalized in the FY 2023 IPPS/LTCH final rule (87 FR 49339), for the measures in the Public Health and Clinical Data Exchange objective, eligible hospitals and CAHs are required to report their level of active engagement as either Option 1 (pre-production and validation) or Option 2 (validated data production) and may only spend one EHR reporting period at the pre-production and validation level of active engagement (Option 1) before advancing to Option 2 (validated data production) to fulfill measure requirements. Under our proposal, the bonus measure would only be available when the eligible hospital or CAH is in active engagement Option 2 (validated data production) with a PHA to transfer health information for one or more of the measures under the Public Health and Clinical Data Exchange objective.

Under our proposal, to attest “yes” for the Public Health Reporting Using TEFCA optional bonus measure, an eligible hospital or CAH must be a signatory to a TEFCA Framework Agreement,\397\ meaning either the Common Agreement or an agreement that includes the Participant/Sub-participant Terms of Participation,\398\ and is not suspended under the respective agreement. To attest “yes” for this bonus measure, an eligible hospital or CAH must transmit electronic health information for at least one measure under the Public Health and Clinic Data Exchange objective using TEFCA. Finally, the eligible hospital or CAH must use the functions of CEHRT to engage in a data exchange with a PHA.

\397\ The Common Agreement defines “Framework Agreement(s)” as: “any one or combination of the Common Agreement, a Participant- QHIN Agreement, a Participant-Subparticipant Agreement, or a Downstream Subparticipant Agreement, as applicable.” See Common Agreement for Nationwide Health Information Interoperability Version 2.1 (Nov 2024)

https://www.healthit.gov/sites/default/files/2024-11/Common_Agreement_2.1.pdf.

\398\ Participant/Subparticipant Terms of Participation (Apr. 2024), https://rce.sequoiaproject.org/wp-content/uploads/2024/05/Common-Agreement-v2.0-Exhibit-1_508.pdf.

We believe there are numerous certified health IT capabilities that can support exchange with a PHA under a TEFCA Framework Agreement. For instance, eligible hospitals or CAHs may exchange information under TEFCA by using technology certified to the health IT certification criteria, “Transmission to public health agencies--reportable laboratory tests and value/results” at 45 CFR 170.315(f)(3) and “Transmission to public health agencies--electronic case reporting” at 45 CFR 170.315(f)(5). Both criteria are associated with the exchange use cases currently identified under the TEFCA Public Health Exchange Purpose Implementation SOP. We further recognize that eligible hospitals and CAHs may connect to entities that connect directly or indirectly to a Qualified Health Information Network\TM\ \399\ (QHIN) using certified health IT in a variety of ways. This includes the other ONC health IT certification criteria at 45 CFR 170.315(f) associated with the Public Health and Clinical Data Exchange objective measures, and we believe that we should allow for substantial flexibility in how eligible hospitals and CAHs use certified health IT to exchange health information under a TEFCA Framework Agreement.

\399\ A Qualified Health Information Network is a health information network that facilitates TEFCA exchange by undergoing technology and security testing, onboarding, and designation. For more information, see: https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca.

For more information about exchange of public health data using TEFCA, we refer readers to the TEFCA Public Health Exchange Purpose Implementation Standard Operating Procedure (SOP).\400\ The Public Health Exchange Purpose Implementation SOP currently identifies electronic case reporting and electronic laboratory reporting as exchange use cases, but the SOP can also be used for any allowable public health purpose. CDC, ASTP/ONC, and others are focused on establishing a foundation for health care providers, including eligible hospitals and CAHs, to use TEFCA to meet their public health reporting needs for the benefit of both public health and clinical care.

\400\ For more information, see https://rce.sequoiaproject.org/wp-content/uploads/2024/08/XP-Implementation-SOP-Public-Health-PH.pdf.

In the FY 2026 IPPS/LTCH PPS proposed rule (90 FR 18359 through 18361), we proposed that an eligible hospital or CAH may earn a total of 5 bonus points if it attests “yes” for one of the following optional bonus measures: the Public Health Reporting Using TEFCA measure, the Public Health Registry Reporting measure, or the Clinical Data Registry Reporting measure. Eligible hospitals and CAHs may attest “yes” to more than one but can only earn a total of 5 bonus points even if the eligible hospital or CAH attests “yes” to multiple bonus measures. Because the Public Health Reporting Using TEFCA measure would be an optional bonus measure, we did not propose any exclusions. We also proposed that if an eligible hospital or CAH uses TEFCA to fulfill any of the required Public Health and Clinical Data Exchange objective measures, such as Electronic Case Reporting or Electronic Laboratory Reporting, that eligible hospital or CAH would be able to claim the 5 bonus points if it attests “yes” to the Public Health Reporting Using TEFCA bonus measure in addition to earning points for fulfilling the requirements of the required measure(s).

We invited public comment on our proposal to adopt an optional bonus measure under the Public Health and Clinical Data Exchange Objective to permit an eligible hospital or CAH to earn a total of 5 bonus points if it is participating as a signatory to a TEFCA Framework Agreement, is not suspended, and submits health information using TEFCA to a PHA consistent with one or more of the measures under the Public Health and Clinical Data Exchange objective, is in active engagement Option 2 (validated data production) with a PHA to transfer health information for one or more of the measures under the Public Health and Clinical Data Exchange objective, and uses the functions of CEHRT to exchange with the PHA.

Comment: Many commenters supported our proposal to create an optional bonus measure for public health reporting using TEFCA. Many commenters supported the proposal because they stated it provides an appropriate incentive to encourage health information exchange between PHAs and health care systems, continues to invest in technical modernization, and improves the capacity for public health surveillance and interventions.

Response: We thank commenters for their responses. We agree that the goal of this bonus measure is to encourage public health information exchange, technical modernization, and improved public health capacity.

Comment: Several commenters supported the proposal and stated it would lead to benefits such as reduced workforce requirements, improved use of data exchange standards, reduced burden during public health crises, faster onboarding, improved data quality, and streamlined public health reporting workflows that would improve PHAs' ability to act upon timely and reliable data. Another commenter stated it would lead to less administrative burden from state agency specification changes and EHR vendor updates.

Response: We thank commenters for their responses. We anticipate that continued improvements in public health information exchange, such as methods relying upon TEFCA, will be beneficial for those eligible hospitals and CAHs that use them.

Comment: A few commenters supported the proposal and stated that the optional rather than required status of the measure would allow participants time and flexibility to engage in public health reporting using TEFCA as well as provide information as to its use for real world reporting. They stated that with the measure being optional, this will appropriately encourage adoption and crediting early adopters.

Response: We agree that an optional rather than required measure will allow eligible hospitals and CAHs more time and flexibility to adopt the measure and evaluate the utility of TEFCA for public health reporting purposes. While we do not require the measure currently, we encourage eligible hospitals and CAHs to consider the use of advanced protocols for public health data exchange.

Comment: A few commenters supported the proposal and recommended that CMS assess hospital and health system experiences with adopting the measure for future policymaking. A commenter recommended CMS treat the measure as informational or developmental in early years and ensure rural and community-based hospitals have clear, low-cost pathways to participate.

Response: We thank commenters for their responses and note we do consider the experiences of eligible hospitals and CAHs when considering all potential measures for the Medicare Promoting Interoperability Program. We are open to modifying or adjusting program measures if experiences of eligible hospitals and CAHs show this to be necessary. We will continue to work with the CDC and ASTP/ONC to find opportunities to lower barriers to participation among rural and community-based hospitals.

Comment: A few commenters supported the proposal but were concerned about the disproportionate burden the optional measure requirements may impose on small, rural, or under-resourced hospitals. These commenters were also concerned that smaller, under-resourced hospitals might not benefit from the optional measure due to the technical capabilities needed to support data exchange.

Response: One reason we proposed the Public Health Reporting Using TEFCA measure as an optional measure rather than a required one is because requiring the measure may have otherwise caused undue hardship for small, rural, or under-resourced eligible hospitals and CAHs. One goal of the optional bonus measure is to encourage the use of networks participating in nationwide exchange under TEFCA without unfairly penalizing eligible hospitals or CAHs that are not yet ready to participate in such networks and may need additional time and flexibility. Eligible hospitals and CAHs that are not ready to participate in exchange under TEFCA can still receive the 5 bonus points by reporting on either the Public Health Registry Reporting measure, the Clinical Data Registry Reporting measure, or both.

Comment: A commenter supported the proposal and recommended maintaining the existing options for exchange with PHAs.

Response: We thank the commenter for the support and recommendation to maintain existing options for exchange to PHAs. Our proposal to add an optional bonus measure for public health reporting using TEFCA is intended to complement, not replace, current exchange methods under the Public Health and Clinical Data Exchange objective. Eligible hospitals and CAHs will continue to have flexibility to use existing standards- based infrastructure and intermediaries to meet reporting requirements regardless of their direct or indirect participation in TEFCA. By establishing this optional measure, we aim to incentivize early adopters while ensuring that hospitals and CAHs can continue using their current arrangements for information exchange and reporting without disruption.

Comment: A commenter supported the proposal but recommended that the measure definition be refined to only count Level 2 exchange use cases within the TEFCA Public Health Exchange Purpose Implementation Standard

Operating Procedure because those have better defined standards.

Response: In the TEFCA Exchange Purpose Implementation Standard Operating Procedure, Level 2 use cases refer to more specific data exchange contexts with accompanying exchange standards.\401\ Although we recognize the value of focusing on more mature and standardized use cases, such as the Level 2 exchange use cases, our proposal aims to provide flexibility for eligible hospitals and CAHs to engage in public health reporting using TEFCA across a variety of use cases. Limiting the measure to Level 2 use cases at this time could restrict participation and hinder measure adoption. However, we will monitor rates of adoption and consider proposing refinements to the measure in the future based on stakeholder feedback and real-world experience with TEFCA-supported exchanges.

\401\ For more information about Level 2 use cases, see the Exchange Purpose Implementation Standard Operating Procedure at: https://rce.sequoiaproject.org/wp-content/uploads/2024/08/XP-Implementation-SOP-Public-Health-PH.pdf.

Comment: A commenter supported the proposal and encouraged CMS to continue allowing flexibility in determining which certified health IT capabilities can be used to meet the specifications of this optional measure.

Response: We thank the commenter for their support. We agree that flexibility is necessary to accommodate the diverse technical environments and resources of eligible hospitals and CAHs. Our proposal is designed to allow eligible hospitals and CAHs to leverage various certified health IT capabilities to exchange data using TEFCA, ensuring they can choose the solutions that best fit their operational needs. We remain committed to supporting adaptable approaches that promote participation while minimizing burden, and we will continue to evaluate opportunities to enhance flexibility as TEFCA evolves.

Comment: Several commenters did not support the proposal to create an optional bonus measure for public health reporting using TEFCA. A few commenters did not support the proposal because they wanted CMS to allow a variety of options rather than one option using TEFCA. They recommended that including a variety of options would allow entities that are capable of public health reporting via TEFCA to pursue that path, while also allowing entities that have other standards-based and governance-supported infrastructures to continue to use what they have without re-architecting their infrastructure.

Response: We acknowledge commenters' concerns about ensuring flexibility in public health reporting options. Our proposal to create an optional bonus measure for public health reporting using TEFCA is intended to complement, not replace, existing pathways for meeting the Public Health and Clinical Data Exchange objective. Eligible hospitals and CAHs can continue using their current standards-based and governance-supported infrastructure to fulfill required measures, regardless of whether the intermediaries or other entities supporting current arrangements participate directly or indirectly in TEFCA. We recognize that many HIEs and other intermediaries across the country not yet participating in TEFCA continue to provide significant value to users reporting data to public health agencies. We remain committed to supporting diverse approaches to public health reporting that accommodate the varied capabilities and resources of stakeholders.

Comment: A few commenters did not support the proposal because they were concerned about a lack of clarity with respect to HIPAA protections and the use of the TEFCA. These commenters specifically raised concerns with respect to queries and exchanges without explicit patient permission, recent HIPAA protections of reproductive health, and the use of record locator services in TEFCA. The commenters were concerned that use of TEFCA may breach HIPAA protections by revealing through a record locator service without a patient's consent that they had sought certain medical services such as at a substance use clinic.

Response: TEFCA is designed to operate within the framework of existing privacy and security laws, including HIPAA, and does not override these protections.\402\ Any exchange of health information using TEFCA must comply with applicable federal and state privacy laws, including those governing sensitive health information. The HIPAA Privacy Rule permits covered entities to use or disclose protected health information for treatment, payment, or health care operations without first obtaining an individual's authorization for such use or disclosure. We will continue to work closely with stakeholders to ensure that measures that reference TEFCA-supported exchange uphold high standards of privacy and security while enabling effective public health reporting. Additionally, we welcome ongoing feedback to address specific concerns and improve clarity around measures that reference the use of TEFCA.

\402\ For details regarding compliance with the HIPAA Privacy Rule among signatories to the Common Agreement, see the Common Agreement at: https://rce.sequoiaproject.org/wp-content/uploads/2024/11/Common-Agreement-2.1_ASTP-508.pdf.

Comment: A few commenters did not support the proposal because they believe there are flaws in TEFCA as a method of data exchange. Commenters stated that they believe TEFCA limits the digital enablement needed for the health care sector, that it is cumbersome and at odds with the technical underpinnings needed for digital applications, and that it is exclusionary because smaller hospitals and CAHs do not connect to QHINs for lack of financial and human resources.

Response: TEFCA is designed to create a standardized framework for secure, nationwide health information exchange, and we recognize that its expansion may require adjustments to address barriers for under- resourced entities. By making the Public Health Reporting Using TEFCA measure optional, we aim to encourage adoption of the measure without imposing undue burden on smaller hospitals and CAHs that may face financial or technical challenges. We remain committed to working with stakeholders to refine program measures to improve accessibility and ensure that they meet the needs of smaller and rural eligible hospitals and CAHs.

Comment: A commenter did not support the proposal and believes that all public health reporting should be done through Health Information Exchanges (HIEs) in states that have them. The commenter believes that CMS should provide strong incentives to form HIEs in states that lack them.

Response: We recognize the important role that HIEs play in facilitating public health reporting at the state level. Our proposal to introduce an optional bonus measure for public health reporting using TEFCA is intended to complement existing infrastructure, including HIEs, rather than replace or compete with them. TEFCA provides a standardized, nationwide framework that supports broader data exchange capabilities that can enhance interoperability across networks, including HIEs. We also note that we support the use of HIEs through the HIE Bi-Directional Exchange measure under the Health Information Exchange objective.

Comment: A commenter did not support the proposal, stating that HIEs are already connected to QHINs and already transmit public health data to

PHAs through TEFCA. The commenter recommended that CMS simplify the scored and bonus categories rather than adding a TEFCA-specific bonus measure.

Response: We acknowledge the commenter's perspective regarding potential redundancy with the proposed TEFCA-specific optional bonus measure. While some HIEs may already connect to QHINs and transmit public health data, some do not, and some may not effectively transfer public health information between networks. The optional bonus measure is intended to incentivize broader interoperability and electronic exchange of health information. We appreciate the recommendation to simplify scored and bonus categories and will continue to evaluate opportunities to streamline program measures in future rulemaking.

Comment: A commenter did not support the proposal because of a concern that TEFCA is not yet a viable national reporting mechanism. The commenter stated that readiness across hospitals, PHAs, and QHINs remains uneven.

Response: We acknowledge the concerns regarding the current readiness of hospitals, public health agencies, and QHINs to fully implement TEFCA as a national reporting mechanism. The Public Health Reporting Using TEFCA measure is intentionally designed as an optional bonus measure to encourage early adoption of this measure in order to foster the electronic exchange of health information and provide flexibility for eligible hospitals and CAHs while TEFCA continues to mature. This approach would allow stakeholders to explore the benefits of TEFCA without imposing requirements that could create challenges for entities not yet prepared to participate.

Comment: Several commenters recommended that CMS work with other HHS agencies to continue investing in public health reporting. The comments included recommendations that CMS continue to invest in TEFCA and in public health data systems' capabilities and that CMS explore mechanisms to encourage state and local PHAs to expand their engagement with TEFCA. Commenters also recommended that CMS work with CDC and ASTP/ONC to build upon and improve TEFCA. Another commenter added that TEFCA should continue to evolve over time to reflect advances in data exchange so that burden and cost are both reduced.

Response: We thank commenters for their recommendations and agree on the importance of continued collaboration with other HHS agencies to invest in public health reporting infrastructure. CMS is committed to working closely with the CDC, ASTP/ONC, and other stakeholders to enhance TEFCA and support the modernization of public health data systems. We also recognize the need to encourage state and local public health agencies to expand their engagement with TEFCA and to ensure its evolution reflects advances in data exchange, reducing both burden and cost for participants. We will continue to prioritize partnerships that strengthen public health reporting capabilities and improve interoperability across the health care and public health sectors.

Comment: A few commenters requested clarification on the proposal. A commenter requested clarification whether an eligible hospital or CAH that used TEFCA for electronic case reporting would attest “yes” to both the proposed optional bonus measure and the Electronic Case Reporting required measure. Another commenter asked for clarification on whether eligible hospitals and CAHs can attest to both the Enabling Exchange under TEFCA measure under the Health Information Exchange objective and the optional bonus measure or if they can only attest to one TEFCA measure.

Response: We thank commenters for their questions and appreciate the opportunity to provide clarification. An eligible hospital or CAH that uses TEFCA for electronic case reporting should attest “yes” to both the proposed Public Health Reporting Using TEFCA optional bonus measure and the required measure under the Public Health and Clinical Data Exchange objective if it used TEFCA to fulfill the measure's requirements, assuming it meets all of the measures' specifications. Additionally, eligible hospitals and CAHs may attest to both the Enabling Exchange under TEFCA measure under the Health Information Exchange objective and the Public Health Reporting Using TEFCA optional bonus measure, as these measures address use of TEFCA to meet different elements of the Medicare Promoting Interoperability Program. However, eligible hospitals and CAHs can only earn five bonus points, even if they report on multiple bonus measures.

Comment: A few commenters encouraged CMS to provide technical assistance resources and grant opportunities to help resource-limited institutions participate in TEFCA. Among these, a commenter recommended that CMS publish a TEFCA readiness framework that would include benchmarks for PHA onboarding, QHIN participation, and EHR vendor integration.

Response: We recognize the challenges faced by smaller and under- resourced eligible hospitals and CAHs and are committed to exploring ways to reduce barriers to participation. We appreciate the suggestion to publish a TEFCA readiness framework with benchmarks for public health agency onboarding, QHIN participation, and EHR vendor integration. We will continue to collaborate with other HHS agencies and stakeholders to identify opportunities for technical support and funding mechanisms that promote access to TEFCA and strengthen public health reporting capabilities.

Comment: A few commenters recommended that CMS collect and publish data on TEFCA enrollment and participation. A commenter requested data disaggregated by hospital size, location, and ownership type. Another commenter recommended the collection of patient-level data sources that they believe would improve the comprehensiveness of surveillance initiatives.

Response: We agree that transparency and data collection are useful for evaluating the adoption and impact of TEFCA and could provide valuable insights into participation trends. We will explore opportunities to collaborate with stakeholders and other HHS agencies to gather and share meaningful data that supports the advancement of TEFCA and public health reporting efforts. While patient-level data sources may enhance the comprehensiveness of surveillance initiatives, we remain committed to ensuring that any data collection aligns with privacy and security standards.

Comment: A commenter recommended including Option 1 of Active Engagement as fulfilling the measure because the commenter believes that TEFCA is still in early stages of adoption and implementation and limiting the measure to Option 2 will limit its applicability.

Response: While we recognize that TEFCA is still in its early stages, the intent of the measure is to incentivize the electronic exchange of health information, which we believe is best reflected by validated data production under Option 2, in which eligible hospitals and CAHs are actively exchanging production-level data with public health agencies. This approach aligns with the goal of promoting meaningful and actionable public health reporting. However, we understand the importance of supporting entities in earlier stages of engagement and will continue to monitor TEFCA's implementation to assess whether adjustments to the measure criteria are

warranted in the future to enhance its applicability and encourage broader participation.

Comment: A commenter recommended that measures related to TEFCA participation remain optional.

Response: We agree that flexibility is important, particularly as TEFCA is still in its early stages of adoption and implementation. By proposing the Public Health Reporting Using TEFCA measure as an optional bonus measure, we aim to avoid imposing undue burden on eligible hospitals and CAHs that may not yet have the resources or infrastructure to participate.

Comment: A commenter recommended making public health reporting with TEFCA mandatory but cautions that hospitals and PHAs would require sufficient time for adoption.

Response: We thank the commenter for the recommendation. We believe establishing the Public Health Reporting Using TEFCA measure as an optional bonus measure is the most appropriate approach at this time because it provides flexibility for eligible hospitals and CAHs while TEFCA continues to mature and expand its adoption. This optional status allows eligible hospitals and CAHs to explore TEFCA's benefits without imposing immediate requirements that could create challenges for entities still developing the necessary infrastructure.

Comment: A commenter was concerned that the 5 bonus points could dilute the incentive to report on multiple bonus measures. They recommended that CMS consider allowing eligible hospitals and CAHs to earn 5 points for each bonus measure they meet and report on.

Response: We designed the scoring structure to balance the opportunity for eligible hospitals and CAHs to earn bonus points while maintaining fairness and simplicity within the program. Allowing 5 points for each bonus measure could disproportionately shift the focus away from required measures and complicate the scoring methodology. The current approach encourages participation in bonus measures while ensuring the overall emphasis remains on fulfilling required objectives. However, we will continue to evaluate the effectiveness of the scoring methodology and may consider adjustments in future rulemaking based on stakeholder feedback and program outcomes.

Comment: A commenter was concerned about reporting the level of Active Engagement for measures in the Public Health and Clinical Data Exchange objective, including the proposed optional bonus measure. The commenter believed that eligible hospitals and CAHs are penalized if state agencies are not ready to promote hospitals to validated data production (Option 2). The commenter recommended that CMS add an exclusion to the effect that if the state or public health agency is unready or unable to move a hospital from pre-production to production reporting, the eligible hospital or CAH may be exempt from the measure.

Response: We recognize that some eligible hospitals and CAHs may face barriers to advancing from pre-production (Option 1) to validated data production (Option 2) if their state or PHA is not prepared to support production-level reporting. While the proposed Public Health Reporting Using TEFCA measure is an optional bonus measure and does not negatively impact scoring for eligible hospital and CAHs that do not participate, we understand the importance of ensuring fairness in reporting requirements.

For required measures, we remind eligible hospitals and CAHs that they may be able to claim an exclusion under the measure and therefore receive full credit. Specifically, any eligible hospital or CAH may be excluded from reporting on a Public Health and Clinical Data Exchange measure, such as Electronic Laboratory Reporting or Electronic Case Reporting if it operates in a jurisdiction for which no PHA is capable of receiving data in the specific standards required to meet the CEHRT definition at the start of the EHR reporting period. For those measures with a relevant exclusion in the Public Health and Clinical Data Exchange objective, CMS interprets “capable of receiving data in the specific standards required” in this exclusion to mean that the PHA in the eligible hospital's or CAH's jurisdiction has the ability to advance, and has advanced, an eligible hospital or CAH registered with the PHA to Active Engagement Option 2: Validated Data Production. Please also see section X.F.1. of the preamble of this final rule for additional discussion regarding this issue.

After consideration of the public comments we received, we are finalizing our proposal to add an optional bonus measure for Public Health Reporting Using TEFCA under the Public Health and Clinical Data Exchange objective, beginning with the EHR reporting period in CY 2026. Eligible hospitals and CAHs may earn a maximum of 5 bonus points under the Public Health and Clinical Data Exchange objective for reporting on any or all of the optional bonus measures. 6. Overview of Scoring Methodology for the EHR Reporting Period in CY 2026

In the FY 2019 IPPS/LTCH PPS final rule (83 FR 41636 through 41641), we adopted a performance-based scoring methodology for eligible hospitals and CAHs reporting to the Medicare Promoting Interoperability Program beginning with the EHR reporting period in CY 2019. This methodology included a minimum scoring threshold that eligible hospitals and CAHs were required to meet, in addition to the requirement to report on the objectives and measures of meaningful use, both under 42 CFR 495.24(e)(1), to be considered a meaningful EHR user under 42 CFR 495.4. In the FY 2025 IPPS/LTCH PPS final rule (89 FR 69616 through 69618), we finalized a proposal to increase the performance-based scoring threshold to at least 70 points for the EHR reporting period in CY 2025 and to at least 80 points beginning with the EHR reporting period in CY 2026 and subsequent years.

As shown in Table X.F.-02., the points associated with the required measures sum to 100 points, and reporting on one or more of the optional bonus measures offers an additional 5 total bonus points. The scores for each of the required measures and bonus measures are added together to calculate a total score of up to 105 possible points for each eligible hospital or CAH. We refer readers to Table X.F.-02. in this final rule, which reflects the objectives, measures, maximum points available, and whether a measure is required or optional for the EHR reporting period in CY 2026 and subsequent years based on our previously adopted policies and newly finalized policies included in this final rule. BILLING CODE 4120-01-P

[GRAPHIC] [TIFF OMITTED] TR04AU25.283

BILLING CODE 4120-01-C

The maximum number of points available by measure in this final rule does not include the points that would be redistributed in the event an exclusion is claimed for a given measure. We did not propose any changes to our policy for point redistribution in the event an exclusion is claimed. We refer readers to Table X.F.-03. in the preamble of this final rule, which shows point redistribution among the objectives and measures for the EHR reporting period in CY 2026 and subsequent years, in the event an eligible hospital or CAH claims an exclusion.

[GRAPHIC] [TIFF OMITTED] TR04AU25.284

In addition to the policies discussed in Section X.F.1. in this final rule, we also refer readers to the CY 2026 PFS proposed rule where we have proposed to adopt a measure scoring suppression policy beginning with the EHR reporting period in CY 2026 and proposed to suppress the Electronic Case Reporting measure from scoring for the EHR reporting period in CY 2025 (90 FR 32732 through 32736). We invite public comment on those proposals through the CY 2026 PFS proposed rule. 7. Overview of Objectives and Measures for the Medicare Promoting Interoperability Program for the EHR Reporting Period in CY 2026

For ease of reference, Table X.F.-04. lists objectives and measures for the Medicare Promoting Interoperability Program for the EHR reporting period in CY 2026, as revised to reflect the finalized policies in this final rule, and Table X.F.-05. lists the ONC Health IT Certification Program certification criteria required to meet the Medicare Promoting Interoperability Program objectives and measures. We also refer readers to section XI.B of this final rule for discussion of certain policies including certain certification criteria being finalized by ASTP. BILLING CODE 4120-01-P

[GRAPHIC] [TIFF OMITTED] TR04AU25.285

[GRAPHIC] [TIFF OMITTED] TR04AU25.286

[GRAPHIC] [TIFF OMITTED] TR04AU25.287

[GRAPHIC] [TIFF OMITTED] TR04AU25.288

[GRAPHIC] [TIFF OMITTED] TR04AU25.289

[GRAPHIC] [TIFF OMITTED] TR04AU25.290

[GRAPHIC] [TIFF OMITTED] TR04AU25.291

[GRAPHIC] [TIFF OMITTED] TR04AU25.292

[GRAPHIC] [TIFF OMITTED] TR04AU25.293

[GRAPHIC] [TIFF OMITTED] TR04AU25.294

[GRAPHIC] [TIFF OMITTED] TR04AU25.295

[GRAPHIC] [TIFF OMITTED] TR04AU25.296

[GRAPHIC] [TIFF OMITTED] TR04AU25.297

[GRAPHIC] [TIFF OMITTED] TR04AU25.298

Under sections 1814(l)(3)(A) and 1886(n)(3)(A) of the Act and the definition of “meaningful EHR user” under 42 CFR 495.4, eligible hospitals and CAHs must use CEHRT to report on clinical quality measures selected by the Secretary (also referred to as electronic clinical quality measures, or eCQMs), as part of the Medicare Promoting Interoperability Program.

Table X.F.-06. summarizes the previously finalized required and self-selected eCQMs available for eligible hospitals and CAHs to report under the Medicare Promoting Interoperability Program for the CY 2026 reporting period and subsequent years. [GRAPHIC] [TIFF OMITTED] TR04AU25.299

BILLING CODE 4120-01-C

We did not propose, nor are we finalizing in this final rule, any changes to the eCQMs for eligible hospitals and CAHs participating in the Medicare Promoting Interoperability Program. 9. Requests for Information (RFI)

In the FY 2026 IPPS/LTCH PPS proposed rule (90 FR 18371 through 18377), we solicited public comment on several areas involving the Medicare Promoting Interoperability Program. These areas included requests for information on changing the Query of PDMP measure from an attestation-based measure to a performance-based measure, modification of the Query of PDMP measure to include all Schedule II drugs, performance-based measures in the Public Health and Clinical Data Exchange objective and improving data quality.

We would like to thank commenters for the feedback, support, and responses we have received. We may consider this feedback in future rulemaking. Because we did not propose any policies in these RFIs, we have not summarized the comments we received in response to them.