Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing

AGENCY:

Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS).

ACTION:

Final rule.

SUMMARY:

This final rule implements the Electronic Health Record (EHR) Reporting Program provision of the 21st Century Cures Act by establishing new Conditions and Maintenance of Certification requirements for health information technology (health IT) developers under the ONC Health IT Certification Program (Program). This final rule also makes several updates to certification criteria and standards recognized by the Program. The Program updates include revised certification criteria for “decision support interventions,” “patient demographics and observations,” and “electronic case reporting,” as well as a new baseline version of the United States Core Data for Interoperability (USCDI) standard to Version 3. Additionally, this final rule provides enhancements to support information sharing under the information blocking regulations. The implementation of these provisions advances interoperability, improves algorithm transparency, and supports the access, exchange, and use of electronic health information (EHI). This final rule also updates numerous technical standards in the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs for health IT developers and users of health IT.

DATES:

Effective date: This final rule is effective on February 8, 2024.

Incorporation by reference: The incorporation by reference of certain publications listed in the rule was approved by the Director of the Federal Register as of February 8, 2024.

FOR FURTHER INFORMATION CONTACT:

Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202–690–7151.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Executive Summary

A. Purpose of Regulatory Action

1. Statutory Responsibilities and Implementation

2. Administration Executive Orders

3. Federal Coordination

B. Summary of Major Provisions

1. ONC Health IT Certification Program Updates

a. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”

b. New and Revised Standards and Certification Criteria

i. The United States Core Data for Interoperability Version 3 (USCDI v3)

ii. C–CDA Companion Guide Updates

iii. “Minimum Standards” Code Sets Updates

iv. Electronic Case Reporting

v. Decision Support Interventions and Predictive Models

vi. Synchronized Clocks Standard

vii. Standardized API for Patient and Population Services

viii. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)

ix. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)

x. Patient Right To Request a Restriction on Use or Disclosure

xi. Requirement for Health IT Developers To Update Their Previously Certified Health IT

2. Assurances Condition and Maintenance of Certification Requirements

3. Real World Testing—Inherited Certified Status

4. Insights Condition and Maintenance of Certification

5. Information Blocking Enhancements

C. Costs and Benefits

II. Background

A. Statutory Basis

1. Standards, Implementation Specifications, and Certification Criteria

2. Health IT Certification Program(s)

B. Regulatory History

C. General Comments on the HTI–1 Proposed Rule

III. ONC Health IT Certification Program Updates

A. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions,” Definition of Revised Certification Criterion, and Related Program Oversight

1. Discontinuing Year Themed “Editions”

2. Definition of “Revised Certification Criterion”

3. Program Oversight Related to Discontinuation of Editions

a. Records Retention

b. Records Retention—Complete EHR

B. Standards and Implementation Specifications

1. National Technology Transfer and Advancement Act

2. Compliance With Adopted Standards and Implementation Specifications

3. “Reasonably Available” to Interested Parties

C. New and Revised Standards and Certification Criteria

1. The United States Core Data for Interoperability Version 3 (USCDI v3)

a. Certification Criteria That Reference USCDI

b. USCDI Standard—Data Classes and Elements Added Since USCDI v1

2. C–CDA Companion Guide Updates

3. “Minimum Standards” Code Sets Updates

4. Electronic Case Reporting

5. Decision Support Interventions and Predictive Models

a. Requirements for Decision Support Interventions (DSI) Certification Criterion

b. Updates to Real World Testing Condition for CDS Criterion

6. Synchronized Clocks Standard

7. Standardized API for Patient and Population Services

a. Native Applications and Refresh Tokens

b. FHIR United States Core Implementation Guide Version 5.0.1

c. FHIR Endpoint for Service Base URLs

d. Access Token Revocation

e. SMART App Launch 2.0

8. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)

9. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)

10. Patient Right To Request a Restriction on Use or Disclosure

11. Requirement for Health IT Developers To Update Their Previously Certified Health IT

D. Assurances Condition and Maintenance of Certification Requirements

1. Condition of Certification

2. Maintenance of Certification Requirements

E. Real World Testing—Inherited Certified Status

F. Insights Condition and Maintenance of Certification

1. Background and Purpose

2. Insights Condition and Maintenance of Certification—Final Measures

3. Insights Condition and Maintenance of Certification—Requirements

4. Insights Condition and Maintenance of Certification—Process for Reporting

G. Requests for Information

1. Laboratory Data Interoperability Request for Information

2. Request for Information on Pharmacy Interoperability Functionality Within the ONC Health IT Certification Program Including Real-Time Prescription Benefit Capabilities

3. FHIR Standard

IV. Information Blocking Enhancements

A. General Comments Regarding Information Blocking Enhancements

B. Defined Terms

1. Offer Health Information Technology or Offer Health IT

a. Exclusion of Certain Funding Subsidy Arrangements From Offer Health IT Definition

b. Implementation and Use Activities That Are Not an Offering of Health IT

c. Consulting and Legal Services Exclusion From Offer Health IT Definition

2. Health IT Developer of Certified Health IT: Self-Developer Health Care Providers

3. Information Blocking Definition

C. Exceptions

1. Infeasibility

a. Infeasibility Exception—Uncontrollable Events Condition

b. Infeasibility Exception—Third Party Seeking Modification Use

c. Infeasibility Exception—Manner Exception Exhausted

2. TEFCA Manner Exception

D. Information Blocking Requests for Information

1. Additional Exclusions From Offer Health IT—Request for Information

2. Possible Additional TEFCA Reasonable and Necessary Activities—Request for Information

3. Health IT Capabilities for Data Segmentation and User/Patient Access—Request for Information

V. Incorporation by Reference

VI. Collection of Information Requirements

A. Independent Entity

B. Health IT Developers

C. ONC–ACBs

VII. Regulatory Impact Analysis

A. Statement of Need

B. Alternatives Considered

C. Overall Impact

1. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis

a. Costs and Benefits

b. Accounting Statement and Table

D. Regulatory Flexibility Act

E. Executive Order 13132—Federalism

F. Unfunded Mandates Reform Act of 1995

Regulation Text

I. Executive Summary

A. Purpose of Regulatory Action

The Office of the National Coordinator for Health Information Technology (ONC) is the principal federal entity charged with coordinating nationwide efforts to implement and use advanced health IT and to facilitate the electronic exchange of health information. ONC is at the forefront of the administration's health IT efforts and is a resource to the entire health system to support the adoption of health IT and the promotion of nationwide, standards-based health information exchange to improve healthcare. ONC is focused on two strategic objectives: (1) advancing the development and use of health IT capabilities; and (2) establishing expectations for data sharing. ONC's overall mission, consistent with the policies adopted in this final rule, is to create systemic improvements in health and care through the access, exchange, and use of data.

This final rule fulfills statutory requirements and aligns with administrative priorities; advances equity, innovation, and interoperability; and supports the access, exchange, and use of EHI. It also promotes the responsible development and use of artificial intelligence through transparency and improves patient care through policies that advance standards-based interoperability and EHI exchange, which are central to the Department of Health and Human Services' efforts to enhance and protect the health and well-being of all Americans.

1. Statutory Responsibilities and Implementation

The Secretary of Health and Human Services has delegated to ONC the responsibility to implement certain provisions in Title IV of the 21st Century Cures Act (Pub. L. 114–255, Dec. 13, 2016) (Cures Act) including: the Electronic Health Record (EHR) Reporting Program condition and maintenance of certification requirements under the ONC Health IT Certification Program (Program) and the identification of reasonable and necessary activities that do not constitute information blocking. ONC is also responsible for implementing certain provisions of the Health Information Technology for Economic and Clinical Health Act (Pub. L. 111–5, Feb. 17. 2009) (HITECH Act) of 2009, including, but not limited to, requirements that the National Coordinator perform duties consistent with the development of a nationwide health information technology infrastructure that allows for the electronic use and exchange of information and that promotes a more effective marketplace, greater competition, and increased consumer choice, as well as requirements to keep, or recognize, a program or programs for the voluntary certification of health information technology.

This final rule adopts new and revised standards and requirements for the certification of health IT under the Program. For example, key provisions of this final rule implement the EHR Reporting Program through new Conditions and Maintenance of Certification requirements (referred herein as the Insights Condition) for developers of certified health IT, which will provide transparency into the use and benefits of certified health IT, with an initial focus on interoperability. This final rule revises several Program certification criteria, including criteria related to decision support, electronic case reporting, and standards-based application programming interfaces (APIs), as well as raises the baseline version of the USCDI from Version 1 to Version 3. The adoption of new and revised standards and criteria in this final rule will facilitate interoperability through standardized health information and functionality, which will lead to better care and health outcomes for patients, while reducing burden and costs. Finally, this rule continues to implement the provisions of the Cures Act to improve information sharing—and address information blocking—by providing refined definitions of statutory terms and further identifying practices that are reasonable and necessary and, therefore, do not constitute information blocking.

2. Administration Executive Orders

In addition to fulfilling the HITECH Act's and Cures Act's requirements described above, this final rule supports implementation of Executive Orders (E.O.) 13994, 13985, 14036, 14058, 14091, and 14110. The President issued E.O. 13994 on January 21, 2021, to ensure a data-driven response to COVID–19 and future high-consequence public health threats. The Cures Act and the information blocking provisions in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (85 FR 25642) (ONC Cures Act Final Rule) took critical steps to making data available across the healthcare system. Adoption of USCDI v3 in this rule facilitates the gathering, sharing, and publication of public health and emergency response data ( e.g., the COVID–19 pandemic) by capturing and promoting the sharing of key data elements related to public health. The updates to API Conditions and Maintenance of Certification requirements, as discussed in section III.C.7, continue the implementation of ONC's statutory responsibilities and efforts to develop and standardize APIs and to help individuals and other authorized health care providers, including those engaged in public health, securely access EHI through the broader adoption of standardized APIs. Additionally, this final rule adopts consensus-based, industry-developed health IT standards for certified Health IT Modules to support electronic case reporting. As discussed in section III.C.4, among other benefits, electronic case reporting facilitates faster and more efficient disease tracking, prevention, and case management. It also provides more timely and complete data to public health agencies than manual or non-standardized reporting.

We are also committed to advancing health equity, and this final rule is consistent with E.O. 13985 of January 20, 2021, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, and E.O. 14091 of February 16, 2023, Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government. Section 1 of E.O. 13985 states that “the Federal Government should pursue a comprehensive approach to advancing equity for all, including people of color and others who have been historically underserved, marginalized, and adversely affected by persistent poverty and inequality.” Section 1 of E.O. 13985 also states that “because advancing equity requires a systematic approach to embedding fairness in decision-making processes, executive departments and agencies must recognize and work to redress inequities in their policies and programs that serve as barriers to equal opportunity.” As noted above, we have adopted USCDI v3 in this final rule to meet statutory responsibilities discussed in section II.A to improve the standardization of health information that is accessed, exchanged, and used within certified health IT. The USCDI v3 standard includes data elements on patient demographics (such as sexual orientation and gender identity) and social determinants of health (SDOH), as discussed in sections III.C.1 and III.C.8 of this final rule. These updates help capture more accurate and complete patient characteristics that are reflective of patient diversity and inclusion, which could potentially help data users address disparities in health outcomes for all patients, including those who may be marginalized and underrepresented. The use of USCDI v3 also supports data users' abilities to identify, assess, and analyze gaps in care, which could in turn be used to inform and address the quality of healthcare through interventions and strategies. This could lead to better patient care, experiences, and health outcomes.

Section 1 of E.O. 14091 also requires the Federal Government to “promote equity in science and root out bias in the design and use of new technologies, such as artificial intelligence.” Section 8 of E.O. 14091 requires agencies to “prevent and address discrimination and advance equity for all” and to “consider opportunities to prevent and remedy discrimination, including by protecting the public from algorithmic discrimination.” The E.O. states that the Federal Government shall continue to “advance equity in health, including mental and behavioral health and well-being.” We are committed to the concept of “health equity by design”, in which health equity considerations are identified and incorporated from inception and throughout the technology design, build, and implementation process. We consider health equity by design to incorporate health equity strategies, tactics, and patterns as guiding principles for software and IT development, enforced by technical architecture, data, and information governance process, and built into the technology at every layer. In this final rule we apply the concept of health equity by design to bring transparency to the quality and performance of intelligence and machine learning-based decision support tools in healthcare. As discussed in section III.C.5, the “decision support intervention,” (DSI) certification criterion is supportive of the goals of E.O. 14091 and advances health equity by design by making it known to users of Health IT Modules certified to the DSI criterion whether patient demographic, SDOH, or health assessment data are used in DSIs. Other finalized policies: (1) establish a definition for algorithm-based and model-based “predictive” DSIs; (2) require Health IT Modules certified to the DSI criterion to enable users to access information about the design, development, training, and evaluation of Predictive DSIs, including descriptions of training data and information on whether the Predictive DSI was tested and evaluated for fairness; (3) require developers of certified health IT to apply risk management practices for all Predictive DSIs that are supplied by the developer of certified health IT as part of its Health IT Module; and (4) make summary information regarding these practices available publicly.

Additionally, the DSI certification criterion and surrounding transparency requirements are especially aligned with E.O. 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, issued October 30, 2023. The finalized DSI requirements will improve transparency, promote trustworthiness, and incentivize the development and wider use of fair, appropriate, valid, effective, and safe Predictive DSIs to aid decision-making in healthcare. The resulting information transparency increases public trust and confidence in these technologies so that the benefits of these technologies may expand in safer, more appropriate, and more equitable ways. This transparency also informs wider discussions, including those across industry, academia, and government, regarding how to evaluate and communicate performance related to Predictive DSIs, consistent with Section 8 of the E.O., “Protecting Consumers, Patients, Passengers, and Students.”

The finalized DSI certification criterion also aligns with the public availability and transparency policy goals of the Office of Science and Technology Policy (OSTP) memorandum “Ensuring Free, Immediate, and Equitable Access to Federally Funded Research.” The memorandum provides policy guidance to federal agencies and departments to promote improved public access to and transparency of federally funded research. The finalized DSI certification criterion aligns with the goals of the memorandum by establishing requirements to make information available through § 170.315(b)(11)(iv), including information created through federally funded research and evaluations, that will enable users to determine if a Predictive DSI supplied by a health IT developer as part of its Health IT Module is acceptably fair, appropriate, valid, effective, and safe.

President Biden's E.O. 14036, Promoting Competition in the American Economy, issued on July 9, 2021, established a whole-of-government effort to promote competition in the American economy and reaffirmed the policy stated in E.O. 13725 of April 15, 2016 (Steps to Increase Competition and Better Inform Consumers and Workers to Support Continued Growth of the American Economy). This final rule fosters competition by advancing foundational standards for certified API technology, which enable—through applications (apps) and without special effort—improved legally permissible sharing of EHI among clinicians, patients, researchers, and others. As described in section III.C.7, competition is advanced through these improved API standards that can help individuals connect to their information and can help authorized health care providers, involved in the patient's care, securely access information. For example, these standards are designed to foster an ecosystem of new applications that can connect through the API technology to provide patients with improved electronic access to EHI.

Further, as described in section IV, this final rule provides enhancements to support information sharing under the information blocking regulations and promote innovation and competition, as well as address market consolidation. As we have noted, addressing information blocking is critical for promoting innovation and competition in health IT and for the delivery of healthcare services to individuals. In both the ONC Cures Act Proposed Rule (84 FR 7508) and Final Rule (85 FR 25790 through 25791), we discussed how the information blocking provisions provide a comprehensive response to the issues identified by empirical and economic research. This research suggested that information blocking may weaken competition, encourage consolidation, and create barriers to entry for developers of new and innovative applications and technologies that enable more effective uses of EHI to improve population health and the patient experience. We explained that the information blocking provisions of the Public Health Service Act (PHSA) itself expressly addresses practices that impede innovation and advancements in EHI access, exchange, and use, including care delivery enabled by health IT (section 3022(a)(2)(C)(ii) of the PHSA). Actors subject to the information blocking provisions may, among other practices, attempt to exploit their control over interoperability elements to create barriers to entry for competing technologies and services that offer greater value for health IT customers and users, provide new or improved capabilities, and enable more robust access, exchange, and use of EHI (85 FR 25820). Information blocking may not only harm competition in health IT markets, but also in markets for healthcare services (85 FR 25820). In the ONC Cures Act Final Rule, we described practices that dominant market health care providers may leverage and use to control access and use of their technology, resulting in technical dependence and possibly leading to barriers to entry by would-be competitors, as well as making some market health care providers vulnerable to acquisition or inducement into arrangements that enhance the market power of incumbent health care providers to the detriment of consumers and purchasers of healthcare services (85 FR 25820). The implementation of the new information blocking provisions detailed in section IV of this final rule promote innovation, encourage market competition, and address consolidation in the interest of the patient to advance interoperability, improve transparency, and support the access, exchange, and use of EHI.

Lastly, in support of E.O. 14058, Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government, issued on December 16, 2021, we are committed to advancing the equitable, inclusive, and effective delivery of services with a focus on the experience of individuals, health IT developers, and health care providers. As required by section 4002 of the Cures Act and included in the ONC Cures Act Final Rule (85 FR 25717), we established certain Conditions and Maintenance of Certification requirements, which express initial and ongoing requirements for health IT developers and their certified Health IT Module(s) under the Program. This final rule implements the EHR Reporting Program Condition and Maintenance of Certification requirement outlined in the Cures Act by establishing—within the Program—a new Condition and Maintenance of Certification hereafter referred to as the “Insights Condition.” As discussed in section III.F, the implementation of the Insights Condition provides transparent reporting to address information gaps in the health IT marketplace and provides insights on the use of specific certified health IT functionalities. The implementation of this new Condition and Maintenance of Certification requirement will allow ONC to gain a better understanding of the use of health IT and provide ONC with information about consumers' experience with certified health IT.

3. Federal Coordination

We strive to improve federal agency coordination. ONC works with the Centers for Medicare & Medicaid Services (CMS) to ensure that the certification timelines we have established complement timelines for CMS programs that reference ONC regulations, such as the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS). In the interest of clarity and cohesion among HHS components, we have aligned some of our compliance dates to the calendar year for consistency with calendar-year based performance periods in CMS programs when participants may be required to use updated certified health IT. We believe this approach reduces confusion for participants in these programs and better serves the public interest.

B. Summary of Major Provisions

1. ONC Health IT Certification Program Updates

a. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”

We noted in the HTI–1 Proposed Rule that we no longer believed that it was helpful or necessary to maintain an “edition” naming convention or to adopt entirely new editions of certification criteria to encapsulate updates over time (88 FR 23750). Instead, we conveyed that there should be a single set of certification criteria, which would be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. In section III.A, we discuss our final policy to rename all certification criteria within the Program simply as “ONC Certification Criteria for Health IT.”

b. New and Revised Standards and Certification Criteria

i. The United States Core Data for Interoperability Version 3 (USCDI v3)

We noted in the HTI–1 Proposed Rule that because USCDI is the standard for data required to be accessible through certified health IT for numerous certification criteria, expanding the data elements and data classes included in USCDI increases the amount of data available to be used and exchanged for patient care (88 FR 23751). To expand standardized data reporting, we have finalized the proposal to codify USCDI v1 in § 170.213(a) and to add USCDI v3 to § 170.213 (to be codified as § 170.213(b)). We have incorporated USCDI v3 by reference in § 170.299 as of the effective date of this final rule. Lastly, we have finalized that the USCDI v1 (July 2020 Errata) in the USCDI standard in § 170.213(a) will expire on January 1, 2026. As codified in § 170.213, only USCDI v3 will be available in the Program as of January 1, 2026.

ii. C–CDA Companion Guide Updates

As discussed in section III.C.2, we have finalized the adoption of the HL7® CDA® R2 Implementation Guide: C–CDA Templates for Clinical Notes STU Companion Guide, Release 4.1—US Realm (C–CDA Companion Guide R4.1) in § 170.205(a)(6) because it is the only version that provides guidance and clarifications for specifying data in USCDI v3.

iii. “Minimum Standards” Code Sets Updates

In the 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications Final Rule (2015 Edition Final Rule), we established a policy of adopting newer versions of “minimum standards” code sets that frequently update (80 FR 62612). Adopting newer versions of these code sets enables improved interoperability and implementation of health IT with minimal additional burden (77 FR 54170). We discussed in the HTI–1 Proposed Rule that, if adopted, newer versions of these minimum standards code sets would serve as the baseline for certification, and developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis (88 FR 23751). We have finalized, as discussed in section III.C.3, the adoption of the versions we had proposed of the following minimum standards code sets:

• § 170.207(a)—Problems
• § 170.207(c)—Laboratory tests
• § 170.207(d)—Medications
• § 170.207(e)—Immunizations
• § 170.207(f)—Race and ethnicity
• § 170.207(m)—Numerical references
• § 170.207(n)—Sex
• § 170.207(o)—Sexual orientation and gender information
• § 170.207(p)—Social, psychological, and behavioral data
• § 170.207(r)—Provider type
• § 170.207(s)—Patient insurance

In addition to the finalized adoption of the minimum standards code sets listed above, we have finalized proposed updates to certification criteria that reference those minimum standards. These criteria include § 170.315(a)(5)(i)(A)( 1) and ( 2), (a)(5)(i)(C) through (E), (a)(12), (b)(1)(iii)(B)( 2), (b)(1)(iii)(G)( 3), (b)(6)(ii)(B)( 2), (c)(4)(iii)(C), (c)(4)(iii)(E), (c)(4)(iii)(G) through (I), (f)(1)(i)(B) and (C), (f)(3)(ii), and (f)(4)(ii).

We have finalized the proposal to change the heading of § 170.207(o) to “sexual orientation and gender information” to acknowledge that § 170.207(o) includes standard code sets to support gender-related data items in addition to standard code sets to support sexual orientation.

iv. Electronic Case Reporting

As discussed in section III.C.4 of this final rule, we have finalized the revisions to the “transmission to public health agencies—electronic case reporting” criterion in § 170.315(f)(5) to adopt consensus-based, industry-developed electronic standards and implementation guides (IGs) to replace all functional, descriptive requirements in the present criterion in § 170.315(f)(5). These standards will support the following requirements for Health IT Modules certified to § 170.315(f)(5): (i) create a case report for electronic transmission; (ii) consume and process a case report response; and (iii) consume and process electronic case reporting trigger codes. We note that these electronic standards are standards-based representations of the functional requirements described in the existing criterion in § 170.315(f)(5) as described in section III.C.4 of this preamble.

v. Decision Support Interventions and Predictive Models

As discussed in section III.C.5 of this final rule, we have finalized the adoption of the certification criterion, “decision support interventions (DSI)” in § 170.315(b)(11). The DSI criterion is a revised certification criterion, serving both an iterative update and replacement criterion for the “clinical decision support (CDS)” certification criterion in § 170.315(a)(9) (88 FR 23751). The DSI criterion, as finalized, ensures that Health IT Modules certified to § 170.315(b)(11) reflect an array of contemporary functionalities, support data elements important to health equity, and enable the transparent use of predictive models and algorithms to aid decision-making in healthcare.

We have adopted a new definition for Predictive Decision Support Intervention, (also referred to hereafter as Predictive DSI) in § 170.102, and we have finalized that Health IT Modules certified to § 170.315(b)(11) must enable a limited set of identified users to select ( i.e., activate) evidence-based and Predictive DSIs, as described in § 170.315(b)(11)(iii). Additionally, we have finalized that Health IT Modules certified to § 170.315(b)(11) must support “source attributes”—categories of technical performance and quality information—for both evidence-based and Predictive DSIs in § 170.315(b)(11)(iv).

We have not finalized proposed requirements that Health IT Modules clearly indicate when source attributes from other parties are unavailable. Rather, we have finalized that Health IT Modules certified to § 170.315(b)(11) must enable a limited set of identified users to access complete and up-to-date descriptions of all source attributes related to evidence-based DSIs and Predictive DSIs that are supplied by the developer of certified health IT as part of their Health IT Module, as described in § 170.315(b)(11)(v)(A). Moreover, we have finalized in § 170.315(b)(11)(v)(B) requirements that Health IT Modules certified to § 170.315(b)(11) must enable a limited set of identified users to record and change source attributes listed in paragraphs § 170.315(b)(11)(iv)(A) and (B).

We have also finalized in § 170.315(b)(11)(vi) that intervention risk management (IRM) practices must be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, including requirements to subject Predictive DSIs to risk analysis and risk mitigation related to validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy. We note that for governance practices, we have finalized in § 170.315(b)(11)(vi)(C) requirements for Health IT Modules to be subject to policies and implemented controls for governance, including how data are acquired, managed, and used. Consistent with the other IRM practices, these policies and implemented controls must be applied for all Predictive DSIs supplied by the health IT developer as part of its Health IT Module.

Additionally, in consideration of comments received and the scope reductions we have made to this final certification criterion, we determined that a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification is necessary to implement our policy objectives and proposals fully. Specifically, we have included in this final rule a Maintenance of Certification requirement at 45 CFR 170.402(b)(4) that reinforces a health IT developer's ongoing responsibility to review and update, as necessary, source attribute information in § 170.315(b)(11)(v)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). We have finalized in § 170.402(b)(4) that developers with products certified to § 170.315(b)(11) will need to comply with this Maintenance of Certification requirement starting January 1, 2025.

Finally, we have finalized our proposals to facilitate this transition from one version of the criterion to the other by updating the 2015 Edition Base EHR definition in § 170.102, which is being replaced with a definition of Base EHR, to include an option for a Health IT Module to meet the definition by either being certified to the existing CDS version of the certification criterion in § 170.315(a)(9), or being certified to the revised DSI criterion in § 170.315(b)(11), for the period up to, and including, December 31, 2024. On and after January 1, 2025, only the DSI criterion in § 170.315(b)(11) will be included in the Base EHR definition and the adoption of the criterion in § 170.315(a)(9) will expire on January 1, 2025. We discuss in section III.C.5.b of this preamble policies that would constitute changes to the CDS criterion, as the new DSI criterion.

vi. Synchronized Clocks Standard

We have finalized, as discussed in section III.C.6, the removal of the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905), in § 170.210(g). Additionally, we have finalized the requirement for any network time protocol (NTP) standard to be used that can ensure a system clock has been synchronized and meets time accuracy requirements.

vii. Standardized API for Patient and Population Services

We have finalized, as discussed in section III.C.7, the proposed revisions to the “standardized API for patient and population services” certification criterion in § 170.315(g)(10). We have finalized the requirement that a certified Health IT Module's authorization server issues a refresh token according to the implementation specification adopted in § 170.215(c).

We have also finalized the proposed revisions in § 170.315(g)(10)(vi) to specify that Health IT Modules presented for certification that allow short-lived access tokens to expire, in lieu of immediate access token revocation, must have such access tokens expire within one hour of the request. This revised requirement aligns with industry standard practice for short-lived access tokens, provides clarity and consistent expectations that developers revoke access or expire access privileges within one hour of a request, and offers patients an assurance that an application's access to their data will be revoked or expired within one hour of a request.

We have also adopted the HL7® FHIR® US Core Implementation Guide (IG) STU version 6.1.0 (FHIR US Core 6.1.0) in § 170.215(b)(1)(ii). This version of the US Core IG provides the latest consensus-based capabilities aligned with USCDI v3 data elements for FHIR APIs.

Additionally, we have finalized the proposal to amend the API Condition and Maintenance of Certification requirements by adding the requirement that Certified API Developers with patient-facing apps must meet the publication requirements associated with service base URLs according to a specified format.

We have adopted the Substitutable Medical Applications, Reusable Technologies (SMART) App Launch Implementation Guide Release 2.0.0 (SMART v2 Guide) in § 170.215(c)(2), which replaces the SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART v1 Guide) as the standard in § 170.215(a)(3) (finalized in this rule as § 170.215(c)(1)). Adoption of this standard impacts the certification criterion in § 170.315(g)(10) in several subparagraphs. The SMART v2 Guide builds on the features of the SMART v1 Guide by including new features and technical revisions based on industry consensus, including features that reflect security best practices. The SMART v1 Guide will continue to be available as a standard for use in the Program through December 31, 2025. Beginning January 1, 2026, the SMART v2 Guide will be the only version of the IG available for use in the Program.

viii. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)

We have finalized, as discussed in section III.C.1 of this final rule, the adoption of USCDI v3, which includes certain data elements, namely Sex, Sexual Orientation, and Gender Identity, that are also data elements in § 170.315(a)(5). As discussed in section III.C.8 of this preamble, to ensure consistency, we have finalized the name change of the certification criterion in § 170.315(a)(5) from “demographics” to “patient demographics and observations.” Additionally, to ensure consistent capture of these data elements across health IT, we carry these changes into their respective data elements in § 170.315(a)(5), as discussed in section III.C.8.

We have finalized the replacement of the specific concepts referenced in § 170.315(a)(5)(i)(D) and (E), Sexual Orientation and Gender Identity, respectively, with the Systematized Nomenclature of Medicine Clinical Terms U.S. Edition (SNOMED CT®) code set, as referenced in the standard in § 170.207(o)(3). We have also finalized our proposal that the adoption of the code sets referenced in § 170.207(n)(1) will expire on January 1, 2026, and that health IT developers can continue to use the specific codes in the current terminology standard through December 31, 2025, in order to provide adequate time for Health IT Modules certified to particular certification criteria to transition to the updated terminology standards.

We have finalized the addition of Sex Parameter for Clinical Use as a new data element in § 170.315(a)(5)(i)(F). As discussed in section III.C.1 of this final rule, we proposed Sex for Clinical Use in the HTI–1 Proposed Rule and have revised the title of Sex for Clinical Use to instead be Sex Parameter for Clinical Use (SPCU) to align with changes made by the HL7 Gender Harmony Project and updated the title in § 170.315(a)(5)(i)(F). The data element definition did not change. Additionally, we have finalized new data elements—Name to Use in § 170.315(a)(5)(i)(G) and Pronouns in § 170.315(a)(5)(i)(H)—to facilitate data capture that supports providers' ability to provide culturally competent care for their patients.

ix. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)

We have finalized, as discussed in section III.C.9, the proposed updates to the “transitions of care” certification criterion (§ 170.315(b)(1)) to align it with our adoption of USCDI v3 in § 170.213(b). This change ensures that Health IT Modules certified to § 170.315(b)(1) are capable of accessing, exchanging, and using USCDI data elements referenced in the standards in § 170.213.

x. Patient Right To Request a Restriction on Use or Disclosure

We stated in the HTI–1 Proposed Rule that we believed that individuals should be provided a reasonable opportunity and technical capability to make informed decisions about the collection, use, and disclosure of their electronic health information (88 FR 23753). The Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule provides individuals with several legal, enforceable rights that empower them to manage their health information. We made several proposals in support of the HIPAA Privacy Rule's individual right to request restriction of certain uses and disclosures of their protected health information (PHI) ( see also45 CFR 154.522(a)). In this final rule, we have finalized a requirement for Health IT Modules certified to the “view, download, and transmit to a 3rd party,” certification criterion in § 170.315(e)(1) to support an “internet-based method” for a patient to request a restriction as proposed. Based on the feedback received from numerous interested parties, we have decided not to finalize the remainder of our proposals for patient requested restrictions at this time. We will continue to monitor standards development efforts in this space.

xi. Requirement for Health IT Developers To Update Their Previously Certified Health IT

We have finalized our proposal to add text to the introductory text in § 170.315 stating that health IT developers participating in the Program must update their certified Health IT Modules and provide that updated certified health IT to customers in accordance with the timelines defined for a specific criterion or standard included in § 170.315. More specifically, we have finalized, as discussed in section III.C.11, that health IT developers with health IT certified to any of the certification criteria in § 170.315 will need to update their previously certified Health IT Modules to be compliant with any revised certification criterion adopted in § 170.315, including any new standards adopted in 45 CFR part 170 subpart B and capabilities included in the revised certification criterion. We have further finalized the requirement that health IT developers will also need to provide the updated health IT to customers of the previously certified health IT according to the dates established for that criterion and any applicable standards.

2. Assurances Condition and Maintenance of Certification Requirements

We have finalized, as discussed in section III.D, additional Assurances Condition and Maintenance of Certification requirements. We have finalized as a Condition of Certification that a health IT developer must provide an assurance that it will not interfere with a customer's timely access to interoperable health IT certified under the Program. To support this assurance, we have finalized two accompanying Maintenance of Certification requirements. We have finalized that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion. We have also finalized that a health IT developer must provide all Health IT Modules certified to a revised certification criterion to its customers of such certified health IT. In response to comments and to provide regulatory clarity, we have revised the separate “timely access” or “timeliness” requirements for each of the two proposed Maintenance of Certification requirements. Rather than relying on independent timeliness requirements for previously certified health IT, the maintenance requirements now cross-reference timeframes specified in 45 CFR part 170, while still maintaining the proposed minimum 12-month timeframe for new customers.

3. Real World Testing—Inherited Certified Status

Section 4002(a) of the Cures Act added a new Condition and Maintenance of Certification requirement that health IT developers must successfully test the real-world use of health IT for interoperability in the type(s) of setting(s) in which such technology would be marketed. Many health IT developers update their certified Health IT Module(s) on a regular basis, leveraging the flexibility provided through ONC's Inherited Certified Status (ICS). Because of the way that ONC issues certification identifiers, this updating can cause an existing certified Health IT Module to be recognized as new within the Program. Regular updating, especially on a frequent basis (such as quarterly or semi-annually), creates an anomaly that could result in existing certified Health IT Modules being inadvertently excluded from the real world testing reporting requirements (88 FR 23753).

To ensure that all developers continue to test the real-world use of their technology as required, we have finalized, as discussed in section III.E, the proposal to eliminate this anomaly by requiring health IT developers to include in their real world testing results report the newer version of those certified Health IT Module(s) that are updated using ICS after August 31 of the year in which the plan is submitted. This will ensure that health IT developers fully test all applicable certified Health IT Module(s) as part of their real world testing requirements.

4. Insights Condition and Maintenance of Certification

The Cures Act specified requirements in section 4002(c) to establish an EHR Reporting Program to provide reporting on certified health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories as appropriate to measure the performance of EHR technology. The Cures Act also specified, in text added at section 3009A(b) of the Public Health Service Act, that a health IT developer be required, as a Condition and Maintenance of Certification requirement under the ONC Health IT Certification Program, to submit responses to reporting criteria in accordance with the EHR Reporting Program established with respect to all certified technology offered by such developer. For clarity, we refer to the Condition and Maintenance of Certification associated with the “EHR Reporting Program” as the “Insights Condition and Maintenance of Certification” (also referred to as the “Insights Condition”) throughout this final rule. We believe this descriptive name captures the essence of this requirement and will help avoid confusion that might occur through use of the term “EHR Reporting Program.”

In section III.F, we have adopted seven reporting measures for developers of certified health IT that focus initially on the interoperability category, emphasizing four areas of interoperability: (1) individuals' access to electronic health information; (2) public health information exchange; (3) clinical care information exchange; and (4) standards adoption and conformance. Through this first set of finalized measures, we intend to provide insights on the interoperability category specified in the Cures Act. We intend to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future years.

We have also finalized, as discussed in section III.F, the implementation of the Insights Condition requirements in § 170.407 in three phases over three years, where health IT developers to which the requirements apply, will be required to report on some of the measures earlier than others. For each final measure, we have included information on the rationale for adopting the measure, the final metrics, and other key topics. The Insights Condition will provide transparent reporting, address information gaps in the health IT marketplace, and provide insights on the use of health IT.

5. Information Blocking Enhancements

As discussed in section IV.B.1 of this preamble, we have finalized a definition of “offer health information technology” or “offer health IT” for purposes of the information blocking regulations in 45 CFR part 171. This definition of “offer health IT,” as finalized in § 171.102, narrows the applicability of the “health IT developer of certified health IT” definition in 45 CFR 171.102. The definition of “offer health IT,” finalized in 45 CFR 171.102, will generally continue to include holding out for sale, selling, or otherwise supplying certified health IT to others on commercial or other terms. However, our finalized definition of “offer health IT” explicitly excludes certain activities and arrangements. First, the “offer health IT” definition excludes making available funding to obtain or maintain certified health IT, provided the funding is made available without condition(s) limiting the interoperability, or use of the technology to access, exchange or use electronic health information for any lawful purpose ( see paragraph (1) of the offer health IT definition). Second, the finalized “offer health IT” definition also explicitly codifies that health care providers or other health IT users do not “offer health IT” when they engage in certain health IT implementation and use activities, regardless of whether they obtain that health IT from a commercial developer or a reseller or develop it themselves ( see paragraph (2) of the offer health IT definition).

We have also finalized (in paragraph (3) of the “offer health IT” definition) an exclusion from the “offer health IT” definition that applies to certain consulting and legal services. This consulting and legal services exclusion ( see subparagraph (3)(iii)) encompasses supplying health IT in complement to the other items, supplies, facilities, and services that a consultant handles for a clinician practice or other health care provider in a comprehensive (“turn key”) package of services for administrative or operational management ( see section IV.B.1.c.iii of this preamble). The consulting and legal services exclusion from the “offer health IT” definition also encompasses assistance by health IT consultants with the selection, implementation, and use of health IT as specified in subparagraph (3)(ii) and legal services furnished by outside counsel as specified in subparagraph (3)(i).

As discussed in section IV.B.2, we have modified the “health IT developer of certified health IT” definition so that it is clear that health care providers who self-develop certified health IT will continue to be excluded from this definition if they do not engage in activities falling within the “offer health IT” definition. The updated § 171.102 health IT developer of certified health IT definition we have finalized represents a change from prior policy to the extent that a health care provider that is a self-developer would not meet the definition of “health IT developer of certified health IT” if they supply certified health IT to one or more other health care provider(s) under a comprehensive and predominantly non-health IT administrative or operations management services arrangement consistent with subparagraph (3)(iii) (under the consulting and legal services exclusion from the 45 CFR 171.102 “offer health IT” definition). Previously, health care providers who self-developed certified health IT were excluded from the 45 CFR 171.102 “health IT developer of certified health IT” definition if they self-developed the Health IT Module(s) for their “own use” (85 FR 25799 and 25956).

We have finalized revisions to the text of § 171.103, which defines “information blocking” for purposes of 45 CFR part 171, to remove paragraph (b) that established a period of time during which electronic health information (EHI) for purposes of the information blocking provision (§ 171.103) was limited to a subset of EHI that was identified by the data elements represented in the USCDI standard adopted in § 170.213. As established in the ONC Cures Act Final Rule (85 FR 25793, 85 FR 25876, and 85 FR 25956), that period of time ended on May 2, 2022. The end date of that period of time was extended to October 5, 2022, in the subsequent interim final rule with comment titled “Information Blocking and the ONC Health IT Certification Program: Extension of the Compliance Dates and Timeframes in Response to the COVID–19 Public Health Emergency” (85 FR 70064). On and after October 6, 2022, the scope of EHI for purposes of the “information blocking” definition (§ 171.103) is EHI as defined in § 171.102 (88 FR 23754, see also85 FR 25793, 25876, 70069, and 70085). October 5, 2022, has passed. Therefore, the paragraph (which had been designated paragraph (b), as codified) limiting the “information blocking” definition to the subset of EHI for the specified time period is no longer needed. We have re-designated remaining paragraphs of § 171.103 as discussed in section IV.B.3 and as shown in updated text we have finalized in § 171.103 ( see Regulation Text, see also discussion in section IV.B.3).

We note that in the HTI–1 Proposed Rule we did not propose to change the scope of EHI for purposes of the information blocking definition (88 FR 23754). We simply proposed to update the CFR text to remove paragraph (b) from § 171.103 that had temporarily—until October 5, 2022—limited the scope of the information blocking definition to the subset of EHI represented by USCDI v1 (88 FR 23864 and 23916). Similarly, because we included the same time period in reference to the scope of EHI in two paragraphs of the Content and Manner Exception (§ 171.301(a)(1) and (2)), we proposed to revise § 171.301 to remove from the regulatory text the existing § 171.301(a)(1) and (2) as no longer necessary (88 FR 23754). We have finalized the revisions to § 171.301 to remove the regulatory text in subparagraphs (a)(1) and (2) as no longer necessary and rename § 171.301 the Manner Exception. We have finalized the redesignation of the paragraphs now codified within § 171.301, so that different paragraphs are now designated (a)(1) and (2) rather than the paragraphs we have removed as no longer necessary ( see discussion in sections IV.B.3 and IV.C.2, see also Regulation Text for revised and redesignated paragraphs of § 171.301).

As explained in section IV.C.1, we have finalized revisions to the Infeasibility Exception codified in 45 CFR 171.204 both by adding two new conditions and by revising one existing condition for improved clarity. First, we have finalized revisions to the uncontrollable events condition in § 171.204(a)(1) to further clarify when an actor's practice meets the uncontrollable events condition. Our finalized revision to § 171.204(a), the uncontrollable events condition of the Infeasibility Exception, is discussed in Section IV.C.1.a. Second, we have added two new conditions to be codified as subparagraphs (a)(3) and (a)(4) and have, therefore, redesignated the infeasible under the circumstances condition as subparagraph (a)(5). The infeasible under the circumstances condition was previously designated as subparagraph (a)(3) of § 171.204.

The first new infeasibility condition in § 171.204(a)(3) (discussed in Section IV.C.1.b) will apply to an actor's practice of denying a third party's request to enable use of EHI in order to modify EHI, including, but not limited to, creation and deletion functionality, provided the request is not from a health care provider requesting such use from an actor that is their business associate. In support of this new condition, we have finalized as proposed a definition of “business associate” in § 171.102. That definition is, by cross-reference to 45 CFR 160.103, the HIPAA Privacy Rule's definition of “business associate.”

The second new infeasibility condition in § 171.204(a)(4), discussed in Section IV.C.1.c, will apply where an actor has exhausted the Manner Exception in § 171.301, including offering at least two alternative manners in accordance with § 171.301(b), including one manner that uses either technology certified to standard(s) adopted in 45 CFR part 170 that is specified by the requestor (§ 171.301(b)(1)(i)) or published content and transport standards consistent with § 171.301(b)(1)(ii). The actor cannot meet this new condition if the actor currently provides a substantial number of individuals or entities similarly situated to the requestor with the same requested access, exchange, or use of the requested EHI.

As discussed in section IV.C.3, we have finalized a new subpart D under part 171 for information blocking exceptions that involve practices related to actors' participation in the Trusted Exchange Framework and Common Agreement (TEFCA^SM ). In this new subpart D, we have established a standalone TEFCA Manner Exception, in § 171.403, that is based on a proposed TEFCA manner condition of the Manner Exception that was included in the HTI–1 Proposed Rule. The new exception provides that an actor's practice of not fulfilling a request to access, exchange, or use EHI in any alternative manner besides via TEFCA will not be considered information blocking when the practice follows certain conditions, which are discussed in more detail in section IV.C.3. Both the actor and requestor must be part of TEFCA, and the requestor must be able to access, exchange, or use the requested EHI via TEFCA. In consideration of comments and our stated policy goals, any fees or license agreements must satisfy the Fees (§ 171.302) and Licensing (§ 171.303) exceptions, which is counter to our initial proposed position. Further, in consideration of our stated policy goals and comments we received, the exception is not available when the requestor has requested access, exchange, or use via FHIR-based APIs.

In section IV.D, we discuss information blocking requests for information that we included in section IV.C of the HTI–1 Proposed Rule (88 FR 23873).

C. Costs and Benefits

Executive Orders 128660 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Executive Order 14094 entitled “Modernizing Regulatory Review” (hereinafter, the Modernizing E.O.) amends section 3(f) of Executive Order 12866 (Regulatory Planning and Review). The amended section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action that is likely to result in a rule that may: (1) have an annual effect on the economy of $200 million or more (adjusted every 3 years by the Administrator of the Office of Information and Regulatory Affairs (OIRA) for changes in gross domestic product); or adversely affect in a material way the economy, a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or State, local, territorial, or Tribal governments or communities; (2) create a serious inconsistency or otherwise interfere with an action taken or planned by another agency; (3) materially alter the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise legal or policy issues for which centralized review would meaningfully further the President's priorities or the principles set forth in this Executive Order, as specifically authorized in a timely manner by the Administrator of OIRA in each case. OMB has determined that this final rule is a significant regulatory action, as the potential economic impacts associated with this final rule could be greater than $200 million per year. Accordingly, we have prepared a Regulatory Impact Analysis (RIA) that, to the best of our ability, presents the costs and benefits of this final rule. We have estimated the potential monetary costs and benefits of this final rule for the health IT community, including costs and benefits as they relate to health IT developers, health care providers, patients, and the Federal Government ( i.e., ONC), and have broken those costs and benefits out by section. In accordance with E.O. 12866, we have included the RIA summary table as Table 37.

We note that we have rounded all estimates to the nearest dollar and that all estimates are expressed in 2022 dollars as it is the most recent data available to address all cost and benefit estimates consistently. The wages used to derive the cost estimates are from the May 2022 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics. We also note that estimates presented in the following “Employee Assumptions and Hourly Wage,” “Quantifying the Estimated Number of Health IT Developers and Products,” and “Number of End Users that Might Be Impacted by ONC's Proposed Regulations” sections are used throughout the RIA.

We estimate that the total annual cost for this final rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined throughout the RIA, would result in $437 million. The total undiscounted perpetual cost over a 10-year period for this final rule (starting in year three), would result in $477 million. We estimate the total costs to health IT developers to be $914 million and estimate the government (ONC) costs to be between $56,800 to $113,600.

We estimate the total annual benefit for this final rule would be on average $1.0 billion. We estimate the total undiscounted perpetual annual net benefit for this final rule (starting in year three), would be $124 million.

II. Background

A. Statutory Basis

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

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

Section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, Public Law 116–260 (CAA), enacted on December 27, 2020, requires prescription drug plan (PDP) sponsors to implement one or more real-time benefit tools (RTBTs) that meet the requirements described in the statute, after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. For purposes of the requirement to implement a real-time benefit tool in section 1860D–4(o)(1) of the Social Security Act, described above, the CAA provides that one of the requirements for an RTBT is that it can integrate with electronic prescribing and EHR systems of prescribing healthcare professionals for the transmission of formulary and benefit information in real time to such professionals. The statute requires incorporation of RTBTs within both the Medicare Part D prescription drug program and the Program. Specifically, the law amends the definition of a “qualified electronic health record” (qualified EHR) in section 3000(13) of the PHSA to require that a qualified EHR must include (or be capable of including) an RTBT.

1. Standards, Implementation Specifications, and Certification Criteria

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

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

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

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

2. Health IT Certification Program(s)

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

Section 4003(b) of the Cures Act added section 3001(c)(9)(B)(i) to the PHSA, which requires the National Coordinator “to convene appropriate public and private stakeholders” with the goal of developing or supporting a Trusted Exchange Framework and a Common Agreement (collectively, TEFCA^SM ) for the purpose of ensuring full network-to-network exchange of health information. Section 3001(c)(9)(B) outlines provisions related to the establishment of a Trusted Exchange Framework for trust policies and practices and a Common Agreement for exchange between health information networks (HINs)—including provisions for the National Coordinator, in collaboration with the NIST, to provide technical assistance on implementation and pilot testing of TEFCA. Section 3001(c)(9)(C) requires the National Coordinator to publish TEFCA on its website and in the Federal Register .

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

B. Regulatory History

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

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

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

After issuing a proposed rule on March 2, 2016, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 11056), we published a final rule by the same title (81 FR 72404) (EOA Final Rule) on October 19, 2016. The EOA Final Rule finalized modifications and new requirements under the Program, including provisions related to our role in the Program. The EOA Final Rule created a regulatory framework for our direct review of health IT certified under the Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The EOA Final Rule also set forth processes for us to authorize and oversee accredited testing laboratories under the Program. In addition, it included provisions for expanded public availability of certified health IT surveillance results.

On March 4, 2019, the Secretary published a proposed rule titled, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (84 FR 7424) (ONC Cures Act Proposed Rule). The ONC Cures Act Proposed Rule proposed to implement certain provisions of the Cures Act that would advance interoperability and support the access, exchange, and use of electronic health information. We also requested comment in the ONC Cures Act Proposed Rule (84 FR 7467) as to whether certain health IT developers should be required to participate in TEFCA as a means of providing assurances to their customers and ONC that they are not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of EHI, with the goal of developing or supporting TEFCA for the purpose of ensuring full network-to-network exchange of health information.

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

On January 19, 2022, we published a notice titled, “Notice of Publication of the Trusted Exchange Framework and Common Agreement” (87 FR 2800) (“TEFCA”). The notice fulfilled an obligation under section 3001(c)(9)(C) of the PHSA, which requires the National Coordinator for Health Information Technology to publish on the Office of the National Coordinator for Health Information Technology's public internet website, and in the Federal Register , the trusted exchange framework and common agreement developed under the PHSA.

On April 18, 2023, the Secretary published a proposed rule titled, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (HTI–1) (88 FR 23746) (HTI–1 Proposed Rule). The HTI–1 Proposed Rule proposed to implement the Electronic Health Record (EHR) Reporting Program provision of the 21st Century Cures Act by establishing new Conditions and Maintenance of Certification requirements for health IT developers under the Program. The HTI–1 Proposed Rule also proposed several updates to certification criteria and implementation specifications recognized by the Program, including a revised certification criterion for decision support and revised certification criteria for “patient demographics and observations” and “electronic case reporting.” Additionally, the HTI–1 Proposed Rule proposed to establish a new baseline version of the United States Core Data for Interoperability (USCDI). The HTI–1 Proposed Rule also proposed enhancements to support information sharing under the information blocking regulations. The implementation of these provisions would advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information. The HTI–1 Proposed Rule also proposed to update the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs and is subject of this final rule.

C. General Comments on the HTI–1 Proposed Rule

Comments. Numerous commenters expressed support for the overall direction of the HTI–1 Proposed Rule and its policy goals, including improved interoperability, standardization, reporting requirements, and electronic health information exchange. Many commenters also stated that the updated standards and certification criteria in the HTI–1 Proposed Rule would enhance patient and clinical access and enable health care providers to better meet patients' needs. A few commenters commended us for the protections for patients' privacy provided by the standards in the HTI–1 Proposed Rule. A few commenters also expressed appreciation for ONC providing clarity on certification criteria for certified health IT. A number of commenters stated that they looked forward to working with ONC and cooperating with the public and private sectors on improving interoperability for EHI.

Response. We appreciate the support expressed by many commenters. This final rule maintains the direction of the HTI–1 Proposed Rule, and we also look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.

Comments. Many commenters expressed concern that the timeline for compliance deadlines for the standards in the HTI–1 Proposed Rule was too aggressive and that it was unrealistic for the health IT community to meet the requirements. Several commenters recommended delaying the compliance deadlines until at least two years after the date of publication of the final rule or providing a temporary enforcement safe harbor for developers and providers who are in the process of implementing the required changes. One commenter suggested that the timeline for adoption might be too aggressive and lead to health IT developers producing Health IT Modules that meet certification standards without providing the intended substantive benefits for patients and providers. A few commenters suggested that ONC create a standardized framework and cycle for adopting and requiring new and revised standards for certification criteria. Commenters suggested that ONC give more consideration to the burden placed on the health IT community by the requirements of both ONC and CMS standards, and work with CMS and other HHS agencies to more closely align standards and compliance dates.

Response. We appreciate commenters' concerns about the timelines for conformance to new standards and certification criteria for the Program. After consideration of comments, we have finalized the adoption of certain certification criteria and standards with a compliance date of January 1, 2026, instead of the proposed compliance date of January 1, 2025, and noted in the specific certification criteria or standards each specific adopted conformance date. We have finalized the adoption of § 170.315(a)(5); (b)(1), (2), and (9); (e)(1); (f)(5); and (g)(6), (9), and (10) with a compliance date of January 1, 2026. We believe that these updated compliance dates, which are approximately two years from when this final rule published in the Federal Register , for certain criteria will allow developers increased flexibility and alleviate burden by allowing additional time for developers to prioritize updates, while also ensuring timely implementation of the requirements for health care providers and patients. We note that the compliance date defines the date by which a health IT developer with a Health IT Module certified to any revised certification criterion, as defined in § 170.102, must update the Health IT Module and provide such update to their customers in order for the Health IT Module to maintain certification.

In response to commenters' recommendations for a standardized framework and cycle for updates to certification criteria, we appreciate commenters' concerns about the long-term timeline for updates to ONC Certification Criteria for Health IT. We have finalized our proposed approach to discontinue the use of year themed editions for ONC Certification Criteria for Health IT and adopt an incremental approach to updates to ONC Certification Criteria for Health IT. We believe that an incremental approach to updates will allow for a more consistent and transparent update cycle. We plan to issue clear guidance and timelines for when updates would be required.

Comments. A number of commenters stated that the HTI–1 Proposed Rule and ONC's rulemaking schedule is overly complex, including a broad range of proposed changes to regulations. Some commenters recommended simplifying the proposals in this rule or creating a process to introduce more simplified regulatory updates in the future.

Response. We appreciate the concerns expressed about the complexity and broad scope of the changes to standards and the Program in this rule. Upon consideration of all the comments we have received, we have made adjustments, such as an extended implementation timeline for most standards and certification criteria and modified requirements for Health IT Modules certified to § 170.315(b)(11), in this final rule to alleviate the potential burden on developers of certified health IT and health care providers.

Comments. Some commenters stated that the adoption of a singular set of standards for EHI could have harmful effects for Health IT Modules. A few commenters were concerned that the standards in the HTI–1 Proposed Rule would not allow for specific standards for specialized or small health care providers. A few commenters were concerned that the requirements in the HTI–1 Proposed Rule could make health care providers dependent on collaboration with health IT developers to meet their obligations and could increase EHR fees for physicians or create bottlenecks that prevent physicians from adopting new EHR technology. Some commenters recommended that ONC provide assistance and guidance for providers to understand new requirements, and consider patient accessibility, particularly the limitations of patient literacy regarding healthcare and health IT, for requirements for patients' records. A number of commenters were concerned that the HTI–1 Proposed Rule's requirements for interoperability and patient access would not adequately protect patients' private information. Several commenters also recommended that ONC require greater transparency from health IT developers to foster an accessible health IT marketplace for consumers.

Response. We believe the updated standards and certification criteria will improve health IT interoperability and functionality for providers and patients. We thank commenters for their comments regarding privacy concerns and recognize the importance of addressing the privacy and confidentiality of sensitive information. Recognizing this, the Program establishes the standards, implementation specifications, and functional requirements for certified health IT to manage and exchange data but does not control the collection or use of data. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), which addresses patients' (and their authorized representatives') ability to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. We also appreciate commenters recommending that we require greater transparency from health IT developers to foster an accessible health IT marketplace for consumers. As stated in the HTI–1 Proposed Rule (88 FR 23831) and this final rule, data collected and reported under the Insights Condition will address information gaps in the health IT marketplace and provide insights on the use of certified health IT. We believe that consumers will benefit from the increased transparency that the reporting requirements of Insights Condition will provide.

While we believe that the language that we use in this rule provides clarity on the effects of this rule, as we did with the HTI–1 Proposed Rule, we will develop, as appropriate, resources such as infographics, FAQs, and fact sheets and provide webinars among other forms of educational materials and outreach to explain the effects of this rule for developers, providers, and patients.

Comments. One commenter requested that ONC adopt a definition of “health IT developer” to provide more clarity regarding what entities may be considered developers for certification criteria.

Response. We thank commenters for their feedback. We decline to adopt a new definition for “health IT developer” in this rule. Adopting a new definition for “health IT developer” would be out of scope for this rule because we did not propose a definition of “health IT developer” in the HTI–1 Proposed Rule.

Comments. One commenter recommended ONC include non-patient facing facilities ( e.g., radiology) in the certified health IT requirements. This commenter stated that by establishing specialty-specific or size-specific health IT requirements, the goal of promoting interoperability across the healthcare landscape may be better achieved.

Response. We thank the commenter for their feedback. Including non-patient facing facilities in the certified health IT requirements was out of the HTI–1 Proposed Rule's scope. As we did not propose such changes to health IT requirements in the HTI–1 Proposed Rule, these changes would also be out of scope for this rule.

Comments. A few commenters raised issues that are out of scope for this rule, including concerns specifically about CMS policies and requirements.

Response. We reiterate that comments regarding CMS program requirements are out of scope as we cannot change CMS policy. We refer to readers to CMS programs for further information.

Comments. Some commenters requested that ONC provide technical assistance for the implementation of the requirements of this rule.

Response. We thank commenters for their feedback. As we did with the HTI–1 Proposed Rule, we will develop, as appropriate, resources such as infographics, FAQs, and fact sheets and provide webinars among other forms of educational materials and outreach to explain the effects of this rule for interest parties.

Comments. Several commenters identified issues that were out of scope for our proposal, such as requesting potential changes to the Cures Act and other federal legislation, and developing state local public health infrastructure and regulations with state and local health agencies.

Response. We appreciate commenters' interest in federal legislation, and state and local public health infrastructure and regulations. Because we did not propose changes related to these areas in the HTI–1 Proposed Rule, these comments are out of scope, and we decline to finalize the recommended changes in this rule. ONC does not have the authority to change federal legislation through rulemaking. ONC looks forward to communicating with state and local public health agencies for the implementation of this rule and the development of future rulemaking.

Comments. We also received numerous comments that were out of scope or that recommended that ONC adopt new requirements that we did not propose and are not addressed in this rulemaking.

Response. We thank commenters for their input. These comments are out of scope for the HTI–1 Proposed Rule in that we did not propose changes to the requirements the comments addressed, and we decline to finalize such changes.

III. ONC Health IT Certification Program Updates

A. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions,” Definition of Revised Certification Criterion, and Related Program Oversight

1. Discontinuing Year Themed “Editions”

In the HTI–1 Proposed Rule, we stated that we no longer believed it was helpful or necessary to maintain an “edition” naming convention or to adopt entirely new editions of certification criteria to encapsulate updates over time (88 FR 23750). Instead, we proposed that there should be a single set of certification criteria, which would be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. We proposed in the HTI–1 Proposed Rule to rename all certification criteria within the Program simply as “ONC Certification Criteria for Health IT” (88 FR 23759). We explained that maintaining a single set of “ONC Certification Criteria for Health IT” would create more stability for users of health IT and Program partners, such as CMS, as well as make it easier for developers of certified health IT to maintain their product certificates over time. Unchanged certification criteria would no longer be duplicated as separate criteria under multiple editions. Accordingly, we proposed to rename § 170.315 as the “ONC Certification Criteria for Health IT” and replace all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this would impact the wording, though not the substance or effect, of §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550, as shown in the revised regulation text).

Comments. Many commenters were supportive of ONC's proposed approach to discontinue the use of year-themed editions for ONC Certification Criteria for Health IT, stating that it would reduce confusion. Commenters generally indicated that the change from year themed editions to adopting the name “ONC Certification Criteria for Health IT” would be understood by health IT developers, patients, and health care providers. Commenters stated and agreed that the previous naming convention inaccurately implied the age and outdatedness of the certification criteria and contributed to confusion about which edition was required for Program adherence. A number of commenters agreed that the change to incremental updates of certification criteria would be more efficient and allow for more flexibility than the edition-based updates to certification criteria that ONC has previously adopted. One commenter stated that such an approach would be more appropriate given the rapid pace at which health IT evolves. Another commenter favored the use of clear, regular, step-by-step updates in small portions, rather than complete overhauls of certification criteria. The commenter also favored a predictable timeline for updates based on standards development cycles with reasonable development timelines.

Alternatively, some commenters expressed concern that discontinuing year-themed editions and adopting incremental advancement for certification criteria would create too much burden for developers of certified health IT and health care providers around updating Health IT Modules. Commenters stated that adopting incremental updates to many criteria instead of edition-based updates to criteria could lead to too many and too frequent deadlines for developers and providers to comply with and a significant added burden in cost and time. Commenters raised concerns that incremental standards updates may divert developer resources away from implementing provider requests. A few developers recommended that ONC adopt a regular cycle for updates and compliance to certification criteria and provide adequate time between revisions to criteria that accommodate typical development timelines for Health IT Modules. Numerous commenters contended that the proposed approach to discontinue the use of year-themed editions for ONC health IT certification criteria in favor of using the title “ONC Certification Criteria for Health IT” would not add sufficient clarity to the Program or would actually make the Program more difficult to understand. Commenters stated that the incremental updates for certification criteria could make it difficult for developers and consumers to understand which iterations of revised and updated standards are the most recently adopted criteria that Health IT Modules need to be certified to. A few commenters stressed that ONC should provide specificity and education regarding the standards that are necessary to participate in federal interoperability programs. Some commenters recommended that ONC create a listing of information on certification criteria that health IT developers and consumers could reference to determine the most up-to-date standards for a certification criterion and Health IT Module certified to such criterion. A few commenters requested greater clarity on how much responsibility consumers as opposed to developers would bear for maintaining the certification for Health IT Modules with the adoption of incremental advancements. One commenter was concerned that developers might charge providers the costs for updates and recommended that ONC add a requirement for developers to inform health care providers of the meaning of a “provider product” and the consequences of declining updates to health IT for participation in other federal programs.

Response. We thank all commenters for their thoughtful feedback. Upon consideration of all comments received on this proposal, we have finalized our approach as proposed. As noted in the HTI–1 Proposed Rule (FR 23759), we believe that there should be a single set of certification criteria, which would be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. To finalize this proposal, we renamed all certification criteria within the Program simply as “ONC Certification Criteria for Health IT.” We believe maintaining a single set of “ONC Certification Criteria for Health IT” will create more stability for users of health IT and Program partners, such as CMS, as well as make it easier for developers of certified health IT to maintain their product certificates over time. In addition, we believe that this approach will have the benefit of reducing administrative burden for health IT developers participating in the Program. Previously, duplicative references to separate certification criteria under multiple, year-themed editions created administrative burden for health IT developers by requiring developers to seek an updated certificate attributed to the “new” duplicated certification criterion even in circumstances when the certification criterion remained substantively unchanged. Under this approach, unchanged certification criteria would no longer be duplicated as separate criteria under multiple editions. Accordingly, we renamed § 170.315 as the “ONC Certification Criteria for Health IT” and replaced all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this impacted the wording, though not the substance or effect, of §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550, as shown in the revised regulation text).

With respect to those commenters that expressed reservations, discontinuing the use of year-themed editions for ONC Certification Criteria for Health IT will not impose a significant burden on implementers. Our intent with this approach is to maintain a single set of certification criteria that have been updated to include the most recent versions of adopted standards, and to establish an incremental approach to health IT updates over time. In fact, this has been embedded within the Program's approach all along because of the way we revised only certain certification criteria within an edition change. Moreover, in the ONC Cures Act Final Rule, we stated our belief that this kind of approach should also include development timelines based on the updates required for each criterion and a transition period allowing for either the prior adopted standard or the new standard to be used for a reasonable period of time (before shifting to exclusive use of the new standard). We further noted our belief that this approach can help to reduce the burden on health IT developers and health care providers and could allow health IT developers to implement updates in the manner most appropriate for their product and customers (85 FR 25665). We have received significant positive feedback expressing that the incremental approach to updates is generally beneficial as a long-term approach. Specifically, feedback conveyed that a consistent, transparent, incremental update cycle that includes the following features would be preferred by some: (1) regular updates to recognize standards advancement and an allowance for voluntary standards advancement between updates, (2) incremental updates rather than “wholesale” product overhauls, (3) a predictable timeline for updates based on standards development cycles with reasonable development timelines, and (4) a reasonable development timeline for any new criterion based on specific development needs. We plan to issue clear guidance and timelines for when updates would be required. In consideration of the overall support from commenters, we have finalized our proposed approach to discontinue the use of year themed editions for ONC Certification Criteria for Health IT.

In response to commenters that indicated we did not provide adequate specificity or education in our HTI–1 Proposed Rule, we appreciate the commenters' concerns and agree with the need for educational materials and resources. We intend to make updates to ONC website materials, engage in public presentations and webinars, and revise the Certified Health IT Product List (CHPL) database to make clear which certification criteria, standards, and implementation specifications are valid under the Program at a given point in time. Between the ONC website and the CHPL updates, we are confident that interested parties will have the necessary information regarding both certification criteria and certified health IT products. We will also develop educational resources so that purchasers and users understand which Health IT Modules have met their obligations under the Program by updating their Health IT Modules to revised certification criteria.

In response to the commenter suggestion that ONC add a requirement for developers to inform health care providers of the meaning of a “provider product” and the consequences for declining updates to health IT regarding participation in federal reporting programs, we thank the commenter for their comment. However, we have not proposed any requirements related to the term, “provider product,” and decline to finalize any such requirements in this final rule. Although we are not at this time requiring developers to inform health care providers of the consequences of declining updates to health IT, we encourage developers to be transparent with customers about the benefits of updates and impacts of declining them. We understand there are costs associated with updating new technology and also with foregoing participation in a federal program that requires the use of certified health IT. Therefore, we encourage developers to ensure that their customers are fully informed about all impacts before making a decision on updates.

Comments. Several commenters requested further clarity on issues related to the impact of the proposed approach on public health entities. Commenters noted that an approach should include an “expiration date” or identify minimum standards to ensure public health and other entities receiving data from certified health IT do not maintain support for outdated standards. Commenters also stated that the proposed approach should recognize the cost and implementation burden for public health agencies associated with updating standards, and that all regulatory impact analyses, including for the current rule, should include estimated costs for public health agencies, laboratories, and their intermediaries. Further, commenters recommended more attention on public input procedures, including from public health, and asked ONC to ensure that regulations do not update standards without verifying that public health authorities can meet the updated standards. Finally, one commenter suggested that ONC reference the authority of state, local, and territorial public health agencies within the standards update process to ensure clarity for users.

Response. We thank commenters for their input. We have identified in several places within 45 CFR part 170 subpart B, and within several certification criteria in 45 CFR part 170 subpart C, “expiration dates” and dates after which a standard or certification criterion is no longer valid within the context of the Program. We believe these dates will ensure public health and other entities receiving data from certified health IT do not maintain support for outdated standards. We understand concerns about the broader overall downstream impact of this rulemaking on entities beyond developers of certified health IT, which are specifically regulated under authorities delegated to ONC. This rule's impact analysis measures the estimated costs for developers of certified health IT to meet new Program requirements, for example, to develop or modify the technical functionality of their certified health IT or adopt a new standard or standard version. These are the expected direct costs of the rule's final policies on developers of certified health IT. However, we recognize that developers of certified health IT are largely private businesses that operate in a competitive marketplace and that they may not bear all costs to meet these requirements. We include in the “Costs and Benefits” section of the Regulatory Impact Analysis the estimated impact on certified health IT end users. In this case, health care providers, such as hospitals and clinicians. We believe these estimates provide a general, but not necessarily comprehensive, understanding of the possible pass-through costs borne by users of certified health IT.

We also plan to issue educational resources explaining, consistent with standards and timelines adopted in this rule, when updates would be required. In addition, we actively engage with public health agencies to ensure that the regulatory process for updating standards represents their input. Finally, we indicate the authority of state, local, and territorial laws and requirements where appropriate.

Comments. One commenter stated that they did not support the change to an “edition-less” format because the availability of the Standards Version Advancement Process (SVAP) allows health IT developers to upgrade to approved standards on a voluntary basis. The commenter urged ONC to consider the following steps to mitigate burden on health IT developers: provide a minimum implementation time of 24 months for any new or updated criteria, utilize the SVAP process over required updates where feasible, accept “evidence-based” attestations for the purposes of certification, and work with other HHS agencies on awareness around updates to certification criteria.

Response. As noted above, we plan to issue educational resources explaining, consistent with standards and timelines adopted in this rule, when updates would be required. In the ONC Cures Act Final Rule, as part of the Real World Testing Condition of Certification, we finalized a “flexibility” within the associated Maintenance of Certification that we refer to as the SVAP (85 FR 25775). This flexibility permits health IT developers to voluntarily use newer versions of adopted standards in their certified Health IT Modules so long as certain conditions are met. These conditions are not limited to, but notably include, successful real world testing of the Health IT Module using the new version(s) subsequent to the inclusion of these newer standards and implementation specification versions in the Health IT Module's certification. We established the SVAP not only to meet the Cures Act's goals for interoperability, but also in response to the feedback ONC has received through prior rulemakings and engagements, which advocated for ONC to establish a predictable and timely approach within the Program to keep pace with the industry's standards development efforts (85 FR 25775). We continue to support the SVAP, but we also believe it is necessary to discontinue the use of year-themed editions for ONC Certification Criteria for Health IT and adopt incremental updates to the Program. While SVAP allows flexibility for the voluntary adoption of newer versions of standards, the incremental Program updates will ensure aligned minimum requirements within the health IT industry that advance interoperability.

Comments. One commenter stated that moving to an “edition-less” approach would require ONC–ACBs to provide increased oversight to ensure certified health IT meets the specific compliance dates provided in regulation. Another commenter stated that ONC should provide a minimum of six months for developers and ONC–ACBs to implement this change, such as removing references to the 2015 Edition from documentation related to the Program.

Response. We thank commenters for their feedback; however, we disagree that moving to an “edition-less” approach will require ONC–ACBs to conduct more oversight than under the edition-based construct. We note that while an “edition-less” approach may require different levels of documentation of oversight than currently exist in the Program, this approach will also likely reduce documentation and oversight in other areas given that health IT developers will not update Health IT Modules to all certification criteria at once, which was the case under the edition-based approach.

Comments. All comments received were supportive of revising the text from “time-limited certification and certification status for certain 2015 Edition certification criteria” in § 170.550(m) to “time-limited certification and certification status for certain ONC Certification Criteria for Health IT.” Commenters noted that our proposal for time-limited certification should require products be clearly labeled and advertised as time-limited and include a description of which aspects of the product/certification are time-limited. Additionally, commenters requested we make a filterable tag in the CHPL and/or provide a list of the time-limited products separately.

Response. We appreciate the support expressed by many commenters, and we have finalized the removal of “2015 Edition” from § 170.550(m). We look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.

After consideration of these comments, we have finalized our proposed approach to discontinue year-themed editions. Specifically, we have renamed § 170.315 as the “ONC Certification Criteria for Health IT” and replaced references to the “2015 Edition” in §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550, with this description.

2. Definition of “Revised Certification Criterion”

In the HTI–1 Proposed Rule, we described the use of terms meant to describe the status of certification criteria for use in the Program from the 2011 to 2014 Edition transition (88 FR 23760). We also referenced the definitions finalized in the 2015 Edition Final Rule for the following terms:

• “New” certification criteria are those that as a whole only include capabilities never referenced in previously adopted certification criteria editions and to which a Health IT Module presented for certification to the 2015 Edition could have never previously been certified.
• “Revised” certification criteria are those that include the capabilities referenced in a previously adopted edition of certification criteria as well as changed or additional new capabilities; and to which a Health IT Module presented for certification to the 2015 Edition could not have been previously certified to all of the included capabilities.

• “Unchanged” certification criteria are those that include the same capabilities as compared to prior certification criteria of adopted editions; and to which a Health IT Module presented for certification to the 2015 Edition could have been previously certified to all the included capabilities (80 FR 62608).

We proposed that these same terms as applied to the certification criteria would continue to be used by the Program in the absence of a year-named edition. However, for clarity, we proposed to define “revised certification criterion (or criteria)” in § 170.102 to mean a certification criterion that meets at least one of the following: (1) has added or changed the capabilities described in the existing criterion in 45 CFR 170 part C; (2) has an added or changed standard or implementation specification referenced in the existing criterion in 45 CFR part 170 subpart B; or (3) is specified through notice and comment rulemaking as an iterative or replacement version of an existing criterion in 45 CFR part 170 subpart C.

We stated in the HTI–1 Proposed Rule that we would continue to use these terms when: communicating proposals for future criteria, such as revising a criterion that will maintain its place in the CFR or establishing a new criterion that is an iterative or replacement criterion in the Program; establishing scenarios for when gap certification is an option for developers of certified health IT; and setting expiration dates or applicable timelines related to standards and certification criteria. Through the development of educational resources, such as fact sheets and resource guides, these designations will help users and the public understand to which versions of standards and certification criteria a Health IT Module may be certified when multiple versions of standards or certification criteria are available under the Program. In the HTI–1 Proposed Rule, we proposed applicability or implementation timelines for both our certification criteria and the standards adopted in 45 CFR part 170 by establishing the dates by which an existing version of a criterion or standard is no longer applicable and by establishing a date by which a new or revised certification criterion or standard version is adopted (88 FR 23760).

Comments. Most commenters supported our proposed definition of “revised certification criterion (or criteria).”

Response. We appreciate the feedback from commenters. We believe the revised certification criterion (or criteria) definition provides clarity around our approach for setting applicability or implementation timelines for both our certification criteria and the standards adopted in 45 CFR part 170. We have finalized our definition for revised certification criterion (or criteria) as proposed.

Comments. Some commenters suggested better coordination with the Centers for Medicare & Medicaid Services (CMS) to ensure that our definition is consistent and aligned with the Medicare Promoting Interoperability (PI) Program or MIPS Promoting Interoperability performance category.

Response. We appreciate the comment and will continue to coordinate and work with our federal partners, including CMS, on points of intersection for potential future rulemaking. We note that the CY 2024 Physician Fee Schedule Proposed Rule has a discussion related to this policy, and we invite readers to review the discussion at 88 FR 52547.

Comments. One commenter inquired how users of a certified Health IT Module that has been certified to multiple certification criteria that have been revised and included overlapping timeframes for standards updates will know if the Health IT Module is compliant.

Response. ONC has included in the Code of Federal Regulations (CFR) revisions to certification criteria, standards, and implementation specifications—and their associated timelines. To meet a certification requirement, a Health IT Module would need to be updated to the most recently adopted capabilities and standards indicated in the CFR within the timelines specified. For example, if a finalized revised certification criterion references a new standard this year that must be adopted by 2027, and we subsequently revised this certification criterion through rulemaking again in 2026 with a newer version of that standard to be adopted by 2028, then the Health IT Module would need to be updated to the new standard identified this year in the CFR by 2027 and subsequently be updated to the standard identified through rulemaking in 2026 by 2028.

Comments. One commenter inquired how an update to an existing criterion will be identified on the CHPL.

Response. ONC will establish clear requirements and timelines for all revised criteria within the CHPL. To support effective communication of the updates, we will implement a practical approach to facilitate transparency using the CHPL.

Table 1 below includes the revised certification criteria we have finalized in this rule.

In the HTI–1 Proposed Rule, we included proposed modifications to our approach for setting applicability or implementation timelines for each certification criteria and the applicable standards adopted in 45 CFR part 170 (88 FR 23761). In this final rule, we have finalized that proposal to incorporate the applicable timelines and “expiration dates” for capabilities and standards updates within each individual criterion or standard.

We direct readers to section III.C.11 of this final rule for further discussion of the requirements for health IT developers voluntarily participating in the Program related to health IT certification updates.

3. Program Oversight Related to Discontinuation of Editions

a. Records Retention

In the ONC Cures Act Final Rule, we revised the Principles of Proper Conduct for ONC–ACBs and ONC–ATLs by amending the records retention policies to include the “life of the edition” (85 FR 25710 through 25713). Specifically, we clarified that the records retention provisions in §§ 170.523 and 170.524 included the “life of the edition” as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. We explained that “[b]ecause the `life of the edition' begins with the codification of an edition of certification criteria in the CFR and ends on the effective date of the final rule that removes the applicable edition from the CFR, the start and end dates for the `life of the edition' are published in the Federal Register in the rulemaking actions that finalize them. The period of three years beyond the `life of the edition' begins on the effective date of the final rule that removes the applicable edition from the CFR, thus the three-year period after removal from the CFR continues through three full calendar years following that date” (85 FR 25710).

In the HTI–1 Proposed Rule, we proposed to maintain a single set of “ONC Certification Criteria for Health IT” and not an edition, so we therefore proposed to revise § 170.523 and § 170.524 (88 FR 23762). We proposed that the period of three years begins on the effective date of the final rule that removes the applicable ONC certification criterion or criteria for health IT from the CFR, thus the three-year period after removal from the CFR continues through three full calendar years following that date (in addition to the calendar year in which it was removed). We also retained the “Complete EHR” language in these sections because beginning with the 2015 Edition, Complete EHR certifications could no longer be issued. However, since the 2014 Edition was not removed from the CFR until the ONC Cures Act Final Rule, which became effective on June 30, 2020, records would need to be retained (including Complete EHRs) until June 30, 2023.

Comments. A majority of commenters, including individuals, professional trade associations, and other interested parties expressed support for the ONC–ATLs retaining the records of Complete EHRs' and Health IT Modules' testing through a minimum of three years from the effective date of the removal of those certification criteria from the CFR. Commenters indicated such requirements were reasonable, particularly in relation to the retirement of the edition concept, and they indicated that these records could better facilitate surveillance and enforcement of certification criteria and transparency for customers. One commenter highlighted the importance of retaining those records for historical documentation regarding their health IT vendors' certification status. One commenter suggested ONC expand the three-year requirement to six years, to align with the HIPAA Privacy Rule's retention period.

Response. We appreciate the commenters' support for continuing our current three-year retention policy and our proposed modifications that the retention policy would be effective for three full calendar years beginning on the effective date of the final rule that removes the applicable ONC certification criterion or criteria for health IT from the CFR. We agree that maintaining those records for historical documentation is important and have finalized our policy as proposed. We do not believe that a six-year retention policy is needed at this time because it may result in more burden than is warranted. However, we will continue to monitor the effectiveness of our existing retention policy and consider changes as needed, including consulting with Federal partners that conduct federal program enforcement, such as the HHS OIG.

Comments. Commenters suggested ONC establish an organized system of documentation management for each Health IT Module/developer to be shared on the CHPL to streamline the process and enhance efficiency; to adopt new indicators of current certification status each time a criterion certified as part of a Health IT Module is incrementally updated; and to create a special coding system that represents the most current year of certification for Health IT Modules to support oversight and compliance requirements health care providers may have with other programs such as the CMS Quality Payment Program.

Response. We appreciate commenters identifying options for enhancing how the Program documents certification status for Health IT Modules as we retire the year-themed edition approach. We note that the CHPL primarily serves as a comprehensive repository of certified health IT products and their corresponding certification details. While it provides information about certified health IT products, it does not specifically serve as a documentation management system for Modules/developers. The CHPL provides transparency and access to certification information, including the certification criteria used for certifying a Health IT Module, test results, and certified health IT product details. It serves as a valuable resource for users to verify the certification status and capabilities of Health IT products. Overall, we will take these comments, and related comments received, into consideration as we implement removal of year-themed editions in the Program.

b. Records Retention—Complete EHR

In the HTI–1 Proposed Rule, we proposed to retain the “Complete EHR” language in §§ 170.523 and 170.524 even though, beginning with the 2015 Edition, Complete EHR certifications could no longer be issued. We did so because the records for 2014 Edition Complete EHR certifications still needed to be retained until the records retention timeframe expired on June 30, 2023. Though not specifically stated in the HTI–1 Proposed Rule, the removal of the “Complete EHR” language from all reference points in §§ 170.523 and 170.524 could have been reasonably anticipated once June 30, 2023, had passed. Therefore, since the date has now passed and because retaining “Complete EHR” in the regulation text may cause confusion for the public, we have removed all remaining references to the “Complete EHR” language in §§ 170.523 and 170.524.

B. Standards and Implementation Specifications

1. National Technology Transfer and Advancement Act

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

In this final rule, we use voluntary consensus standards except for:

• The standard adopted in § 170.213, the United States Core Data for Interoperability Version 3 (USCDI v3), is a hybrid of government policy ( i.e., determining which data to include in the USCDI) and voluntary consensus standards ( i.e., the vocabulary and code set standards attributed to USCDI data elements); and

• The standard adopted in § 170.207(f)(3) for race and ethnicity.

We are not aware of any voluntary consensus standards that could serve as an alternative for the purposes we describe in further detail throughout this final rule including establishing a baseline set of data that can be exchanged across care settings for a wide range of uses. We refer readers to section III.C.1 of this preamble for a discussion of the USCDI.

Comments. One commenter suggested ONC look at the work of the FHIR accelerators as meeting the requirements of `voluntary consensus bodies' outlined in the OMB Circular A–119 for standards and frameworks that fall outside of the HL7 process. The commenter stated that as an example, CARIN has worked with FAST to develop a framework for how digital identity is federated across healthcare participants with the CARIN/HHS Healthcare Digital Identity Federation Proof of Concept report in which ONC participated. The commenter encouraged ONC to leverage the open-source work that has been done to advance digital identity federation in future rulemaking.

Response. We thank commenters for their input. We will consider leveraging the work that the commenter suggested in future rulemakings.

2. Compliance With Adopted Standards and Implementation Specifications

In accordance with Office of the Federal Register regulations related to “incorporation by reference,” 1 CFR part 51, which we follow when we adopt proposed standards and implementation specifications in any subsequent final rule, the entire standard or implementation specification document is deemed published in the Federal Register when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the standard and implementation specification includes the entire document unless we specify otherwise. If an element of the IG is optional or permissive in any way, it will remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text would preempt the permissiveness of the IG.

3. “Reasonably Available” to Interested Parties

The Office of the Federal Register has established requirements for materials ( e.g., standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). To comply with these requirements, in section V (“Incorporation by Reference”) of this preamble, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we have adopted and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about these standards and implementation specifications throughout the relevant sections of this final rule.

C. New and Revised Standards and Certification Criteria

1. The United States Core Data for Interoperability Version 3 (USCDI v3)

As discussed in the HTI–1 Proposed Rule, the USCDI is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange (88 FR 23751). USCDI v1 established a baseline set of data that can be commonly exchanged across care settings for a wide range of uses and is a required part of certification criteria in the 2015 Edition Cures Update. For the overall structure and organization of USCDI, including data classes and data elements in USCDI v1, please see the discussion in the ONC Cures Act Final Rule (85 FR 25669–25670), as well as www.healthIT.gov/uscdi.

We stated in the ONC Cures Act Final Rule that we intended to utilize a predictable, transparent, and collaborative process to expand USCDI, including providing the public with the opportunity to comment on USCDI's expansion (85 FR 25670). We also noted that developers of certified health IT would be able to use the Standards Version Advancement Process (SVAP) to voluntarily implement and use a newer, National Coordinator-approved version of USCDI without waiting for ONC to propose and adopt via rulemaking an updated version of the USCDI (85 FR 25669). We, therefore, established a process for expanding USCDI based on public input and submissions of new data elements and classes. To enable these submissions, we created the ONC New Data Element and Class (ONDEC) submission system, which provides the public with the opportunity to submit new data elements for consideration for inclusion in future versions of USCDI.

In the HTI–1 Proposed Rule, we proposed to update the USCDI standard in § 170.213 by adopting the newly released USCDI v3 and establishing a January 1, 2025, expiration date for USCDI v1 (July 2020 Errata) for purposes of the Program. We proposed to add USCDI v3 in § 170.213(b) and incorporate it by reference in § 170.299. Specifically, we proposed in the HTI–1 Proposed Rule to adopt USCDI v3 (October 2022 Errata). We also proposed to codify the existing reference to USCDI v1 (July 2020 Errata) in § 170.213(a). Lastly, we proposed that as of January 1, 2025, any developers seeking certification for their Health IT Modules to criteria that reference the standards in § 170.213 would need to be capable of exchanging the data elements that comprise USCDI v3.

Comments. We received a large number of comments expressing overall support for our proposals to adopt USCDI v3 in § 170.213(b) and for USCDI v1 to expire on January 1, 2025. Many commenters specifically supported the inclusion of SDOH data elements in USCDI v3 and noted that more accurate and complete patient characteristics will help address health disparities. Several commenters in support of our proposals specifically agreed with the proposed deadline. Commenters supporting our proposal also noted that it would reduce burden, advance interoperability, support quality measurement initiatives, and support providers' ability to acquire and share the information needed to provide the best care for their patients.

Response. We thank commenters for the support of our proposals and for recognizing potential benefits such as reduced burden, increased interoperability, more complete data, and the ability to support quality measurement initiatives and better address health disparities.

Comments. We received numerous comments that expressed concern about the proposed deadline and advocated for an extension. These comments generally expressed concern about the burden on developers posed by the proposed deadline, stating that more time would be needed to successfully adopt USCDI v3, including development, implementation, and testing, and stressed that it would be a large undertaking for developers as well as for health care providers. Some commenters recommended moving the deadline to the end of the calendar year which is no shorter than 24 months from the publication of this final rule. Some commenters suggested extending the compliance deadline by six months, and others suggested compliance dates of December 31, 2025, or January 1, 2026. Several commenters mentioned the need for ONC to coordinate with CMS on timelines, and one mentioned the need to allow providers a “flex” year after the certification deadline during which to upgrade. Some comments suggested aligning compliance deadlines with the availability of scalable FHIR-based API standards, which they stated could help support successful implementation of USCDI v3, while others suggested waiting to adopt USCDI v3 until after Release 4 of the C–CDA Companion Guide is finalized. Some commenters stated that USCDI v3 should not be required until all of the standards supporting USCDI v3 are officially published.

Additionally, a number of commenters requested clarification from ONC related to the proposed adoption of USCDI v3. This included clarification on future updates to USCDI; how USCDI works with CMS rules and programs; the applicability of USCDI v2 once USCDI v3 is adopted; the distinction between USCDI, USCDI+ and US Core; the lack of vocabulary standards for some USCDI v3 data elements; and the expectations regarding data sharing.

Response. We thank commenters for expressing a desire for an extension on proposed deadlines. USCDI v3 includes all data elements in USCDI v2, as well as additional data elements. In response to commenters' feedback, we have extended the deadline for the expiration of USCDI v1 in § 170.213 to January 1, 2026. We believe the extended time, combined with the fact that USCDI v3 has been publicly available since July 2022, will make it feasible for all interested parties to meet the revised deadline. We note that USCDI v3 has been available for use in the Program using the FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 through SVAP effective September 11, 2023. In response to comments suggesting that USCDI v3 lacks vocabulary standards, in the USCDI v3 standard ONC has identified applicable vocabulary standards for those USCDI data elements where a coded value is expected, a standard code set is currently in use, and where the submitters and commenters have provided evidence of current use. Further terminology bindings are defined in the C–CDA Companion Guide and HL7 US Core Implementation Guide.

In response to the comment requesting that ONC explain the distinction between USCDI, USCDI+, and US Core, we note that the USCDI+ program was not referenced in the HTI–1 Proposed Rule. USCDI+ supports the identification and establishment of domain or program-specific datasets that will operate as extensions to USCDI and uses similar processes as the USCDI, such as seeking input from the Health IT Advisory Committee and other interested partners to stimulate public engagement and help shape USCDI+ datasets.

As we have described previously, the USCDI is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange. In order for the USCDI to be implemented with specific exchange modalities or functionalities, additional specifications are required to provide guidance on how the USCDI should be implemented in the context of that exchange method. The US Core and C–CDA implementation guides are aligned to specific versions of USCDI and provide the implementation specification and expectations for each particular version of USCDI. In this case, we have finalized USCDI v3 and the applicable FHIR US Core Implementation Guide (FHIR US Core 6.1.0) and C–CDA Companion Guide (C–CDA Companion Guide R4.1), both of which provide guidance on how to implement the updates from USCDI v1 to USCDI v3.

We recognize that we stated in the HTI–1 Proposed Rule that we would consider adopting the most up-to-date versions of the FHIR US Core and C–CDA Companion Guide specifications that align with the updates to USCDI v3 (FHIR US Core 6.0.0 and C–CDA Companion Guide R4). However, after the publishing of FHIR US Core 6.0.0 and C–CDA Companion Guide R4, HL7 found errors with how the guides implemented data elements in USCDI v3 and had to make updates to those specifications to align with USCDI v3 and ensure that USCDI v3 can be implemented in Health IT Modules. Adopting FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real-world implementation (see, for example, 85 FR 25677 and 25708).

In response to comments regarding how CMS or other federal programs incorporate USCDI into rules and programs, we note that ONC receives submissions and comments from federal partners, including CMS, on USCDI content and will continue to work towards alignment where appropriate with these partners.

In response to comments on future updates to USCDI, we clarify that USCDI generally expands annually to keep pace with clinical, technology, and policy changes. ONC follows a predictable, transparent, and collaborative process for updating USCDI that allows interested parties to submit new data elements and classes for future versions of USCDI through the ONDEC submission system. Regarding applicability, USCDI v2 will not be available for new and updating certifications via SVAP after December 31, 2023. We erroneously stated in the HTI–1 Proposed Rule that USCDI v2 would remain available via SVAP until December 31, 2024 (88 FR 23764); however, our intention was that USCDI v2 would remain available via SVAP until it sunsets. USCDI v2 sunsets on December 31, 2023 and will no longer be available via SVAP after that date.

Comments. We received numerous comments expressing concerns about privacy and the implementation of USCDI v3. These commenters generally noted that USCDI v3 includes data elements that may contain sensitive health information, including mental health, substance use, and reproductive health information, the disclosure of which could increase the risk of harassment or harm toward providers and patients. Several of these commenters noted the need for ONC to create education materials around the fact that USCDI v3 does not require sharing of sensitive information. Some commenters recommended that ONC remove data elements that provide personally identifiable information that does not support the provision of care. Several comments encouraged ONC to consider requiring granular data segmentation policies concurrently with adopting USCDI v3. Commenters also requested that ONC consider removing any personally identifiable data elements in USCDI that do not provide value in order to avoid re-identification, or alternatively to revise policies that require automatic inclusion of all data elements in the USCDI.

Response. We thank commenters for their feedback regarding the importance of addressing the privacy and confidentiality of sensitive information. The adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur. We have not adopted new or additional privacy standards related to controlling sensitive data that may be represented in USCDI data elements. However, our existing criteria in § 170.315(b)(7) and (b)(8) include support for privacy and security labels in health information exchange workflows and these criteria reference the HL7® Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 adopted in § 170.205(o)(1) and incorporated by reference in § 170.299. In addition, we have adopted a new requirement as part of the certification criterion in § 170.315(e)(1) in support of the HIPAA Privacy Rule's individuals' “right to request a restriction” as discussed in section III.C.10. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 for discussion on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), stating that patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. The HIPAA Privacy Rule provides federal protections for PHI held by covered entities and gives individuals an array of rights with respect to that information.

Comments. We received multiple comments expressing concern about provider burden, including administrative, cognitive, and documentation burden associated with USCDI data elements. Some commenters also expressed concerns about the cost burden of implementing USCDI v3, noting that it could require numerous downstream standards updates, migration costs, costs to standardize and use unconstrained data, and costs related to software, IT infrastructure, workforce recruiting and training, and ongoing operational costs. Several commenters were particularly concerned about the potential costs to public health organizations and to small and rural providers, which may have limited budgets or resources to devote to the implementation of EHR systems capable of collecting and sharing data according to the USCDI v3 standard. Several commenters suggested that ONC provide resources and support to providers to help reduce provider burden. One commenter proposed a test or pilot to ensure that burdens are not shifted to providers when USCDI v3 is implemented. Another commenter proposed that ONC consider regulations to prevent developers of certified health IT from increasing fees due to the update to USCDI v3.

Response. We thank commenters for the feedback regarding implementation burden and the adoption of USCDI v3. As we have noted, the adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data. USCDI v3 does not dictate when and how either of those two actions occur, including with what frequency health care providers document information that could be captured as part of the data elements within USCDI v3. We also note that we have established a predictable, transparent, and collaborative expansion process for USCDI based on public evaluation of previous versions and submissions by the health IT community. Each of the data elements in USCDI v3 has been evaluated for overall value, maturity, and ease of implementation. In addition, the data elements (as applicable) are represented by health IT standard terminologies, technical specifications, or implementation guides, and are used extensively in production electronic systems. We intend to provide implementation resources such as implementation guide validators for both HL7 C–CDA and FHIR corresponding implementation guides to USCDI v3. However, we decline to conduct a test pilot or create additional regulations focused on burden and USCDI v3 at this time.

We appreciate the comments related to implementation burden for rural and small providers and understand concerns about the overall downstream impact of the HTI–1 Proposed Rule on entities beyond developers of certified health IT to which ONC authorities apply. As part of our Regulatory Impact Analysis in section VII, we have identified that developers of certified health IT are largely private businesses who operate in a competitive marketplace, and they may not bear all costs to meet regulatory requirements.

Comments. Several commenters expressed concerns about data quality when USCDI v3 is implemented and suggested that ONC work with the industry on developing standards. Several commenters expressed concerns about the lack of use cases and standards related to USCDI v3 and suggested that ONC develop those.

Response. We thank commenters for their feedback. We work directly with HL7 to finalize HL7® FHIR® US Core and C–CDA Companion Guide specifications for each published version of USCDI, including USCDI v3. These specifications include terminology bindings to value sets drawn from standard code sets, where appropriate. To further support implementation of USCDI v3, we will update the C–CDA validator and Inferno test tools to align with USCDI v3 and validate the quality of the data. We will continue to identify opportunities to work with industry to improve data quality. For example, we recently awarded a Leading Edge Acceleration Project (LEAP) award to explore enabling easy access to high-quality, standardized healthcare data, with a focus on USCDI in FHIR and open-source platforms.

Comments. Several commenters expressed concern that not all data elements in USCDI v3 are applicable to all users and urged that ONC allow EHRs flexibility in adopting USCDI v3. These commenters generally urged ONC to allow EHRs to add only the data elements needed by their users. Commenters also urged ONC to explore a modular approach for USCDI that would group data elements to support specific use cases, noting that this would help reduce burden and costs while improving care.

Response. We thank commenters for the input suggesting that ONC allow flexibility in supporting USCDI v3 data classes and data elements for purposes of the Program. We decline to allow developers to be selective in which USCDI v3 data classes and data elements they support for purposes of the Program. The USCDI standard is intended to provide a common set of data classes and data elements in support of nationwide health information exchange, therefore, partial adoption of the USCDI standard would impact the effectiveness of the standard and impede interoperability. Additionally, we recognize that not all USCDI v3 data elements originate in an EHR, however Health IT Modules certified to particular certification criteria must be able to capture and exchange the values when available.

Comments. One commenter suggested that ONC establish a framework for certification of specialty EHRs and non-EHRs to help promote USCDI uptake across the care continuum.

Response. We thank the commenter for their suggestion that ONC establish a framework for certification to support specialty EHRs and non-EHRs to promote USCDI uptake across the care continuum. At this time, we decline to provide selective certification frameworks for purposes of the Program. The USCDI standard is intended to provide a common set of data classes and data elements in support of nationwide health information exchange.

Comments. Several commenters expressed a preference for USCDI v4 over USCDI v3, noting that it will help the healthcare marketplace and encourage competition. One comment encouraged ONC to finalize USCDI v4 in 2023 and require support by the end of 2024.

Response. We thank commenters for the comments in support of USCDI v4. However, we did not propose, and therefore decline to adopt, USCDI v4 in the USCDI standards in § 170.213 at this time. We have adopted USCDI v3 in § 170.213(b) as proposed. Additionally, we note that implementation guides are not yet released to support USCDI v4.

Comments. A number of commenters generally encouraged ONC to work with CMS on timelines and on alignment with program requirements, including aligning future USCDI updates with CMS programs.

Response. We thank commenters for the comments regarding working with CMS and assure commenters that we work closely with CMS across multiple programs and initiatives on aligning program requirements and deadlines. We will continue to do so in the future. Those CMS programs include, but are not limited to, the Quality Payment Program, Inpatient Quality Reporting Program, and Medicare Promoting Interoperability Program, as well as regulatory proposals such as the Interoperability and Prior Authorization Proposed Rule (87 FR 76238).

Comments. Several commenters encouraged ONC to maintain awareness of state agency data exchange requirements and to work to alleviate discrepancies, noting that the variances in USCDI versioning pose challenges industry-wide if not aligned with state and federal regulations.

Response. We thank commenters for the comments regarding state agency data exchange requirements and assure commenters that we monitor and are aware of state and federal regulations impacting adoption of USCDI v3.

Comments. There were a number of comments requesting technical support, education, and other resources or actions from ONC related to adopting and implementing USCDI v3. These included addressing semantic differences across health systems, developing mappings and value sets for data elements, improving the specificity and testing requirements for USCDI, expediting the availability of high-quality testing tools, developing and publicizing an analysis of which USCDI elements are interoperable, and aligning data standardization efforts across programs.

Response. We acknowledge the comments requesting resources and technical support from ONC related to adoption of USCDI v3. We maintain a variety of resources and technical support related to USCDI, including numerous resources related to the Program. Resources include Certification Companion Guides (CCGs) and Test Procedures related to specific certification criterion to assist developers that are seeking to certify to the criteria. Any considerations for implementing USCDI in compliance with these criteria are, additionally, outlined in these resources. In addition, there is a USCDI CCG that includes clarifications for specific data classes and elements as they relate to terminology standards and/or implementation guides. The Program offers testing and conformance methods for verification that a product meets criteria requirements. Other technical documentation may be found on ONC's website: https://www.healthit.gov/uscdi .

Comments. There were also a number of commenters that made suggestions for future versions of USCDI. Commenters suggested improving the USCDI interface and allowing comment on proposed value sets. Various commenters suggested adding specific data elements in future versions of USCDI, including the following:

• marital status
• education
• water insecurity
• value-based care
• prescription drug insurance information
• advance directive documentation
• clinical orders
• care experience preference
• newborn delivery information
• vaccine administration date
• vaccination event record type
• medical record number
• mother's maiden name
• multiple birth indicator
• birth order

Response. We thank commenters for the feedback and suggestions regarding future versions of USCDI. The USCDI v3 is a published standard at https://www.healthit.gov/isa/sites/isa/files/2022-10/USCDI-Version-3-October-2022-Errata-Final.pdf and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website, available at https://www.healthit.gov/uscdi, where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future versions of USCDI.

a. Certification Criteria That Reference USCDI

As discussed in the HTI–1 Proposed Rule, the USCDI standard is currently cross-referenced, via cross-reference to § 170.213, in certain certification criteria (88 FR 23763). The criteria cross-referencing to USCDI via cross-reference to § 170.213 are as follows:

• “Care coordination—Transitions of care—Create” (§ 170.315(b)(1)(iii)(A)( 1));

• “Care coordination—Clinical information reconciliation and incorporation—Reconciliation” (§ 170.315(b)(2)(iii)(D)( 1) through ( 3));

• “Patient engagement—View, download, and transmit to 3rd party—View” (§ 170.315(e)(1)(i)(A)( 1));

• “Design and performance—Consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A));

• “Design and performance—Application access—all data request—Functional requirements” (§ 170.315(g)(9)(i)(A)( 1)); and

• “Design and performance—Standardized API for patient and population services—Data response” (§ 170.315(g)(10)(i)(A) and (B)).

We noted in the HTI–1 Proposed Rule that § 170.315(f)(5) also currently references § 170.213; however, we proposed to rely on specific IGs for that criterion, rather than reference § 170.213 (88 FR 23763). We proposed that through December 31, 2024, a Health IT Module certified to the criteria above that cross-reference § 170.213 may be certified by complying with (1) USCDI v1; (2) USCDI v2 under SVAP; and (3) USCDI v3 (88 FR 23763). We proposed to allow only USCDI v3 after this date for the criteria that cross-reference § 170.213.

We noted in the HTI–1 Proposed Rule that a developer of certified health IT will not be required to provide technology updates for certified criteria or standards to a user who declined such updates; however, if such an update is not provided, that version of the Health IT Module will no longer be considered certified under the Program (88 FR 23764).

In the HTI–1 Proposed Rule, we proposed in the preamble to add introductory text to § 170.213 noting that the Secretary adopts the following standards as the standards available for representing EHI (88 FR 23764), and we proposed in the regulatory text to add introductory text to § 170.213 stating the Secretary adopts the following versions of the USCDI standard (88 FR 23907). This discrepancy was inadvertent, and we clarify that we intended to propose introductory text to § 170.213 stating the Secretary adopts the following versions of the USCDI standard. We also proposed to include the date the adoption of the standard in § 170.213(a) expires. Consistent with our proposals in sections III.A and III.C.11, we proposed this expiration date to be January 1, 2025. Health IT developers with Health IT Modules certified to certification criteria that reference § 170.213 would have to update such certified health IT to USCDI v3 and provide it to customers by December 31, 2024. Further, we proposed that Health IT Modules certified to the above-listed certification criteria would need to update their Health IT Modules to accommodate USCDI v3 data elements using the FHIR US Core Implementation Guide Version 5.0.1 in § 170.215(b)(1)(ii) and the HL7 CDA® R2 IG: C–CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 in § 170.205(a)(6). We noted in the HTI–1 Proposed Rule that if the FHIR US Core Implementation Guide and the HL7 CDA® R2 IG: C–CDA Templates for Clinical Notes R2.1 Companion Guide are updated before the date of publication of this final rule, it would be our intent to consider adopting the updated versions that support USCDI v3.

We refer to the term “expires” in standards throughout this final rule, and it means that the standard is unavailable for use in the Program, or any other programs that may cite the standard, as of the expiration date.

Additionally, because we finalized in the ONC Cures Act Final Rule that the Common Clinical Data Set (CCDS) would no longer be applicable for certified Health IT Modules 24 months after the publication date of the ONC Cures Act Final Rule (85 FR 25671), and then extended that date to December 31, 2022, in the interim final rule titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID–19 Public Health Emergency” (85 FR 70073), we proposed to remove references to CCDS in the following sections of 45 CFR 170.315: § 170.315(b)(1)(iii)(A)( 2); (e)(1)(i)(A)( 2); (g)(6)(i)(B); and (g)(9)(i)(A)( 2). In each of those sections, we proposed to instead include a reference to USCDI. Because § 170.315(b)(6)(ii)(A), which also references CCDS, is still available for the period before December 31, 2023, we did not propose to remove the reference to CCDS in that section.

Comments. A number of commenters expressed support for ONC's proposals regarding certification criteria that reference USCDI. Commenters stated this would support health equity by design, help capture more accurate and complete patient data, and help address health disparities.

Response. We thank commenters for support of our proposals and for recognizing the potential benefits. We note that the implementation guides we proposed in the HTI–1 Proposed Rule aligned with USCDI v2, and since the publication of the HTI–1 Proposed Rule, HL7 released updated FHIR US Core and C–CDA Companion Guides that align with the updates to USCDI v3. However, after the publishing of US Core 6.0.0 and C–CDA Companion Guide 4.0, HL7 found errors with how the guides implemented data elements in USCDI v3 and had to make updates to those specifications to align with USCDI v3 and to ensure that USCDI v3 can be implemented in Health IT Modules. Given the adoption of USCDI v3, we have finalized the FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1, which are the most recent versions that align with USCDI v3. FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 have not added any substantial functionality or requirements. We do not believe adoption of FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 would contribute to a greater implementation burden, and FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 are the only versions of their respective implementation guides that fully align with and support the complete USCDI v3.

As discussed earlier in this section, we recognize that we stated in the HTI–1 Proposed Rule that we would consider adopting the most up-to-date versions of the FHIR US Core and C–CDA Companion Guide specifications that align with USCDI v3 FHIR US Core 6.01 .0 and C–CDA Companion Guide R4).1 . However, after the publishing of FHIR US Core 6.0.0 and C–CDA Companion Guide R4, HL7 found errors with how the guides implemented data elements in USCDI v3 and had to make updates to those specifications to align with USCDI v3 and ensure that USCDI v3 can be implemented in Health IT Modules. Adopting FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real-world implementation (see, for example, 85 FR 25677 and 25708).

Comments. Several commenters suggested ONC should establish a more formal schedule for adopting future versions of USCDI into the Program, in addition to requests for clarification on the availability of USCDI v2 under SVAP. Commenters also recommended updating SVAP to allow at least two new versions of the same standard ( e.g., USCDI v2 and USCDI v3) to be available under SVAP at a time.

Response. We thank the commenters for the suggestion. Generally, ONC updates USCDI on an annual basis, usually over the summer after an extensive public comment period. We decline to adopt a more formalized schedule; however, we promote widely the availability of draft versions of USCDI and engage heavily with interested parties, including the HITAC on new versions. As finalized in this rule, developers of certified health IT are able to certify Health IT Modules to certification criteria that reference USCDI v1 until it expires on January 1, 2026. Beginning on January 1, 2026, only USCDI v3 will be available in § 170.213 as the USCDI standard for use by developers of certified health IT. Under SVAP, developers of certified health IT had the opportunity to certify their Health IT Modules to certification criteria that reference USCDI using USCDI v2 from July 2021 through December 2023. Because we approved a newer version of USCDI—USCDI v3 in July 2023 as part of approved standards for 2023 SVAP—Health IT Modules not already certified to USCDI v1 or v2 may adopt USCDI v3 instead. USCDI v2 will not be available for new and updating certifications via SVAP after December 31, 2023. In this final rule, we have codified USCDI v3 in § 170.213(b), and thus it will not be necessary to use the SVAP process to advance to USCDI v3 after this final rule is effective. In general, these comments are out of scope for this final rule as we did not request feedback on the SVAP program as part of the HTI–1 Proposed Rule.

b. USCDI Standard—Data Classes and Elements Added Since USCDI v1

USCDI v3 includes all data elements defined in USCDI v1 and USCDI v2, as well as additional data elements added in USCDI v3. In the HTI–1 Proposed Rule, we described the data classes and data elements in USCDI v3 that are not included in USCDI v1, as well as any data classes or data elements that were changed through the USCDI update processes when comparing USCDI v3 to USCDI v1 (88 FR 23764). For the overall structure and organization of the USCDI standard, including USCDI v3, we urged the public to consult www.healthIT.gov/uscdi . We proposed that each of the data classes or data elements listed below be included in the USCDI standard in § 170.213 and be incorporated by reference in § 170.299 as part of our proposal to adopt USCDI v3.

i. Social Determinants of Health (SDOH)

SDOH are the conditions in which people live, learn, work, and play, and these conditions affect a wide range of health and quality-of-life risks and outcomes. In the HTI–1 Proposed Rule, we stated that USCDI v3 includes four SDOH data elements that represent aspects of SDOH data related to the use or purpose of the SDOH data rather than being based on the domain (88 FR 23764). These data elements are SDOH Assessment in the Assessment and Plan of Treatment data class, SDOH Goals in the Goals data class, SDOH Interventions in the Procedures data class, and SDOH Problems/Health Concerns in the Problems data class.

Comments. A number of commenters expressed general support for inclusion of SDOH-related data elements in USCDI v3, often noting that the access, exchange, and use of these elements by Health IT Modules certified to particular certification criteria would support the availability of more information and better care for patients, as well as more equitable public health interventions.

Response. We thank commenters for the comments expressing support for the inclusion of SDOH-related data elements in USCDI v3 and for recognizing the benefits.

Comments. Several commenters did not support the inclusion of data elements related to SDOH at this time, stating that the proposed data elements fail to capture a comprehensive view of all SDOH and that there is a lack of standards related to these data elements. Commenters also suggested that SDOH-related data elements only be required as part of USCDI v3 once FHIR-based APIs and implementation guides are available.

Response. We thank commenters for their comments voicing concern that SDOH data elements as written in USCDI v3 are not comprehensive enough, lack standards, and should only be required once FHIR-based APIs and implementation guides are available. We note that there are available and applicable standards. Specifically, FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 support USCDI v3 and align with the SDOH data elements in USCDI v3. We note that both FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 are incremental updates which address errors and misalignments in their respective prior versions. FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 have not added any substantial functionality or requirements. We do not believe adoption of FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 would contribute to a greater implementation burden, and FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 are the only versions of their respective implementation guides that fully align with and support the complete USCDI v3.

As mentioned earlier, we recognize that we proposed different versions of the US Core and C–CDA Companion Guide specifications but stated that we would consider newer versions that align with USCDI v3 (FHIR US Core 6.0.0 and C–CDA Companion Guide R4). However, after the publishing of FHIR US Core 6.0.0 and C–CDA Companion Guide R4, HL7 found errors with how the guides implemented data elements in USCDI v3 and had to make updates to those specifications to align with USCDI v3 and ensure that USCDI v3 can be implemented in Health IT Modules. Adopting FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real world implementation (see, for example, 85 FR 25677 and 25708).

In addition, the HL7 Gravity Project's Social Determinants of Health Clinical Care Release 2.0.0 Implementation Guide was published in October 2022. While the Gravity Project's Social Determinants of Health Clinical Care Implementation Guide does not encompass all possible SDOH aspects, it does define exchange standards for multiple key domains.

Comments. Commenters also urged that SDOH data be protected to ensure the privacy and security of the information, with some commenters urging ONC to adopt granular data segmentation requirements along with USCDI v3.

Response. We thank commenters for noting their concerns regarding SDOH data, specifically the importance of addressing the privacy and confidentiality of sensitive information. The adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to specific certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur. We did not propose and are not adopting privacy protections or standards related to controlling sensitive data that may be represented in USCDI data elements, including granular data segmentation requirements. However, we have adopted a new technical requirement as part of the certification criterion in § 170.315(e)(1) in support of the development and use of technology to enable the HIPAA Privacy Rule's individuals' “right to request a restriction” as discussed in section III.C.10. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) stating that patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. As noted in the HTI–1 Proposed Rule (88 FR 23765), in the 2015 Edition, ONC adopted a certification criterion to enable users of Health IT Modules(s) certified to that criterion with the functionality to electronically capture, modify, and access SDOH data elements—that is information that identifies common SDOH conditions in a standardized manner—in § 170.315(a)(15) social, psychological, and behavioral data (80 FR 62631). These functionalities are intended to support users with the ability to use technology to comply with applicable existing legal requirements or organizational policies that may require such data collection and broader, existing industry interests and efforts to collect and use this data to inform clinical decision-making and improve patient care by looking at the whole patient, including leveraging other types of care such as home and community-based services. ONC supports the use of technology to improve the standardized capture of a set of health data elements to support the healthcare industry's need to electronically capture the underlying data they need or want to collect for healthcare. ONC will continue working with our federal partners in their efforts to educate interested parties, including both health care providers and patients, regarding the access, exchange, and use of information about patients and the use of certified health IT.

Comments. One commenter suggested that a base set of SDOH criteria for each of the SDOH elements be required, while optional criteria could be added based on the hospital or provider's specific situation.

Response. We thank the commenter for their suggestion. USCDI v3 includes data elements for SDOH Problems/Health Concerns, SDOH Assessment, SDOH Goals, and SDOH Interventions. For the purposes of the Program, developers with Health IT Modules certified to specific certification criteria must support all USCDI v3 data elements, including the SDOH data elements for Problems/Health Concerns, Assessment, Goals, and Interventions. Under these required data elements, those health IT developers may support any of the SDOH domains such as referrals, food insecurity, transportation, and housing security. The USCDI standard is intended to provide a common set of data classes and data elements to support nationwide health information exchange and interoperability, and partial adoption of the USCDI standard would impair its effectiveness in doing so.

Comments. Commenters had a variety of recommendations related to including SDOH data elements in USCDI v3. Several comments suggested that ONC partner with standards organizations and others in the industry in developing and implementing SDOH data elements. Commenters also suggested that when developing SDOH data elements, ONC should seek input from patients and advocates representing those with health disparities. Commenters also suggested that ONC work with CMS and state Medicaid agencies on capturing and sharing SDOH data. One commenter suggested aligning SDOH data collection across federal and state healthcare program reporting requirements.

Response. We thank commenters for the recommendations related to including SDOH data elements in USCDI v3. We work closely with the HL7 FHIR Gravity Accelerator to develop and implement SDOH data elements. We also support the HL7 Gravity Pilots Affinity Group and support testing through connectathons and pilots. Throughout the spring of 2023, we engaged interested parties and the community in the ONC SDOH Information Exchange Learning Forum, resulting in the creation of an ONC SDOH Information Exchange Toolkit. In 2021, we funded a Leading Edge Acceleration Project for Referral Management to Address SDOH Aligned with Clinical Care.

The HL7 FHIR Gravity Accelerator participants include individuals, patients, advocates, representatives from payer organizations, social services organizations, health IT developers, provider associations, and other government participants, including CMS.

Comments. Several commenters suggested that ONC provide support to providers and their staff to implement SDOH data elements and ensure SDOH data is collected, used, and shared appropriately. Commenters suggested that education and training on SDOH data elements, including definitions and use cases, is needed for the industry, and several commenters suggested that ONC develop standards, value sets, and mappings related to SDOH data elements.

Response. We thank commenters for the input regarding the need for support and resources. To support the adoption and implementation of SDOH data elements, ONC published the SDOH Information Exchange Toolkit to further support communities working toward achieving health equity through SDOH information exchange and the use of interoperable, standardized data. The Toolkit is intended to provide information on the exchange of SDOH information to interested parties of all experience levels, as well as identify approaches to advance SDOH information exchange goals. The audience for the Toolkit includes states, payers, health care provider networks, human services providers, and community-based services entities.

Comments. One commenter sought clarification regarding the Medicare Promoting Interoperability Program requirements and the SDOH Problems/Health data element and whether there is a need for an option to indicate “None.”

Response. We thank commenters for the feedback seeking clarification regarding the Medicare Promoting Interoperability Program requirements for the SDOH Problems/Health data element. ONC refers the commenter to CMS for their program requirements.

ii. Care Team Member

In USCDI v1, the Care Team Member data class had one data element to capture all aspects about a care team member. USCDI v3 includes five Care Team Member data elements: Name, Identifier, Role, Location, and Telecom.

Comments. Several commenters specifically supported the inclusion in USCDI v3 of the Care Team Member Name and Identifier data elements. However, several commenters had concerns about the Care Team Member data elements. These commenters suggested removal of the Care Team Member Name and Identifier data elements to protect providers or, alternatively, to let providers opt out of having their information included and noted that providers may be at risk of personal harm if their identity is known. Other commenters noted that without standards, organizations will implement the data elements differently. One commenter recommended that a value set and coding be provided for the Care Team Member Role data element.

Response. We thank commenters for the comments regarding Care Team Member Name, Role and Identifier data elements. We work with the HL7 community to develop vocabulary applicable to USCDI data elements to ensure standard implementation of these data elements. In addition, we note that the USCDI v3 is a standard as a whole and has been adopted in whole, as proposed. As conveyed elsewhere in our responses, the adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange such data but does not dictate when and how either of those two actions occur. Specifically, in the Program, we establish requirements for Health IT Modules to enable a user to capture or exchange data. We do not establish requirements in the Program for an entity to use a certified Health IT Module or for the user of a Health IT Module to capture or record specific data.

iii. Clinical Notes

For the data element Discharge Summary Note in the Clinical Notes data class, we specified additional requirements in USCDI v3 including admission and discharge dates and locations, discharge instructions, and reason(s) for hospitalization, which are also required elements in the “transitions of care” certification criterion (§ 170.315(b)(1)).

Comments. We received several comments supporting the Clinical Notes data class and data elements, including Discharge Summary Note. One commenter noted that standardizing the presentation of this information will improve consistency and reliability. Another commenter focused on the specified Logical Observation Identifiers Names and Codes (LOINC®) codes and recommended linking them to International Classification of Diseases, Tenth Revision, Clinical Modification (ICD–10–CM) –Z codes and/or SNOMED–CT, which represent concepts rather than specific questions and answers, and recommended considering one-to-many bindings. One commenter sought clarification regarding whether ONC certification would require support for both structured and unstructured narrative findings.

Response. We thank commenters for the comments on the Clinical Notes data class and data elements regarding standardization. Health IT developers certifying Health IT Modules to certification criteria that reference USCDI v3 must align with the applicable vocabulary standards as defined in USCDI v3 and with the requirements in the C–CDA Companion Guide R4.1 and FHIR US Core 6.1.0 that list concept codes from the LOINC Document Ontology to identify the note type. Many certification criteria reference the USCDI standard, which comprises either structured or unstructured narrative notes.

iv. Clinical Tests

USCDI v3 includes a data class for Clinical Tests, which has two data elements, Clinical Test and Clinical Test Result/Report. This is a new data class as compared to USCDI v1.

Comments. We received several comments expressing concerns regarding the Clinical Tests data class and data elements. One commenter expressed concerns about the Clinical Tests Results/Report data element, stressing that human interpretation is needed and that it could be dangerous to send test results without “normal” or “abnormal” indicators, or a reference range. One commenter sought clarification regarding whether ONC will require support for both structured and unstructured narrative findings. One commenter noted that the availability of clinical tests in EHR systems varies substantially.

Response. We appreciate the comments regarding concerns about how the Clinical Tests data elements are implemented. The two data elements represent the minimum information necessary to convey patient data for non-laboratory and non-diagnostic imaging tests, such as electrocardiograms and visual acuity. We agree with the commenter that supplemental data such as “normal,” “abnormal,” or reference ranges provide valuable information. However, the USCDI v3 is a published standard at www.healthit.gov/uscdi and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website available at https://www.healthit.gov/uscdi where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future version of USCDI. Health IT developers are encouraged to work with their customers to exchange data that adds value. The Clinical Test data element must be represented with a LOINC® code to indicate the specific test performed or planned. The Clinical Test Result/Report data element may be structured and represented using a code set such as SNOMED CT U.S. Edition, or unstructured and represented with free text. The Program does not require the use of standardized vocabularies for Clinical Test Result/Report.

ONC acknowledges that clinical test availability varies within and across EHR systems. However, Health IT Modules certified to criteria that reference the USCDI standards in § 170.213 must have the capability to exchange clinical test data.

v. Diagnostics Imaging

USCDI v3 includes the Diagnostic Imaging data class and its two elements: Diagnostic Imaging Test and Diagnostic Imaging Report. This is a new data class as compared to USCDI v1.

Comments. We received comments on the Diagnostic Imaging data class noting that many specialty health IT systems may not integrate with or support imaging services, and a requirement to support this data class could be infeasible for some systems or result in unused capabilities.

Response. We thank commenters for their input. We understand that many specialty health IT systems do not integrate with or support imaging services. The data elements in the Diagnostic Imaging data class are not specific to the actual images that may be housed or supported in an image storing system, but rather are based on types of diagnostic imaging referenced by LOINC® codes and the interpreted imaging test results in a report. USCDI is not specific to a setting of care, a healthcare specialty, or a specific category of health IT user; the standard provides a common set of data classes and data elements that can be used for nationwide, interoperable health information exchange. To ensure interoperability for the core set of data in the USCDI, it is important for developers of certified health IT to support the complete USCDI where required for health IT certification criteria in the Program. To the extent that such specialty health IT systems are not certified to certification criteria that reference § 170.213, then they would not have to support this data class.

vi. Encounter Information

USCDI v3 includes the Encounter Information data class, which includes five data elements: Encounter Type, Encounter Diagnosis, Encounter Time, Encounter Location, and Encounter Disposition. This is a new data class as compared to USCDI v1.

Comments. One commenter expressed specific agreement and support of the Encounter Information data class. Several comments expressed concerns, including regarding a lack of standards. One commenter recommended only adopting the Encounter Diagnosis data element since it does have a standard. One commenter expressed concern that Encounter Information would identify information about pregnancy termination services that could be misused and lead to administrative or criminal investigations of patients and providers. Another commenter sought confirmation regarding whether inpatient encounters need to be included and suggested that they be included in a final rule.

Response. We have reviewed the comments regarding the Encounter Information data class and concerns around the lack of standards. The USCDI v3 data classes and data elements apply to inpatients and outpatients and define applicable vocabulary standards where appropriate. The Encounter Diagnosis data element references the SNOMED CT U.S. Edition and ICD–10–CM vocabulary standards. Regarding comments on privacy and security of Encounter Information and related services, we note the adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur.

vii. Health Insurance Information

USCDI v3 includes the Health Insurance Information data class, which provides an opportunity for health IT to capture and exchange key elements of healthcare insurance coverage. This is a new data class as compared to USCDI v1. This data class includes seven data elements: Coverage Status, Coverage Type, Relationship to Subscriber, Member Identifier, Subscriber Identifier, Group Identifier, and Payer Identifier.

Comments. A number of commenters expressed support for the Health Insurance Information data class. Comments included that it would be vital for emergency medical services (EMS) providers to receive reimbursement and that it will open opportunities for patients and providers to use beneficial apps, such as those related to cost barriers and administrative transactions.

Response. We thank commenters for their support of the Health Insurance Information data class and for recognizing the potential benefits.

Comments. A number of commenters expressed concern or did not support the Health Insurance Information data class. Several commenters stated that the data elements needed more standardization before they should be required, and that it was unreasonable to include this data class because there are no related standards yet. One commenter stated that the Health Insurance Information data class is problematic because there is no guidance about how to align this proposed standard with the proposed US Core IG v5.0.1 that payers would be required to adopt via the Interoperability and Prior Authorization Proposed Rule (87 FR 76238). The commenter stated that ONC's proposal does not align with the changes proposed in the Interoperability and Prior Authorization Proposed Rule. Commenters also stated that prior authorization standards were needed for payers to see value in this data class. Additionally, commenters expressed concern that most health IT systems seeking certification would need to rely on third-party systems to support documentation and storage of health insurance data. Commenters also stated that ONC should not add data elements to the USCDI that duplicate processes housed in practice management systems. Several commenters stated that USCDI v3 should not be required until the Health Insurance Information data class is revised, or that USCDI v3 should be adopted without the Health Insurance Information data class included. Commenters also stated that the Health Insurance Information data class should not have to be shared until CMS clarifies which data elements do not have to be shared through the Payer-to-Payer API to avoid the exchange of competitively sensitive information.

Response. We have considered the comments expressing concern about the Health Insurance Information data class. We do not agree that there are no related standards for these data elements, as HL7 FHIR US Core and the C–CDA Companion Guide support the Health Insurance Information data elements and include references to standard vocabulary where available and in use. Regarding alignment with requirements proposed by CMS in the Interoperability and Prior Authorization Proposed Rule, we refer readers to CMS' proposals in the Interoperability and Prior Authorization Proposed Rule to allow payers to use updated versions of standards in § 170.215, subject to certain conditions including approval for use by the National Coordinator (87 FR 76315). We also note that in the Interoperability and Prior Authorization Proposed Rule, CMS has proposed to allow flexibility for use of a version of the USCDI standard in § 170.213 (87 FR 76250) where proposed payer API requirements reference the USCDI, which will include USCDI v3 under our finalized policy. We further disagree with the concerns reflected in the comments about the burden that would be associated with sharing this data and believe these comments may not accurately reflect what is expected from the USCDI v3 data elements. The data elements in this data class are to exchange information about whether a patient has insurance coverage, and the type of coverage. Also included are elements that provide information about the plan. The Health Insurance Information data elements do not include any claims specific information. Additionally, we recognize that this information may or may not originate in an EHR, however Health IT Modules certified to certification criteria that reference § 170.213 must be able to capture and exchange the values when available.

Regarding the comment about this data only being valuable with respect to prior authorization standards, we note that such standards may be adopted in the future and believe that this information can provide substantial value at present by supporting the availability of data about coverage that is important for health care providers to understand a patient's situation. We recently sought comment through an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475), which appeared in the January 24, 2022 issue of the Federal Register , on how updates to the Program could support electronic prior authorization. We have reviewed comments, and this information may be used to inform a future rulemaking related to the ONC Health IT Certification Program and electronic prior authorization. We will continue to work with CMS to ensure alignment with our rules.

Comments. Several commenters also expressed privacy concerns regarding the Health Insurance Information data class. Commenters suggested that ONC revise the data class to protect patient privacy and that ONC should remove data elements that provide personally identifiable information not supportive of patient care, such as “group identifier.” Commenters also expressed concern about the inclusion of financial data in the USCDI, the sharing of claim-level payment information and the disclosure of confidentially negotiated rates.

Response. As we have noted in similarly themed comments, the adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur. Further, the concerns expressed related to financial data including claim-level payment and negotiated rates are not within scope of the HTI–1 Proposed Rule because USCDI v3 does not include any financial, claim level, or negotiated rate data elements.

Comments. Commenters suggested that the data class should focus on data elements related to whether a person has insurance coverage, the type of coverage, and which payers are covering the patient. Other commenters suggested that the data class should be revised to focus on sharing information that can be collected based on national standards. Commenters also stated that vendors use different health insurance payer identification numbers, making it challenging to match records, and that ONC should work with the industry to adopt a single source for payer identification. One commenter recommended including both medical insurance and prescription insurance as part of the data elements, and another comment recommended that ONC adopt the data elements included in the CARIN IG for Blue Button.

Response. We appreciate the additional suggestions. The data elements in the Health Insurance Information class are to exchange information about whether a patient has insurance coverage, and the type of coverage. Also included are elements that provide information about the plan.

The USCDI v3 is a published standard at www.healthit.gov/uscdi and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website available at www.healthit.gov/uscdi where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future versions of USCDI.

Comments. Commenters sought clarification regarding the Coverage Status data element and if it should indicate whether and which type of health insurance a patient has, rather than if specific services are covered. One commenter sought clarification for why the value set for Coverage Type data element was not a required standard in USCDI v3. Commenters also sought clarification regarding whether health insurance includes both medical and prescription insurance.

Response. The Health Insurance data class is intended to capture data related to an individual's insurance coverage for healthcare including medical and prescription insurance. Coverage Status is defined in USCDI v3 as the presence or absence of healthcare insurance, whereas Coverage Type is designed to communicate the category of healthcare payer ( e.g., Medicare, Commercial, Managed Care—PPO). ONC refers implementers to the US Core and C–CDA implementation guides for guidance on specific value sets. For future versions of USCDI, we encourage interested parties to provide feedback for applicable vocabulary standards, for the Coverage Type and Coverage Status data elements during an open comment period at https://www.healthit.gov/uscdi.

viii. Health Status Assessments

USCDI v3 includes a data class called Health Status Assessments, which contains four new data elements: Disability Status, Mental/Cognitive Status, Functional Status, and Pregnancy Status. This is a new data class as compared to USCDI v1. In USCDI v3, the Health Status Assessments data class also includes two data elements that have been recategorized, Health Concerns and Smoking Status, which were previously part of different data classes in USCDI.

Comments. Several commenters expressed concerns about the Health Status Assessment data class. One commenter noted that Health Status Assessments often vary from provider to provider and that requiring these data elements from non-standardized forms by the proposed deadline is not possible. One commenter noted that it is not clear how the USCDI data elements apply to mental/behavioral health and substance use treatment data.

Response. We thank commenters and acknowledge that assessments often vary from provider to provider. The USCDI data elements in this data class reference applicable vocabulary standards, including LOINC and SNOMED CT U.S. Edition, to identify the assessment and related questions which may identify not only the assessment or survey instrument, but may also allow for understanding the semantics of the assessment data. The USCDI v3 includes a Mental/Cognitive Status data element to support the exchange of mental/behavioral health data. There are new data elements in USCDI v4 that capture Alcohol Use and Substance Use assessments. We clarify that USCDI v4 is not being adopted as a standard in this final rule. Additionally, USCDI v4 is not available through SVAP at this time. Generally, approved SVAP versions of standards are announced in June each year and become effective for Program use after a 60-day period.

Comments. The majority of the comments on the Health Status Assessment data class were related to the Pregnancy Status data element. One commenter expressed support for including Pregnancy Status as a data element, but most comments expressed concerns about Pregnancy Status, including regarding legal implications for providers and that sharing this information in patients' records without their express consent could create real dangers. Some commenters recommended reconsidering this data element given the increased criminalization of reproductive health and pregnancy-related care. Commenters suggested delaying the inclusion of this data element until patient requested restrictions could be fully operationalized. Commenters also noted a lack of standards around this data element and stated that without standards, incompatible data could be entered for Pregnancy Status, and recommended against including it as a data element until there is a defined standard. One commenter recommended also including Pregnancy Intention Screening as a data element.

Response. We appreciate the comments regarding privacy concerns expressed above. The adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), stating patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213.

The USCDI v3 is a published standard at www.healthit.gov/uscdi and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website available at www.healthit.gov/uscdi where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future versions of USCDI. Commenters are directed to the FHIR US Core 6.1.0 and C–CDA Companion Guide R4.1 for guidance on how to implement the Pregnancy Status data element.

ix. Laboratory

USCDI v3 includes Specimen Type and Result Status data elements, which have been added to the USCDI Laboratory data class to address public health reporting priorities.

We did not receive comments to specifically respond to with clarifications.

x. Medications

USCDI v3 includes Dose, Dose Unit of Measure, Indication, and Fill Status data elements, which have been added to the Medications data class in response to public feedback. These data elements are necessary for certain CMS reporting programs and are also critical to certain ONC certification criteria (including the “electronic prescribing certification” criterion at § 170.315(b)(3)).

Comments. Several comments expressed concern about the lack of standards for data elements in the Medications data class, including Medications, Indication, and Fill Status. One comment noted that Fill Status data is generally maintained by pharmacy systems and many systems seeking certification would not natively support documentation and storage of this information. One comment stated that USCDI v3 is not clear regarding what must be included for the Medications data element and that more specificity could improve patient care and safety.

Response. The Medications data element includes both RxNorm and NDC as applicable vocabulary standards in USCDI v3. The HL7 FHIR US Core Implementation Guide and C–CDA Companion Guide for USCDI v3 have defined terminology bindings for Indication to include value sets drawn from both SNOMED CT U.S. Edition and ICD–10–CM. Regarding the utility of including Fill Status in the USCDI v3, we recognize that this information may or may not originate in an EHR, however certified health IT with Health IT Modules certified to particular certification criteria that reference § 170.213 must be able to capture and exchange the value when it is available.

xi. Patient Demographics/Information

Based on submissions and comments during the USCDI update processes described above, we changed or added data elements in the Patient Demographics/Information data class. USCDI v3 includes data elements Sexual Orientation and Gender Identity, which have been added to the USCDI Patient Demographics/Information data class. As described in the HTI–1 Proposed Rule, we previously adopted standards for Sexual Orientation in the demographics criterion in § 170.315(a)(5)(i)(D) and for Gender Identity in the demographics criterion in § 170.315(a)(5)(i)(E) that included requirements to code Sexual Orientation and Gender Identity according to the adopted SNOMED CT® U.S. Edition codes and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor, as referenced § 170.207(o)(1) and § 170.207(o)(2), respectively (88 FR 23766). We proposed to remove the requirement to use specific codes for representing Sexual Orientation and Gender Identity and have removed the codes as applicable vocabulary standards from USCDI v3. We proposed that certified health IT with Health IT Modules certified to particular certification criteria that reference § 170.213 would be required to be capable of representing Sexual Orientation and Gender Identity in SNOMED CT® U.S. Edition when such information is exchanged as part of USCDI. We stated in the HTI–1 Proposed Rule that we believe it is best to let the health IT community develop the list of appropriate values for Sexual Orientation and Gender Identity, whether through implementation specifications or developing additional codes in SNOMED CT® U.S. Edition (88 FR 23766).

As described in the HTI–1 Proposed Rule, we have recharacterized the USCDI data element Sex (Assigned at Birth) to Sex (88 FR 23766). We proposed to remove the requirement in § 170.315(a)(5)(i)(C) and § 170.315(b)(1)(iii)(G)( 3) to code Sex according to the adopted value sets of HL7 Version 3 Value Sets for AdministrativeGender and NullFlavor as referenced in the value sets in § 170.207(n)(1). We proposed instead to permit coding according to either the adopted value sets of HL7 Version 3 Value Sets for AdministrativeGender and NullFlavor as referenced in the value sets in § 170.207(n)(1) until December 31, 2025, or in accordance with the standard in proposed § 170.207(n)(2). We also proposed to no longer require the use of specific code sets for representing Sex and have removed the codes from USCDI v3. We proposed that certified health IT with Health IT Modules certified to certification criteria that reference § 170.213 would be required to be capable of representing Sex in SNOMED CT when such information is exchanged as part of USCDI. We proposed to adopt the same changes for relevant certification criteria that reference these standards (see sections III.C.8 and III.C.9).

In the HTI–1 Proposed Rule, we noted efforts to develop a clinically meaningful way for identifying a patient's sex from observable information that may be suitable for clinical care, including the development of a new data element Sex for Clinical Use, and sought public comment on this concept and approach (88 FR 23766). In addition, as noted in our proposals to the “patient demographics and observations” certification criterion in § 170.315(a)(5), we proposed to adopt the same changes for relevant certification criteria that reference these standards (see sections III.C.8 and III.C.9).

As discussed in the HTI–1 Proposed Rule, a new standard for patient addresses, the Unified Specification for Address in Health Care (US@), emerged and was released in 2022 (88 FR 23767). After receiving broad support from the public, ONC has incorporated the Project US@ Technical Specification version 1 as the applicable standard for Current Address and Previous Address in USCDI v3.

Also as discussed in the HTI–1 Proposed Rule, USCDI v3 includes six data elements added to the USCDI Patient Demographics/Information data class: Related Person's Name, Related Person's Relationship, Date of Death, Occupation, Occupation Industry, and Tribal Affiliation.

Comments. Several commenters explicitly expressed support for the Patient Demographics/Information data class, noting that this will improve healthcare quality, enhance communication, bolster cultural competency, and support the ability of providers to gather and exchange the information needed to make the best care plans for their patients.

Response. We thank commenters for their support of the Patient Demographics/Information data class and for noting the potential benefits.

Comments. Some commenters had concerns about the Patient Demographics/Information data class, including that it was not reasonable to require the full data class. Additionally, comments included recommendations for ONC with respect to the Patient Demographics/Information data class. Comments recommended aligning deadlines with the availability of FHIR-based APIs to ensure consistency across interested parties and aligning the USCDI Patient Demographics/Information data class with CMS definitions of the included data elements.

Response. We receive submissions and comments from federal partners, including CMS, on the USCDI and will continue to work towards alignment where appropriate with these partners. With respect to the suggestions regarding flexibility in supporting USCDI v3 data classes and data elements for purposes of the Program, we decline to allow developers to be selective in which USCDI v3 data classes and data elements they support for purposes of the Program. Because the USCDI standard is intended to provide a common set of data classes and data elements in support of nationwide health information exchange, partial adoption of the USCDI standard would impact the effectiveness of the standard and impede interoperability.

Comments. Specific comments about data elements stated that standards should be included to restrict date formats for Date of Birth and Date of Death data elements, and that Previous Name and Tribal Affiliation data elements should not be included in USCDI v3 until there are standards for them. One commenter asked for clarification on whether detailed race standards or free text fields should be used for Tribal Affiliation.

Response. We thank commenters for the feedback on the lack of standards for the Date of Birth and Date of Death data elements. We direct commenters to the HL7 FHIR US Core Implementation Guide and the C–CDA Companion Guide when an applicable standard is not identified in USCDI. In addition, these implementation guides provide guidance for exchanging Previous Name and Tribal Affiliation, the latter of which includes a vocabulary binding to a harmonized value set.

Comments. A number of commenters addressed the Sexual Orientation and Gender Identity (SOGI) and Sex data elements. Many of those commenters expressed support for including SOGI data elements, for removal of the requirement to use specific codes for representing SOGI, and for updating SOGI codes with SNOMED CT. Some of these commenters noted that this would reduce burden and would facilitate identifying disparities and improving outcomes for the LGBTQ+ population.

Response. We thank commenters for the feedback in support of the Sexual Orientation, Gender Identity, and Sex data elements and related requirements and standards, and for recognizing the potential benefits.

Comments. Several commenters expressed concerns related to the SOGI data elements, including that best practices around SOGI data are not well established and that there could be unintended confusion around the terms. Commenters also stressed the need for standardized codes related to SOGI, the importance of industry collaboration, and the value of education on SOGI data elements and use cases. One commenter noted that patients are historically reluctant to answer questions on sexual identity and this may lead to lower accuracy. One commenter stated that the health IT industry will not coalesce around value sets for Sex, Sexual Orientation and Gender Identity data elements and urged ONC to create them. Commenters also noted that several existing definitions within the proposed standards for SOGI expire on December 31, 2025, and recommended aligning deadlines.

Response. We appreciate the detailed comments. We defined SNOMED CT, U.S. Edition as the vocabulary standard for Sex, Sexual Orientation, and Gender Identity in USCDI v3. We collaborated with HL7, and the HL7 Gender Harmony Project team to update the US Core Implementation Guide and C–CDA Companion Guide with references to value sets with specific SNOMED CT U.S. Edition concepts. We work closely with federal partners to promote quality data capture and storage practices using standard terminology. We encourage providers to work with their patients to understand how and when this data is valuable for patient care and to address the situation where a patient may be reluctant to share information.

Comments. One commenter stated that changing Sex (assigned at birth) to Sex would lead to inconsistency and that it would be preferable to define a series of specific data elements with clear definitions related to this data class. One commenter sought clarification that under USCDI v3 developers should continue exchanging the same data from their systems that is currently being exchanged as the Sex (assigned at birth) data element to comply with requirements for the Sex data element.

Response. We thank commenters for the input regarding the Sex data element in USCDI v3 and concerns regarding the update from Sex (Assigned at Birth) in USCDI v2 to Sex in USCDI v3. We, along with the HL7 community recognized that Sex (Assigned at Birth) has been used to represent different concepts not always associated with the value assigned at time of birth such as clinically relevant sex for laboratory tests or diagnostic imaging, and administrative sex recorded on birth certificates and health forms. The values used for each instance may not be the same for a given patient. Furthermore, the value set referenced in earlier versions of USCDI for Sex (Assigned at Birth) does not include all possible values that represent sex. We therefore removed the reference to the limited value set previously used and expanded the applicable vocabulary standard to the SNOMED CT U.S. Edition code set. ONC worked closely with HL7 Structured Documents and US Core teams to update the US Core Implementation Guide and the C–CDA Companion Guide to distinguish between Sex (Assigned at Birth) and Sex as separate data elements. It is ONC's intent that developers continue exchanging the same data from their systems that is currently being exchanged as Sex (Assigned at Birth) and additionally exchange the USCDI v3 Sex data element.

Comments. In the HTI–1 Proposed Rule, we stated that we welcomed public comment on the development and inclusion in future standards of a new data element Sex for Clinical Use (88 FR 23766). We received several comments in support of including a Sex for Clinical Use data element in future versions of USCDI, generally because of the perceived benefits. One commenter opposed inclusion of Sex for Clinical Use as a data element in USCDI without further consultation with transgender and intersex communities. However, most of the comments about Sex for Clinical Use related to proposals regarding the Sex for Clinical Use data element in the “patient demographics and observations” criterion.

Response. We thank commenters for these suggestions. Sex for Clinical Use may be considered for inclusion as a data element in a future version of USCDI. We received comments related to Sex for Clinical Use as it relates to the “patient demographics and observations” certification criterion, and we discuss those comments in section III.C.8 of this final rule concerning the “patient demographics and observations” certification criterion in § 170.315(a)(5).

Comments. There were several comments related to the Race and Ethnicity data elements. Commenters expressed concerns about upgrading to the 2022 version of the Centers for Disease Control and Prevention (CDC) Race and Ethnicity code sets because this would add burden to the industry and recommended only adding codes and not changing existing ones. Commenters requested clarification on why this change was needed and the benefits. Commenters also noted that ONC should follow efforts by the Office of Management and Budget (OMB) regarding adoption of new race and ethnicity data standards.

Response. We thank commenters for the input regarding the Race and Ethnicity data elements. We did not propose updating to the 2022 version of the Centers for Disease Control and Prevention (CDC) Race and Ethnicity code set at this time as the 2022 version of CDC Race and Ethnicity code set has not been released. We assure commenters that we follow efforts by OMB regarding adoption of new race and ethnicity standards.

Comments. Several commenters asked for additional guidance, including on how data for the Patient Demographics/Information data class is collected and used, and on terminology related to SOGI. One commenter requested that ONC clarify how interested parties should address conflicting information among SOGI data elements due to disparities in elements and collection. One comment stated that ONC should encourage healthcare organizations to offer the term “nonbinary” as a Gender Identity data element field.

Response. We thank commenters for the feedback. We do not dictate when and how capture and exchange of USCDI data elements occur, nor how conflicting information may be reconciled. We also do not require specific concepts, such as “nonbinary,” from the applicable vocabulary standard, SNOMED CT U.S. Edition for Gender Identity, and instead defer to the HL7 FHIR US Core Implementation Guide, HL7 v2 and C–CDA Companion Guide to declare value sets appropriate for use.

xii. Problems

As discussed in sub-section i of this section, USCDI v3 includes the SDOH Problems/Health Concerns data element added to the prior USCDI Problems data class. In addition, USCDI v3 includes Date of Diagnosis and Date of Resolution data elements added to the prior USCDI Problems data class to include timing elements for recorded and maintained problem lists within electronic health records.

Comments. A couple of commenters noted a lack of standards for the Date of Diagnosis, Date of Resolution, and Problems data elements. Commenters stated that the lack of standards constricting date formats impacts interoperability, and that the Problems data element should be able to indicate a degree of importance.

Response. We thank commenters for the input regarding the lack of standards for Date of Diagnosis, Date of Resolution, and Problems data elements. While the USCDI v3 does not identify applicable vocabulary standards for the data elements, the HL7 FHIR US Core Implementation Guide and C–CDA Companion Guide define the allowable date formats.

Addressing the comment about indicating a degree of importance for a Problem, the USCDI v3 is a published standard at www.healthit.gov/uscdi and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website available at www.healthit.gov/uscdi where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future versions of USCDI.

xiii. Procedures

USCDI v3 includes the Reason for Referral data element added to the prior USCDI Procedures data class. As discussed in sub-section i of this section, the USCDI v3 also includes the SDOH Interventions data element added to the prior USCDI Procedures data class.

Comments. One commenter on the Procedures data class recommended that USCDI v3 specify that CDT is the applicable standard for technology developed to record dental procedures.

Response. We thank the commenter for the comment and note that the Code on Dental Procedures and Nomenclature (CDT) is included in USCDI v3 as an applicable standard in the USCDI v3 Procedures data element in the Procedures Data Class and may be used when exchanging dental procedures.

xiv. Updated Versions of Vocabulary Standard Code Sets

In the 2015 Edition Final Rule, we established a policy for minimum standards code sets that update frequently throughout a calendar year at 80 FR 62612, and we have listed several standards as minimum standards code sets in 45 CFR part 170 subpart B. As with all adopted minimum standards code sets, health IT can be certified to newer versions of the adopted baseline version minimum standards code sets for purposes of certification, unless the Secretary specifically prohibits the use of a newer version (see § 170.555 and 77 FR 54268). In USCDI v3, we included the versions of the minimum standards code sets available when we published USCDI v3. We have adopted the minimum standards code sets we proposed in the HTI–1 Proposed Rule.

Comments. Commenters recommended that HL7, LOINC, SNOMED CT U.S. Edition, and RxNorm vocabulary bindings be added to the USCDI criteria in the final rule.

Response. We thank commenters for the comments related to vocabulary and vocabulary bindings in USCDI. USCDI v3 includes required and optional applicable vocabulary standards with references to code sets for data elements where an encoded value is expected and where a code set has been identified and is in use. This general binding to a code system may be further refined in the HL7 implementation guides.

xv. Unique Device Identifier(s) for a Patient's Implantable Device(s)

Comments. Several commenters specifically supported Unique Device Identifier(s) for a Patient's Implantable Device(s) as a data class and data element in USCDI v3. One commenter encouraged ONC to include this data element in all information exchanges and to work with CMS to tie Unique Device Identifier codes to payment for devices.

Response. We thank commenters for the comments regarding Unique Device Identifier(s) for a Patient's Implantable Device(s). Regarding requests that ONC work with CMS on alignment, we assure commenters that we work closely with CMS across multiple programs and initiatives to align program requirements and deadlines and will continue to do so in the future.

xvi. Vital Signs

Comments. One commenter expressed concern that without dates and times, vital signs information is not meaningful and potentially dangerous.

Response. We thank commenters for the comments and understand the concern. The HL7 FHIR US Core Implementation Guide (both the prior and updated versions) adopted in § 170.215(b)(1) and incorporated by reference in § 170.299 and the HL7 C–CDA R2.1 base standard adopted in § 170.205(a)(4) and incorporated by reference in § 170.299 require dates and times when exchanging vital signs.

After consideration of all comments regarding the data classes and data elements in USCDI v3, we have finalized our adoption of USCDI v3 in § 170.213(b) as proposed. We have extended the date USCDI v1 expires as a standard for use in the Program to January 1, 2026.

2. C–CDA Companion Guide Updates

We proposed to adopt the HL7® CDA® R2 Implementation Guide: C–CDA Templates for Clinical Notes STU Companion Guide, Release 3—US Realm in § 170.205(a)(6) (“C–CDA Companion Guide R3”). The C–CDA Companion Guide R3 provides supplemental guidance and additional technical clarification for specifying data in the C–CDA Release 2.1 for USCDI v2. We stated that if the C–CDA Companion Guide Release 4 (C–CDA Companion Guide R4) is published before the date of publication of this final rule, it would be our intention to consider adopting the updated C–CDA Companion Guide R4 that provides guidance and clarifications for specifying data in USCDI v3 in § 170.205(a)(6), since we proposed to adopt USCDI v3 as the baseline (88 FR 23767).

As mentioned above, HL7® has been updating the C–CDA Companion Guide to accommodate the new data classes and data elements in each USCDI version. To allow developers to voluntarily update to USCDI v2, ONC included the C–CDA Companion Guide R3 in the SVAP Approved Standards List for 2022. ONC released the SVAP Approved Standards List for 2022 in June 2022. We stated in the HTI–1 Proposed Rule that we anticipated that the C–CDA Companion Guide R4 would support updates included in the proposed USCDI v3 and that the adoption of the C–CDA Companion Guide R4 would align with our goal to increase the use of consistently implemented standards among health IT developers and improve interoperability. We proposed to adopt the C–CDA Companion Guide R3 as a standard in § 170.205(a)(6) and incorporate it by reference in § 170.299. We stated that if the C–CDA Companion Guide R4 is available at the time of publication of this final rule, we would consider adopting the C–CDA Companion Guide R4 in § 170.205(a)(6), which would support the updates included in proposed USCDI v3 (88 FR 23767).

Consistent with our proposals in sections III.A and III.C.11, we proposed to revise § 170.205(a)(5) to add that the adoption of the standard in § 170.205(a)(5) expires on January 1, 2025. Developers of certified health IT with Health IT Modules certified to particular certification criteria that reference § 170.205(a)(5) would have to update those Health IT Modules to § 170.205(a)(6) and provide them to customers by January 1, 2025. We clarified that under this proposal, for the time period up to and including December 31, 2024, HL7 CDA® R2 Implementation Guide: C–CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 would remain applicable as the minimum version required in the Program.

Further, we proposed that Health IT Modules certified to the particular certification criteria below would need to update to the HL7 CDA® R2 IG: C–CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 in § 170.205(a)(6) by January 1, 2025:

• “transitions of care” (§ 170.315(b)(1)(iii)(A));
• “clinical information reconciliation and incorporation” (§ 170.315(b)(2)(i), (ii), and (iv));
• “care plan” (§ 170.315(b)(9)(ii));
• “view, download, and transmit to 3rd party” (§ 170.315(e)(1)(i)(A) and (B));
• “consolidated CDA creation performance” (§ 170.315(g)(6)(i)); and
• “application access—all data request” (§ 170.315(g)(9)(i)).

For the purposes of meeting that compliance date, we stated that we expected health IT developers to update their certified health IT without new mandatory testing and notify their ONC–ACB on the date at which they have reached compliance. Developers would also need to factor these updates into their next real world testing plan (88 FR 23767 through 23768).

Comments. The majority of commenters supported the adoption of the HL7 CDA® R2 IG: C–CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 as proposed in § 170.205(a)(6). Many of the comments also noted support for the adoption of C–CDA Companion Guide Release that aligns with USCDI v3 if published before the date of publication of this final rule. Comments supporting this proposal noted that incorporating newer versions of the C–CDA standard will improve interoperability of clinical data.

Response. We thank commenters for support of our proposals and for recognizing potential benefits expand interoperability for clinical information shared via structured clinical notes. We also appreciate commenters who recommended adoption of the most recent version of C–CDA Companion Guide. After the publication of C–CDA Companion Guide R4, HL7 found errors with how the guide implemented data elements in USCDI v3 and had to make updates to the specification to align with USCDI v3 and ensure that USCDI v3 can be implemented in certified Health IT Modules. We note that C–CDA Companion Guide R4.1 has not added any substantial functionality or requirements beyond C–CDA Companion Guide R4. Therefore, we do not believe adoption of C–CDA Companion Guide R4.1 would contribute to a greater implementation burden, and C–CDA Companion Guide R4.1 is the only version of the C–CDA Companion Guide that fully aligns with and supports the complete USCDI v3. Given the support of the commenters to adopt the most recent version of the C–CDA Companion Guide that aligns with USCDI v3, we have finalized adoption of C–CDA Companion Guide R4.1, which was published in June 2023, in § 170.205(a)(6).

Adopting the C–CDA Companion Guide R4.1 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real world implementation (see, for example, 85 FR 25677 and 25708).

Comments. Some commenters expressed concern about the deadline for this proposal and requested to extend the implementation deadline. Some suggested deadline extensions included to 24 months post-effective date of this final rule and December 31, 2025.

Response. We thank commenters for expressing a desire for an extension on proposed deadlines. We have finalized a January 1, 2026 date for the expiration of the standard in § 170.205(a)(5). We believe that this deadline provides adequate time for developers and industry to support C–CDA Companion Guide R4.1, which we have finalized in § 170.205(a)(6).

Comments. A minority of commenters cautioned us about the real-world needs of physicians and patients and added complexities of implementing additional health IT standards. One commenter appreciated the flexibility and reduced burden of confirming conformance via a notification to their ONC–ACB and noted concern that certification to a new requirement may involve proof of conformance to ensure that there is clear and consistent understanding and application of requirements across developers of certified health IT.

Response. We thank commenters for the comments regarding the potential burden placed on providers and developers by our proposal. We do not believe that the burden on providers or developers for the adoption of a new version of the C–CDA Companion Guide is excessive. ONC has worked closely with the implementer community to help alleviate burden, and we are confident that the addition of USCDI v3 data elements will provide significant benefit.

3. “Minimum Standards” Code Sets Updates

We established a policy in the 2015 Edition Final Rule for minimum standards code sets that update frequently (80 FR 62612). In prior rulemaking, we discussed the benefits of adopting newer versions of minimum standards code sets, including the improved interoperability and implementation of health IT with minimal additional burden (77 FR 54170). When determining whether to propose newer versions of minimum standards code sets, we consider the impact on interoperability and whether a newer version would require substantive effort for developers of certified health IT to implement. If adopted, newer versions of minimum standards code sets would serve as the baseline for certification and developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis. We reiterate that while minimum standard code sets update frequently, perhaps several times in a single year, these updates are confined to concepts within the code system, not substantive changes to the standards themselves. In the HTI–1 Proposed Rule, we proposed to adopt the following versions of the minimum standards code sets listed below (88 FR 23768 through 23769).

• § 170.207(a)—Problems

We proposed to remove and reserve § 170.207(a)(3), IHTSDO SNOMED CT® International Release July 2012 and US Extension to SNOMED CT® March 2012 Release. We proposed to revise § 170.207(a)(1), which is currently reserved, to reference SNOMED CT US Edition March 2022 and incorporate it by reference in § 170.299.

• § 170.207(c)—Laboratory tests

We proposed to remove and reserve § 170.207(c)(2), Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.40. We proposed to revise § 170.207(c)(1), which is currently reserved, to reference LOINC Database version 2.72, February 16, 2022, and incorporate it by reference in § 170.299.

• § 170.207(d)—Medications

We proposed to revise § 170.207(d)(1), which is currently reserved, to reference RxNorm July 5, 2022, Full Monthly Release and incorporate it by reference in § 170.299. We proposed in § 170.207(d)(4) to reference the code set specified in 45 CFR 162.1002(c)(1) which includes International Classification of Diseases, 10th Revision, Clinical Modification (ICD–10–CM); International Classification of Diseases, 10th Revision, Procedure Coding System (ICD–10–PCS) (including The Official ICD–10–PCS Guidelines for Coding and Reporting); National Drug Codes (NDC); the combination of Health Care Financing Administration Common Procedure Coding System (HCPCS), as maintained and distributed by HHS, and Current Procedural Terminology, Fourth Edition (CPT–4), as maintained and distributed by the American Medical Association, for physician services and other healthcare services; Health Care Financing Administration Common Procedure Coding System (HCPCS) as maintained and distributed by HHS, for all other substances, equipment, supplies, or other items used in healthcare services; and Code on Dental Procedures and Nomenclature.

We have not finalized this proposal and explain the update later in this section in response to a comment in support of our proposal to update the standards for Medications in § 170.207(d).

• § 170.207(e)—Immunizations

We proposed to revise § 170.207(e)(1), which is currently reserved, to reference CVX—VaccinesAdministered, updates through June 15, 2022, and incorporate it by reference in § 170.299. We also proposed to revise § 170.207(e)(2), which is currently reserved, to reference National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through July 19, 2022, and incorporate it by reference in § 170.299.

• § 170.207(f)—Race and ethnicity

We proposed to add § 170.207(f)(3) to reference CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021) and incorporate it by reference in § 170.299.

• § 170.207(m)—Numerical references

We proposed to revise § 170.207(m)(2), which is currently reserved, to reference the Unified Code for Units of Measure, Revision 2.1, November 21, 2017, and incorporate it by reference in § 170.299.

• § 170.207(n)—Sex

We proposed to revise § 170.207(n)(2), which is currently reserved, to reference the version of SNOMED CT ® U.S. Edition codes specified in § 170.207(a)(1). We also proposed to add § 170.207(n)(3) to reference the version of LOINC ® codes specified in § 170.207(c)(1).

• § 170.207(o)—Sexual orientation and gender information

We proposed to change the heading of § 170.207(o) from “sexual orientation and gender identity” to “sexual orientation and gender information” to acknowledge that § 170.207(o) includes standard code sets to support other gender related data items. We proposed to add § 170.207(o)(3) to reference the version of SNOMED CT ® U.S. Edition codes specified in § 170.207(a)(1) and to add § 170.207(o)(4) to reference the version of LOINC ® codes specified in § 170.207(c)(1) for Pronouns.

• § 170.207(p)—Social, psychological, and behavioral data

We proposed to revise § 170.207(p)(1) through (8) to reference the version of LOINC® codes specified in proposed § 170.207(c)(1) instead of § 170.207(c)(3). We proposed to revise § 170.207(p)(4), (5) and (7) and (8) to reference the version of the Unified Code of Units of Measure in proposed § 170.207(m)(2), instead of § 170.207(m)(1). We also proposed to revise § 170.207(p)(6) to include a reference to the version of the Unified Code of Units of Measure in proposed § 170.207(m)(2).

• § 170.207(r)—Provider type

We proposed to revise § 170.207(r)(2), which is currently reserved, to reference Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021, and incorporate it by reference in § 170.299.

• § 170.207(s)—Patient insurance

We proposed to revise § 170.207(s)(2), which is currently reserved, to reference Public Health Data Standards Consortium Source of Payment Typology Code Set December 2020 Version 9.2 and incorporate it by reference in § 170.299.

In addition to updating the minimum standards code sets listed above, we proposed to update some of the certification criteria that reference those minimum standards. We proposed to update some of the certification criteria that reference § 170.207(a) Problems by replacing the reference to § 170.207(a)(4) in those criteria that reference it with a reference to the new proposed § 170.207(a)(1). These criteria include § 170.315(a)(12), (b)(1)(iii)(B)( 2), (b)(6)(ii)(B)( 2), (c)(4)(iii)(I), and (f)(4)(ii). We also proposed to update § 170.315(f)(3)(ii) by replacing the reference to § 170.207(a)(3) with a reference to the new proposed § 170.207(a)(1).

We proposed to update the certification criteria that reference § 170.207(c) Laboratory Tests by replacing the references to § 170.207(c)(2) and (c)(3) in those criteria with a reference to the new proposed § 170.207(c)(1). These criteria include § 170.315(f)(3)(ii) and (f)(4)(ii).

We proposed to update two certification criteria that reference § 170.207(e) Immunizations. We proposed to update the certification criterion § 170.315(f)(1)(i)(B), which references § 170.207(e)(3), to instead reference the new proposed § 170.207(e)(1). We also proposed to update the certification criterion § 170.315(f)(1)(i)(C), which references § 170.207(e)(4), by replacing the reference to § 170.207(e)(4) in that criterion with a reference to the new proposed § 170.207(e)(2).

We proposed to update several certification criteria that reference § 170.207(f) Race and Ethnicity. We proposed to update certification criteria that reference § 170.207(f)(2) to instead reference the new proposed § 170.207(f)(3). These criteria include § 170.315(a)(5)(i)(A)( 1) and ( 2) and § 170.315(c)(4)(iii)(H).

As described in sections III.C.1 and III.C.8 of this final rule, we proposed to update criteria that reference § 170.207(n) Sex by updating criteria that reference § 170.207(n)(1) to reference the new proposed § 170.207(n)(2). More specifically, we proposed to update § 170.315(a)(5)(i)(C) to reference § 170.207(n)(1) for the time period up to and including December 31, 2025, or to reference § 170.207(n)(2). We also proposed to update § 170.315(c)(4)(iii)(G) and § 170.315(b)(1)(iii)(G)( 3) to reference § 170.207(n)(2). We note that, in the HTI–1 Proposed Rule regulation text in § 170.315(b)(1)(iii)(G)( 3), we inadvertently included a reference to § 170.213 (88 FR 23909) instead of including § 170.207(n)(2) as discussed in our proposal (88 FR 23821). ONC has finalized § 170.315(b)(1)(iii)(G)( 3) without the proposed reference to § 170.213. We have finalized § 170.315(b)(1)(iii)(G)( 3) to include a reference to § 170.207(n)(2) to correct this error and to reference the most recent version of SNOMED CT U.S. Edition available at the time of this rule. Health IT developers may update to a newer version if one exists at effective date of the criterion.

Additionally, as described in sections III.C.1 and III.C.8 of this final rule, we proposed to update the criteria that reference § 170.207(o) Sexual orientation and gender information (as we proposed to rename the criterion) by updating criteria that reference § 170.207(o)(1) and (2). We proposed to replace the reference to § 170.207(o)(1) in § 170.315(a)(5)(i)(D) with a reference to the new proposed § 170.207(o)(3) and proposed to replace the reference to § 170.207(o)(2) in § 170.315(a)(5)(i)(E) with a reference to the new proposed § 170.207(o)(3). More specifically, we proposed to update § 170.315(a)(5)(i)(D) to reference § 170.207(o)(1) for the time period up to and including December 31, 2025, or to reference § 170.207(o)(3), as well as whether a patient declines to specify sexual orientation. We proposed to update § 170.315(a)(5)(i)(E) to reference § 170.207(o)(2) for the time period up to and including December 31, 2025, or to reference § 170.207(o)(3), as well as whether a patient declines to specify gender identity.

We also proposed to update § 170.315(c)(4)(iii)(C), which references § 170.207(r) Provider Type. Specifically, we proposed to replace the reference to § 170.207(r)(1) in that criterion with a reference to the new proposed § 170.207(r)(2). We also proposed to update § 170.315(c)(4)(iii)(E), which references § 170.207(s) Patient insurance. Specifically, we proposed to replace the reference to § 170.207(s)(1) in that criterion with a reference to the new proposed § 170.207(s)(2).

Comments. Most commenters were supportive of ONC's proposal to adopt updated minimum code set versions. Meanwhile other commenters had recommendations pertinent to specific standards considered a “minimum standard” code set.

Response. We thank commenters for their support of our proposal to adopt updated minimum code set versions. We have finalized the adoption of updated minimum standard code set versions as proposed. We note that newer versions of the codes sets may have become available since we published the HTI–1 Proposed Rule and this does not preclude developers of certified health IT from updating minimum code sets to newer versions in their Health IT Modules.

Comments. Several commenters suggested different naming conventions for different standards and data concepts included as part of the Program's minimum standard code sets, including the name of Patient Demographics, Sexual Orientation, and Gender Identity.

Response. We appreciate these comments. However, we have finalized the title of § 170.207(o) to reflect the inclusion of the minimum standard code set for Pronouns in that section, and we have finalized our proposal to update the Sexual Orientation and Gender Identity title in § 170.207(o) to “Sexual orientation and gender information” to provide clarity on the standard code sets related to data elements in that section. We have also finalized our proposal to update the “demographics” title in § 170.315(a)(5) to “patient demographics and observations” to acknowledge that not all data described in that section are understood to be demographics.

Comments. We received multiple comments encouraging ONC to continue to work with the HL7 Gender Harmony project team and federal partners to update terminology definitions over time.

Response. We thank commenters for their support of our working with the HL7 Gender Harmony project team and federal partners to update terminology definitions. We anticipate ongoing collaboration with these parties to promote collection and exchange of data elements related to health equity and support for underserved populations.

Comments. We received a comment in support of the proposal to update the standards for Medications at § 170.207(d); however, the commenter noted that the reference to 45 CFR 162.1002(c)(1) for NDC includes references to medical code sets that are not appropriate for medications and the reference should be changed to 162.1002(b)(2), which is specific to NDC.

Response. We thank the commenter for their support of our proposed updates. We note that our reference to 45 CFR 162.1002(c)(1) in the proposal was intended to be consistent with the timeframes identified in the referenced regulation— i.e., “For the period on and after October 1, 2015” as opposed to 45 CFR 162.1002(b)(2) which is referenced as “For the period on and after October 16, 2003 through September 30, 2015.” However, we agree with the commenter that the reference should include only NDC, and we have finalized § 170.207(d)(4) to reference 45 CFR 162.1002(b)(2) as referenced in 45 CFR 162.1002(c)(1) for the period on and after October 1, 2015.” We did not intend to cross-reference code sets no longer in effect, and we believe that commenters would have anticipated us to correct this.

Comments. We received several comments related to the OMB Initial Proposals For Updating OMB's Race and Ethnicity Statistical Standards and the 2022 proposed updates to the CDC Race and Ethnicity code set. Some commenters suggest that ONC prioritize and prepare for any changes that may be necessary should the proposed changes be finalized. Other commenters expressed concern that the proposed changes will have a significant impact on health IT. Some commenters provided suggestions for ONC to develop data collection guidelines and provided suggestions for code set content updates.

Response. We thank commenters for their input regarding the proposed updates to the CDC race and ethnicity code set and OMB race and ethnicity collection; however, these comments are out of scope for this rulemaking. We will continue to work with federal partners to promote alignment for these data concepts.

Comments. We received comments regarding the effective dates for the new minimum code set versions. Some comments suggested that ONC specify the time health IT developers must incorporate the new code set versions once they have been published to allow time for health IT developers and providers to incorporate the new versions. Other commenters recommended that ONC align code set version update timelines to the base program requirements.

Response. We thank commenters for their input regarding the effective dates for new minimum code set version and to align code set version updates timelines to the base Program requirements. We have finalized the adoption of § 170.207 with a compliance date of January 1, 2026.

We have adopted the proposed version of code sets. Again, we note that we have adopted minimum code set versions and this does not preclude developers of certified health IT from updating minimum code sets to newer versions in their Health IT Modules.

4. Electronic Case Reporting

As discussed in the HTI–1 Proposed Rule, case reporting serves as early notification to Public Health Agencies (PHAs) for potential disease outbreaks and includes information that enables PHAs to start contact tracing and other prevention measures. (88 FR 23769)

Since ONC adopted 45 CFR 170.315(f)(5) as a functional requirement for Health IT Modules in the 2015 Edition, standards development organizations (SDOs), public health, and interested parties within the healthcare industry have balloted several standards related to electronic case reporting. The standards were produced and developed through a collaborative effort among many partners, including CDC, the Council of State and Territorial Epidemiologists (CSTE), the Association of State and Territorial Health Officials (ASTHO), the Association of Public Health Laboratories (APHL), EHR developers, and the HL7 Public Health (PH) Work Group. These standards pertain to both HL7® FHIR and HL7® CDA and include multiple Implementation Guides (IGs).

Recognizing advancement of standards development in this area, ONC analyzed the currently balloted standards for potential inclusion in the existing 45 CFR 170.315(f)(5) criterion. As discussed in detail in the HTI–1 Proposed Rule, ONC examined the standards for potential inclusion as a part of this criterion (88 FR 23770–23771).

In the HTI–1 Proposed Rule (88 FR 23771–23772), we proposed to adopt standards for electronic case reporting in § 170.315(f)(5)(ii). This included a proposal in § 170.315(f)(5)(ii)(A) that a Health IT Module certified to § 170.315(f)(5) support the consumption and processing of electronic case report trigger codes and parameters based on a match from Reportable Conditions Trigger Code value set in § 170.205(t)(4) received from the eRSD profiles as specified in the HL7 FHIR eCR IG in § 170.205(t)(1). We clarified that a Health IT Module need only support parsing and consuming the eRSD Specification Library and eRSD Supplemental Library because we understand that health IT developers may choose to either manually encode the electronic case reporting trigger logic into Health IT Modules or may support a more automated process for encoding the trigger logic into Health IT Modules. We requested comment on this approach and on whether there is general support of the eRSD Specification Library and eRSD Supplemental Library for electronic case reporting triggering (88 FR 23773).

Additionally, we proposed in § 170.315(f)(5)(ii)(B) to require a Health IT Module to create a case report for electronic transmission according to at least one of the following two HL7® standards: in accordance with the electronic initial case report (eICR) profiles specified in the HL7 FHIR eCR IG in § 170.205(t)(1) or in accordance with the HL7 CDA eICR IG in § 170.205(t)(2). Finally, we proposed in § 170.315(f)(5)(ii)(C) to require that Health IT Modules certified to § 170.315(f)(5) support the receipt, consumption, and processing of reportability responses (RR) formatted according to the RR profiles defined in the HL7 FHIR eCR IG or the HL7 CDA RR IG.

Comments. We received numerous comments and broad support for updating the “electronic case reporting” criterion to reference standards-based requirements. Commenters stated that the current functional certification criteria in the Program do not meet eCR program needs and that requiring use of a standard would improve interoperability and implementation consistency to further enable the transmission of timely, granular, and accurate case data between health providers and public health agencies. Commenters stated that moving from functional electronic case reporting requirements to standards-based requirements is an important step toward ensuring that public health programs have access to critical data. Commenters also stated there is substantial opportunity to empower public health, improve public health surveillance, and more efficiently monitor and manage public health concerns through standardization of electronic case reporting. Others wrote that the standards would improve consistency and increase real-time communication between healthcare and public health.

Several commenters supported the requirements as proposed, including the requirements for Health IT Modules to support either HL7 FHIR or HL7 CDA standards for case reporting. Some commenters stated the need for EHRs to support the HL7 CDA standard since many public health agencies only accept HL7 CDA documents. Several commenters stated that both the HL7 CDA and the HL7 FHIR standards should be required to allow Public Health Agencies (PHAs) time and the appropriate resources to be able to receive incoming electronic case reports. Other commenters stated they would prefer a single standard be included in the criterion rather than including multiple options for certification. Commenters noted that existing health information conversion tools could help with the translation between HL7 CDA and HL7 FHIR formats. Additionally, commenters advocated that the electronic case report and the reportability response should adhere to the same standard (CDA or FHIR) and noted that it would be burdensome if the reportability response from public health was based on a different standard than the initial case report.

Response. We appreciate these comments and agree with the importance of including standards to improve interoperability and public health agencies' access to critical information. Taking into consideration feedback from commenters, we have finalized our proposal in § 170.315(f)(5)(ii)(B) to require Health IT Modules to enable a user to create a case report consistent with at least the eICR profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA eICR IG § 170.205(t)(2). Additionally, we have finalized in § 170.315(f)(5)(ii)(C) to require Health IT Modules to receive, consume, and process a case report response according to the reportability response profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA RR IG in § 170.205(t)(3) as determined by the standard used in (f)(5)(ii)(B) of this section. We have finalized this requirement to ensure that a Health IT Module that creates a case report according to the eICR profile of HL7 FHIR eCR IG can receive, consume, and process a case report response using the same HL7 FHIR eCR IG. The same would be true for a Health IT Module that creates a case report according to the HL7 CDA eICR IG; this Health IT Module must be capable of receiving a reportability response according the HL7 CDA RR IG. We believe requiring support for creating a case report based on either the HL7 FHIR eCR IG or the HL7 CDA eICR IG while requiring support for receipt, consumption, and processing of a case report response according to either the HL7 FHIR eCR IG or the HL7 CDA RR IG provides technical design flexibility while supporting the HL7 CDA-based landscape for case reporting that exists today. Additionally, we have finalized our proposal in § 170.315(f)(5)(ii)(D) for Health IT Modules to support transmission of a case report electronically to a system capable of receiving a case report.

As with most consensus-based standards, we recognize that additional improvements can be made to the HL7 FHIR and HL7 CDA IGs for case reporting. We encourage interested parties, including the CDC, the appropriate HL7 working groups, and public health associations to update and improve the IGs, as well as collaborate on solutions that facilitate the ability of PHAs to parse, filter, and consume case reports. We plan to continue monitoring the development of standards for case reporting and foundational standards that facilitate interoperability for various public health use cases. As the HL7 FHIR-based certification criteria in the Program continue to grow and industry more broadly supports HL7 FHIR-based IGs, we intend to transition to solely an HL7 FHIR-based approach for case reporting in future rulemaking.

Comments. One commenter suggested that the adoption of HL7® standards was unnecessary to advance interoperability for EHI because EHR systems are capable of effectively and securely communicating using multiple standards and messaging formats. This commenter stated that the adoption of HL7 standards would prevent health care providers from using other standards that could better serve different situations and communities.

Response. We disagree that adoption of standards for case reporting is unnecessary to advance interoperability. We note that for nearly a decade, Program requirements for electronic case reporting have not been standards-based, and numerous examples cited in this preamble and in the HTI–1 Proposed Rule reveal deficiencies in nationwide electronic case reporting due to misaligned technical standards and implementations. We believe that consensus has emerged for adoption of HL7 standards, which we have finalized in § 170.315(f)(5)(ii), and we believe that such standards can be enhanced over time to address the emergent needs of health care providers and the communities they serve.

Comments. We received multiple comments supporting our proposal relating to the consumption and processing of case report trigger codes based on the Reportable Conditions Trigger Code value set in § 170.205(t)(4). Many public health agency commenters expressed support to require certified Health IT Modules to support the ability to consume and process the eRSD profiles, which include the RCTC value set, regardless of whether such a Health IT Module supports a FHIR-based or CDA-based approach to certification, stating that it would support interoperability. One hospital-based commenter suggested that in addition to the mandated proposed RCTC value sets, ONC should require support for the adjunct `eRSD Supplemental Library' as part of the certification criterion at § 170.315(f)(5) as we proposed. Several health IT developer commenters stated that the eRSD profiles should not be required, including the reference to the eRSD Supplemental Library or the eRSD Specification Library, stating that the underlying standards are too immature and not sufficient for broad use. Commenters further stated concerns about the burdensome and manual updates and maintenance required to support the eRSD profiles and noted that the specification is mainly in use today by the eCR Now FHIR App, a solution developed specifically for case reporting. One commenter suggested that Health IT Modules should be required to use updated reportable condition trigger codes, stating that during an emergency, new trigger codes are almost always needed and are necessary in effectiveness of use in an emergency response. One commenter emphasized coordination with the CDC to not only make eRSD-based sharing of reportable events available, but also the Reportable Conditions Knowledge Management System (RCKMS) to enable efficient sharing of PHA requirements in terms of reportable events, content, format, and transport.

Response. We thank the commenters for their perspectives. We agree that consuming and processing reportable condition trigger codes is a necessary first step in electronic case reporting, and we have finalized in § 170.315(f)(5)(ii)(A) our proposal that Health IT Modules certified to § 170.315(f)(5) must, beginning January 1, 2026, support the consumption and processing of case reporting trigger codes and must identify a reportable patient visit or encounter based on a match from the RCTC value set in § 170.2015(t)(4). However, after additional examination of the HL7 FHIR eCR specification, and in response to comments received, we have not adopted our proposal to require that such Health IT Modules receive the RCTC value set from the eRSD profiles as specified in the HL7 FHIR eCR IG in § 170.205(t)(1). This means that Health IT Modules do not need to support the eRSD profiles, including the eRSD PlanDefinition, Supplemental Library, and Specification Library, in order to be certified to § 170.315(f)(5).

We have finalized this approach to allow developers of certified health IT flexibility to support the consumption of the RCTC value set in the way that best suits their technology and in a way that does not constrain how the RCTC value set is consumed as the underlying standards mature. We share concerns with commenters who noted that the triggering logic within the eRSD profiles of the FHIR IG are complex, not supported across the industry, and remain largely untested outside their use in the eCR Now FHIR App. We believe requiring that a Health IT Module certified to § 170.315(f)(5) support the consumption and processing of case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the RCTC value set in § 170.205(t)(4), without further constraining how the RCTC value set is received, will simplify Program conformance and responds to concerns raised by commenters and raised through our own analysis.

For purposes of Program conformance, we reiterate from the HTI–1 Proposed Rule that the RCTC value set in § 170.205(t)(4) is a minimum standard code set, and that Health IT Modules certifying to § 170.315(f)(5) by way of § 170.315(f)(5)(ii) may voluntarily support an updated version ( e.g., a subsequent release) of the RCTC value set. We anticipate that health IT developers would be incentivized by their customers to take advantage of this opportunity to voluntarily support updated versions of the RCTC value set because updated versions will likely include new codes reflecting new or emerging infectious diseases (88 FR 23773). We urge developers with Health IT Modules certified to § 170.315(f)(5)(ii) to support all the reportable condition trigger codes in the RCTC value set as it updates so that emerging infectious diseases may be reported electronically to public health authorities as those infectious diseases emerge.

We note that the RCTC value set is not currently hosted on the National Library of Medicine Value Set Authority Center, like many other value sets. Instead, the RCTC value set is currently available for distribution by the Association of Public Health Laboratories. We plan to work with CDC and the industry to align the availability of the RCTC value set with other, similar value sets in the future.

Finally, we note that the CDA IG cross-references the RCTC value set specified in the HL7 FHIR eCR IG. Therefore, Health IT Modules certified to § 170.315(f)(5) using the HL7 CDA IG as described in § 170.315(f)(5)(i), must also support the requirement to trigger a case report based on a match from the RCTC value set in § 170.205(t)(4) at a minimum. We encourage implementers to reference the HL7 CDA eICR IG for additional guidance regarding the use of the RCTC value set for identifying reportable cases.

Comments. Commenters suggested requiring a longer compliance date than December 31, 2024, for health IT developers to certify to the proposed updated criterion to allow the industry to widely implement the standards-based requirements in production. One commenter expressed support, stating that allowing current standards requirements to remain until December 31, 2024, is reasonable, while another commenter recommended an implementation deadline of December 31, 2025. Several commenters stated that more time should be given for compliance, such as a minimum of 24 months post-final rule effective date for such deadlines or postponing the requirement for electronic case reporting until public health jurisdictions can adequately adapt to the technology needed to ingest the data. One commenter expressed that more time is needed to develop, test, and deliver new capabilities, stating that the proposed timeframe is insufficient.

Response. We appreciate commenters' concerns about the timelines for conformance to new standards for the Program. We have finalized in § 170.315(f)(5) that Health IT Modules must enable a user to create a case report for electronic transmission meeting requirements in § 170.315(f)(5)(i) for the time period up to and including December 31, 2025, or meet the requirements in § 170.315(f)(5)(ii). This approach will allow developers to continue to certify to functional requirements for case reporting according to § 170.315(f)(5)(i) while allowing developers to certify to the standards-based approach to case reporting in § 170.315(f)(5)(ii). After December 31, 2025, developers will only be able to certify to case reporting using the standards-based approach described § 170.315(f)(5)(ii). In addition, previously certified products will need to update their certification to the standards-based approach described in § 170.315(f)(5)(ii) by December 31, 2025. We believe this date will provide adequate time for developers of certified health IT with Health IT Modules certified to § 170.315(f)(5) to comply with the requirements we have finalized, while also ensuring timely implementation of the requirements for public health agencies.

Comments. Many commenters suggested that systems receiving electronic case reports should also have to certify to capabilities that align with the requirements in § 170.315(f)(5). Another commenter stated that there is little value in requiring the capability to transmit electronic case reporting if public health partners do not have the capabilities to receive data electronically. Some commenters stated that they are prepared to support electronic case reporting but have not been able to do so due to lack of public health capacity to receive it, and recommended ONC work with other agencies to support public health partners with funding to bolster electronic case reporting capacity. Several commenters suggested ONC provide support for the transition to eCR reporting, such as ONC collaborating with other agencies and public health entities to provide financial resources/incentives and support, as well as publishing and maintaining a master list of U.S. public health data standards, and work with state and local public health agencies to ensure technical readiness for their adoption and implementation. One commenter recommended ONC encourage and enforce public health agencies to move away from manual reporting. The same commenter also urged coordination to promote the reduction and elimination of variances in format and transport mechanisms.

One commenter expressed support and requested clarification if the intent is to require support based on the standards ONC specifies, and not to require support for jurisdiction-specific communication methods. Another commenter stated that state and local variations create burden on the sender to meet specific requests and needs of jurisdictions. One commenter requested further guidance through a companion guide on how to comply with differing federal and state regulations related to electronic case reporting requirements, such as what additional data elements are needed by state PHAs and beyond those that are defined in the standards. Multiple commenters expressed concern regarding variability in implementation of standards, and the jurisdictional distinctions that required customizations and manual burden to maintain. We received a few comments stating that the proposed requirements are too broad and urged a more tempered approach to permit maturation as integrations increase. One commenter stated that the proposal does not describe likely performance parameters or offer an architecture that would support true disease surveillance. Some commenters expressed concern with public health agencies' lack of readiness for electronic case reporting, stating that, in their experience, production use of electronic case reporting is limited for conditions beyond COVID–19 and Mpox.

Response. We understand that gaps remain in practice regarding the ability of public health agencies to receive electronic case reports, particularly with parsing, filtering, and consuming incoming electronic case reports, and that manual reporting mechanisms remain in place for many reportable conditions. We appreciate the commenters that suggested we create an aligned requirement for systems receiving electronic case reports and will consider these comments for future rulemaking. We are supportive of CDC-led efforts to build public health capacity to accept electronic case report information, and the electronic receipt and ingestion of electronic case reports are a core component of the CDC Public Health Data Strategy. We believe the timeline for requiring standards-based electronic case reporting for Health IT Modules certified to § 170.315(f)(5) will allow both healthcare organizations and public health agencies to develop and implement the capability for receipt and exchange of electronic case reports and associated information. We recognize the need for ONC to continue to collaborate and coordinate with CDC and national public health associations, as well as with public health jurisdictions. Further, there are tools and intermediary options available, like HL7 CDA to HL7 FHIR conversion tools, that PHAs could leverage to accept incoming HL7 FHIR-based case reports and convert them into a format they can receive and process.

We acknowledge that variations between state and federal requirements and local requirements and needs add burden for reporters. However, we are unable to holistically solve this challenge through the Program. The Program is voluntary, and developers that elect to participate are only required to adhere to the requirements in applicable certification criteria. The Program does not directly address case reporting requirements imposed by state or local bodies. Furthermore, we believe these issues could be addressed through the standards development processes, including through the Public Health Workgroup for HL7, and through working with PHAs and appropriate public health associations to align on the use of a national standard and reduce state and local variation in requirements where possible. Regarding comments that the proposals are too broad, we believe requiring standards-based support for electronically reporting case reports and receiving reportability responses, including using standard triggers, will allow for implementation flexibility while improving interoperability. Further, standards-based requirements can help to reduce variation and fragmentation that may otherwise cause interoperability issues for implementers and users. We understand that PHAs expressed concerns related to technology used by PHAs being able to accept incoming reports that adhere to the FHIR standard. We believe that the longer timeline can help with this transition, as well as allow the industry time to pursue different approaches to implementing the required components of the eCR FHIR IG. We understand concerns related to performance, scalability, and maintenance, and will monitor standards development and implementation to inform future rulemaking.

Comments. Some commenters stated that public health-specific approaches for data exchange should not be the way of the future, and that existing solutions, such as FHIR capabilities including subscriptions and patient-level queries, should instead be leveraged for the purposes of public health data exchange. Several commenters believe common data infrastructure and standards, such as HL7 FHIR-based APIs and the SMART Backend Services, would better serve electronic case reporting than the current standards, which they stated are brittle and require consistent updating and manual support. Several commenters offered suggestions of additional functionality. One commenter suggested that health IT developers must provide functionality to users to send on-discharge summary updates for patients admitted to hospital, and interfaces to allow their users to adjust timing of triggering, document build, send, and other parameters. One commenter suggested that ONC incorporate the language and data elements of specialty records into its standards to increase effectiveness for interoperability initiatives across the spectrum of patient care. Another commenter suggested requiring functionality related to high-risk and immediate reporting for provider-initiated (or `manually triggered') electronic reporting stating that provider-triggered `manual' eCRs are critical for emergency preparedness and reducing the burden on healthcare staff and public health staff of manual reporting and data entry in future outbreaks, novel conditions, and early in confirmed outbreak scenarios. One commenter stated that healthcare facility IDs and address formatting cause serious impacts for public health because they cannot be verified for eCRs sent. The commenter, therefore, suggested more standards conformance and health IT functionality to allow users to easily edit, update, and maintain correct facility IDs, as well as consistent formatting of address and rational facility naming, will ease processing burden on PHAs and other data receivers. Several comments mentioned specific challenges within the proposed specifications, including challenges with certain data elements.

Response. We acknowledge the importance of reusable and scalable standards for health information interoperability including standards-based APIs. The Standardized API for “patient and population services” criterion at § 170.315(g)(10) has provided a baseline for reusable services to advance interoperability nationwide. Like many other HL7 FHIR IGs in the US Realm, the HL7 FHIR profiles defined in the eCR FHIR IG were built using the profiles defined in the US Core IG as part of the HL7 FHIR profiling model. Notably, the US Core IG is part of the certification criterion at § 170.315(g)(10), adopted in § 170.215(b)(1) and incorporated by reference in § 170.299. While we recognize the potential of these foundational APIs, implementation guides, and services to generally support public health, we believe it is helpful to provide further specificity for use cases like electronic case reporting. We will consider ways to align the public health certification criteria in the Program to promote reuse of common standards to support various public health reporting and interoperability use cases in future rulemaking. We appreciate that challenges and additional potential uses and applications of the electronic case reporting standard remain. However, the Program is not the venue through which the specification can be updated or changed. We encourage commenters to participate in standards development processes, including in the HL7 Public Health Workgroup. Further, we are aware that tools exist for PHAs that can translate incoming FHIR to CDA and/or other formats that public health surveillance systems can currently accept, which can aid with data receipt in the interim period as surveillance systems are updated to be able to receive FHIR and as additional FHIR-based tools and solutions are developed and implemented.

For concerns related to triggering and adjusting triggers based on timing and the occurrence of certain events, we believe this can be addressed through healthcare organizations and other reporters working with public health jurisdictions to determine the timing and triggers that work for all involved participants and that do not place undue burden on health IT and public health systems. We also encourage triggering and timing approaches to be discussed through standards development processes to develop, pilot, and share approaches that meet the needs of both reporters and public health agencies.

Comments. One commenter requested clarification on whether the Health IT Module being certified needs to identify any intermediaries involved in the transmission of electronic case reports or RR messages as part of certification, or if these intermediaries need to also be certified for these eCR criteria. Another commenter requested clarification on how a “system capable of receiving an electronic case report” would be identified or validated, and whether this system would need to be certified against specific criteria. A few commenters recommended recognition, or new certification processes using the eCR Now FHIR application with a companion guide, as well as a different set of data than the USCDI v1 data set cited as standard for the criterion to ensure health IT systems can meet the new certification criteria. One commenter suggested that the eCR Now FHIR App should be accepted for certification. Some commenters expressed a belief that continued success in case reporting relies on a reasonable expectation of a routing and decision support intermediary such as AIMS (APHL Informatics Messaging Services). One commenter suggested that the AIMS network should support the submission (and response to submission) of any public health reporting using RESTful (or Representational State Transfer) application programming interfaces. One commenter recommended that ONC work closely with the CDC and the AIMS Platform team to ensure requirements do not exceed or violate the AIMS requirements, stating that many of the proposals are beyond the current allowed features on the AIMS network application programming interfaces. One commenter recommended that ONC work closely with the CDC and the AIMS Platform team to ensure requirements do not exceed or violate the AIMS requirements, stating that many of the proposals are beyond the current allowed features on the AIMS network.

Response. We appreciate the questions we received related to intermediaries, the use of specific tools or systems, and the applicability of the Program to intermediaries. Our Program is voluntary, and health IT developer participation in the Program has traditionally been incentivized through connections to CMS payment programs. While we do not have the authority to enforce or provide incentives for adoption of certified Health IT Modules, other entities could choose to do so. Should other federal entities choose to require certain systems or technologies to certify to the criterion at § 170.315(f)(5) via other mechanisms, the applicability of the requirements could extend beyond health IT that is traditionally presented for certification. Additionally, developers of intermediary software may also voluntarily certify their technology through the Program without incentives or requirements.

As part of the Program, we do not require the use of specific systems or solutions, such as the eCR Now FHIR App, which several commenters raised. Rather, we specify standards-based requirements based on standards and implementation specifications that have been developed through consensus by the health IT industry and functional requirements to allow for flexibility and innovation. We are aware that the eCR Now FHIR App is an option for transmitting electronic case reports using either the HL7 CDA IG or the HL7 FHIR eCR IG. We also are aware of the CDC-supported data ingestion building blocks that can aid PHAs in converting incoming information from HL7 FHIR to HL7 CDA so that surveillance systems are able to process reports in the standards with which they can currently receive data. Developers of certified health IT have the flexibility to leverage the eCR Now FHIR App or other solutions to meet the requirements under our Program under existing requirements for § 170.315(f)(5). Further, as developers of certified health IT work to implement either the CDA or FHIR standards as part of their Health IT Modules, they can use “relied upon software” to demonstrate certification criteria compliance (see 84 FR 7433 and 76 FR 1276–1277). This encompasses third-party software or products that are not developed by the health IT developer but are being used to meet a portion of (or the entirety of) certain certification criteria. Such third-party products must be reported to the Certified Health IT Product List. We are aware that there are several technical options that meet our required functional criteria adhering to the FHIR standard. Intermediaries, such as the AIMS platform supported by APHL, as well as other intermediaries such as HIEs or HINs, are used by healthcare organizations to assist with routing, transport, and, in some cases, conversion before submitting electronic case reports to PHAs. However, we do not dictate the mechanism through which vendors or organizations choose to accomplish the electronic case reporting workflow—only the functional expectations and the accompanying standard(s). At this time, ONC is not requiring Health IT Modules certified to § 170.315(f)(5) to specifically connect to AIMS or support RCKMS to meet the proposed requirements in § 170.315(f)(5)(ii)(D). While we understand the role AIMS and RCKMS play in a centralized, hub-and-spoke model for electronic case reporting, we proposed that the functional requirements for § 170.315(f)(5)(ii)(D) remain agnostic as to which reporting platform and which decision support tool(s) are used. Further, the use of HL7 FHIR supports the use of RESTful APIs. We will continue to coordinate and work with CDC on ensuring support is available as Health IT Modules work toward Certification of the “electronic case reporting” criterion, regardless of their approach. Given public comments and our desire to support providers reporting electronic case reports to any PHA that may be authorized to receive case reports, we have finalized our requirements in § 170.315(f)(5)(ii)(D) to “transmit a case report electronically to a system capable of receiving an electronic case report,” as proposed.

Comments. One commenter recommended that systems be tested with “live” public health information systems, or systems specified by the public health community instead of self-certifying that real world testing has been completed. The same commenter also recommended that if a Health IT Module is certified only for CDA or FHIR exchange of RR data, the Health IT Module must also successfully complete real world testing with a commercially available service to transform the data into the format not implemented as part of the Health IT Module to ensure the provider can receive RR messages regardless of the format utilized. One commenter recommended that timely and or automated eRSD updates should be considered for inclusion in real world testing. One commenter expressed that they appreciate the requirement to ensure Health IT Modules continue to demonstrate conformance through real world testing.

Response. We appreciate the comments and note that electronic case reporting is subject to the Real World Testing Condition and Maintenance of Certification requirements at § 170.405(a). However, we note that developers of certified Health IT Modules subject to real world testing have extensive flexibility to design real world testing approaches that meet requirements established in § 170.405(b)(1)(iii). We decline to establish specific requirements for real world testing plans beyond what is established in § 170.405(b)(1)(iii) for electronic case reporting currently. We also note that our requirement for Health IT Modules certifying to § 170.315(f)(5)(ii) to use either the FHIR-based or CDA-based IG is intended to facilitate interoperability and should not necessitate support for multiple formats to receive RR messages. Several commenters were concerned about receiving RRs in a different standard than the sent eICR, and we encourage the reporters to work with PHAs and intermediaries to limit the potential differentiation in standards used for eICR and RR, and to consider the use of potential solutions that could convert the eICR or RR into the corresponding standard.

We have finalized the revised criterion for electronic case reporting in § 170.315(f)(5) with modifications. First, we have finalized a modification of the proposed description in § 170.315(f)(5) from “an electronic case report” to “a case report for electronic transmission” consistent with the prior functional criterion in § 170.315(f)(5). Second, we have modified the date from December 31, 2024 to December 31, 2025 for certification to the existing functional criterion, which is now specified in § 170.315(f)(5)(i) Functional electronic case reporting. For the standards-based version of the criterion in § 170.315(f)(5) and specified in § 170.315(f)(5)(ii) Standards-based electronic case reporting, we have finalized a modification to the proposed regulation text to reference the Reportable Conditions Trigger Code value set in § 170.205(t)(4) without including the reference to the HL7 FHIR eCR IG in § 170.315(f)(5)(ii)(A). We have finalized a modification to the proposed regulation text as described above to reference only the HL7® CDA® eICR IG in § 170.315(f)(5)(ii)(B)(2). We have finalized a modification to the proposed regulation text for the capabilities described in § 170.315(f)(5)(ii)(C) by adding “as determined by the standard used in (f)(5)(ii)(B) of this section.” Finally, we have finalized a modification to § 170.315(f)(5)(ii)(D) to modify “capable of receiving an electronic case report” as follows: “Transmit a case report electronically to a system capable of receiving a case report.”

5. Decision Support Interventions and Predictive Models

Since 2010, the Program has maintained a CDS certification criterion, consistent with the qualified electronic health record definition in section 3000(13) of the PHSA, which defines a qualified EHR as an electronic record of health-related information on an individual that has the capacity to “provide clinical decision support” (42 U.S.C. 300jj(13)(B)(i)). The initial requirements for the CDS certification criterion were intended to ensure that Health IT Modules would support broad categories of CDS while being agnostic toward the intended use of the CDS beyond drug-drug and drug-allergy interaction checks (75 FR 2046).

In 2012, ONC established a new set of requirements for Health IT Modules to support CDS. These requirements included capabilities to support evidence-based CDS based on a defined set of data elements; CDS configuration for both inpatient and ambulatory settings; and the display of source attribute or bibliographic citation of CDS (77 FR 54212). These requirements were largely based on recommendations made by ONC's Health Information Technology Policy Committee (HITPC) from 2011 recommending ONC require Health IT Modules support CDS, including: (1) display source or citation of CDS; (2) be configurable based on patient context ( e.g., inpatient, outpatient, problems, meds, allergies, lab results); (3) be presented at a relevant point in clinical workflow; (4) include alerts presented to users who can act on alerts ( e.g., licensed professionals); and (5) be integrated with the EHR ( i.e., not standalone). In the 2015 Edition Final Rule, ONC finalized an updated CDS criterion in § 170.315(a)(9) (80 FR 62622).

Since the CDS criterion was first adopted in § 170.315(a)(9), health IT implementation and technology resources used to support clinical decision-making have continued to evolve and expand across the health IT ecosystem. Within healthcare today, predictive models are increasingly being used and relied upon to inform an array of decision-makers, including clinicians, payers, researchers, and individuals, and to aid decision-making through CDS. In many cases, Health IT Modules are key components of these predictive models, often providing the data used to build and train algorithms and serving as the vehicle to influence day-to-day decision-making. Both structured and unstructured data generated by, and subsequently made available through, certified Health IT Modules power the training and real-world use of predictive models. Developers of certified health IT also create and deploy predictive algorithms or models for use in production environments through their Health IT Modules and, increasingly, such developers also enable other parties, including third-party developers and the developer of certified health IT's customers, to create and deploy predictive models through the developer's Health IT Modules. In turn, certified Health IT Modules are often the vehicle or delivery mechanism for predictive model outputs to reach users, such as clinicians, through clinical decision support.

The National Academy of Medicine (NAM) described in a 2019 report how predictive models and other forms of artificial intelligence (AI) have the potential to represent the “payback” of using health IT “by facilitating tasks that every clinician, patient, and family would want, but are impossible without electronic assistance.” The NAM report also identified a crucial “need to present each health care AI tool along with the spectrum of transparency related to the potential harms and context of its use. Evaluating and addressing appropriate transparency, in each sub-domain of data, algorithms, and performance, and systematically reporting it, must be a priority.”

In November 2020, the Office of Management and Budget released a Memorandum for the Heads of Executive Departments and Agencies on Guidance for Regulation of Artificial Intelligence Applications, which directed that “[w]hen considering regulations or policies related to AI applications, agencies should continue to promote advancements in technology and innovation, while protecting American technology, economic and national security, privacy, civil liberties, and other American values, including the principles of freedom, human rights, the rule of law, and respect for intellectual property.” This was followed by an executive order in December 2020, E.O. 13960 Promoting the Use of Trustworthy Artificial Intelligence in the Federal Government. The executive order stated: “The ongoing adoption and acceptance of AI will depend significantly on public trust. Agencies must therefore design, develop, acquire, and use AI in a manner that fosters public trust and confidence while protecting privacy, civil rights, [and] civil liberties[.]” (85 FR 78939).

In June 2021, the Government Accountability Office (GAO) published Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities, which specifically outlined key principles and actions “[t]o help entities promote accountability and responsible use of AI systems.” This included outlining four principles for the framework, including governance, data, performance, and monitoring.

In September 2022, the Biden-Harris Administration published Principles for Enhancing Competition and Tech Platform Accountability, which included a principle related to stopping discriminatory algorithmic decision-making. In October 2022, the Biden-Harris Administration published a Blueprint for an AI Bill of Rights, which outlines five principles, informed by public input, that should guide the design, use, and deployment of automated systems to protect the American public in the age of AI. These principles are safe and effective systems; algorithmic discrimination protections; data privacy; notice and explanation; and human alternatives, consideration, and fallback.

On February 16, 2023, E.O. 14091, Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, was issued (88 FR 10825–10833). E.O. 14091 builds upon previous equity-related executive orders, including E.O. 13985. Section 1 of E.O. 14091 requires the Federal Government to “promote equity in science and root out bias in the design and use of new technologies, such as artificial intelligence.” Section 8, subsection (f) of E.O. 14091 requires agencies to consider opportunities to “prevent and remedy discrimination, including by protecting the public from algorithmic discrimination.”

Finally, on October 30, 2023, E.O. 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, was issued to ensure that America leads the way in seizing the promise and managing the risks of AI. This E.O. established directives and priorities for this emerging technology, including, standards for AI safety and security. E.O. 14110 supports responsible AI development and use in healthcare, specifically, and directs HHS to issue a strategic plan on responsible deployment and use of AI and AI-enabled technologies in the health and human services sector that includes “development, maintenance, and availability of documentation to help users determine appropriate and safe uses of AI in local settings in the health and human services sector;” (Section 8, subsection (b)(i)(E)). It likewise directs the Secretary of HHS to develop a strategy to “determine whether AI-enabled technologies in the health and human services sector maintain appropriate levels of quality, including, as appropriate, in the areas described in subsection (i) of this section. This work shall include the development of AI assurance policy—to evaluate important aspects of the performance of AI-enabled healthcare tools—and infrastructure needs for enabling premarket assessment and post-market oversight of AI-enabled healthcare-technology algorithmic system performance against real-world data (Section 8, subsection (b)(ii)). In addition, E.O. 14110 directs HHS to establish a safety program to receive reports of—and act to remedy—harms or unsafe healthcare practices involving AI (Section 8, subsection (b)(iv)).

A growing body of peer-reviewed evidence, technical and socio-technical expert analyses, and government activities and reports focus on ensuring that the promise of AI and machine learning can equitably accelerate advancements in healthcare to improve the health and well-being of the American public. The Department has a longstanding interest in understanding and addressing concerns about negative, adverse, or harmful consequences that may result from the use of digital data or information about individuals' health (including data analytics), including historically, their use in computerized decision-making. As such, we proposed in the HTI–1 Proposed Rule (88 FR 23774–23811) to incorporate new requirements into the Program for Health IT Modules that support the execution of AI or machine learning-based technology in support of decision-making as part of the revised CDS criterion in § 170.315(b)(11). These requirements align with the Federal Government's efforts to promote trustworthy AI and the Department's stated policies on advancing equity in the delivery of health and human services.

We believe that the continued evolution of decision support software, especially as it relates to AI or machine learning-driven Predictive DSIs, necessitates new requirements for the Program's CDS criterion. We therefore proposed requirements for new sets of information that are necessary to guide decision-making based on outputs ( e.g., recommendations) from Predictive DSIs, such as an expanded set of “source attributes” and information related to how risk is managed by developers of certified health IT (88 FR 23775). We believe that these new sets of information will provide appropriate information to help guide decisions at the time and place of care, consistent with 42 U.S.C. 300jj–11(b)(4).

In the HTI–1 Proposed Rule (88 FR 23746), we provided an overview of the history, current uses, and risks associated with predictive algorithms and models in healthcare. We refer readers to section III.C.5 of the HTI–1 Proposed Rule for the details of those discussions (88 FR 23776 through 23781). We noted our goal with the proposals, described herein and as aligned with our authority, was to assist in addressing the gaps between the promise and peril of AI in health articulated in the National Academy of Medicine report discussed in the HTI–1 Proposed Rule (88 FR 23780).

Objectives of the Policies To Address Predictive Modeling in DSI

In the HTI–1 Proposed Rule at 88 FR 23780–23781, we noted that the proposals for § 170.315(b)(11) were intended to introduce much-needed information transparency to address uncertainty regarding the quality of Predictive DSIs that Health IT Modules certified to the criterion in § 170.315(b)(11) support. We noted that doing so would equip potential users with sufficient information about how a Predictive DSI was designed, developed, trained, and evaluated to determine whether it was trustworthy (88 FR 23780). We proposed a dual emphasis for transparency on (1) the technical and performance aspects of Predictive DSIs and (2) the organizational competencies employed to manage risks for Predictive DSIs. Together, this information would support potential users in making better informed decisions about whether and how to use Predictive DSIs in their decision-making given the specifics of their context, patients, and needs. We noted that we considered the information included in these proposed requirements as a prerequisite to determine the quality of predictive models. We explained that our proposals were not aimed at approving or guaranteeing the quality of Predictive DSIs or the models on which they are based. Instead, the proposals were intended to provide users and the public with greater information, available in a consistent manner, on whether a Predictive DSI is fair, appropriate, valid, effective, and safe (FAVES). We anticipated that a long-term outcome of such transparency would be increased public trust and confidence in Predictive DSIs. As a result of new transparency, we anticipated that users, including healthcare systems, clinicians, and patients, would be able to expand the use of these technologies in safer, more appropriate, and more equitable ways.

We did not propose to establish or define regulatory baselines, measures, or thresholds for FAVES (88 FR 23780). Instead, we proposed to establish requirements in § 170.315(b)(11) to make information available that would enable users, based on their own judgment, to determine if a Predictive DSI, that is supported by a Health IT Module, is acceptably fair, appropriate, valid, effective, and safe. We conveyed our understanding that numerous and parallel efforts led by industry groups and academia were developing methods to evaluate Predictive DSIs for fairness, appropriateness, validity, effectiveness, and safety, among other kinds of evaluations. Moreover, we noted that we understood that these efforts were also identifying means to communicate measures of FAVES through model cards, model nutrition labels, datasheets, data cards, or algorithmic audits. However, we also noted that these efforts lacked consensus and have not been widely or consistently implemented to date. We described that we thought it would be premature to propose requirements for specific measures or thresholds for FAVES. Rather, we stated that the proposed requirements would enable consistent and routine access to technical and performance information specifically relevant to FAVES, which would support users in making informed decisions about whether and how to use Predictive DSIs. While we stressed that transparency regarding the technical and performance dimensions of Predictive DSIs was needed, we also believed that transparency regarding the organizational and socio-technical competencies employed by those who develop Predictive DSIs was foundational for users to determine whether their Predictive DSI is FAVES. Therefore, in addition to the proposed requirements for Predictive DSI-specific source attributes, we also proposed that developers of certified health IT with Health IT Modules that enable or interface with Predictive DSIs employ or engage in intervention risk management practices, subsequently making summary information about these practices publicly available. We proposed three intervention risk management practices: (1) risk analysis, (2) risk mitigation, and (3) governance (88 FR 23780). Overall, we identified these as practices that promote transparency regarding how the developer of certified health IT analyzes and mitigates risks at the organization level, including proposals that would have such developers establish policies and implement controls for governance, inclusive of how data are acquired, managed, and used in Predictive DSIs. Together, transparency regarding the technical and performance details of a Predictive, as well as the organizational competencies of the developer of certified health IT to manage risks for a Predictive DSI, were intended to contribute to the trustworthiness of these emerging and important technologies.

We noted at 88 FR 23780–23781 that the proposed requirements for the certification criterion in § 170.315(b)(11) also supported health equity by design, for example, (1) emphasizing transparency regarding the use of specific data elements relevant to health equity in Predictive DSIs; (2) enabling users to review whether and how the Predictive DSI was tested for fairness; and (3) enabling transparency about how developers of certified health IT manage risks related to fairness for the Predictive DSIs their Health IT Modules enable or interface with.

At 88 FR 23781, we noted our belief that the existing scope and structure of the Program were fit for these purposes because the Program has existing requirements to make information transparent regarding the authorship, bibliography, and other kinds of “source attribute” information for evidence-based decision support and linked referential intervention types (at § 170.315(a)(9)(v)(A) and (B), respectively). We proposed to build on these requirements so that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) would need to enable user review of evidence-based and Predictive DSIs within their certified products, and to disclose approach(es) to intervention risk management in a publicly accessible manner. Together, we said these requirements would have an important impact on the Department's efforts to address disparities and bias that may be propagated through DSIs. Consequently, we hoped to enhance market transparency and encourage trust across the software development life cycle (SDLC) of DSIs in healthcare. We said this transparency would serve as a foundation for establishing consistency in information availability, improving overall data stewardship, and guiding the appropriate use of data derived from health information about individuals.

At 88 FR 23781, we noted that we were intentional regarding the level of prescriptiveness in our proposals because these are nascent technologies with enormous potential benefit. Thus, we sought to establish appropriate guardrails for information transparency about Predictive DSIs that do not undercut the value that could be offered to patients and clinicians from such promising technologies.

Comments. Commenters were largely supportive of our DSI proposals but mixed in their support of the specifics of the DSI certification criterion we proposed in § 170.315(b)(11). Most commenters stated that our proposals would increase transparency and accountability, enhance trustworthiness in AI and machine learning-driven decision support tools, and promote risk management by developers of certified health IT. Several commenters stated that these benefits would lead to equitable access to healthcare, contribute to reducing health disparities during provider-patient encounters, increase user and patient trust, and enhance patient experience. Commenters commended ONC's efforts to prevent bias and discriminatory outcomes driven by DSIs and noted that a regulatory framework must be created whereby tools are appropriately tested and vetted during their development, and products are labeled to provide users with essential information.

Several commenters applauded our effort to address transparency of rapidly evolving AI in healthcare. Commenters noted that adding new requirements for transparency around DSI applications' technical information, risk management processes, and real-world testing are all foundational steps in establishing these tools' safe and effective use. Several commenters agreed with our proposal that biases in the data and algorithms underlying AI or machine learning could negatively impact certain subpopulations and supported more rigorous evaluation of such tools to ensure that they are fair, effective, and support improved outcomes for patient populations. Specifically, commenters remarked that greater transparency, including about the datasets used to train a Predictive DSI, would help avoid embedding bias in the system and help improve efficiency. Several commenters noted that the HTI–1 Proposed Rule would help lay the foundations for responsible, ethical AI development in healthcare and for enhanced federal AI transparency and will promote establishing necessary assurances for greater trust in AI use. Commenters acknowledged that due to the leaps in technological innovations, especially as it relates to predictive models, it is necessary to have new requirements for the Program's CDS criterion. Several commenters agreed that it is critical for the end user to understand how a Predictive DSI is designed, developed, trained, and evaluated; and how it should be used by the end-user.

Commenters approved of the proposal separately looking at risk analysis, risk mitigation, and governance as essential tasks in ensuring proper DSI development, management, and use. Commenters observed that the proposal, if adopted, would provide the opportunity for transparent, thoughtful decision-making by enabling users, including medical practitioners, health care providers, and other interested parties of AI and algorithmic tools to evaluate, disclose, and mitigate risks that could impact patients. Lastly, commenters urged ONC to be mindful that regulations on AI should not stifle innovation or have a chilling effect on beneficial uses of this emerging tool, and that we should seek to balance the risks and benefits to consumers of the public availability of information with the need to protect certain data to comply with the HIPAA Privacy Rule and limit adverse effects from a clinical standpoint.

Response. We thank commenters for their broad support of our proposals. We appreciate that many commenters understood our policy objectives and agreed with our proposals to improve trustworthiness through transparency in support of decision-making using AI machine learning-driven tools. We agree with and thank commenters who noted that greater transparency, including about the datasets used to train Predictive DSI, would help avoid embedding bias in the system and help improve efficiency. We are also mindful of the need to balance prescriptiveness and flexibility in our requirements for developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) and have made several modifications to our proposals, described in detail in subsequent responses, to achieve this balance.

Comments. Several commenters expressed concern that the proposed requirements were not strong enough to ensure DSIs are designed with equity in mind and fully validated for all patient populations when deployed and believed the HTI–1 Proposed Rule did not ensure developer accountability. One commenter was concerned that the proposal did not address or require equity testing across patient populations to limit potential biases.

Response. We appreciate commenters concerns. We have finalized several requirements that will help promote DSIs to be designed with health equity in mind, and we have finalized specific requirements related to performance measures of validity and fairness. Our proposal sought to ensure that information would be available for users to easily review whether a given model has been adequately validated and tested for fairness before using it, as well as enable users to understand if a DSI used data elements relevant to health equity, such as race, ethnicity, and sexual orientation, among other data elements. We clarify that nothing from our proposals nor our finalized criterion would require a user of a Health IT Module certified to § 170.315(b)(11) to review source attributes, though we also note that certain users may already have an existing obligation to ensure compliance with non-discrimination requirements and comply with applicable law.

Comments. A minority of commenters did not support the proposed revised DSI certification criterion, noting that it was premature for ONC to adopt policies related to AI or machine learning. Some commenters expressed a belief that ONC's proposed revised DSI certification criterion's requirements would exceed ONC's authority, questioned whether ONC had the authority to impose non-quality or efficacy criteria on Predictive DSI, and believed there was not sufficient statutory support for the proposed revisions to DSI or authority over non-certified software that is enabled by or interfaces with certified health IT. In particular, commenters noted that ONC's authority to adopt certification criteria is provided by section 3001(c)(5)(D) of the PHSA and that the HTI–1 Proposed Rule would make changes to the architecture of health software used by thousands of hospitals and health providers across the country, including software that would not be directly part of the Program. Commenters also requested that ONC address how each of its proposed changes fit within the subcategories permitted by section 3001(c)(5)(D) of the PHSA.

Response. We disagree with commenters who believe that requirements for AI or machine learning-driven decision support is premature. Given the proliferation of such tools used in healthcare and supplied by developers of certified health IT, we believe now is an opportune time to help optimize the use and improve the quality of AI and machine learning-driven decision support tools. Moreover, our statutory authority to promulgate regulations to define certification criteria for the Program is established in 42 U.S.C. 300jj–11(c)(5)(A) and 300jj–14(b). The authority in 42 U.S.C. 300jj–11(c)(5)(D) of the PHSA was added by section 4002(a) of the Cures Act and is specific to conditions of certification under the Program, which does not limit the scope of the Program and, in fact, expanded the scope and applicability of the Program with respect to developers of certified health IT. Moreover, since 2010, the Program has included a certification criterion related to decision support in response to the definition established by Congress for qualified electronic health record, in 42 U.S.C. 300jj(13)(B)(i). At the time Congress included this specific capability within the qualified electronic health record definition, it did so without specific limits and in the context of the broader HITECH Act, and subsequently the Cures Act, with the understanding that technology changes over time and so too would certification criteria. Finally, we note that our authority to propose and finalize revisions to the Program's DSI criterion is consistent with 42 U.S.C. 300jj–(c)(5) and fulfills several purposes enumerated by Congress in 42 U.S.C. 300jj–(b). The finalized requirements in § 170.315(b)(11), consistent with our authority, substantially focus on the responsibilities of developers of certified health IT and the products these developers bring forward for certification. Specifically, the updated criterion includes new sets of information that are necessary to guide decision-making based on outputs ( e.g., recommendations) from Predictive DSIs, including:

• An expanded set of “source attributes” in § 170.315(b)(11)(iv);
• Requirements for Health IT Modules to enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information in § 170.315(b)(11)(v);
• Requirements for intervention risk management practices to be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module in § 170.315(b)(11)(vi); and
• Requirements for summary information related to how intervention risk is managed to be publicly accessible in § 170.523(f)(1)(xxi).

We believe that these new sets of information will provide appropriate information to help guide decisions at the time and place of care, consistent with 42 U.S.C. 300jj–11(b)(4). Additionally, our finalized policies in §§ 170.315(b)(11), 170.402(b)(4), and 170.523(f)(1)(xxi) will support several other Congressionally-identified purposes that inform the National Coordinator's work in carrying out their duties, including the duty identified in 42 U.S.C. 300jj–11(c)(5)(A). These additional purposes include 42 U.S.C. 300jj–11(b)(2), “improves health care quality, reduces medical errors, reduces health disparities, and advances the delivery of patient-centered medical care”; 42 U.S.C. 300jj–11(b)(8), “facilitates health and clinical research and health care quality”; 42 U.S.C. 300jj–11(b)(10), “promotes a more effective marketplace, greater competition, greater systems analysis, increased consumer choice, and improved outcomes in health care services”; and 42 U.S.C. 300jj–11(b)(11), “improves efforts to reduce health disparities.”

In consideration of all the public comments received, and aligned with both the authorities granted by Congress and directives established by several Executive Orders, we have finalized most of our proposals for § 170.315(b)(11) with modifications intended to align and simplify technical requirements between evidence-based DSIs and Predictive DSIs as well as to clarify: (1) the definition of Predictive DSI in § 170.102; (2) the scope of technologies considered to be an evidence-based DSI for purposes of the Program; and (3) the scope of source attribute information that must be accessible to users. Specifically, we have finalized our proposals by significantly narrowing the scope of requirements for Predictive DSI-related source attributes and intervention risk management (IRM) practices to apply only to Predictive DSIs supplied by the health IT developer as part of its Health IT Module. In addition to the detailed section-by-section final rule discussions, the following paragraphs summarize some of the key policy determinations included in this final rule.

Additionally, in consideration of comments received and the scope reductions we have made to this final certification criterion, we determined that a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification is necessary to fully implement our policy objectives and proposals. Specifically, we have finalized in this final rule an “Assurances” Maintenance of Certification requirement at 45 CFR 170.402(b)(4) that starting January 1, 2025, and on an ongoing basis thereafter, health IT developers with Health IT Modules certified to § 170.315(b)(11) review and update as necessary, source attribute information in § 170.315(b)(11)(v)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). This reinforces a health IT developer's ongoing responsibility to enable users to access complete and up-to-date descriptions of DSI source attribute information at § 170.315(b)(11)(v)(A) and (B) to review and update as necessary IRM practices for all Predictive DSIs it supplies as part of its Health IT Module, and to ensure the ongoing public availability of summary IRM practice information as submitted to their ONC–ACB via hyperlink in § 170.523(f)(1)(xxi). We have finalized that developers with Health IT Modules certified to § 170.315(b)(11) will need to comply with this Maintenance of Certification requirement starting January 1, 2025. We added this Maintenance of Certification requirement to serve as a discrete connection for developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) to ensure that their Health IT Modules have complete and up-to-date descriptions of source attribute information and other required information, both at the time of certification and on an ongoing basis while their Health IT Modules are certified to § 170.315(b)(11).

We have not finalized proposals related to the proposed Predictive DSI attestation statement, and we will not require Health IT Modules certified to § 170.315(b)(11) to support linked referential DSIs or related source attributes under the Program. Further, we have finalized modifications to our proposal for IRM practices in § 170.315(b)(11)(vi) and did not adopt the requirement for detailed documentation we proposed in § 170.315(b)(11)(vi)(B). The finalized § 170.315(b)(11)(vi) requires that IRM practices must be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, which is similar to how we described the proposal in § 170.315(b)(11)(vii)(A) in the HTI–1 Proposed Rule (88 FR 23798).

We have also finalized in § 170.102, as proposed, the date for which the requirements of § 170.315(b)(11) must be satisfied for Health IT Modules to meet the definition of Base EHR. This means that proposed changes to the Base EHR definition in § 170.102 that would allow a Health IT Module to meet said definition if it has been certified to § 170.315(a)(9) or (b)(11) for the period up to and including December 31, 2024, and § 170.315(b)(11) on and after January 1, 2025, have been finalized as proposed. This also means that a developer of certified health IT with a Health IT Module certified to § 170.315(b)(11) must apply IRM practices for each Predictive DSI supplied by the health IT developer as described in § 170.315(b)(11)(vi) and submit summary information of their IRM practices to its ONC–ACB via publicly accessible hyperlink according to § 170.523(f)(1)(xxi) before December 31, 2024. We note that we have finalized, as discussed in section III.C.5.a.xiv, that the adoption of the criterion at § 170.315(a)(9) for purposes of the ONC Health IT Certification Program expires on January 1, 2025.

Together, these modifications reflect feedback received from numerous interested parties and are in response to both their support and opposition to our proposals. They are also intended to simplify Program requirements and support practical implementation of the certification criterion by developers of certified health IT. We elaborate on the details of these and other finalized policies more fully in subsequent responses of this final rule.

a. Requirements for Decision Support Interventions (DSI) Certification Criterion

i. Structural Revisions and New Criterion Categorization

We proposed at 88 FR 23782 through 23783 to adopt the certification criterion “decision support interventions,” (DSI) in § 170.315(b)(11) as a “revised certification criterion” according to the proposed definition in § 170.102. The proposed criterion in § 170.315(b)(11) was a revised version of 45 CFR 170.315(a)(9), “clinical decision support (CDS).” In § 170.315(b)(11), we proposed to adopt a substantially similar structure as is currently in § 170.315(a)(9). In the revised certification criterion at § 170.315(b)(11), we proposed to modify the existing requirements in § 170.315(a)(9) to reflect an array of contemporary functionalities, data elements, and software applications that certified Health IT Modules support to aid decision-making in healthcare. We proposed that the policies established in § 170.315(a)(9)(i) through (iv) would be included as § 170.315(b)(11)(i) through (iv) with modifications. We proposed to introduce a new intervention type in § 170.315(b)(11), Predictive DSIs, with a corresponding definition in § 170.102 for the term.

At 88 FR 23782, we discussed our rationale for these proposals and stated our view that proposed § 170.315(b)(11) reflected functionality that is better categorized as part of the “care coordination certification criteria,” as opposed to the “clinical certification criteria,” supported by the Program. Hence, we proposed to adopt the “decision support intervention” certification criterion in the “care coordination criteria” section adopted within § 170.315(b).

At 88 FR 23783, we proposed modifications to the Base EHR definition in § 170.102 to identify the dates when § 170.315(b)(11) would replace § 170.315(a)(9) in the Base EHR definition. In keeping with the proposal to modify the Base EHR definition in § 170.102, we proposed that the adoption of § 170.315(a)(9) as part of the Program would expire on January 1, 2025. We noted that if we finalized these proposals, developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) would need to certify those Health IT Modules to § 170.315(b)(11) in order for those Health IT Modules to continue to meet the Base EHR definition. Lastly, as a consequence of the proposed adoption of this criterion in § 170.315(b), we noted that developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11) would be required to submit real world testing plans and corresponding real world testing results, consistent with § 170.405.

Comments. Commenters' support was split with respect to the proposal to adopt the certification criterion naming update of “decision support interventions,” or DSI, for § 170.315(b)(11) as a “revised certification criterion” of 45 CFR 170.315(a)(9), “clinical decision support” (CDS). Commenters in support noted that the proposal would promote greater trust in DSI and predictive models through the Program. Commenters stated that distinguishing between CDS and DSI was warranted and that with the technological advancements in predictive analytics, AI, and machine learning, the certification criterion needed to be updated to better reflect the market, and our proposal reflected contemporary and emerging functions, uses, and data elements. Commenters who did not support the proposal recommended against renaming clinical decision support to decision support interventions because they stated the term “intervention” has other meanings within healthcare. Commenters suggested that retaining the name “clinical decision support” aligns better with the clinical decision support included in the legislative definition of a qualified electronic health record.

Response. We appreciate commenters' support for our proposal and agree that revising the existing CDS criterion in § 170.315(a)(9) as the DSI criterion in § 170.315(b)(11) is reflective of how decision support relies on increasing technological advancements in predictive analytics, AI, and machine learning. We agree the Program should be updated to reflect these advancements. While we appreciate the concerns raised regarding renaming the criterion from Clinical Decision Support to Decision Support Interventions, we note that the term “evidence-based decision support intervention,” has been part of the Program for nearly a decade, and we believe that removing “clinical” reflects the reality that Health IT Modules already support a broad array of decision support beyond what has been traditionally considered CDS. We also believe that the DSI criterion will continue to support the legislative definition of a qualified electronic health record as it has since the inception of the Program. We note our discussion of the term “intervention” was described in 88 FR 23786 and that the Program's use of the term “intervention” is different from “clinical intervention” as defined under FDA regulation that includes a range of regulated products, such as a medication or medical device. We discuss the term “intervention” in more detail in subsequent responses.

Comments. Several commenters suggested that ONC make Predictive DSI support a separate certification criterion from the existing “clinical decision support” criterion to better facilitate it being on a more extended timeframe for implementation and potentially impacting different products, whereas other commenters were supportive of revising the criterion to account for the rapid changes in this area of health IT.

Response. We appreciate the comments, but we decline to create a separate certification criterion for Predictive DSIs. We believe that the current structure of the CDS criterion in § 170.315(a)(9) is suitable to be implemented in a revised version in § 170.315(b)(11) and that this approach is more straight-forward than having substantially similar yet separate criteria. We have not extended the timeframe for implementation from what we proposed because many of the capabilities we have finalized in § 170.315(b)(11) are substantially similar to what already exists in § 170.315(a)(9) and because we have made other corresponding scope adjustments to the finalized certification criterion. We agree with commenters who note that technology is changing rapidly and there is a need for these policies to be implemented on a more accelerated timeline from other requirements in the HTI–1 Proposed Rule.

After consideration of these comments, we have finalized our proposal to adopt the “DSI certification criterion” in § 170.315(b)(11) as a “revised certification criterion” according to the proposed definition in § 170.102 and as part of the “care coordination certification criteria,” in § 170.315(b), including paragraph (b)(11)(i), which remains unchanged from paragraph (a)(9)(i). We have also finalized inclusion of the certification criterion at § 170.315(b)(11) as part of the Base EHR definition in § 170.102, and that beginning January 1, 2025, the certification criterion at § 170.315(a)(9) would not be included in that definition. Among the numerous standards and certification criteria proposed for revision by the end of 2024, the certification criterion in § 170.315(b)(11) has been prioritized and finalized on the proposed timeline. Based on public comment, we have lengthened the implementation timeline for nearly every other standard and certification criterion proposed in the HTI–1 Proposed Rule, as well as made other timing adjustments that could impact prioritization for § 170.315(b)(11). We believe these final rule updates will give developers of certified health IT time to focus on implementing the DSI criterion at § 170.315(b)(11).

Finally, as we noted in the HTI–1 Proposed Rule (88 FR 23783), as a consequence of adopting this revised criterion in § 170.315(b), developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11) are required to submit real world testing plans and corresponding real world testing results, consistent with § 170.405, demonstrating the real world use of each type of DSI in § 170.315(b)(11), including evidence-based DSIs and Predictive DSIs. Finally, as we noted in the HTI–1 Proposed Rule (88 FR 23783), as a consequence of adopting this revised criterion in § 170.315(b), developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11) are required to submit real world testing plans and corresponding real world testing results, consistent with § 170.405, demonstrating the real-world use of each type of DSI in § 170.315(b)(11), including evidence-based DSIs and Predictive DSIs.

ii. Decision Support Configuration

At 88 FR 23783, we proposed in § 170.315(b)(11)(ii) to establish “decision support configuration” requirements based on what is currently in § 170.315(a)(9)(ii) with modifications and additional requirements. To reflect ONC's focus on the USCDI and to acknowledge the varied data for which DSIs may be enabled, we proposed that data elements listed in § 170.315(b)(11)(ii)(B)( 1)( i) through ( iii) and ( v) through ( viii) be expressed according to the standards expressed in § 170.213, including the proposed USCDI v3. We proposed to reference the USCDI in § 170.315(b)(11)(ii)(B)( 1) to define the scope of the data “at a minimum.” We noted the intention was to establish baseline expectations that Health IT Modules certified to § 170.315(b)(11) must be capable of supporting DSIs that use those data elements listed in § 170.315(b)(11)(ii)(B)( 1). We did not propose to establish requirements for specific interventions to be supported, only that Health IT Modules certified to § 170.315(b)(11) be capable of supporting interventions that use those listed data elements. This proposed requirement was framed to pertain to both evidence-based DSIs and Predictive DSIs that would be enabled by or interfaced with a certified Health IT Module, including any Predictive DSIs that were developed by users of the certified Health IT Module. We proposed to adopt in § 170.315(b)(11) the existing reference in § 170.315(a)(9)(ii)(B)( 1)( iv) to demographic data in § 170.315(a)(5)(i).

Additionally, at 88 FR 23783 we proposed to include two USCDI data classes not currently found in § 170.315(a)(9)(ii)(B)( 1). In § 170.315(b)(11)(ii)(B)( 1)( vii)–( viii), we proposed to include the Unique Device Identifier(s) for a Patient's Implantable Device(s) and Procedures data classes, respectively, as expressed in the standards in § 170.213, including the proposed USCDI v3. We proposed to require that Health IT Modules would support data from the Procedures data class and the Unique Device Identifier(s) for a Patient's Implantable Device(s) data class as an input to DSIs. We invited comment on the additional data classes described in § 170.315(b)(11)(ii)(B)( 1)( vii).

At 88 FR 23784, we proposed to adopt in § 170.315(b)(11)(ii)(C) a new functionality to enable users to provide electronic feedback data based on the information displayed through the DSI. We proposed that a Health IT Module certified to § 170.315(b)(11) must be able to export such feedback data, including but not limited to the intervention, action taken, user feedback provided (if applicable), user, date, and location, so that the exported data could be associated with other relevant data.

At 88 FR 23784, we proposed that such feedback data be available for export by users for analysis in a computable format, so that it could be associated with other relevant data. We noted that “computable format,” was consistent with current requirements in § 170.315(b)(10)(i)(D) for EHI Export, and we clarified that “computable format” is also referred to as “machine readable,” in other contexts, which is not synonymous with “digitally accessible.” We did not propose to require specific formatting requirements for such feedback mechanisms.

Comments. The majority of commenters expressed support for the proposal to define the scope of data and supported the inclusion of USCDI v3 as the minimum set of data that should be included stating that defining data elements according to the USCDI v3 standard would have the benefit of improving transparency and increasing accuracy. Commenters recommended ONC support alignment efforts with standards development organizations (SDOs) and convene listening sessions with DSI developers to align reporting efforts and to understand the appropriate minimum base sets of data for DSI technology. One commenter expressed concern that the proposal to include USCDI v3 data elements was unclear and requested ONC clarify whether a Health IT Module must support these data elements so external DSI solutions can be integrated. One commenter expressed concern that the proposal for the data to be expressed in the standards in § 170.213 was unclear and recommended including USCDI data elements individually within the criterion for clarity on which elements would be required.

Response. We thank commenters for their support and feedback received during the public comment period, and we have finalized several proposals based on such feedback. We thank the commenter for expressing their concern regarding our proposals to include the USCDI v3. We did not propose to establish requirements for specific interventions to be supported, only that Health IT Modules certified to § 170.315(b)(11) be capable of supporting interventions that use those listed data elements (88 FR 23783). The criterion at § 170.315(a)(9)(ii)(B)( 1) listed many of the same types of information, such as medications for example, but the criterion at § 170.315(a)(9) did so without specifying a standard. As the result of our finalizing references to the standards in § 170.213, we have provided clarity and better alignment with other certification criteria in the Program. We appreciate the suggestion that we work with SDOs and coordinate listening sessions with DSI developers. We will take these suggestions under consideration for future work, including potential future workshops, listening sessions, and advisory group task forces.

We have finalized § 170.315(b)(11)(ii)(A) with a minor modification to remove “( e.g., system administrator)” from that provision (which is also in existing regulation text at § 170.315(a)(9)(ii)(A)), as this example is unnecessary. We have also finalized the list of data elements proposed at § 170.315(b)(11)(ii)(B)( 1) with the following modifications in consideration of comments. We have moved the list from proposed § 170.315(b)(11)(ii)(B)( 1) and finalized the list at § 170.315(b)(11)(iii)(A)( 1) and finalized the list as proposed. We have finalized the list of data elements in § 170.315(b)(11)(iii)(A)( 1) because they establish a scope for evidence-based DSIs that must be supported by Health IT Modules certified to § 170.315(b)(11) as well as scope the evidence-based DSIs that are subject to requirements in § 170.315(b)(11)(v). Including the list in § 170.315(b)(11)(iii)(A)( 1) is intended to make this connection clearer.

We note that elsewhere in this final rule we have finalized an expiration date in § 170.213 for USCDI v1 to occur on January 1, 2026. Consistent with the applicable dates for the versions of the USCDI in § 170.213, this means Health IT Modules certified to § 170.315(b)(11) need only support the listed data elements according to the USCDI v1 standard until this time. A Health IT Module certified to § 170.315(b)(11) may support the data elements according to the USCDI v3 standard adopted in § 170.213 as of the effective date of this final rule. On and after January 1, 2026, Health IT Modules certified to § 170.315(b)(11) must support those listed data elements according to the USCDI v3 standard consistent with § 170.213.

We have also finalized § 170.315(b)(11)(ii)(B)( 2) as § 170.315(b)(11)(ii)(B) due to the corresponding shift of the list of evidence-based DSI-related data elements noted above. We did not propose any changes to § 170.315(b)(11)(ii)(B) in transposing the proposed regulatory text from the regulation text at § 170.315(a)(9)(ii)(B)( 2), and we have finalized regulation text proposed at § 170.315(b)(11)(ii)(B)( 2) using existing language found at § 170.315(a)(9)(ii)(B)( 2) at § 170.315(b)(11)(ii)(B).

Comments. Commenters generally expressed support for the proposal at § 170.315(b)(11)(ii)(C) to enable users to provide electronic feedback based on the information displayed through the DSI and applauded including human-readable display. However, there was concern among many commenters regarding the details of this proposal, including requirements that Health IT Modules must be able to export feedback data, including but not limited to the intervention, action taken, user feedback provided (if applicable), user, date, and location, so that the exported data can be associated with other relevant data. These concerns were generally related to how these requirements would impact usability, user interfaces, and ongoing innovation of decision support tools. Specific commenters noted that capturing the “action taken,” by a user would be particularly problematic and would degrade DSI to simple “yes/no” designs.

Commenters suggested that we should limit the requirements to DSIs directly implemented by a developer of certified health IT and limit the requirements to interruptive alerts, because passive alerts cannot have associated user actions. Other commenters recommended the functionality to enable “feedback loops” be optional for users and that the requirement pertain to evidence-based DSIs exclusively.

Response. We appreciate the comments and thank commenters for their recommendations. We noted in the HTI–1 Proposed Rule that this is the second time we have proposed a functionality that would require a Health IT Module to enable a user to provide electronic feedback, also referred to as the capability to support “feedback loops,” on the performance of DSIs implemented at the point of care (88 FR 23783). We note that in our 2015 Edition Proposed Rule, we proposed to adopt new functionality that would require a Health IT Module certified to the CDS criterion in § 170.315(a)(9) to be able to record at least one action taken, and by whom it was taken, when a CDS intervention is provided to a user ( e.g., whether the user viewed, accepted, declined, ignored, overrode, provided a rationale or explanation for the action taken, took some other type of action not listed here, or otherwise commented on the CDS intervention) (80 FR 16821). At the time, many commenters stated that current systems already provided a wide range of functionality to enable providers to document decisions concerning CDS interventions and that such functionality was unnecessary to support providers participating in the EHR Incentive Programs (80 FR 62622). However, subsequent research over the last seven years indicates that “feedback loop” functionality is not widely available across Health IT Modules certified to the CDS criterion in § 170.315(a)(9), but that such functionality could be useful (88 FR 23784).

We appreciate the comments asking us to clarify to which DSI types our proposals would pertain. We agree with commenters who indicated that feedback loop functionality would be most appropriate for evidence-based DSIs. We have finalized § 170.315(b)(11)(ii)(C) to make clear that this functionality would only be required to apply to evidence-based decision support interventions. We decline to limit this functionality to interruptive alerts only, but we believe that interruptive alerts can be improved if user feedback data is applied to make such interruptions more meaningful.

While we are receptive to concerns regarding usability, we do not believe that the finalized requirements to enable a user to provide electronic feedback on evidence-based DSIs constrain or hinder usability or would lead to CDS degradation because this electronic feedback data can be gathered in ways that are non-disruptive to users and we believe our requirements are sufficiently flexible to enable a user to provide feedback in a manner appropriate to their workflow. Furthermore, we note that while Health IT Modules must support the capability at § 170.315(b)(11)(ii)(C) in order to demonstrate conformance to the certification criterion, a user still needs to choose to implement such functionality. A user would not be required to provide feedback; rather, the capability to enable a user to provide electronic feedback is what must be included within the Health IT Module.

We clarify that only evidence-based DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives must be supported by the “feedback loop” functionality described in § 170.315(b)(11)(ii)(C). We believe that scoping the requirement for feedback loops to these kinds of evidence-based DSIs would be both appropriate to the goal of enabling ongoing quality improvement of DSIs, as discussed on 88 FR 23784–23785, and feasible for Health IT Modules to support. We also clarify that a Health IT Module must be able to make available feedback data to a limited set of identified users for export in a computable format. This clarifies that while the Health IT Module must enable any user to provide electronic feedback, the Health IT Module is not required to export this feedback data to any user; rather, such an export of feedback data must be available to a limited set of identified users.

As it relates to concerns regarding the “action taken,” requirement, we note that the action taken will be specific to the intended use of the evidence-based DSI. Actions could include whether the user viewed, accepted, declined, ignored, overrode, or modified the DSI in some way. At this time, we decline to require an enumerated list of “actions taken” be supported. We believe that developers of certified health IT and their customers are better positioned to determine the range of actions that are appropriate as part of feedback data.

iii. Evidence-Based Decision Support Interventions

In the HTI–1 Proposed Rule, we proposed at 88 FR 23784 to establish “evidence-based decision support interventions” at § 170.315(b)(11)(iii), with a minor revision to current requirements that are part of the CDS criterion in § 170.315(a)(9)(iii). We explained that this proposal would replace the current construct in § 170.315(a)(9)(iii), which states a Health IT Module must enable evidence-based decision support interventions “based on each one and at least one combination of” the data referenced in paragraphs § 170.315(a)(9)(ii)(B)( 1)( i) through ( vi). We proposed that Health IT Modules supporting evidence-based DSIs must have the ability to support “any,” meaning all, of the revised data referenced in paragraphs of proposed § 170.315(b)(11)(ii)(B)( 1)( i) through ( viii). We noted this proposal would broaden the scope of data elements that Health IT Modules must support when enabling evidence-based DSIs to include 15 data elements expressed by the standards in § 170.213, including USCDI v3, which we proposed to adopt in § 170.213(b) elsewhere in the HTI–1 Proposed Rule. The HTI–1 Proposed Rule did not prescribe the intended use of the evidence-based DSI. Rather, the proposed subparagraph at § 170.315(b)(11)(iii), in combination with the data referenced in § 170.315(b)(11)(ii)(B)( 1), represented the scope of evidence-based DSIs and scope of data that Health IT Modules certified to § 170.315(b)(11) should enable for purposes of certification under our Program.

Comments. Commenters were generally evenly split on their support for the proposal to establish “evidence-based decision support interventions,” with a minor revision to current requirements that are part of the CDS criterion in § 170.315(a)(9)(iii), with those in support noting that it would ensure that decision support systems are founded on the latest scientific research and clinical guidelines and assist healthcare professionals in making informed and effective choices that are supported by robust evidence. One commenter appreciated that we differentiated between predictive and evidence-based DSIs to support decision-making. One commenter noted that they believed it is critical that ONC account for the needs of clinical guideline developers so that undue burdens are not placed on the guideline development process as DSI tools are developed and implemented in part based on clinical guidelines.

Response. We appreciate these comments. We have finalized § 170.315(b)(11)(iii) with accompanying modifications and clarifications. As articulated in more detail in subsequent responses, we clarify that evidence-based DSIs, for purposes of requirements in § 170.315(b)(11), are limited to only those DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives and that do not meet the definition for Predictive Decision Support Intervention at § 170.102. Actively presented stands in contrast to decision support that initiates an action without a user's knowledge or occurs outside a user's normal workflow. We believe this clarification will help interested parties differentiate between evidence-based DSIs and Predictive DSIs and delineate which requirements in § 170.315(b)(11) pertain to these DSI types. We also note that some data elements in § 170.315(b)(11)(iii)(A) are not part of USCDI v1 and are only in USCDI v3. For the time period before the expiration date of USCDI v1, Health IT Modules are not required to support evidence-based DSIs that are based solely on data elements included in USCDI v3. However, beginning January 1, 2026, Health IT Modules must support DSIs based on all—meaning each—USCDI v3 data element listed in § 170.315(b)(11)(iii)(A).

Comments. Commenters not in support of the proposal expressed concern that the definition of evidence-based DSI was too broad and would encompass a large number of baseline functionality and capabilities within an EHR including passive and active alerts, order sets, care plans and protocols, simple rules and calculations, references ranges, age and weight based dosing and reminders for preventative care. Commenters sought more clarity related to how evidence-based and Predictive DSIs were defined and should be supported. Specifically, commenters noted concerns related to consistently determining what types of functionalities qualify as an evidence-based DSI, a Predictive DSI, or neither. Commenters also noted that EHRs support a vast number of financial and reimbursement rules to support medical necessity and reimbursement. The commenters recommended that the definition of evidence-based DSI align with the current § 170.315(a)(9) definition of clinical decision support and that the § 170.315(a)(9) certification criterion remain unchanged until future rulemaking can more clearly define the criterion and specific priority use cases beyond clinical.

Response. We thank commenters for their concerns and understand there is substantial confusion regarding the scope of what constitutes an evidence-based DSI as well as corresponding requirements for evidence-based DSIs in § 170.315(b)(11). In the HTI–1 Proposed Rule we included background information indicating that the initial CDS criterion, established in 2010, required that a Health IT Module could: (1) implement rules, “according to specialty or clinical priorities;” (2) “automatically and electronically generate and indicate in real-time, alerts and care suggestions based upon clinical decision support rules and evidence grade;” and (3) track, record, and generate reports on the number of alerts responded to by a user (75 FR 2046).” (88 FR 23774). Since this time, the CDS criterion has remained agnostic to use case, except for drug-drug and drug-allergy contraindication checking, requiring Health IT Modules to enable the use of a variety of tools based on a specified set of data, including problems, medications, demographics, and laboratory data. While this framing has ensured that users have access to a broad range of tools, for a wide array of purposes, related to decision support through Health IT Modules certified to the CDS criterion, we now believe some clarity is needed to refine the scope of evidence-based DSIs for the purposes of requirements in § 170.315(b)(11).

We noted in the HTI–1 Proposed Rule that we were not establishing requirements for specific interventions to be supported, only that Health IT Modules certified to § 170.315(b)(11) be capable of supporting interventions based on specified data (as proposed in § 170.315(b)(11)(ii)(B)( 1)( i) through ( viii) (88 FR 23783)). We also noted in the HTI–1 Proposed Rule that the term “intervention,” is specific to “an intervention occurring within a workstream, including but not limited to alerts, order sets, flowsheets, dashboards, patient lists, documentation forms, relevant data presentations, protocol or pathway support, reference information or guidance, and reminder messages,” (88 FR 23786).

Given the confusion conveyed through comments received from many interested parties regarding the scope of what decision support is considered evidence-based decision support, we clarify that for purposes of requirements in § 170.315(b)(11), evidence-based DSIs are limited to only those DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives and that do not meet the definition for Predictive DSI at § 170.102. In the context of Program requirements, this means that if a developer of certified health IT with a Health IT Module certified to § 170.315(b)(11) enables a user to select an evidence-based DSI that is actively presented in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives that evidence-based DSI would be subject to the requirements that apply to evidence-based DSIs within § 170.315(b)(11). We note that if the DSI in question meets the definition of Predictive DSI at § 170.102, then requirements that apply to those types of interventions within § 170.315(b)(11) would be applicable. Additionally, we clarify that “actively presented,” is inclusive of, but not limited to, “interruptive alerts,” and we clarify that “related to the care a patient receives,” would include use cases related to direct patient care as well as use cases that impact care a patient receives. For example, a decision support rule that recommends a follow-up appointment within 12 weeks according to United States Preventive Services Taskforce (USPSTF) recommendations would be considered an evidence-based DSI for purposes of Program requirements. These clarifications stand in contrast to back-end systems rules that are not presented to users and are not related to care an individual patient receives, such as those used for resource management or back-end logic that may support an organization's business rules but are not part of a user's workflow. Such rules and tools would not be considered an evidence-based DSI for the purposes of this certification criterion.

Beyond this clarification, we have finalized § 170.315(b)(11)(iii) by changing the title of the paragraph from proposed “ Evidence-based decision support interventions, ” to “ Decision support intervention selection ” and included explicit instruction for Health IT Modules to enable a limited set of identified users to select ( i.e., activate) decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are evidence-based DSIs and Predictive DSIs. We have finalized the same requirement for all DSI types recognized in the Program, be they evidence-based DSIs or Predictive DSIs, because the technical capability to enable a user to select ( i.e., activate) is the same regardless of the type of DSI being activated. As described in more detail below, Program requirements to enable a user to select a DSI is contingent only on the data elements in § 170.315(b)(11)(iii)(A) (for evidence-based DSIs) and § 170.213 (for Predictive DSIs) and supportive of various use cases.

As discussed in more detail in the section III.C.5.v. “Predictive Decision Support Interventions, Attestation for Predictive Decision Support Interventions,” we did not adopt the Predictive DSI attestation statement proposed at § 170.315(b)(11)(v) in this final rule and we have narrowed the overall scope of technologies impacted by finalized requirements in § 170.315(b)(11). Given these changes, certain adjustments to the certification criterion were necessary to simplify, clarify, and align technical requirements that could be shared between evidence-based DSIs and Predictive DSIs. We believe these adjustments directly respond to commenter confusion and help reduce the technical updates that developers will need to complete in response to final requirements in § 170.315(b)(11) as they will be able to build on and extend existing capabilities to support Predictive DSIs. This is particularly true with respect to the capability expressed at final § 170.315(b)(11)(iii). Further, the alignment of evidence-based DSI and Predictive DSI capabilities will help provide for a consistent experience for those users identified to select DSIs pursuant to final § 170.315(b)(11)(iii).

While we specifically discussed evidenced-based DSIs in the HTI–1 Proposed Rule (88 FR 23784) with respect to proposed § 170.315(b)(11)(iii), we did not (aside from the paragraph title) expressly limit the scope of the proposed regulation text to evidenced-based DSIs—instead focusing on “electronic decision support interventions.” Moreover, at 88 FR 23783, we noted that requirements proposed at § 170.315(b)(11)(ii) for DSI configuration “would pertain to both evidence-based DSIs and predictive DSIs that are enabled by or interfaced with a certified health IT Module, including any predictive DSIs that are developed by users of the certified Health IT Model.” We have addressed these ambiguities in finalized regulation text at § 170.315(b)(11)(iii) and appreciate the comments that sought more clarity related to the shared uses expected for certification for evidence-based and Predictive DSIs.

We note that the capability in § 170.315(b)(11)(iii) is consistent with the historic and current expectation for evidence-based DSIs in § 170.315(a)(9)(iii) and we reiterate that this capability does not require a developer of certified health IT with a Health IT Module certified to § 170.315(b)(11) to author, develop, or otherwise support a specific evidence-based DSI or Predictive DSI.

Comments. One commenter suggested that ONC reconsider including Unique Device Identifier(s) for a Patient's Implanted Devices as a required element, or alternatively recognize that any DSI around Unique Device Identifier(s) is likely to only use certain elements of the Unique Device Identifier, not the full Unique Device Identifier—particularly the Device Identifier—and suggested that adoption as a required element for support via evidence-based DSIs is unnecessary at this stage.

Response. We appreciate the comment. We noted in the HTI–1 Proposed Rule that we believed that data regarding a patient's procedures and whether a patient has an implantable medical device, as indicated by a unique device identifier (UDI), can play a significant role in contemporary DSIs (88 FR 23783). As a result, we proposed to require that Health IT Modules would support data from the Procedures data class and the Unique Device Identifier(s) for a Patient's Implantable Device(s) data class as an input to DSIs. The addition of UDI complements medications and proposed procedures as an important focal point for various decision support interventions, including those related to MRIs, post-implant clinical care, among other care scenarios (88 FR 23783). We note that under this requirement, a Health IT Module would be required to enable an evidence-based DSI that included a UDI as expressed in the standards in § 170.213, and we clarify this requirement is affirmed regardless of whether the full UDI is part of the intervention or a component of the full UDI, such as the device identifier or the production identifier. Both identifiers are required to be supported as a part of USCDI v1 (§ 170.213(a)) and v3 (§ 170.213(b)).

Comments. One commenter requested clarification on whether algorithms that use patient medical/demographic information to provide patient-specific screening, counseling, and preventive recommendations by mapping to well-known and established authorities are considered evidence-based DSI unless there is a “predicted value.” The commenter questioned if scenarios where the algorithm is calculating a risk value based on a pre-defined deterministic clinical guideline are included.

Response. We appreciate the opportunity to clarify this point. We note that to be considered a Predictive DSI, a function or technology must meet all parts of the definition in § 170.102. Namely, it must support decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. Based on the information presented by this commenter, we do not believe a risk score based on a deterministic clinical guideline would be considered a Predictive DSI. Rather, this would be considered an evidence-based DSI. However, we note that whether a technology meets the definition of Predictive DSI is fact based, and this response should not be understood as determinative.

Comments. One commenter noted that for non-predictive CDS certified to existing ONC standards, the new transparency requirements related to patient demographics, social determinants of health, and health status assessments would be difficult to implement as such information is often not available to the CDS developer and recommended that ONC not require this for certified CDS but encourage it when such information is available.

Response. We appreciate the comment and we note that our requirements for evidence-based DSIs related to source attributes is substantially unchanged from the existing requirements. We describe in more detail our final policy for source attributes in the section “vi. Source Attributes.” However, we will require that users can review whether and which patient demographics, social determinants of health, and health status assessments data are used as part of an evidence-based DSI.

iv. Linked Referential CDS

At 88 FR 23784, we proposed to replicate what is currently in § 170.315(a)(9)(iv) as § 170.315(b)(11)(iv) with a modification to reference the criterion in § 170.315(b)(11) wherever the current reference is to § 170.315(a)(9). We welcomed comment regarding the functionalities and standards listed in § 170.315(a)(9)(iv), the HL7 Context Aware Knowledge Retrieval Application (“Infobutton”) standards, including whether linked referential CDS were commonly used with, or without, the named standards in § 170.315(a)(9)(iv)(A)( 1) and ( 2) and whether we should continue to require use of these standards.

Comments. The majority of commenters were in support of removing the linked referential CDS provisions from the scope of the criterion, noting that it emphasizes the shift in focus to AI and machine learning-based DSI technology and removes a requirement that has been of little value for health care providers. In particular, commenters were supportive of removing the HL7 Context Aware Knowledge Retrieval Application (“Infobutton”) standards from the scope of the criterion, noting that removal is appropriate because there is low utilization for this standard, there is significant expansion of the proposed criterion in the areas of evidence-based and Predictive DSI, it would help streamline the certification process, and that customers perceive it as lacking value to clinical workflow in favor of traditional evidence-based CDS interventions. However, one commenter strongly supported retention of the “Infobutton” standard for linked referential DSIs but did not provide a rationale.

Response. We thank commenters for their recommendations. We agree with commenters that “infobuttons,” while helpful and useful in some contexts, no longer need to be mandated as part of the revised criterion at § 170.315(b)(11). We also note that the “infobutton” standard has not been updated for several years (since 2014). As part of an effort to streamline and update the historic criterion at § 170.315(a)(9), we have finalized § 170.315(b)(11) without proposed paragraph (b)(11)(iv) Linked referential DSI and associated subparagraphs. We anticipate that “infobuttons” and other linked referential DSIs will continue to be used where they provide value without a requirement in the Program. We believe that removal of this requirement as part of the revised certification criteria at § 170.315(b)(11) will reduce overall burden and focus requirements on evidence-based and Predictive DSIs.

Comments. One commenter was supportive of our proposal to include “linked referential DSIs” in the Program, noting that it has the advantage of equipping health care providers with comprehensive and up-to-date resources, thus empowering them to make well-informed decisions by drawing upon a wealth of knowledge and clinical expertise, ultimately improving patient outcomes.

Response. We appreciate the commenter's support for the requirement. However, we have finalized § 170.315(b)(11) without requiring “Linked referential DSIs.” We reiterate that in circumstances where linked referential DSIs and “infobuttons” are providing value, nothing in this final rule would inhibit their use. Furthermore, nothing in this final rule should be used to inhibit the use of diagnostic and therapeutic reference information or any associated bibliographic information that is part of the linked referential DSI.

v. Predictive Decision Support Interventions

We proposed at 88 FR 23784 to reference a new intervention type, “predictive decision support intervention,” in § 170.315(b)(11)(v), and we proposed a corresponding definition in § 170.102. We also proposed in § 170.315(b)(11)(v)(A) that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) attest “yes” or “no” as to whether their Health IT Module enables or interfaces with one or more Predictive DSIs based on any of the data expressed in the standards in § 170.213, including USCDI v3, which we also proposed at 88 FR 23746.

Definition of Predictive Decision Support Intervention

We proposed at 88 FR 23784–23785 a definition of “predictive decision support intervention,” (again hereafter referenced as Predictive DSI) in § 170.102 to mean “technology intended to support decision-making based on algorithms or models that derive relationships from training or example data and then are used to produce an output or outputs related to, but not limited to, prediction, classification, recommendation, evaluation, or analysis.” We explained that such Predictive DSIs are based on the use of predictive model(s), and that “model” refers to a quantitative method, system, or approach that applies statistical, economic, bioinformatic, mathematical, or other techniques ( e.g., algorithm or equations) to process input data into quantitative estimates. We also discussed our use of the phrase “intended to support decision-making” to be interpreted broadly and to encompass technologies that require users' interpretation and action to implement as well as those that initiate patient management without user action and require action to contest. We also noted that our use of Predictive DSI was not tied to who developed it, the level of risk or degree to which the Predictive DSI informs or drives treatment, is relied upon by the user, relates to time sensitive action, or whether the Predictive DSI is augmentative or autonomous. We differentiated Predictive DSIs as those that support decision-making by learning or deriving relationships to produce an output, rather than those that rely on pre-defined rules based on expert consensus, such as computable clinical guidelines, to support decision-making.

We noted in the HTI–1 Proposed Rule that our definition of Predictive DSI was intended to cover a wide variety of techniques from algebraic equations to machine learning and natural language processing (NLP) (88 FR 23785). We mentioned the Acute Physiology and Chronic Health Evaluation IV (APACHE IV) model, which predicts in-hospital mortality for patients in intensive care units and was initially trained and validated with data from 45 hospitals, including over 100,000 individuals in 2006 (88 FR 23785). We also mentioned that models designed to estimate risk of a first Atherosclerotic Cardiovascular Disease, trained and validated on pooled cohorts of large studies as examples of common and in-scope models for our definition of Predictive DSI. We also noted that more complex models, for instance ones developed by combining multiple algorithms or deep neural networks trained and validated on over ten thousand individuals, that can be applied to patients in operational contexts would meet the proposed definition. So too would our definition include models that were adaptive, online or unlocked, which continue to adapt when exposed to new data, as well as those that are locked to the relationships learned in training data.

As proposed in § 170.102, the definition of Predictive DSI would not include simulation models that use modeler-provided parameters rather than training data or unsupervised machine learning techniques that do not predict an unknown value ( i.e., are not labeled) (88 FR 23786). For instance, the use of an unsupervised learning model within decision support would not meet our definition of Predictive DSI, nor would the use of developer-supplied parameters to simulate operating-room usage and develop an effective scheduling strategy. We refer readers to 88 FR 23784–23786 for the discussion on the definition of Predictive DSI.

Comments. Commenters were mixed in their support for the proposed definition of Predictive DSI, with those in support noting that it provides broad flexibility, comprehensively encompasses AI, and accurately highlights its distinction from any other potential sources of decision support interventions that do not involve modeling. Some commenters expressed support particularly for including complex predictive models leveraging machine learning in the proposed definition, noting that this recognition serves as a necessary step to combat bias and promote equity amid the growing number and increased use of AI tools.

While many commenters broadly supported the intent and goals of the proposed definition for Predictive DSI, other commenters expressed concern that the proposed definition was too broad and should be narrowed in several ways to provide clarity on the scope of technologies covered to prevent burden on health IT developers and health care providers. Other commenters noted that a broad definition of Predictive DSI creates confusion for what technology must be scoped for certification. Notably, many commenters suggested revising the definition to clarify that Predictive DSI means technology intended to support clinical or medical decision-making to ensure organizational and administrative decision making are excluded from the definition to limit the documentation requirements to demonstrate compliance and limit the number of citations in the system to alleviate user burden. For instance, one commenter suggested that ONC add the term “clinical” so that Predictive DSI means “Predictive decision support intervention means technology intended to support clinical decision-making based on algorithms or models that derive relationships from training or example data and then are used to produce an output or outputs related to, but not limited to, prediction, classification, recommendation, evaluation, or analysis.” Commenters recommended that the definition be limited to high risk DSIs, and that it should exclude certain health care providers, such as those that develop their own DSI and do not make it commercially available. Commenters also requested that we reconsider the proposals to apply a more limited scope that centers on functionality that necessitates the granular transparency of source attributes and feedback capabilities for end-users that ONC proposed.

Response. We appreciate the support from those commenters that said our definition comprehensively encompasses AI, and accurately highlighted the definition's distinction from any other potential sources of decision support interventions that do not involve modeling. We sought to establish a definition that was both broad and appropriate. Consistent with our rationale to move from CDS to DSI in Program nomenclature, we sought to establish a definition that encompassed the broad forms that algorithm and model-based decision support interventions can take and for which transparency regarding the performance of that model would benefit users, and would help users determine whether the technology they are using is fair, appropriate, valid, effective, and safe. We also sought to establish a definition that did not include a range of simple alerts and functions that would not benefit from the sorts of transparency our requirements would portend. However, we note there are many recent examples where the task of delineating between those predictive algorithms and models can have unintended consequences.

We thank commenters for their critiques of our definition. Many commenters said that our definition was too broad, and a small minority of these commenters offered specific suggestions on how to reduce the scope of our definition. We thank those commenters, especially. We understand that many algorithms not directly supporting medical decision making can nevertheless impact the delivery of healthcare ( e.g., algorithms supporting scheduling or the provision of supplies), and so have not sought to limit the definition to models specifically informing medical decision making. Overall, we found that many other commenters did not consider our definition for Predictive DSI as a whole; rather, these commenters chose to isolate certain phrases or aspects of the definition to question its scope and its applicability to specific use cases. As stated, our intention with the definition of Predictive DSI is to be expansive beyond the traditional role of CDS, yet appropriate to the dynamic technology environment that Predictive DSIs may be applied. Toward these two intentions, we noted in the HTI–1 Proposed Rule that we differentiate Predictive DSIs as those that support decision-making by learning or deriving relationships to produce an output, rather than those that rely on pre-defined rules to support decision-making (88 FR 23785). Taken alongside the rest of the definition, this distinction is intended to preclude the vast number of alerts or reminders that are either based on consensus clinical guidelines or bespoke business processes and organizational policies that may or may not be based on any guideline.

We also noted in the HTI–1 Proposed Rule that our definition is not tied to the level of risk (88 FR 23785) and our certification criterion for CDS was established to ensure that Health IT Modules support broad categories of CDS while being agnostic toward the intended use of the CDS beyond drug-drug and drug-allergy interaction checks (88 FR 23774). We did not propose to alter that construct in our proposals. However, we are sensitive to defining Predictive DSIs in a way that makes clear which technologies are in scope for § 170.315(b)(11).

We also decline to limit the definition to a specific source or developer of the intervention, although additional facets of the final policy define the applicable scope of § 170.315(b)(11).

We have finalized our proposed definition for Predictive DSI with modification. Specifically, we have finalized the definition in § 170.102 as follows: “Predictive decision support intervention or Predictive DSI means technology that supports decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis.” We note that this version of the definition is not markedly different from the definition we proposed, but we intend it to be more exacting. Thus, the examples and discussion regarding scope in the HTI–1 Proposed Rule remain relevant to this definition (88 FR 23784–23786). To help interested parties better understand the scope of technologies included in this definition we reiterate the following: The development process whereby models under this definition “learn” relationships in training data and then are used to generate an unknown label or value (via prediction, classification, recommendation, evaluation, or analysis) that is based on the “learned” relationships is a fundamental differentiator from evidence-based DSIs. While we appreciate commenters' request to limit or constrain the scope of the Predictive DSI definition based on its intended purpose or use ( e.g., clinical and medical versus administrative), level of risk ( e.g., high versus low), and entity or party that developed the technology ( e.g., health care provider that self-develops versus technology company that sells Predictive DSIs), we do not believe such an approach would be appropriate. We believe that the transparency requirements within this criterion are appropriate to all Predictive DSIs used within the context of certified health IT, given the potential of these Predictive DSIs to impact the delivery of healthcare at vast scale. We believe that constraining the definition of Predictive DSI by intended purposes, level of risk, or developing entity would create multiple layers of complexity and lead to different requirements for technology that may have qualities that pertain to one or more of these dimensions or exist along a spectrum of these concepts. We believe that a broad and consistently applied definition will improve the likelihood of achieving our stated goals for transparency and trustworthiness.

We note that the definition of Predictive DSI is aligned with and within the scope of the definition of Artificial Intelligence at 15 U.S.C. 9401(3), as used in E.O. 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence (88 FR 75191). Predictive DSIs perceive environments through the use of training data; abstract perceptions into models as they learn relationships in that data; and produce an output, often for an individual, through inference based on those learned relationships. We further note that evidence-based DSI likely represents another form of Artificial Intelligence, though that form is fundamentally based on rules-based models.

We also clarify that the exclusion of unsupervised learning models discussed at 88 FR 23786 was intended to focus on models trained in data without labels. This exclusion reflected our understanding that it is not feasible to produce descriptions for many of the source attributes we are requiring for Predictive DSI. For example, unsupervised models are generally based on data without labels, which often generate measures of similarity or closeness of observations rather than a predicted value. In these instances, assessing the accuracy, validity and fairness of a prediction would be difficult, if not impossible, because the outcome is not specified. The exclusion of unsupervised learning models is embedded in the definition because the definition focuses on “relationships in training data,” which generally refers to the relationship between some set of data (sometimes referred to as inputs, features, or predictors) and an outcome or label (such as a diagnosis or the next word in a string). In contrast, unsupervised learning models rely more generally on patterns in data. We further clarified this exclusion in the HTI–1 Proposed Rule at 88 FR 23786 and maintain the exclusion in the final definition.

These unsupervised models contrast with LLMs and other forms of generative AI, which often leverage self-supervised learning wherein the data itself provides a label ( e.g., the next word in a string of text) and the model returns a predicted value of that label as output, in which case the accuracy, validity and fairness of a prediction can readily be assessed (although additional use-case specific evaluation may also be beneficial). Self-supervised learning models would therefore generally be included within the definition of Predictive DSI. We also note that LLMs and other forms of generative AI often use a combination of unsupervised, self-supervised, supervised and reinforcement learning, and those that include a component of supervised learning, including semi-supervised approaches, would likely meet the definition of Predictive DSI.

Finally, we understood that models that solely rely on unsupervised learning techniques are not widely deployed in healthcare today. We will continue to monitor development of methodologies and applications of unsupervised learning to health-related use cases and may consider future rulemaking for these models as the field develops.

Comments. Several commenters expressed concern about consistency, duplication, and redundant requirements across various federal programs. Commenters recommended that ONC tailor the scope of the proposed term Predictive DSI, and the proposed definition at § 170.102, to exclude FDA-authorized AI and machine learning medical devices to mitigate their concerns mentioned above. Specifically, one commenter recommended tailoring the Predictive DSI requirements to explicitly exclude tools that are regulated medical devices, to exclude third-party tools that qualify as non-device per the statutory exemption for CDS software, and, to apply only to technology developed by vendors of certified Health IT Modules to avoid unnecessary burdens on regulated device manufacturers. Commenters noted that our proposal for Predictive DSI could implicate CDS software that falls within FDA regulated medical devices which may have already been cleared, approved, or otherwise authorized for marketing within the United States.

Response. We appreciate the concerns expressed by these commenters, which is why we worked closely with the FDA on development of our proposals in § 170.315(b)(11). This collaboration included consultation with the FDA on the inclusion or exclusion of devices within FDA's authority in the definition of Predictive DSI. Specifically, we sought alignment with the FDA's recent Clinical Decision Support Guidance for Industry (CDS Guidance), finalized in September 2022, and we note that our requirements in § 170.315(b)(11) are complementary to FDA's Content of Premarket Submissions for Device Software Functions guidance, finalized in June 2023. This high degree of coordination will reduce burden on device manufacturers by establishing the potential that a device manufacturer that also develops a Predictive DSI can fulfill two separate federal agency's requirements with substantially similar or the same information.

We noted in the HTI–1 Proposed Rule that our authority to regulate developers of certified health IT under the Program is separate and distinct from other federal agencies' regulatory authorities focused on the same or similar entities and technology (88 FR 23811). For example, the safety and effectiveness of a software function, including clinical decision support or other kinds of decision support interventions, is within the purview of FDA regulatory oversight, if such software functionality meets the definition of a “device.” In the area of predictive technology, ONC and FDA support a harmonized and complementary approach, independent of the platform on which the technology operates, in accordance with our existing intersecting regulatory oversight. We also noted in the HTI–1 Proposed Rule that questions of whether DSIs enabled by or interfaced with certified health IT are subject to FDA regulations, under the Federal Food, Drug, & Cosmetic Act, or are used by entities subject to the HIPAA Rules, are separate and distinct from the question of whether a developer or a particular technology is subject to regulatory oversight by our Program, to which our proposals pertain (88 FR 23811).

We also anticipate that in a scenario where a Device CDS (this is a CDS with software functions) has been cleared, approved, or otherwise authorized for marketing by the FDA, this device's manufacturer will have ready access to much of the information necessary for it to comply with requirements in § 170.315(b)(11) as a developer of certified health IT.

We appreciate the suggestions to exclude from our definition for Predictive DSI software that are regulated medical devices and to exclude third-party software that qualify as non-device software functions per the statutory exemption for CDS software. However, we decline to include any exclusionary criteria in our definition for Predictive DSI, such as exclusions for specific types of functions or specific types of Predictive DSI developers because the finalized definition is appropriate to reflect the wide variety of predictive tools that impact and intersect with the delivery of healthcare. Also, whether or not a given technology or tool is a Predictive DSI should be consistent regardless of the developer of the tool. We also note—as stated above and previously in the HTI–1 Proposed Rule—that the FDA and ONC have separate and distinct authorities and regulate for separate and distinct purposes with separate and distinct policy objectives (88 FR 23811). Moreover, we stress the benefits that such alignment and coordination brings to users. Because of our requirements for source attributes in § 170.315(b)(11), users of both CDS with device software functions and Non-Device CDS will have easy access to important information at the point-of-care.

Comments. Several commenters requested we clarify the proposed definition of Predictive DSI by providing examples of use cases to show the application of the policy. One commenter recommended that ONC include a clear standard or definition as to which entities the HTI–1 Proposed Rule applied to, and which applications and tools are in scope for Predictive DSIs.

Response. We understand commenters' desire to have ONC assess whether specific algorithms, models, and technologies would meet the definition for Predictive DSI. in § 170.102. Rather than make specific assessments to these commenters' questions, we provide the following examples of technologies that would likely meet our definition for Predictive DSI and examples of technologies that would likely not meet our definition for Predictive DSI:

1. Models that predict whether a given image contains a malignant tumor or that predict patient reported pain based on an image, trained based on relationships observed in large data sets often using neural networks, would likely be considered Predictive DSIs.

2. Models that pre-selected or highlighted a default order from an order set based on relationships in training data indicating that order was most likely to be selected would likely be considered Predictive DSIs.

3. Models that predict risk of sepsis, readmission ( e.g., LACE+), estimated glomerular filtration rate (eGFR), or risk of suicide attempt, which have been trained based on relationships observed in large data sets, often using logistic regression and machine learning techniques, and are used to support decision making, would likely be considered Predictive DSIs.

4. Indices and classification systems developed by expert consensus rather than in empirical data, such as the SOFA index and NYHA Heart Failure classification, would likely not be considered Predictive DSIs but are likely evidence-based DSI because the score is based on pre-defined rules and not relationships learned in training data.

5. Models that generate clinical notes or draft clinical notes and that were trained based on relationships in large data sets of free text, including large language models, and support decision making about what to document in the clinical note, would likely be considered Predictive DSIs.

6. Models that use natural language processing to route secure messages, which were trained based on the relationship between message contents and the individual who responded to similar messages in the past would likely be considered Predictive DSIs.

7. Rules-based algorithms for routing secure messages based on the type of message, rather than relationships in training data, would likely not be considered Predictive DSIs.

8. Growth charts, for instance percentile calculations based on a lambda-mu-sigma transformation of similar age children's weights, with parameters learned in training data from a national sample of children, would likely not be considered Predictive DSIs because the underlying model is based on the distribution of a single variable ( e.g., weight) rather than a prediction based on relationships between variables.

9. A calculation for BMI would likely not be considered a Predictive DSI because the calculation (weight divided by height squared) is not based on relationships in training data.

10. Patient matching algorithms based on indices of similarities, rather than by relationships in training data where an outcome is known, would likely not be Predictive DSIs. Many of these technologies are most similar to unsupervised machine learning, which we described previously in this section and in the HTI–1 Proposed Rule at 88 FR 23786 as out of scope of the current definition of Predictive DSI.

11. Optical character recognition, used simply to make a PDF readable or searchable to end users, would likely not be considered Predictive DSI because it does not support decision-making.

Comments. Commenters were generally mixed on our mention of LLMs and other generative AI as in scope for the proposed definition of Predictive DSI in the HTI–1 Proposed Rule. Some commenters in support agreed with our assessment that the use of predictive models, such as AI, invariably present model risk that can lead to patient harm, bias, widening health disparities, discrimination, inefficient resource allocation decisions, or ill-informed clinical decision-making. Commenters stated LLMs and generative AI tools could pose risks if they are not deployed appropriately and monitored carefully and viewed our proposals as a necessary step to combat bias and promote equity amid the growing number and increased use of AI tools.

Other commenters expressed concern that LLMs, such as ChatGPT, would be covered in the proposed Predictive DSI definition, noting the definition could sweep in developers of general-purpose AI applications that enable or interface with Health IT Modules. One commenter noted that these models are fundamentally different than other Predictive DSI models, thus including these models in the same category as Predictive DSIs would be an inaccurate classification. Commenters were concerned that including LLMs could potentially limit their effective application in non-clinical aspects of healthcare software intended to help users save time and organizations save money and urged ONC to revise the definition so that developers of general-purpose AI applications are not obligated by the proposed requirements and instead that applications be evaluated within the context of a specific use case.

Response. In the HTI–1 Proposed Rule, we were explicit in describing the scope of our Predictive DSI definition to include large language models, or LLMs, and other forms of generative AI that meet the definition of Predictive DSI. We do not believe that LLMs should be excluded from our definition for Predictive DSI if the LLMs are used to support decision-making, nor do we believe that LLMs are complete “black-boxes” about which no information can be made available to users that would be valuable. We agree with commenters that LLMs could pose a risk if they are not deployed appropriately. We believe that the source attribute- and risk management-related requirements in this rule could help to decrease the likelihood that a model is inappropriately deployed in a Health IT Module in a way that exacerbates bias or poses other risks. We note that we have finalized a fundamentally limited the scope in § 170.315(b)(11) to focus on transparency capabilities and instances where Predictive DSIs (such as LLMs or other generative AI) are supplied by a developer of certified health IT—and not generally on LLMs or generative AI that may be used in the healthcare ecosystem. If, as part of its Health IT Module, a health IT developer supplies an LLM or other generative AI that meets the definition of Predictive DSI, the finalized policy in § 170.315(b)(11) requires the health IT developer's Health IT Module certified to § 170.315(b)(11) to enable access to complete and up-to-date plain language descriptions of source attribute information related to that Predictive DSI. Our finalized policy also requires Health IT Modules certified to § 170.315(b)(11) to, at a minimum, have the technical capability for users and other parties to populate the source attributes listed in § 170.315(b)(11)(iv) themselves. We agree with commenters that LLMs should be evaluated within the context of specific use cases and believe that the scope of this final rule will not limit the effective application of LLMs.

Regarding commenters' concerns about LLMs being fundamentally different and requiring different kinds of source attributes that are more fit for transparency purposes, we note that our requirements for source attributes represent a minimum “floor,” and developers of certified health IT are encouraged to provide additional source attributes to users as appropriate. We also describe in more detail in subsequent responses that we have finalized a requirement for Health IT Modules to enable a limited set of identified users to record, change, and access additional source attribute information not specified in § 170.315(b)(11)(iv)(B) of this final rule. This will enable users to identify source attributes and record, change, and access those source attributes based on local validation and enable users to access emerging transparency measures specific to emerging Predictive DSI types, such as those based on LLMs.

Comments. One commenter expressed concern with the proposed definition including the term “derive relationships from training or example data,” stating that it is overly broad and unclear as to what would be considered in scope, such as whether general system improvements learned from user behavior would fall into this definition. The commenter also expressed concern with our preamble description that “Predictive models are those that have `learned' relationships from a training or historic data source, generally using some form of statistical or machine learning approach” stating that it is unclear whether commonly used predictions ( e.g., LACE+ for readmission or a SOFA score) are included in the definition of Predictive DSI. The commenter requested that the definition should be clarified to focus only on models that are generated from machine learning techniques and for the types of clinical predictions that are not commonly used in medical practice and clarified to focus on a prediction of an unknown or future clinical event.

Response. We appreciate the comment and the questions. We note that “derive relationships from training data” is only a part of the overall definition we have finalized. If a technology is used to make “general system improvements” based on training data that consists of “user behavior,” it may meet the definition of a Predictive DSI in § 170.102 if it derived relationships (for instance, correlations) from that training data and then produced an output that results in prediction, classification, recommendation, evaluation, or analysis used to support decision-making. “General system improvements” based on other analysis, such as tracking the time required to perform a task, would likely not meet the definition because that technology does not “derive relationships.” If “general system improvements learned from user behavior,” were the outputs of the technology or the effect of the technology, but that output was not used to support decision-making or was not a prediction, classification, recommendation, evaluation or analysis, then this technology likely would not meet our finalized definition.

We noted above in examples that the LACE+ model for readmission would likely meet the definition of Predictive DSI at § 170.102 and because the SOFA score was defined by expert consensus, rather than training data, this would not likely meet the definition of Predictive DSI at § 170.102. We note that in our finalized definition, we have removed “or example” and now only refer to “training data,” for clarity and because we do not believe there is an appreciable or impactful difference between training and example data. We respectfully decline to include any exclusionary criteria in our definition for Predictive DSI, including exclusions for specific types of functions or specific types of Predictive DSI developers.

Comments. Several commenters recommended that we revise the definition to take a tiered approach to DSI requirements based on the type and level of meaningful risk to patients associated with the AI systems, suggesting that we should focus on “high-risk” DSIs, remarking that it would help alleviate public confusion and suggesting that this approach would better meet the intent of addressing the risks associated with DSI. One commenter recommended that Predictive DSI should not apply to consumer-facing devices and low risk tools, noting that the public interest would not be served by imposing regulatory compliance obligations on low-risk Predictive DSI use cases—even when applied in a clinical context. For example, Predictive DSI tools used for non-clinical purposes ( e.g., EHR integrations for administrative notes and billing) do not present the sorts of risks that the HTI–1 Proposed Rule is intended to address. Along with clarifying that low-risk Predictive DSI tools are exempt, the commenter suggested that ONC should also issue guidance clarifying the types of proposed uses that are considered “low-risk.”

Response. We noted in the HTI–1 Proposed Rule that our definition is not tied to the level of risk (88 FR 23785), and we decline to focus on “high-risk” DSIs. Doing so would diverge from established approaches within the CDS criterion. The certification criterion for CDS was established to ensure that Health IT Modules certified to the criterion support broad categories of CDS, including by making information about the CDS available for user review, while being agnostic toward the intended use of the CDS beyond drug-drug and drug-allergy interaction checks (88 FR 23774). We did not propose to alter that construct in our proposals, and we respectfully decline to do so in this final rule. We do not agree with commenters that a focus on “high-risk” DSIs would alleviate public confusion because defining and determining levels of risk for Predictive DSIs that, in some cases indirectly, impact the healthcare of millions of individuals is complex and requires consideration of numerous factors. Instead, the information required for Predictive DSI will be beneficial for all Predictive DSI supplied by developers of certified health IT.

We also decline to include any exclusionary criteria in our definition for Predictive DSI, including exclusions for specific types of functions, such as consumer-facing tools or other “low risk” tools, or for specific types of Predictive DSI developers. We note that non-clinical Predictive DSIs and clinical Predictive DSIs that may be categorized as of relatively low risk have consequences for and impact the care individuals receive, and as we have noted elsewhere, demonstrably negative impacts beyond clinical safety have been well-documented in various studies and academic literature in recent years. Together, we believe these factors warrant a broad and inclusive definition for Predictive DSI.

Comments. Some commenters were concerned that due to the breadth of the definition, non-certified health IT would be included in the definition and believed the HTI–1 Proposed Rule should be limited to software that an EHR vendor submits for certification under the Program, noting that ONC's authority under the Program is limited to oversight of certified Health IT Modules and developers of certified health IT.

Response. We acknowledge that the definition of Predictive DSI itself may have broad applicability. As part of 45 CFR part 170, any application of the definition (and the related requirements in § 170.315(b)(11)) is limited to certified Health IT Modules and developers who develop them. We note that our definition does not depend on or reference the certification status of the entity that developed the technology that may or may not be considered a Predictive DSI. We established the definition to be agnostic to both use case and party that develops a Predictive DSI, and we and have not chosen to finalize a definition with any such caveats. As described elsewhere in the rule, and to address these and related commenters' concerns, we have focused the scope of Predictive DSIs to which our regulatory requirements apply to those supplied by the developer of certified health IT as part of its Health IT Module. We noted in the HTI–1 Proposed Rule that our authority to regulate developers of certified health IT and their Health IT Modules, ensuring that both conform to technical standards, certification criteria, implementation specifications, and adherence to Conditions and Maintenance of Certification requirements, is separate and distinct from other federal agencies' authorities to regulate for separate and distinct purposes with separate and distinct policy objectives that may be focused on the same or similar entities and technology (88 FR 23809–23810), that may pertain to the use of Predictive DSIs and technology, including AI and machine learning, in health and human services. Outside of the Department of Health and Human Services, multiple federal agencies, within their unique authorities, are exploring policies pertaining AI and machine learning (88 FR 23810).

Comments. A few commenters expressed concern that our proposed definition does not add clarity and offered other examples of definitions that ONC should consider. For example, one commenter recommended ONC use public definitions of AI and include a neural net component for an adopted definition of Predictive DSI. Another commenter suggested ONC narrow the definition of Predictive DSI to focus on outputs that are recommendations and to limit the definition by removing the proposed “. . . prediction, classification, evaluation or analysis” section of the proposed definition. One commenter urged ONC to survey the definitions of healthcare AI currently in use, including the American Medical Association Current Procedural Terminology (CPT®) Appendix S: AI taxonomy for medical services and procedures because it outlines the range of AI tools from those performing purely assistive functions to fully autonomous technologies.

Response. We appreciate the comments, and we are aware of the American Medical Association Current Procedural Terminology (CPT®) Appendix S: AI taxonomy for medical services and procedures. We think this taxonomy has value but decline to include specific purposes or kinds of machine learning in our Predictive DSI definition. We believe such constraints may unintentionally exclude relevant technology as it evolves and is applied to more use cases, humans interact with technology in more diverse ways, and societal views on the line between assistive and autonomous technologies shift. We, again, decline to modify our definition to exclude specific use cases, purpose of uses or intended uses and decline to modify our definition to include specific types of algorithms, such as neural networks, because we suspect the relevant algorithms will similarly evolve over time. We also decline to narrow the definition to exclude prediction, classification, evaluation and analysis because we believe that each of these types of output and use are of relevance in healthcare and can result from fundamentally similar technologies.

Comments. Several commenters expressed concern that the proposed definition included and implicated algorithms that are not directly tied to clinical workflows or capture large areas of software solutions used in certified EHR systems or types of interventions that are not conducive to source attributes or feedback gathering, specifically noting concerns with gathering feedback from passive clinical support. One commenter noted that the proposed definition could be interpreted to classify any list of patients, information form, or a comparison against a population average as Predictive DSI and recommended that ONC should remove the overly broad examples or clarify that the definition applies only when the predictive modifier applies.

Response. We appreciate the comments, and we acknowledge that our discussion regarding the term “intervention,” at 88 FR 23786, which included mention of “alerts, order sets, flowsheets, dashboards, patient lists, documentation forms, relevant data presentations, protocol or pathway support, reference information or guidance, and reminder messages,” was imperfectly placed. It was not our intention to intimate that each of these kinds of “interventions,” would always fall under the Predictive DSI definition but that each kind of intervention could be a Predictive DSI if they are driven by algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. We believe that source attributes can be provided for a Predictive DSI that is used in operations, scheduling, payment, and other workflows and that there is value in doing so, for instance, for medical coders to evaluate the relevance of codes suggested by a Predictive DSI. We note that feedback gathering is limited to evidence-based decision support interventions, which have a more limited scope. We believe that our finalized definition and associated examples provide interested parties with better clarity on technology within the definition's scope.

Comments. Several commenters expressed concern that the proposed definition does not adequately distinguish Predictive DSI from evidence-based DSI, which they believed is also defined too broadly. Commenters provided examples they believed should be excluded from the definition, such as passive decision support, reminders for preventative care, industry standard growth charts, well established reference ranges, default selections in the system, suggested word completions when typing, or rules-based decision support. Several commenters recommended that DSIs should be limited to predictive, evidence-based medicine support interventions impacting clinical choice, and solutions supporting fact-based administrative functions, such as scheduling appointments or bed availability, should be carved out.

Response. We have provided a set of examples, discussed above, along with our finalized definition in § 170.102 of Predictive DSI as meaning technology that supports decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. We also have clarified the scope of evidence-based DSIs, for purposes of requirements in § 170.315(b)(11), as being limited to only those DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives and that do not meet the definition for Predictive DSI at § 170.102. We decline to further limit the scope of the Predictive DSI definition, especially for administrative functions, which would likely benefit from the transparency our requirements would provide. We note that even appointment scheduling and block scheduling predictive models have been demonstrated to be of insufficient quality, causing harm to patients. We believe that greater transparency on the quality of these models could have avoided harm to patients by users interpreting predictions more judiciously or choosing not to use the model, or by motivating developers to retrain the models.

Comments. Several commenters recommended that ONC limit the definition to exclude health care providers that have developed their own tools for internal use regardless of whether they are enabled by or interface with the EHR the provider uses from the proposed regulatory requirements. Commenters remarked that the distinction between health care providers and EHR vendors offering DSI services through certified health IT products is important as providers have greater understanding and experience with self-developed DSI tools they use internally and should not be subject to the same requirements as vendors offering DSI tools in certified health IT products for commercial use.

Response. We appreciate the comments. With regards to the definition of Predictive DSI, we did not propose and have not finalized a definition that is dependent on the entity or party developing the Predictive DSI. In other words, “who develops” a Predictive DSI is separate and distinct from how we define what a Predictive DSI is for the purpose of this regulation. Along those lines, while health care providers may develop Predictive DSIs (as we have defined), we have not excluded those provider-authored Predictive DSIs from meeting the regulatory definition. However, it is important for commenters to keep in mind that the definition is only one part of the Program's policy approach to Predictive DSIs. In response to comments that appeared to conflate “the who” and “the what” with respect to the definition, we clarify that a health care provider who self-develops a tool that meets our definition of Predictive DSI is not subject to the requirements in § 170.315(b)(11). We believe that `self-developed' tools, which may be developed by informaticians in a health system and then applied to individual patients by clinical users or others without knowledge of the development or evaluation process could benefit from the inclusion of transparency information guiding their use. And our finalized certification criterion in § 170.315(b)(11) would result in health care providers being equipped with the technological capabilities to deliver such transparency through Health IT Modules certified to § 170.315(b)(11). We describe requirements further below that Health IT Modules certified to § 170.315(b)(11) must support the technical capability for source attribute information to be accessed and modified by users as well as the limited contexts in which developers of certified health IT are required to populate those attributes. Specifically, as already noted, we have limited the scope of our transparency requirements for source attribute information to apply to Predictive DSIs that are supplied by the health IT developer as part of its Health IT Module.

Comments. One commenter urged ONC to revise the proposed definition of Predictive DSI in a manner that specifically excludes laboratory results reported to a health care provider via a Health IT Module when such laboratory results are derived using an algorithm. The commenter noted their concern that the broad definition of Predictive DSI could cause Health IT developers to believe that a laboratory offering a test whose result is derived using an algorithm, and which is reported via an interfaced laboratory information system (LIS), must provide source attribute information about the test. The commenter also noted instrumentation result generation should not be considered covered by this DSI intervention rule, because laboratories' instrumentation remains under the auspices of standards established by the College of American Pathologists (CAP) and CLIA. One commenter expressly requested that we adopt an exception for radiologists in implementing DSI because they stated that DSI is not useful to that specialty and thus we should exempt them until the CMS Appropriate Use Criteria (AUC) program is available.

Response. We appreciate the comments. As noted above, we respectfully decline to include any exclusionary criteria in our definition for Predictive DSI, including exclusions for specific types of organizations that develop the Predictive DSI, exclusions for specific types of technology that may be considered a Predictive DSI, and exclusions for organizations or technology that may be subject to other federal requirements and authorities, like the Clinical Laboratory Improvement Amendments regulations, the CMS Appropriate Use Criteria program, or Medicare Advantage Program regulations related to utilization management. Related to the lab example provided by the commenter, and reflective of our final policy, this example would generally not be within the scope of a developer of certified IT's accountability, unless the developer of certified health IT specifically supplied the laboratory Predictive DSI as part of its Health IT Module certified to § 170.315(b)(11). As indicated by the comment, the certified health IT would be receiving a lab result for an outside entity using instrumentation separate and distinct (not included as a part of the developer's certified health IT), even if that result was arrived at by the laboratory using a Predictive DSI.

Comments. One commenter requested clarification on whether patient matching algorithms are subject to the Predictive DSI definition, and thus included in the risk management and reporting requirements. The commenter was supportive of including patient matching algorithms under the proposed definition given that the models use example data to determine accuracy prior to implementation and produce an output stating which patient it believes matches to which record given the data it is presented with. The commenter observed that by being able to understand the matching algorithms themselves, the healthcare continuum can better react and hone its data capture practices ensuring the algorithms receive the best quality data to guarantee the best possible match given the algorithms' determinations. Relatedly, a second commenter requested clarification on whether an algorithm that assigns similarity scores without labels is not a Predictive DSI.

Response. We appreciate the comment and refer readers to our finalized definition for Predictive DSI as technology that supports decision-making based on algorithms or models that derive relationships from training data and then produces an output that results in prediction, classification, recommendation, evaluation, or analysis. We are aware of a variety of methods to perform patient matching, including identifying whether specific fields are exact matches, or whether certain strings of text contain a high proportion of matching characters, and not all of them are based in relationships derived from training data. Such patient matching methods would likely not be considered Predictive DSI if they were not based on relationships derived from training data. We further note that the exclusion of unsupervised machine learning approaches, which generally do not predict an unknown value but rather identify the similarity or closeness of data, described at 88 FR 23786, is likely to apply to some patient matching algorithms, which would also likely not be considered Predictive DSI. That same clarification would apply to other algorithms that generate a similarity or closeness score without labeled training data (for instance, patient phenotyping or search recommendations based on the similarity between search strings and document contents), which would likely not be considered Predictive DSI. Other patient matching algorithms, especially those leveraging a supervised learning approach, are likely to meet the definition of a Predictive DSI.

Comments. A different commenter was concerned with the proposed definition of Predictive DSI including the term “algorithm” because it suggested a more inclusive set of health IT than they believed was intended by legislative and regulatory scope, which they stated would create confusion in the marketplace. The commenter recommended refining DSI's definition by removing “algorithms” to limit scope specifically to decision support driven by models using example data. Some commenters recommended ONC shift the criterion back to a specific focus on clinical DSIs as an initial starting point for the revised criterion.

Response. We appreciate the comment and the concern. Our definition for Predictive DSI includes technology that supports decision-making based on both models and algorithms that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. We understand that not all interested parties share the same conception of how an algorithm is related to a model or vice versa. Regardless, the existence of an algorithm in or as part of a technology is not, alone, determinative in meeting our definition for Predictive DSI. In addition to including an algorithm, a technology must also support decision-making based on the algorithm and that algorithm must derive, or learn, relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. We also decline to limit the scope of our definition to focus on clinical uses as previously discussed in this section.

Attestation for Predictive Decision Support Interventions

In proposed § 170.315(b)(11)(v)(A), at 88 FR 23786, we proposed that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) attest “yes” or “no” to whether their Health IT Module enables or interfaces with Predictive DSIs based on any of the data expressed in the standards in § 170.213. This attestation requirement would have the effect of permitting developers of certified health IT to certify to § 170.315(b)(11) without requiring their Health IT Modules to enable or interface with Predictive DSIs. However, for those developers of certified health IT that attest “yes” as described in § 170.315(b)(11)(v)(A), we described in the HTI–1 Proposed Rule additional applicable requirements related to source attributes and IRM practices (88 FR 23786).

We clarified that “enables” means that the developer of certified health IT has the technical capability to support a predictive model or DSI within the developer's Health IT Module. We clarified that applications developed by other parties and self-developed applications that are used within or as a part of a Health IT Module would mean that the Health IT Module is considered to “enable” Predictive DSIs. We provided an example, stating that if the calculations or processing for a Predictive DSI occur within the Health IT Module, either through a standalone application developed by an other party or an application self-developed by a developer of certified health IT for use within a Health IT Module, we would consider this “enabling.” In contrast, we clarified that “interfaces with” means that the Health IT Module facilitates either (1) the launch of a predictive model or DSI or (2) the delivery of a predictive model or DSI output(s) to users when such a predictive model or DSI resides outside of the Health IT Module and provided examples. We noted that some organizations may use USCDI data exported or sourced from a certified Health IT Module to develop data-driven advanced analytics leveraging predictive models or technologies to provide insights for healthcare. We also noted that in such circumstances, our proposed requirements would only apply if the output of the predictive model subsequently interfaced with a Health IT Module. The proposed requirement would not establish requirements for predictive technologies that are not enabled or do not interface with a Health IT Module.

Finally, we clarified that other parties includes any party that develops a DSI, a model, or an algorithm that is used by a DSI and is not a developer of certified health IT (88 FR 23796). We said these other parties could include, but are not limited to: a customer of the developer of certified health IT, such as an individual health care provider, provider group, hospital, health system, academic medical center, or integrated delivery network; a third-party software developer, such as those that publish or sell medical content or literature used by a DSI; or researchers and data scientists, such as those who develop a model or algorithm that is used by a DSI.

Comments. Commenters were generally supportive of the proposal to enable Health IT Modules to be certified to § 170.315(b)(11) without the health IT developer being obligated to provide Predictive DSIs to their customers by having developers of certified health IT attest “yes” or “no” to whether their Health IT Module enables or interfaces with Predictive DSIs based on any of the data expressed in the standards in § 170.213. Commenters requested that we reflect that health IT developers would not be compelled to provide (or author) Predictive DSIs due to the attestation statements adopted in this provision.

Notwithstanding the general support, many commenters did not support the “enables or interfaces with,” construct associated with the attestation proposed in § 170.315(b)(11)(v)(A). Many commenters noted that the “enables or interfaces with,” scope was a vague, ambiguous, and problematic phrase when applied to the proposed definition for Predictive DSI. Commenters, specifically health IT developers, were concerned that it would be hard to comply with the “enables or interfaces with” scope on which conditional requirements for source attributes and IRM practice requirements would rely. Commenters requested that we further define and narrow the scope of “enables or interfaces with,” and commenters stated that ONC should clearly define the scope of activities or technologies to which the related requirements for source attributes and IRM practices apply. For example, some commenters suggested that source attribute and IRM practice requirements should only apply in specific situations, such as when entities have contracts specifically covering the enablement and use of such technologies. Commenters also expressed substantive concerns that the phrase “enables or interfaces with” would require health IT developers to meet the transparency requirements for all third-party apps that customers utilize via § 170.315(g)(10) technology. They also stated that it would be difficult for developers to know when these third-party apps “enable or interfaced with” their Health IT Module and difficult to require third parties to provide source attributes information, particularly when there is no contractual relationship between the health IT developer and those third parties.

Taken together and as we looked at the substance of comments comprehensively, we noticed that commenters described circumstances that would otherwise make the original intent behind the attestation proposal moot. Instead of enabling a health IT developer that did not provide or author Predictive DSIs to meet the attestation for proposed § 170.315(b)(11)(v) by attesting “no” regarding their support for Predictive DSIs, many developers appeared to convey that they would need to attest “yes” because of their understanding of the proposed scope for “enable or interface with.” This was because they interpreted our proposal for “enable or interface with” to include their accountability for customer actions associated with Predictive DSIs, which would not necessarily be known at the time of certification and, as a result, the developer of certified health IT would have to err on the side of expecting that one of their customers would enable or interface their Health IT Module with a Predictive DSI. In short, we understood from commenter feedback that developers of certified health IT could not reasonably validate whether customers were using Health IT Modules to enable or interface with Predictive DSIs.

On the whole, commenters contended that our proposal included ambiguities and challenges related to implementation, knowledge, and ongoing compliance. The latter of which would be the most difficult for developers of certified health IT based on what we had proposed. For example, if under our proposal, a developer had attested “no” and then months later a single customer had “enabled or interfaced with” an other party Predictive DSI with the developer's Health IT Module (certified to § 170.315(b)(11)), it was unclear whether the developer would need to reengage its ONC–ACB to change its certificate for § 170.315(b)(11) and attest “yes” and take on the additional compliance requirements. Comments also made clear that we should seek to minimize and separate how independent customer actions and decisions associated with Predictive DSIs interplay with conditional compliance requirements for developers of certified health IT under the Program.

Response. We appreciate commenters' feedback on the attestation proposal, its construction within the criterion at § 170.315(b)(11), and how to make it more implementable. In summary, the intent behind the proposed attestation statement and its associated framing was to establish a conditional approach whereby developers of certified health IT certifying to § 170.315(b)(11) would still be able to get certified to § 170.315(b)(11) even if their Health IT Module did not enable or interface with a Predictive DSI. We had hoped that this would relieve specific regulatory burdens for developers of certified health IT that had no intention to enable or interface with a Predictive DSI. However, as commenters pointed out, because of the broad scope of “enable or interfaced with” even those developers that could have plausibly attested “no” may still have felt it necessary to attest “yes” when seeking certification. Despite not knowing of customers using Health IT Modules to enable or interface with a Predictive DSI, these developers of certified health IT would need to attest “yes” as soon as single customer used their certified Health IT Module to enable or interface with a Predictive DSI. We interpreted these developer compliance concerns, about whether they would know if a customer had enabled or interfaced a Predictive DSI with their Health IT Module, as an important implementation issue and necessary to address as part of this final rule.

In consideration of these and similar comments, we have not adopted the attestation statement we proposed in § 170.315(b)(11)(v). Given the circumstances and concerns described by commenters, we have concluded that accurate attestations, relieved burden, and clear (initial and ongoing) compliance would not have been accomplished as proposed. Rather than adopt an attestation statement, we have finalized minimal, uniform requirements for all Health IT Modules certified to § 170.315(b)(11) while also maintaining a construction that enables a developer of certified health IT to certify a Health IT Module to § 170.315(b)(11) without being obligated to author, develop, or otherwise directly provide Predictive DSIs to their customers. In response to comments, we believe this synthesized approach provides developers of certified health IT with clear policy and layered compliance requirements that are specifically within the scope of the Program and that of the developer's control ( i.e., a customer's action will not create any corresponding compliance impact on a developer's § 170.315(b)(11) compliance).

As described throughout this section, we have removed “enabled or interfaced with” and replaced it with “supplied by.” The final rule's scope places the knowledge, decision, and ongoing compliance associated with including a Predictive DSI solely within the control of a developer of certified health IT. While the use of “supplied by” is a different configuration nexus than the proposed attestation statement that used “enables or interfaces with,” this approach similarly addresses our intent to only apply additional Predictive DSI related stewardship responsibilities to health IT developers who supply Predictive DSIs as part of their Health IT Module. The paragraphs that follow illustrate by way of final certification criterion requirements some of the changes we have made in response to comments associated with the certification criterion's focus on Predictive DSI's “supplied by” the health IT developer and the corresponding effect of not finalizing the attestation. We believe the finalized requirements provide much more certainty for health IT developers while still addressing our overall policy goal for § 170.315(b)(11)—to provide as part of the Program greater transparency associated with DSIs, particularly Predictive DSIs and their ability to be FAVES.

First, we have adopted requirements in § 170.315(b)(11)(iii), described previously in this final rule, that enables a limited set of identified users to select ( i.e., activate) electronic DSIs that are evidence-based in (b)(11)(iii)(A) and predictive in (b)(11)(iii)(B). We believe that this uniform requirement to enable the selection of a Predictive DSI represents a minimal level of effort beyond, and a slight modification to, what developers of certified health IT would have had to do if we had finalized the “no,” attestation. Such developers of certified health IT would have had to enable selection of evidence-based DSIs and supported source attribute fields for evidence-based DSIs. As stated previously, enabling the selection of Predictive DSIs would likely be operationalized through the same technical means as enabling selection of an evidence-based DSI. Additionally, and in acknowledgement of our proposed rule discussion that requirements for DSI configuration in § 170.315(b)(11)(ii) applied to both evidence-based DSIs and Predictive DSIs (88 FR 23783), we believe that Health IT Modules certified to § 170.315(b)(11) would have baseline expectations to support both user configuration of Predictive DSIs and user selection of Predictive DSIs. Finally, we believe that software development of fields to support source attributes (in § 170.315(b)(11)(v)(B)) for Predictive DSIs would likely not be substantially more burdensome than the work necessary to develop fields to support evidence-based DSI source attributes (in § 170.315(b)(11)(A)).

Second, the finalization of § 170.315(b)(11) without an attestation statement but with uniform requirements for users to configure and have the technical capability to select both evidence-based and Predictive DSIs achieves a policy goal to ensure that users have equal technical capabilities to access, record, and change Predictive DSI source attributes in § 170.315(b)(11)(v)(B) for Predictive DSIs they self-develop and for Predictive DSIs they purchase from other parties, in addition to potential Predictive DSIs supplied by the users' developer of certified health IT. Under the proposed attestation statement with the enables or interfaces with configuration nexus, users of Health IT Modules that attested “no,” would have technical challenges to use self- developed or other party- developed Predictive DSIs. This is because Predictive DSI-related source attribute fields (proposed in § 170.315(b)(11)(vi)(C)) and Predictive DSI-related capabilities to author and revise source attributes (proposed in § 170.315(b)(11)(vi)(E)) would not have been required for those “no attestation” Health IT Modules to support. We believe that as the market for Predictive DSIs grows, equivalent technical capabilities for users to access, record, and change source attributes in § 170.315(b)(11)(iv) across Health IT Modules certified to § 170.315(b)(11) will be vital to promote Predictive DSIs that are FAVES.

Third, we have narrowed the focus of requirements related to providing IRM practices information on Predictive DSIs to those that are “supplied by the health IT developer as part of its Health IT Module.” This approach reduces the overall scope of technologies subject to final requirements in § 170.315(b)(11) while keeping the intent of the attestation statement we proposed. For instance, our finalized policy in § 170.315(b)(11)(vi) requires that for Predictive DSIs supplied by the developer of certified health IT as part of its Health IT Module the developer would have to address specific IRM practices associated with each Predictive DSI it supplies. As noted and similar to our intent with the “no” attestation proposal, based on the revised scope in this final rule, if a health IT developer does not supply any Predictive DSIs it will still be able to comply with § 170.315(b)(11) and will not have to meet, for example, IRM practice requirements in § 170.315(b)(11)(vi) because the health IT developer does not supply any Predictive DSIs as part of its Health IT Module. We note, however, if after certification to § 170.315(b)(11), a developer does begin to supply Predictive DSIs as part of its certified Health IT Module, it would need to comply with all applicable requirements in § 170.315(b)(11).

We interpret “supplied by” to include interventions authored or developed by the health IT developer as well as interventions authored or developed by an other party that the health IT developer includes as part of its Health IT Module, such as stated in the comments “when entities have contracts specifically covering the enablement and use of such technologies.” The concept of “supplied by” means that the developer of certified health IT has taken on stewardship and accountability for that Predictive DSI for the purposes of the Health IT Module. We interpret “as part of its Health IT Module” to mean that the developer of certified health IT has explicitly offered or provided its customers the technical capability to use or support a Predictive DSI, regardless of whether the Predictive DSI was developed by the developer of certified health IT or by an other party.

By way of example, “supplied by the health IT developer as part of its Health IT Module” would include the implementation of a publicly available predictive model, like LACE+, if a developer of certified health IT includes this Predictive DSI as part of its product and it is part of what the developer offers its customers. As another example, “supplied by the health IT developer as part of its Health IT Module” would include incorporation of an other party's LLM, or other generative AI, that meets the definition of Predictive DSI and is part of what the developer offers its customers.

From a conformance perspective, “supplied by the health IT developer as part of its Health IT Module” means that developers of certified health IT are not accountable for populating source attribute information for, or applying IRM practices, to Predictive DSIs in instances where their customers choose to deploy a self-developed Predictive DSI or an other party -developed Predictive DSI for use within their certified health IT. This is true even if the customer leverages data from the developer of certified health IT's Health IT Module and even if the output from an other party's Predictive DSI is delivered to or through a Health IT Module into a customer's clinical workflow.

We reiterate that other party means any party that develops a DSI, a model, or an algorithm that is used by a DSI, and is not the developer of certified health IT or a subsidiary of the developer of certified health IT. This is consistent with our discussion in the HTI–1 Proposed Rule on 88 FR 23796. This description of other party in this final rule preamble specifically excludes a subsidiary of a developer of certified health IT. We intend for purposes of our requirements in § 170.315(b)(11) that a subsidiary of a developer of certified health IT that develops a Predictive DSI would be considered the same as if it were the developer of certified health IT, subjecting Predictive DSIs developed by a subsidiary to the same requirements as a Predictive DSI supplied by a developer of certified health IT as part of its Health IT Module.

We note that Health IT Modules certified to § 170.315(b)(11) must support the technical capability for other party source attribute information to be entered into the Health IT Module's source attribute fields, per requirements elaborated below for final § 170.315(b)(11)(v)(B). We note that if a developer of certified health IT would like to include a capability for other parties to record source attributes into a Health IT Module in a way that shields the developer of certified health IT from having access to the other party source attributes, they may do so. However, we reiterate that developers of certified health IT are not required to receive, acquire, or otherwise obtain source attribute information for an other party's Predictive DSI unless such Predictive DSI is supplied by the developer of certified health IT as part of its Health IT Module.

Finally, and in consideration of comments received and the scope reductions we have made to this final certification criterion, we determined that a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification in 45 CFR 170.402(b) was necessary to fully implement our policy objectives and proposals. We have included in this final rule an Assurances Maintenance of Certification requirement that reinforces a certified health IT developer's ongoing responsibility in § 170.315(b)(11)(v)(A)( 1) to enable user access to updated descriptions of source attribute information at § 170.315(b)(11)(iv)(A) and (B), to review and update as necessary IRM practices that must be applied for each Predictive DSI the health IT developer supplies as part of its Health IT Module in § 170.315(b)(11)(vi), and to ensure the ongoing public accessibility of updated summary IRM practice information as submitted to their ONC–ACB via hyperlink in § 170.523(f)(1)(xxi).

This Maintenance of Certification requirement is a § 170.315(b)(11)-specific instantiation of general Program requirements described in § 170.402(a) as well as an adaptation of what we proposed at § 170.315(b)(11)(vii)(D), which proposed to establish an “annual and, as necessary, update” requirement for developers with Health IT Modules certified to § 170.315(b)(11) (88 FR 23805). In consideration of comments received on § 170.315(b)(11) as a whole and the corresponding changes we made to the final certification criterion to focus on Health IT Module capabilities, it became clear that the ongoing transparency of source attribute and IRM practices associated with § 170.315(b)(11) would best fit under the Program as a developer-level responsibility compared to a product-level responsibility. As such, it made the most sense to shift the nature of these proposals from the more technical certification criterion to the Assurances Condition. Accordingly, we have finalized at § 170.402(b)(4) that starting January 1, 2025, and on an ongoing basis, developers of Health IT Modules certified to § 170.315(b)(11) must review and update, as necessary, source attribute information in § 170.315(b)(11)(iv)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi).

First, we have finalized this Maintenance of Certification requirement to serve as a discrete connection for developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) to have complete and up-to-date descriptions of source attribute information (in § 170.315(b)(11)(iv)(A) and (B)) at the time of certification and on an ongoing basis while their Health IT Module is certified to § 170.315(b)(11). This Maintenance of Certification requirement builds on three existing Assurances Condition of Certification requirements at § 170.402(a)(1), (2) and (3), respectively, stating that a health IT developer must provide assurances to the Secretary that it “. . . will not take . . . any other action that may inhibit the appropriate exchange, access, and use of electronic health information,” “must ensure that its health IT certified under the ONC Health IT Certification Program conforms to the full scope of the certification criteria,” and “must not take any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the full scope of the technology's certification.” While we believe these existing requirements within the Assurance Condition pertain to both evidence-based and Predictive DSIs, as well as IRM practices, we believe this specific additional Maintenance of Certification requirement is necessary because of the unique, evolving, and dynamic nature of DSIs. Moreover, it is important for users of health IT certified to § 170.315(b)(11) as well as the Secretary to have as an explicit assurance that developers of certified health IT are keeping source attribute information up-to-date and, as applicable, that such developers are committed to IRM practices.

For example, both evidence-based and Predictive DSIs use EHI as key input data in underlying rules and models. Supplying DSIs without accompanying accurate and up-to-date documentation could inhibit the appropriate use of EHI in two ways. First, it could lead the health IT developer's customers to fail to use the DSI in appropriate ways, most obviously by omission of an updated statement of the DSI's intended use as required at § 170.315(b)(11)(iv)(B)( 2)( i). Similarly, supplying DSIs without accompanying documentation could lead to the use of a DSI on unintended populations, on individuals from groups for which the DSI does not perform adequately, or by leading to the use of a DSI for which associated risks have not been appropriately identified and mitigated. Further, supplying a DSI without accompanying documentation could inhibit the selection and use of a DSI that would make appropriate use of EHI. Without information on the DSI supplied by the developer of certified health IT, users will not be able to adequately determine whether the developer of certified health IT's supplied DSI is fit for their purpose, or whether they should select a more effective DSI.

While we believe that, under our proposal, developers of certified health IT would have taken actions to continually maintain information associated with DSIs and IRM practices, in accordance with Assurances requirements in § 170.402(a)(1), (2), and (3), this Maintenance of Certification requirement adds necessary specificity to the overall Assurances Condition of Certification and ensures that developers of certified health IT are firmly aware of their ongoing obligations associated with the certification criterion at § 170.315(b)(11). Moreover, this Maintenance of Certification requirement ensures that actions taken by the developer of certified health IT enable a user to access § 170.315(b)(11)-related documentation on an ongoing basis will not inhibit the appropriate use of EHI. In establishing this Maintenance of Certification requirement, we address acute transparency concerns from public comments regarding the accuracy, relevance, and timeliness of the source attribute information provided by the developers of certified health IT. As reflected in several source attributes seeking information on the ongoing maintenance of intervention implementation and use, and in particular the validity and fairness of predictions in local data, models and data used to drive Predictive DSIs will change over time (88 FR 23792); if developers of certified health IT do not continue to keep associated attribute information up to date, their failure to do so could have adverse impacts on user trust, accuracy, usage, and safety.

Second, we have finalized in this Maintenance of Certification requirement that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) review and update as necessary risk management practices described in § 170.315(b)(11)(vi). This is substantially similar to what we proposed at § 170.315(b)(11)(vii)(D), which was to review annually and, as necessary, update IRM practice documentation. We discuss comments received to proposed § 170.315(b)(11)(vii)(D) further in this final rule preamble.

Last, we have finalized in this Maintenance of Certification requirement that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) review and update as necessary summary information provided to the developer's ONC–ACB, consistent with what we proposed at § 170.315(b)(11)(vii)(C), which required that summary information be submitted to the health IT developer's ONC–ACB via publicly accessible hyperlink, as well as what we proposed at § 170.523(f)(xxi), which required ONC–ACBs to ensure that all of the information required to be submitted by the health IT developer to meet IRM requirements in § 170.315(b)(11)(vii)(C) were available via public hyperlink. We discuss comments received to proposed § 170.315(b)(11)(vii)(C) and § 170.523(f)(xxi) further in this final rule preamble.

Comments. While some commenters agreed with and were supportive of the proposed definition and our explanation of the differences between “Enables” and “Interfaces with,” several commenters expressed concern that the proposed phrase “enables or interfaces with” was overly broad when applied to the proposed definition for Predictive DSI and requested that we further define and narrow the scope of these terms. These commenters stated that ONC should clearly define the scope of activities or technologies that “enable or interface with” Predictive DSIs to narrow the scope of this requirement to make it clear that the HTI–1 Proposed Rule applies in situations such as, for example, when entities have contracts specifically covering the enablement and use of such technologies. Commenters also expressed concern that the phrase “enables or interfaces with” would require health IT developers to meet the transparency requirements for all third-party apps that customers utilize via § 170.315(g)(10) technology, and that it would be difficult for developers to require third parties to provide source attributes information, particularly when there is no contractual relationship between the health IT developer and other party developers.

Response. We appreciate the comments and have modified our final scope for Health IT Modules that must provide source attribute information and our scope for which Predictive DSIs must be subject to IRM practices in response to public comment. We understand through public comments that interested parties viewed the scope contingent on “enables or interfaces with” as too broad and ambiguous, especially given that the scope of these terms would impact conditional requirements related to source attributes and risk management by way of the proposed attestation in § 170.315(b)(11)(v). In considering alternative constructions that would clarify our intent and in consideration of commenters' concerns, we have finalized a construction that narrows and replaces the two concepts of “enables,” and “interfaces with,” with “supplied by.” This modification is reflected in the finalized text of § 170.315(b)(11)(v) and regulatory text in § 170.315(b)(11)(vi) to establish conditional requirements for Health IT Modules that include an other party's Predictive DSI that is supplied by the health IT developer.

For example, if a user ordered a lab test using the existing certification criterion capability for computerized provider order entry-laboratory (§ 170.315(a)(3)) and the lab test result was derived from a Predictive DSI used by the laboratory, such a configuration would be out of scope and the Health IT Module would not subject to the requirements in § 170.315(b)(11)(v), because the Predictive DSI that rendered the lab test result was not supplied by ( i.e., included as part of the Health IT Module) the developer of the certified health IT.

We believe that these modifications significantly narrow the scope of our proposal and clarify which other party Predictive DSI configurations are subject to requirements in § 170.315(b)(11) for source attributes. We also note that the phrase “supplied by” is also included in the text of § 170.315(b)(11)(vi) to establish a conditional requirement that for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, is subject to risk analysis, risk mitigation, and governance, which we discuss more in section “xi. Intervention Risk Management (IRM)” later in this final rule. We believe that developers of certified health IT with Health IT Modules that supply an other party's Predictive DSI as part of their Health IT Module would be generally aware of and be well positioned to make source attribute information available for user review as well as apply IRM practices given the likelihood of a high degree of technical coordination and formalized business relationship between a developer of certified health IT and an other party in such scenarios.

Comments. One commenter expressed concern that the definition of Predictive DSI included the terms “interfaces with,” and “enabled by” could potentially incorporate test results generated using laboratory processes that contain algorithmic components, if the outputs of those tests are transmitted to an EHR, and requested that the definition exclude laboratory results because labs are already subject to other federal requirements and should not be subject to additional requirements due to their results being made available through an EHR.

Response. We thank the commenter for their input. However, we clarify that neither our proposed nor final definition in § 170.102 included the terms “interfaces with,” or “enabled by.” These terms of art were used in the HTI–1 Proposed Rule to establish a configuration nexus that would subject Health IT Modules to additional requirements if such Health IT Modules enabled or interfaced with a Predictive DSI. As noted above, and given that our final policy nexus is dependent on “supplied by the health IT developer as part of its Health IT Module,” we note that if the test result is generated by a Predictive DSI used by the lab itself for the generation of results but the Predictive DSI is not supplied by the developer of the certified Health IT Module, it would be out of scope of the requirements established by the final policy. As another example, if a user ordered a lab test using the existing certification criterion capability for Computerized provider order entry-laboratory (§ 170.315(a)(3)) and the lab test result was derived from a Predictive DSI used by the laboratory, such a configuration would be out of scope and the Health IT Module would not subject to the requirements in § 170.315(b)(11), because the Predictive DSI that rendered the lab test result was not supplied by the health IT developer as part of its Health IT Module.

vi. Source Attributes

At 88 FR 23787, we proposed in § 170.315(b)(11)(vi) that Health IT Modules certified to § 170.315(b)(11) enable a user to review a plain language description of source attribute information as indicated at a minimum via direct display, drill down, or link out from a Health IT Module. We noted that § 170.315(g)(3) “safety-enhanced design,” applies to the existing § 170.315(a)(9) criterion and in keeping with that applicability, we proposed that safety-enhanced and user-centered design processes described in § 170.315(g)(3) would apply to the new certification criterion proposed in § 170.315(b)(11) as well. We proposed to update § 170.315(g)(3) accordingly to reference the proposed § 170.315(b)(11).

Comments. Commenters were generally split on supporting or not supporting the proposal in § 170.315(b)(11)(vi) that Health IT Modules certified to § 170.315(b)(11) enable a user to review a plain language description of source attribute information as indicated at a minimum via direct display, drill down, or link out from a Health IT Module. Those in support noted that it would have the benefit of allowing users to assess the DSI's quality and thereby enhancing trustworthiness; enable those with sufficient knowledge to understand the data to make informed purchasing decisions; and give flexibility that ensures that the recommendations and guidance provided by these systems align with the organization's unique workflows and patient populations, facilitating seamless integration into clinical practice. Several commenters agreed that user feedback can be a useful tool to support quality improvement within health IT and emphasizing transparency and customization allows healthcare organizations to tailor decision support systems to their specific needs. Other commenters urged ONC not to adopt the direct display, drill down, or link requirement observing that including too much information in the direct display can negatively impact usability and user adoption in comparison to providing rational and accessible paths to deeper information via click-paths that are based on user-centered design principles. These commenters worried that requiring “at a minimum direct display, drill down, or link out,” could unintentionally inhibit innovative user interfaces and user designs to enable user access to source attributes.

Response. We thank commenters for their support, and we note that requirements originally proposed in § 170.315(b)(11)(vi) for source attributes built off more than a decade of existing expectations for source attributes in the current CDS criterion at § 170.315(a)(9)(v) where the expectation for direct display, drill down, or link out had been described at 77 FR 54215. However, in consideration of comments, we have not finalized the requirements for source attribute information to be available via direct display, drill down, or link out from a Health IT Module. Rather we have finalized a source attributes requirement in § 170.315(b)(11)(iv) without the text “at a minimum via direct display, drill down, or link out from a Health IT Module.” While we have not finalized a requirement for presenting source attribute information to users in the regulation text at § 170.315(b)(11)(iv), we reiterate the requirement in § 170.315(b)(11)(v)(A)( 1) that Health IT Modules enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information in paragraphs § 170.315(b)(11)(iv)(A) and § 170.315(b)(11)(iv)(B). And we have also included a requirement in § 170.315(b)(11)(v)(B)( 1) to enable a limited set of identified users to record, change and access the same source attribute information. The phrase “limited set of identified users” conveys that the capability is not required for all users of the Health IT Module. Rather, that the capability can be constrained to a smaller userbase that are identified to have the privileges necessary to use the capabilities in § 170.315(b)(11), including the capability to record, change, and access source attributes and source attribute information. We have provided this flexibility so that any number and configuration of users may record, change, and access source attribute information according to organizational needs. For example, if a client of a developer of certified health IT hosts source attributes for each deployed evidence-based or Predictive DSI centrally, a Health IT Module could include a hyperlink from a dashboard or other user interface to a user at the point-of-care. Additionally, this flexibility could limit record, change, and access privileges to a user who has responsibilities for an organization's procurement and implementation decisions.

Finally, we did not receive any substantive or direct feedback regarding our proposal to update “safety-enhanced design,” to reference the certification criterion finalized in § 170.315(b)(11). We continue to believe that just as the CDS criterion in § 170.315(a)(9) was subject to safety-enhanced design requirements, so too should the revised criterion in § 170.315(b)(11). Thus, we have finalized our proposed modification to § 170.315(g)(3) “safety-enhanced design,” to reference the certification criterion finalized in § 170.315(b)(11).

Comments. Commenters requested clarity on the proposal for source attributes noting that the proposal was ambiguous as to what source attributes would need to be implemented and requested that ONC provide more clarity on the expectation of how source attributes must be implemented in a Health IT Module. Specifically, one commenter requested clarification on whether software should support source attribution when clinically appropriate, noting that many health care providers and health systems have structures in place to track appropriate source attributes. One commenter requested additional clarity on how the information being available at the point of care should be used in real time stating that most of the source attribute information will be relevant to the organization while it makes procurement and implementation decisions versus during care delivery.

Response. We appreciate the commenters' suggestions and have finalized our proposal with modifications in consideration of these and related comments. We have made several modifications to reduce the ambiguity cited by commenters related to the source attributes proposals. We have separately identified requirements related to accessing up-to-date and complete information for DSI supplied in the Health IT Module at § 170.315(b)(11)(v)(A) and requirements related to enabling customers to modify source attributes and source attribute information for DSI at § 170.315(b)(11)(v)(B). We also separately list source attribute categories for evidence-based and Predictive DSI at § 170.315(b)(11)(iv)(A) and (B), respectively. We believe that information available as source attributes will have value both as reference information to individual users evaluating the use of a DSI on an individual patient—for instance, by assessing whether it has been recently evaluated at their health system and whether it has been shown to perform well for a patient like theirs—and for the organization during procurement, implementation, and analysis.

To further address potential ambiguity about how source attributes must be implemented in Health IT Modules certified to § 170.315(b)(11), we have finalized uniform requirements in § 170.315(b)(11)(iv) for Health IT Modules to support source attributes listed at § 170.315(b)(11)(iv)(A) and (B). This means that all Health IT Modules certified to § 170.315(b)(11) must support the categories, but not necessarily the content, for each source attribute listed at § 170.315(b)(11)(iv)(A) and (B). For example, Health IT Modules must support user access to complete and up-to-date source attribute information in § 170.315(b)(11)(iv)(B) only if the Predictive DSI is supplied by the health IT developer as part of its Health IT Module.

We have provided additional specificity about the technical capabilities required to support source attributes at § 170.315(b)(11)(v). As described above, we have not finalized our proposal for an attestation statement. Rather, we have finalized in § 170.315(b)(11)(v) a set of four capabilities that Health IT Modules must support related to source attributes. Each of these capabilities was proposed in different parts of § 170.315(b)(11) in the HTI–1 Proposed Rule.

First, we have finalized requirements for “Source attribute access and modification” in § 170.315(b)(11)(v). Specifically, we finalized a requirement in § 170.315(b)(11)(v)(A)( 1) that is substantially similar to what we proposed in § 170.315(b)(11)(vi) to “Enable a user to review a plain language description of source attribute information as indicated and at a minimum via direct display, drill down, or link out from a Health IT Module . . . .” The finalized “access” requirement states in § 170.315(b)(11)(v)(A)( 1) that for evidence-based and Predictive DSIs supplied by the health IT developer, the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in § 170.315(b)(11)(iv)(A) and (B) as finalized. As discussed earlier, we have not finalized proposed requirements for Health IT Modules to make source attribute information available via direct display, drill down, or link out.

Second, we have finalized at § 170.315(b)(11)(v)(A)( 2) that for Predictive DSIs supplied by the health IT developer as part of its Health IT Module, the Health IT Module must indicate when information is not available for review for source attributes in paragraphs (b)(11)(iv)(B)( 6); (b)(11)(iv)(B)( 7)( iii), ( iv), and ( v); (b)(11)(iv)(B)( 8)( ii) and ( iv); and (b)(11)(iv)(B)( 9). This requirement is finalized as a modified version of what was proposed at § 170.315(b)(11)(vi)(D)( 1) and § 170.315(b)(11)(vi)(D)( 2), which required Health IT Modules to indicate a source attribute is missing if the source attribute included the “if available” phrase. We clarify that per conformance with this certification criterion and its associated maintenance of certification requirement adopted as part of § 170.402(b)(4), if and when information related to these source attributes are generated, the developer of certified health IT must make this information available to users. For example, if the developer of certified health IT gets newly available information on the validity of the intervention in local data (§ 170.315(b)(11)(iv)(B)( 8)( ii)) following the deployment of a Predictive DSI, that information must be made available as source attributes information to reflect up-to-date descriptions of source attributes.

Third and fourth, we have finalized two requirements related to the ability to “modify” source attributes and source attribute information at § 170.315(b)(11)(v)(B). At § 170.315(b)(11)(v)(B)( 1), we have finalized a requirement that for evidence-based DSIs and Predictive DSIs, the Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section. At § 170.315(b)(11)(v)(B)( 2) we have finalized that, for Predictive DSIs, a Health IT Module must enable a limited set of identified users to record, change, and access additional source attributes not specified in § 170.315(b)(11)(iv)(B). These requirements are substantially similar to what we proposed in § 170.315(b)(11)(vi)(E) while retaining the ability to access or review this information as would have been required in proposed § 170.315(b)(11)(v). In proposed § 170.315(b)(11)(vi)(E) we proposed that a Health IT Module must enable a limited set of identified users to “author and revise,” source attribute information beyond source attributes listed. We note that the capability to record and change replaces the proposed capability to author and revise.

Comments. Commenters requested guidance on the level of detail required in these descriptions and specification of “plain language descriptions” for which audience ( e.g., developers, clinicians, and other end-users) and guidelines on how to present this information, noting the concern that a user may have difficulty finding the required documentation depending on how the interface is designed. Commenters expressed concern that the proposal to enable a user to review a plain language description of source attribute information could result in legal liability and vulnerability for clinicians and health care providers, underscoring the need that the information provided in the new source attributes for Predictive DSI are useful and understandable.

Response. We thank commenters for their concerns. We note that requirements related to a plain language description are now included at § 170.315(b)(11)(v)(A)( 1). When we indicate “plain language description,” we mean language that the intended audience can readily understand and use because that language is clear, concise, well-organized, accurately describes the information, and follows other best practices of plain language writing. We encourage model developers to consider what information would be useful for users to determine if a Predictive DSI is FAVES without providing difficult to understand technical details. We agree that providing this information in a useful form will be essential. Comments regarding legal liability are outside the scope of this rulemaking. Therefore, we decline to finalize any such change.

Comments. One commenter requested clarity regarding cases where third-party IT that is enabled or interfaced with certified health IT but is modified by users or a different third-party developer such that the added functionality results in the generation of a Predictive DSI, and whether such cases would be subject to conditional requirements for source attributes listed in § 170.315(b)(11)(vi)(A) and deployment of or engagement in intervention risk management practices discussed in § 170.315(b)(11)(vii).

Response. In a scenario where an other party technology is modified by a different other party (e.g., users or a different third-party developer) such that the initial technology meets the definition of a Predictive DSI, we would categorize the modified technology as a Predictive DSI developed by an other party. A Health IT Module may be expected to have the technical capability for users to record, change and access source attributes of this modified technology, and may be expected to provide up-to-date source attribute information if the Predictive DSI is supplied by the developer of certified health IT as part of the Health IT Module.

vii. Source Attributes—Demographic, SDOH, and Health Status Assessment Data Use

We proposed at 88 FR 23787 to include as source attributes in § 170.315(b)(11)(vi)(A)( 1) through ( 4) the source attributes currently found in § 170.315(a)(9)(v)(A)( 1) through ( 4). Additionally, we proposed that the use of three additional specific types of data in a DSI be included as source attributes in § 170.315(b)(11)(vi)(A)—Demographic data elements in § 170.315(b)(11)(vi)(A)( 5), SDOH data elements in § 170.315(b)(11)(vi)(A)( 6), and Health Status Assessment data elements in § 170.315(b)(11)(vi)(A)( 7). We noted at 88 FR 23787 that “types of data in a DSI” means that the DSI includes any of these data as inputs or otherwise expressly rely on any of these data in generating an output or outputs. We explained that by proposing to modify the source attributes as part of proposed § 170.315(b)(11)(vi)(A) relative to the existing attributes in § 170.315(a)(9)(v)(A), we expected that information would be made available to users if the specific data elements within these three data categories were used in the DSI.

Context note. We note for readers that while all of the proposals just summarized were part of proposed § 170.315(b)(11)(vi), we have finalized modified versions of these requirements as part of § 170.315(b)(11)(iv)(A). As a result, we discuss the finalized requirements with that context in mind.

Comments. The majority of commenters supported the proposal to include the requirement that certified Health IT Modules should provide users with source attributes for DSI, including the three additional specific types of data of demographic, SDOH, and health status assessment data elements. These commenters stated that it would have the benefit of enabling individuals and organizations to understand the nature of certified health IT, whether there are inherent biases, and how best to use the technology for a specific patient population. Commenters also stated that requiring developers of certified health IT to report on these data elements' inclusion will assist providers in both ensuring the whole patient is cared for and that there is transparency as part of that whole-person care. Commenters noted that the proposed requirements would address pressing concerns that AI algorithms can reinforce biases related to socioeconomic status, race, ethnicity, sexual orientation, gender identity, sex, and other identities and conditions, observing that recent advances in AI stand to potentially harm patients by reinforcing implicit and explicit biases that do not reflect the diverse population of America and that may only increase health inequities. Commenters supported the public transparency requirements for source attribute information as an important measure to avoid exacerbating these inequities.

A minority of commenters did not support the proposal stating that the HTI–1 Proposed Rule would create significant implementation burden with unclear benefits. One commenter suggested that the HTI–1 Proposed Rule may also paradoxically increase disparities by reducing innovation and the implementation of DSIs due to increased regulatory burden. One commenter expressed concern that the preamble was unclear on what it meant for an evidence-based decision support intervention to “use” or “include” patient demographics and observations, SDOH, or health status assessments.

Response. We thank commenters for their support and agree that by highlighting when an evidence-based DSI uses patient demographics, SDOH, or health status assessments data elements, users are empowered to interrogate and ensure that the DSI is appropriate. We believe that identification of race, ethnicity, language, age (date of birth), sexual orientation, gender information, SDOH, and health status assessments, such as disability, data elements, if included as part of an evidence-based DSI, would greatly improve the possibility of identifying and mitigating the risks of employing evidence-based DSIs for patient care, including those related to exacerbating racial disparities and promoting bias. We believe that this requirement represents a low burden that is unlikely to reduce innovation and implementation of DSIs. We also thank commenters for identifying ambiguities in what it means for an evidence-based decision support intervention to “use” or “include” these data elements. We clarify that our intention is to enable a user to understand if one or more of these data elements are included as inputs or otherwise expressly relied upon to generate an output in an evidence-based DSI. We also intend that, if the data elements are included, the user is informed which one(s) are used in the evidence-based DSI. This means that a user must be able to review whether a data element relevant to those categories in § 170.315(b)(11)(iv)(A)( 5)–( 13) (as expressed by the standards in § 170.213) is used in the evidence-based DSI, and if so, which specific data element or elements are used in the evidence-based DSI.

We do not prescribe how this information is communicated to a user, nor do we prescribe a minimum level of context at this time. For example, we do not require that a source attribute indicating the use of an SDOH data element in § 170.315(b)(11)(iv)(A)( 6) must describe how the data element is used as part of the evidence-based DSI. Instead, we require a Health IT Module to enable a user to review whether an SDOH data element is used as part of the evidence-based DSI and which SDOH data element (as expressed by the standards in § 170.213) is used as part of the evidence-based DSI.

After consideration of comments, we have finalized as part of § 170.315(b)(11)(iv)(A) patient demographic, SDOH, and health status assessment data elements in § 170.315(b)(11)(iv)(A)( 5) through ( 13) as expressed in the standards in § 170.213. We note that, consistent with the dates established in § 170.213, compliance with USCDI v1 will be required to initially meet this certification criterion until compliance with USCDI v3 becomes required as part of this certification criterion ( i.e., January 1, 2026). As a result, for the first compliance date associated with § 170.315(b)(11) a Health IT Module may include, but is not required to include, identification of the use of patient demographic data elements that are only found in USCDI v3 as part of evidence-based DSIs in § 170.315(b)(11)(iv)(A)( 5)–( 13).

Comments. Several commenters responded to our solicitation for comment on whether we should require a certain format or order in which these source attributes must appear to users. Commenters noted that the proposed source attribute requirements would require each organization to craft their own documentation process and suggested that ONC collaborate with interested parties to implement and refine a standards-based approach for capturing and sharing source attributes, including sharing both machine-readable and human-readable tables/lists of DSI source attribute information. Commenters also observed that requiring information about DSIs to be submitted in a standard format will focus the scope of the information disclosed, create consistency in the kind of information shared about these AI tools, and contribute to a presentation of this information for end users that is repeatable and digestible. Commenters noted that without a standardization and strategic placement, providers moving across organizations will experience the added stress of learning each organization's method of addressing DSI, compounding burden. One commenter supported including HL7 consensus-based implementation guides for AI information, and another commenter recommended that ONC should produce a document format for DSI developers to use in conveying information to EHR developers and interface specialists. One commenter suggested that there are two common ways to present this type of long list of data: alphabetically or by type (often organized alphabetically underneath each category) and recommended categorizing by type of data then presenting each list therein alphabetically. For example: Demographic Data: date of birth, race, sex Health Status: disability status, smoking status.

One commenter observed that to implement a standardized format may be burdensome for health IT developers but also will be beneficial to reduce bias in decision making and will encourage smaller, third-party applications to be more transparent and responsible in their development, stating that there are potential benefits to requiring documentation of what a clinical decision support algorithm does, and provides certainty that a level of testing and trials has been done to ensure the relevance and accuracy of the model.

Response. We appreciate the comments received regarding a standardized format for source attribute information. We noted in the HTI–1 Proposed Rule that we were not aware of widely agreed upon best practices for the format in which these elements or source attributes information should be displayed. We are also not aware of a consensus-based standardized format that might best meet the objective described by the commenter to reduce bias in decisions making. However, we are aware of industry efforts to standardize a format to display information about technology in the form of a “model card” or “nutritional label” for healthcare (88 FR 23794). We did not propose a specific format for source attributes, and we decline to finalize any specific formats. We believe this represents an ideal space for interested parties across industry, academia, government, and the non-profit sector (such as SDOs and patient advocacy organizations) to collaborate. We note that part of our rationale for being flexible in the use of standardized formats and placement of source attributes within users' workflows is precisely because there is a lack of consensus. We look forward to working with interested parties to develop consensus-based standards across numerous and far-reaching types of use cases.

viii. Source Attributes for Predictive Decision Support Interventions

At 88 FR 23788–23795, we proposed source attributes applicable for all Predictive DSIs that are enabled by or interface with certified Health IT Modules certified to § 170.315(b)(11). These source attributes were intended to provide users with greater insight into the model incorporated into a particular Predictive DSI and intended to provide information for an array of uses, including in support of so-called “model cards” or algorithm “nutrition labels” that have been described by others. This proposed requirement applied to developers of certified health IT that attest “yes” in § 170.315(b)(11)(v)(A).

We noted that the proposals for source attributes would not require disclosing or sharing intellectual property (IP) existing in the developer's health IT, including other parties' IP. We reiterated that source attributes in § 170.315(b)(11)(vi) would not require disclosure of proprietary information or IP (88 FR 23788). We also noted that if developers of certified health IT would like to include a capability for other parties to record source attributes into a Health IT Module in a way that shields the developer of certified health IT from having access to the other party source attributes, they could do so, but that this was not proposed as a required technical capability within the proposed criterion.

New Source Attributes for Predictive DSI

At 88 FR 23789, we proposed to add fourteen new source attributes for Predictive DSIs that enable or interface with Health IT Modules. Consistent with our proposals in § 170.315(b)(11)(vi), we proposed that these new source attributes listed in § 170.315(b)(11)(vi)(C) would be in plain language and available for user review via direct display, drill down, or link out from a Health IT Module certified to § 170.315(b)(11) and for which the developer attested “yes” in § 170.315(b)(11)(v)(A).

We clarified that we proposed to require that developers must enable a user to review a plain language description of source attribute information as indicated and at a minimum via direct display, drill down, or link out from a Health IT Module and that information on these source attributes must be provided by the developer of certified health IT unless the attribute contained the phrase “if available” (discussed at 88 FR 23789) or was developed by an other party, as proposed at § 170.315(b)(11)(vi)(D) discussed at 88 FR 23795–23796.

Context note. We note for readers that while all of the proposals just summarized were part of proposed § 170.315(b)(11)(vi)(C), we have finalized modified versions of these requirements as part of § 170.315(b)(11)(iv)(B). As a result, we discuss the finalized requirements with that context in mind.

Comments. Commenters were mixed in their support or opposition to requirements for source attributes for Predictive DSI, with those in support noting that it would create greater transparency for patients and providers that is key to building trust in AI. Commenters who were supportive noted that it would be critical for the end user to understand how a Predictive DSI is developed, evaluated, and how it should be used appropriately. Commenters also noted that health care providers would benefit because transparency promotes the exercise of a provider's judgment at the point of care, which can help avoid errors and mitigate algorithmic biases, and that source attributes will help organizations make informed decisions around potential implementation. One commenter noted that complex predictive models that incorporate difficult-to-observe validity or fairness issues may lead to harm if left unchecked, resulting in bias that can lead to decisions that can have a collective, disparate impact on certain groups of people even without the programmer's intention to discriminate.

Response. We thank commenters for their feedback and their support. As expressed in our proposals for § 170.315(b)(11), we believe that transparency is a prerequisite for high-quality Predictive DSIs to be trusted by clinicians, patients, health systems, software developers, and other interested parties. We believe that transparency can help to reduce the harm of complex predictive models by informing the use, disuse, updating or decommissioning of such models. As described in more detail below, we have finalized in § 170.315(b)(11)(iv)(B) modified versions of our proposals for Predictive DSI-specific source attributes.

Comments. Several commenters did not support our proposal, with many expressing concerns that our proposal is too prescriptive and limiting to industry innovation, the source attribute categories and disclosure requirements create unnecessary burden on health IT developers and providers, and stifle competition. Several commenters were concerned that the proposed source attribute disclosure requirements could compromise patient privacy and requested clarification on the granularity of data elements that developers must disclose. Commenters recommended ONC limit the type of data that is made publicly available from high-impact DSIs to protect patient information privacy and security and safeguard protected health information (“PHI”) or sensitive data.

Response. We respectfully disagree with these commenters. In developing proposed source attributes for Predictive DSIs, we sought a balance between limited prescriptiveness and sufficient detail to enable thorough transparency of source attribute information to users. Our selection of the proposed attributes was guided by reviews of existing model reporting guidelines, including seventeen different sets of industry- and academia-developed recommendations for information to be reported on models and related standards. ¹¹⁷ Because these guidelines are designed to support innovation and competition in the development and validation of predictive models in the academic literature, we believe that their use will similarly leave sufficient space for innovation by a variety of entities. In our review, we emphasized attributes that: (1) were most commonly included in the reviewed reporting guidelines; (2) we believed would be most interpretable by both health IT professionals and users; (3) were focused on identifying issues of bias; and (4) were intended to show that the model would perform effectively outside of the specific context in which it was developed. In finalizing Predictive DSI source attributes in § 170.315(b)(11)(iv)(B), we have provided information on what we believe should be included in each attribute based on our understanding of the current best practices in this area. However, given the varied technologies, applications, and contexts in which Predictive DSIs may be used, we have sought to keep requirements sufficiently flexible to meet varied use cases. We note that under that this policy establishes different requirements for developers of certified health IT that supply Predictive DSIs versus those certified health IT developers that do not supply Predictive DSIs. Many developers of certified health IT that do not supply a Predictive DSI as part of their Health IT Module are among those developers with smaller revenues and fewer clients. These developers will be able to certify to the criterion at § 170.315(b)(11) while expending limited additional development resources on products they have certified currently. Specifically, these developers will likely have no costs related to providing complete and up-to-date source attribute information for Predictive DSI supplied by the developer or engaging in risk management and annually update risk management information.

We believe that our finalized Predictive DSI source attributes strike a balance between prescriptiveness and flexibility that is necessary to foster a nascent information ecosystem that can help users understand whether the Predictive DSI they are using (as supplied by their health IT developer as part of its Health IT Module) is FAVES. Moreover, we believe these source attributes help establish a consistent transparency baseline, or foundation, especially given that we have not established requirements for specific measures. Rather, we encourage industry, academic, professional associations, and other interested parties to determine which information best fits each use case. We also do not believe that the information in source attributes creates a risk to patient privacy, given the level of detail at which information should be provided, as described in more detail in response to concerns related to intellectual property. We also note that we are affording flexibilities related to source attributes that are only required once information for them become available, such as source attributes related to validity and fairness of prediction in external and local data. We have finalized the categories of source attributes related to Predictive DSIs at § 170.315(b)(11)(iv)(B) with modifications and clarifications to source attribute category subparagraphs, described below in this final rule.

Comments. Several commenters, including health information technology companies, insurance companies, software developers, and professional trade associations, expressed concerns that providing users with access to information described as part of source attributes would expose proprietary information regarding the predictive algorithm or model and risk exposing intellectual property (IP) among other risks, including that disclosure of such information would stifle competition and innovation. Some commenters suggested ONC specify that the information in our proposals does not include confidential information such as IP. Some commenters were concerned that source attributes could enable reconstruction of the algorithm and that it would create a power imbalance between small and startup “ other parties” and large incumbent developers of certified health IT, which could either refuse to display source attributes from other parties or use information in those source attributes inappropriately. While many commenters were vague in their concerns related to revealing IP and trade secrets a small number of commenters identified the “Intervention Development” category of source attributes as problematic and another commenter noted that the output of the intervention would constitute IP. During further fact-finding, commenters mentioned specific concerns around source attribute information on how input and output variables were identified, as well as the model parameters, hyperparameters, or the results of tuning, which they described as crucial pieces of intellectual property, proprietary information, or trade secrets. Another commenter included “model type, target definition (intended use), and inputs” as information that could include IP or proprietary information.

Several commenters suggested ways to mitigate IP and proprietary information concerns, including listing data classes instead of data elements used in the algorithm; limiting source attribute information to summary information for high-risk use cases only; limiting source attribute requirements to algorithms developed by developers of certified health IT; requiring only links to DSIs centrally supported by a government-sponsored resource and to information maintained by the FDA if the DSI is regulated as a medical device; and giving developers the ability to exclude or redact source attribute information they considered proprietary.

Response. As described in detail below, we respectfully disagree with the claims that our proposed, and now final, requirements for source attributes in § 170.315(b)(11)(iv)(B) would result in disclosures of IP, trade secrets, or proprietary information. Nor do we believe that our requirements for source attributes would stifle competition and innovation. Given the overall scope changes and numerous clarifications offered through this final rule to narrow health IT developer's scope of responsibilities (to only those Predictive DSIs that are supplied as part of its Health IT Module) we believe we have substantively address commenters' concerns regarding exposure of proprietary information to other parties as well as exposure to proprietary information originating from other parties. Additionally, we believe that the transparency needs are so acute for Predictive DSIs that the public benefit outweighs any remaining concerns. Overall, we anticipate that better information regarding Predictive DSIs will bolster the use of high-quality, fair, appropriate, valid, effective, and safe predictive algorithms across the healthcare landscape.

First, we do not agree that the information we require for Predictive DSI source attributes is new or novel within the healthcare context, presenting authors of Predictive DSIs with new or novel concerns related to IP or proprietary information. We note that we analyzed and drew from more than a dozen widely accepted and used reporting guidelines, used by researchers and developers to demonstrate the validity of algorithms in peer-reviewed literature. We believe that much of the same information required for publication by the New England Journal of Medicine or the Journal of the American Medical Association, for example, ought to be routinely and consistently available for user review to improve the trustworthiness of Predictive DSIs. We note that some reporting guidelines, from which we draw our own source attributes, have more than 15,000 citations across peer-reviewed, academic literature.

Second, we have clarified the scope of our requirements by adding detail to the information expected as part of source attributes in what is now finalized at § 170.315(b)(11)(iv)(B). We note that these explicit requirements in regulation text mirror the requirements described previously in preamble or represent a subset of requirements previously described in preamble. The information required in source attributes is not intended to include detailed information on model parameters, hyperparameters, detailed specifics around how input or output variables are defined, transformed, or otherwise operationalized. We do not believe that information at that level of detail is necessary for source attributes in § 170.315(b)(11)(iv)(B) or necessary for users of a Predictive DSI to determine whether it is fair, appropriate, valid, effective, and safe.

Third, as it relates to “Intervention Development,” source attributes, which include input features, such as exclusion and inclusion criteria that influenced the data set; use of race, ethnicity, language (REL), SDOH, and health assessment variables as input features; and a description of relevance of training data to intended deployed setting, we note that these source attributes are important to give users a sense of whether they ought to use the Predictive DSI on an individual in front of them, or on individuals generally seen within the user's organization. Understanding whether specific input features, such as race, sex, or food insecurity is part of the training data set for a Predictive DSI could present a user with critical information on its relevance and validity to individual patients or patient cohorts for which the Predictive DSI is being applied. We further ask in § 170.315(b)(11)(iv)(B)( 4)( iii) for some sense of how representative demographic variables are within a Predictive DSI's training data set, which could be equally important if the Predictive DSI was trained on data dominated by one racial group and applied to a different group.

To further mitigate concerns around IP, we have limited the input features that must be included to those listed at § 170.315(b)(11)(iv)(A)( 5)–( 13). We understand that resources are expended to identify and operationalize numerous input features to improve Predictive DSI performance. We believe this list narrows the scope of features that must be reported and addresses concerns about revealing IP underlying curation of input features more broadly. Furthermore, in developing information for source attributes, we encourage model developers to consider the level of information that would be useful for health systems and end users to best determine if a Predictive DSI is FAVES without providing difficult to understand technical details that might reveal trade secretes or proprietary information. We also reiterate that information provided should be described in plain language, as stated at § 170.315(b)(11)(v)(A)( 1).

We disagree with commenters concerns that identifying the output of the intervention would constitute IP. We provided an example of a prediction of the likelihood that an individual will be readmitted among individuals recently discharged (88 FR 23789). We do not believe that the description of an output, at the low level of detail provided in the example, is likely to constitute intellectual property or trade secrets. We believe that a description of the output produced by the model, along with “intended use,” is foundational to understanding how the model is meant to be deployed and used.

Fourth, we appreciate the many commenters that raised IP and proprietary information concerns while also providing ways to mitigate those concerns, primarily by limiting the number or the scope of source attributes that should be available to users. Based on the scope changes to final § 170.315(b)(11) and other clarifications issued throughout this final rule, we have not finalized additional mitigation suggestions by commenters. We believe that the clarifications provided as part of this response on the level of detail required for source attributes (as well as other corresponding responses below) will sufficiently mitigate concerns related to IP.

Last, while we understand concerns raised by commenters regarding a potential to create a power imbalance between small and startup “ other parties” and large incumbent developers of certified health IT, which could either refuse to display source attributes from other parties or use information in those source attributes inappropriately, we believe our finalized scope for Predictive DSI source attributes addresses these concerns. Particularly, we note that these source attributes must be complete and up-to-date if they are supplied by the health IT developer as part of its Health IT Module. In this scenario, other party source attributes could be directly supplied to a developer certified health IT's customer (who will have both the ability to select this other party's Predictive DSI and have a Health IT Module support Predictive DSI source attribute categories for the other party's source attributes, even if their developer does not supply a Predictive DSI as part of its Health IT Module, due to requirements at § 170.315(b)(11)(iii)(B) and § 170.315(b)(11)(iv)(B)). Further, if developer of certified health IT a with Health IT Module certified to § 170.315(b)(11) would like to include a capability for other parties to record source attributes into a Health IT Module in a way that shields the developer of certified health IT from having access to the other party source attributes, the developer of certified health IT may do so.

Comments. Several commenters were concerned that our proposal requires health IT software developers to expend significant resources to gather information from numerous sources and is an unnecessary burden. Specifically, commenters noted that requiring developers of certified health IT to monitor, catalog, request information, and conduct analysis requires significant resources that will need to be redirected from development, enhancement, and assessment of its own software.

Response. We appreciate the comment and as part of this final rule we have substantially reduced the scope of the final requirements to be fully within the developer of certified health IT's purview, such that the developer will know and be able to fully estimate the resources it will need to expend to maintain complete and up-to-date source attribute information (which could be limited if, for example, the developer does not supply any Predictive DSIs as part of its Health IT Module). We appreciate the comment and as part of this final rule we have substantially reduced the scope of the finalized requirements to be fully within the developer of certified health IT's purview, such that the developer will know and be able to fully estimate the resources it will need to expend to maintain complete and up-to-date source attribute information (which could be limited if, for example, the developer does not supply any Predictive DSIs as part of it Health IT Module). We also believe that this scope and associated information is necessary for the trustworthy use of Predictive DSIs and that the benefits will be commensurate with the burden implied. As stated numerous times throughout the preamble, our intention in requiring such work is to better ensure that high quality Predictive DSIs can be more effectively used to improve patient care.

Given the many comments received from interested parties, we have limited the source attributes that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) are required to complete and keep current to those that are related to Predictive DSIs supplied by the developer of certified health IT, which we believe would limit the resources required to gather information from other parties. We describe in further detail these requirements in subsequent responses in this final rule. We reiterate that Health IT Modules must support the capability for other party source attribute information to be accessible to users, but that developers are not required to receive or proactively acquire such information for user access from these other parties just because a user selects ( i.e., activates) a Predictive DSI using the developer's Health IT Module.

Comments. Some commenters recommended that the requirements should be limited to require summary information of source attributes and only for high-impact Predictive DSI that presents a greater risk of potential harm. One commenter recommended that ONC should take a risk-based approach and limit Predictive DSIs in scope and exclude low-risk use cases for consumers, such as general wellness.

Response. We appreciate the comments. However, the Program is not predicated on levels of risk that a technology may pose. As previously noted, we believe that identifying whether a Predictive DSI is “high-risk” or could have a “high-impact” across millions of patients is not appropriate for this rulemaking because Predictive DSIs that may in some sense be “low-risk,” such as those that predict appointment no-shows can (in some cases indirectly) impact the healthcare of millions of individuals and thereby be “high-impact.” We also believe that it is important to require the same information for Predictive DSIs supplied by developers of certified health IT. We reiterate that we have not established requirements for specific measures of validity or fairness, for example. Rather, we encourage industry, academic, professional associations, and other interested parties to determine which information best fits each use case. For instance, a radiological or oncologic society might develop recommendation on how to measure fairness for a Predictive DSI that predicts onset of melanoma in diverse populations, and we encourage the use of those measures as they continue to be refined. We are also aware of ongoing work to standardize approaches to select specific measures and performance targets and encourage developers to follow those best practices. We believe our requirements at § 170.315(b)(11)(iv)(B) are consistent with industry and academia-developed reporting guidelines, and are appropriately balanced and flexible, while ensuring a consistent baseline of information users need to make informed decisions regarding their use of a Predictive DSI.

Comments. Several commenters expressed concerns that our proposal was duplicative of FDA requirements, noting that they believed our proposal imposes duplicative and unnecessary requirements for software solely based on its use within certified health IT, creating additional burdens for device manufacturers who are also regulated by the FDA. Commenters expressed concern regarding the existing authority that the FDA has over device CDS, which may result in a duplication of efforts with differing requirements, meaning providers and EHR vendors would need to satisfy two sets of regulations. One commenter noted that they believe that in some instances, publication of source attribute information distinct from existing labeling could require supplemental FDA authorization. Some commenters suggested that regulating source attributes would be accomplished more effectively by the FDA.

Response. We appreciate the concerns expressed by these commenters, which is why we worked closely with the FDA on development of our proposals in § 170.315(b)(11), especially regarding Predictive DSI-specific source attributes. We are aware that technologies that meet the definition for Predictive DSI within the Program may be considered Non-Device CDS, be considered CDS with device software functions, or lie outside of FDA's purview, depending on the specifics of the technology. We worked with the FDA expressly to minimize duplication of effort and maximize alignment across our distinct and different authorities.

We coordinated with FDA to ensure that the information required within source attributes in our finalized § 170.315(b)(11) is complementary and not conflicting with the information that FDA describes in its CDS Guidance, finalized in September 2022. Specifically, we believe that both (1) the content of the information described for source attributes in § 170.315(b)(11)(iv) and (2) the capabilities required in § 170.315(b)(11)(iii) and § 170.315(b)(11)(v) are complementary and aligned with FDA CDS guidance and could reduce burdens for entities that develop device software functions that also meet the definition of Predictive DSI.

We note that section 520I(1)(E) of the Food Drug & Cosmetics (FD&C) Act (Pub. L. 75–717, Jun. 1938) excludes from the definition of “device,” software functions that, among other things, are intended for the purpose of enabling a healthcare professional to independently review the basis for recommendations that such software presents. As part of this alignment effort across both FDA and ONC regulatory requirements, we identified and have finalized source attribute information that could plausibly address some of the informational requirements in 520I(1)(E)(iii) of the FD&C Act, including:

• § 170.315(b)(11)(iv)(B)( 2) Purpose of the intervention, including: ( i) Intended use of the intervention; ( ii) Intended patient population(s) for the intervention's use; ( iii) Intended user(s); and ( iv) Intended decision-making role the intervention was designed to be used/for ( e.g., informs, augments, replaces clinical management).

• § 170.315(b)(11)(iv)(B)( 4) Intervention development details and input features, including at a minimum: ( i) Exclusion and inclusion criteria that influenced the data set; ( ii) Use of variables in 170.315(b)(11)(iv)(A) (5)–(13) as input features; ( iii) Description of demographic representativeness according to variables in § 170.315(b)(11)(iv)(A) (5)–(13) including, at a minimum, those used as input features in the intervention; and ( iv) Description of relevance of training data to intended deployed setting.

• § 170.315(b)(11)(iv)(B)( 7) Quantitative measures of performance, including: ( i) Validity of intervention in test data derived from the same source as the initial training data; and ( v) References to evaluation of use of the intervention on outcomes, if available, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes.

We believe that these similarities will reduce compliance burden in three ways. First, an entity that develops device software functions that also meet the definition of Predictive DSI would be able to fulfill informational requirements for both FDA and ONC purposes using the same or similar information. Second, an entity that develops device software functions that also meet the definition of a Predictive DSI may be eligible to be considered Non-Device CDS according to FDA guidance, if the developer of the Predictive DSI fulfils informational requirements according to Program requirements in § 170.315(b)(11) and § 170.402(b)(4). Specifically, we note that the capability to enable a limited set of identified users to select evidence-based DSIs and Predictive DSIs in § 170.315(b)(11)(iii) and access source attributes for these DSIs in § 170.315(b)(11)(v) could be the technical mechanism by which technologies meet requirements in section 520I(1)(E)(iii) of the FD&C Act, described as Criterion 4 of the FDA CDS guidance. Finally, we believe that burdens will be reduced across entities regulated by FDA and ONC because an entity that develops device software functions that also meet the definition of a Predictive DSI could leverage Program requirements to enable users to select Predictive DSIs in § 170.315(b)(11)(iii) and access source attribute information in § 170.315(b)(11)(v). These capabilities could serve as the technical means to deliver information to users about the credibility of the device software function that is necessary for “independent review,” without having to build a parallel technological means to deliver such information.

For example, for those software functions that are considered non-device CDS, and therefore are not the focus of the FDA's regulatory oversight, our source attribute requirements are complementary to the required factor “intended for the purpose of enabling such healthcare professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such healthcare professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient” (section 520I(1)(E)(iii) of the FD&C Act). In this case, our requirements are supportive of meeting aspects which may be part of determining that a Predictive DSI is not a medical device and therefore not the focus of the FDA's oversight.

For those CDS software that are medical devices and the focus of the FDA's oversight, we note our requirements are consistent with best practices and recommendations similarly provided by the FDA. In such cases, as these recommendations are consistent across our agencies, we believe that providing such information should not increase burden on developers who may be responsible for meeting both FDA and ONC requirements.

We note that our authorities and policy objectives for decision support are not identical to those of the FDA, and so the information required for source attributes may not be identical to the information that would enable independent review according to FDA's guidance and determination, and that the inverse is also true. For instance, we have included source attributes related to the determination of fairness, as well as measures of local validation pursuant to the purposes enumerated in 42 U.S.C. 300jj–11(b)(11) and (4) to support development of a nationwide health information technology infrastructure that improves efforts to reduce health disparities and that provides appropriate information to help guide medical decisions at the time and place of care, respectively, but the FDA CDS guidance did not explicitly describe measures related to fairness or local validation in their description of independent review. We note that a determination regarding information necessary for independent review lies with, and would continue to lie with, the FDA.

Beyond the FDA CDS guidance, we note alignment with several categories of source attribute information in the finalized § 170.315(b)(11)(iv)(B) and IRM practices described in § 170.315(b)(11)(vi) across other FDA guidance documents including the FDA's draft guidance on Marketing Submission Recommendations for a Predetermined Change Control Plan for Machine Learning Device Software Functions (PCCP–ML guidance) and the FDA's guidance on Content of Premarket Submissions for Device Software Functions. We also note important differences between these requirements and FDA guidance, which highlights our complementary—yet distinct—regulatory authorities. Specifically, we highlight that the source attributes for ongoing maintenance of intervention implementation and use in the finalized § 170.315(b)(11)(iv)(B)( 8) are similar to information described within FDA's PCCP–ML draft guidance. However, specific emphases for fairness measures in local data (at § 170.315(b)(11)(iv)(B)( 8)( iv)) and descriptions of the frequency by which the intervention's performance is corrected when risks related to validity and fairness are identified (at § 170.315(b)(11)(iv)(B)( 9)( ii)) are not requirements of the FDA's PCCP–ML draft guidance. We also note that our source attribute information pertains to an expanded set of technologies because it is not limited to Predictive DSI that are unlocked or those that developers intend to modify over time. Our scope for technology that meets the definition of Predictive DSI is more expansive than what the PCCP–ML guidance considers because we view transparency into the performance of Predictive DSIs in a local health system or clinic to be particularly important to users to determine if a given Predictive DSI is fit for use on or with their patients, particularly in the case of older Predictive DSI that are rarely retrained based on local data. We believe that ensuring certified health IT has a place to provide this information, or indicate its omission, will be of value to users deciding on whether a technology is fit-for-purpose at their organization, but may be beyond the scope of FDA's review and approval process.

Similar examples exist in what FDA describes in its Premarket Submissions for Device Software Functions guidance, including documentation recommendations related to “software description,” which align with ONC final requirements in § 170.315(b)(11)(iv)(B)( 1) for details and output of the intervention and § 170.315(b)(11)(iv)(B)( 4) for intervention development details and input features, as well as FDA guidance for a “risk management file,” which aligns with requirements in § 170.523(f)(1)(xxi) for summary risk management information to be available via publicly accessible hyperlink. We believe that these similarities will reduce the burden on complying with our Program requirements for those Predictive DSI that have device software functions.

We are aware that some Predictive DSI may not be within FDA's purview because, consistent with the history of our Program, we have not focused requirements for DSIs on specific use cases. Thus, we believe that ONC is well positioned to regulate certified health IT in ways that are different from how FDA regulates device software functions and disagree with commenters' suggestion that more effective regulation of source attributes could be accomplished by the FDA, or that there is conflict between FDA labeling requirements and source attributes, because we have different authorities and, where similar requirements may be needed within these differing scopes, our agencies have worked closely to ensure complementary recommendations and requirements. These technologies, especially in the aggregate, impact how healthcare is delivered, and we believe our complementary authorities will provide important benefits to users.

Comment. Several commenters expressed concern that the list of required source attributes that must be disclosed is overly broad and potentially impractical to implement. Commenters requested clarity regarding how DSI developers would satisfy the proposed requirement of providing access of source attributes to an end user and how that information would need to be presented or formatted. They further noted the concern that providing access to users of such broad source attribute information could result in an interface that impairs physician usability. Another commenter suggested that the health IT developers should be required to instead provide a configuration option through which third-party vendors of Predictive DSI could include their source attributes during the integration with health IT or implementation within a hospitals or provider's database. Another commenter suggested that the health IT developers should be required to instead provide a configuration option through which third-party vendors of Predictive DSI could include their source attributes during the integration with health IT or implementation within a hospitals or provider's database.

Response. We appreciate comments regarding implementation of our source attributes requirements for user review and implications for usability. While our proposals required a Health IT Module to enable users to review source attribute information, we did not specify either that a user must review source attribute information or that source attribute information be presented at a specific time or manner to a user. We noted in the HTI–1 Proposed Rule that we understood that source attribute information may be presented in varied ways at various points of workflow and contain varying levels of detail and do not intend to limit the options by which this information can be made available (88 FR 23788). We also said, consistent with prior ONC discussion related to existing § 170.315(a)(9)(v) requirements for source attributes (77 FR 54215), the proposal would not require the automatic display of source attributes information when a recommendation, alert, or other decision support output is presented that resulted from a DSI (88 FR 23788). Last, we noted that we were not aware of widely agreed upon best practices for the format in which this source attribute information should be displayed. However, we are aware of industry efforts to standardize a format to display information about technology in the form of a “model card” or “nutritional label” for healthcare (88 FR 23794). We believe that rather than prescribing uniform presentation of this kind of information, that developers of certified health IT should work with their customers to determine the best format and structure of source attribute information. Finally, we note that we did not prescribe a mechanism, standard, or process for how developers of certified health IT should receive or acquire information from other parties for source attributes in the HTI–1 Proposed Rule and have also not done so in this final rule.

Comments. Several commenters expressed concern that our proposal would require health IT developers with certified health IT to regulate other developer's Predictive DSI and stated that health IT developers should not be responsible for the Predictive DSI of their customers or other parties and that health IT developers' certification should not be contingent on other parties providing information to the developer.

Response. We thank the commenters for their concerns. As described elsewhere in this final rule, we have adopted modified final rule requirements and a reduced scope to address these concerns. Specifically, we have finalized a different scope with respect to other party source attributes, such that developers of certified Health IT are only required to make source attribute information available when the health IT developer supplies the other party's Predictive DSI as part of its Health IT Module. In alignment with the comments, the finalized requirements of § 170.315(b)(11) do not extend to developers of certified health IT being accountable for Predictive DSIs developed by their customers or other party Predictive DSIs implemented by their customers.

Comments. One commenter expressed concern that the proposal will not be effective at creating broad, uniform transparency throughout the Predictive DSI marketplace because ONC has authority to regulate certified health IT, which is only a portion of the predictive model marketplace. The commenter noted that the proposal would create imbalance in the marketplace between developers of certified health IT and developers of noncertified health IT. The commenter also stated that information from third-party developers will be inconsistent and intermittent.

Response. We believe that the scope of our definition for Predictive DSI and our requirements for Predictive DSIs supplied by developers of certified health IT are sufficiently calibrated to affect a substantial portion of the DSI marketplace and that developers of certified health IT are well-positioned to ensure that information is updated routinely and consistently for Predictive DSI they supply as part of their health IT.

Comments. One commenter expressed concern that our proposals would result in inefficiencies for developers, and that transparency goals would be more efficiently achieved through regulations that directly apply to creators of clinical decision alert content. They noted that in some cases that would be those developing EHRs, but in most instances, those creating alerts are either third-party businesses or health care providers themselves.

Response. We agree with the commenter that there is a growing market for DSIs created by other parties, which could include third-party businesses or health care providers using certified health IT. While we have not finalized our proposals to require developers of certified health IT to indicate when source attributes are missing for all other party -developed Predictive DSIs, we have finalized that a developer of certified health IT must complete and keep current descriptions of source attribute information as specified in § 170.402 (b)(4) for all interventions supplied by the health IT developer, including other party interventions the health IT developer supplies as part of its Health IT Module. We believe this scope appropriately focuses on what a developer of certified health IT can readily and efficiently access in terms of source attribute information. We also finalize that for source attributes in § 170.315(b)(11)(iv)(B)( 6); (b)(11)(iv)(B)( 7)( iii), ( iv), and ( v); (b)(11)(iv)(B)( 8)( ii) and ( iv); and (b)(11)(iv)(B)( 9) a health IT developer must indicate when information is not available for review. This requirement pertains to both source attributes related to Predictive DSIs authored by the developer of certified health IT and to Predictive DSIs developed by other parties that are supplied by the developer as part of its Health IT Module.

Comments. Numerous commenters requested that we clarify that the certification requirements for developers of certified health IT do not convey an obligation for health care providers to review all the source attributes of a DSI each time they choose to use a tool.

Response. Nothing in our proposals nor this final rule would compel a user of certified health IT to review source attributes. However, we note it would be a best practice for users to conduct such affirmative reviews in an effort to identify potentially discriminatory tools, as discriminatory outcomes may violate applicable civil rights law.

Comments. Several commenters expressed concern that our proposal for source attributes for Predictive DSIs is overly broad and should instead be narrowed to specifically focus on AI and machine learning algorithms, noting that there are substantial risks of bias associated with these models if they are not constructed in a manner that allows the end user to understand how they were constructed and will be maintained going forward.

Response. We appreciate the comments and agree that bias associated with AI and machine learning algorithms could create substantial risks if they are presented to the end user without information to understand how they were constructed, evaluated, and should be maintained. We believe that recent scrutiny of other predictive models has shown that those models can similarly present substantial risk if presented without this information. We note that most of our source attributes are specific to Predictive DSIs, which encompasses AI and machine learning algorithms. We have only amended existing requirements for evidence-based DSIs by asking for specific data elements to be identified when used by the DSI, including race, ethnicity, language, sexual orientation, gender identity, sex, date of birth, SDOH, sexual orientation, and health assessments data elements ( e.g., disability status).

Comments. Several commenters applauded HHS's efforts to recognize the challenges of complex predictive models and the general need for public disclosure of source data to determine reliability. Commenters also encouraged HHS to consider additional measures to oversee the explain-ability of the data output and for HHS to adopt broad policies that ensure public access to both models and their data sources. One commenter stated that they believed that the information presented under “source attributes” should be in the public domain and not just presented to end users, and information about which datasets were used to train and evaluate a DSI should be in the public domain and added to the required “source attributes.”

Response. We thank commenters for their support. However, we decline to consider additional measures regarding the concept of “explain-ability,” at this time and instead we include a requirement for risks related to intelligibility to be analyzed and mitigated at § 170.315(b)(11)(vi). We also appreciate the feedback regarding the value of making public the information we are requiring for source attributes. We view access to source attribute information as a necessary step for users of Predictive DSIs to determine the quality of Predictive DSIs they use. We decline to require public disclosure of source attribute information at this time. Rather, we believe that it is vital to implement the policies that we have finalized in this rule, learn from their implementation, and revisit ways to improve transparency over time. As the industry as a whole gains experience with making source attributes available to users of Predictive DSIs, we may consider broader and public availability of source attribute information in future rulemakings.

Meanwhile, we remind interested parties that under current Program requirements related to the Communications Condition and Maintenance of Certification requirements in § 170.403 users have explicit rights to discuss publicly various aspects regarding the performance of certified health IT. Specifically, we note that in § 170.403(a)(1)(iv) users have the right to describe relevant information regarding their experiences when using a Health IT Module. We also noted in the ONC Cures Act Final Rule that algorithms would be considered “non-user-facing aspects of health IT” as they are not readily apparent to persons using health IT for the purpose for which it was purchased or obtained (85 FR 25731). Thus, communications regarding algorithms ( e.g., mathematical methods and logic) could be restricted or prohibited, while communications regarding the output of the algorithm and how it is displayed in a health IT system could not be restricted as “non-user-facing aspects of health IT.” Given this, we note that source attribute information is user-facing and is relevant to a user's experience using certified health IT. Thus, source attribute information is among the kinds of information that customers may freely discuss publicly.

We also note our discussion in the HTI–1 Proposed Rule regarding an individual's ability to obtain information about any use of a Predictive DSI—or other emerging technologies—in their healthcare through the HIPAA Privacy Rule individual's right of access (88 FR 23795).

In many cases, developers of certified health IT serve as HIPAA business associates to their covered entity customers, such as health care providers or health plans. If an individual requests access to their health information from a HIPAA covered entity ( e.g., a health care provider that transmits health information in electronic form in connection with an HHS adopted standard transaction) that individual, generally, has a right to access medical and health information (protected health information (PHI)) about themselves in one or more designated record sets (DRS) maintained by or for the individual's HIPAA covered entity. The DRS could include underlying data and information used to generate recommendations about an individual's healthcare, such as information about the use of a Predictive DSI in a healthcare decision and source attribute information associated with use of a Predictive DSI in a healthcare decision.

Comments. One commenter agreed that developers should implement practices and processes when a model's performance is inconsistent with its intended use and recommended that we include in regulations a specific process for developers to follow. Another commenter recommended including “identification of intended user qualifications.”

Response. We agree with commenters that developers should implement processes to update models and have included relevant source attributes describing the process of updating models at § 170.315(b)(11)(iv)(B)( 8) and ( 9). However, we decline to specify a process by which this is performed because it is likely to vary across Predictive DSI. Information on intended user qualifications would be appropriately included at § 170.315(b)(11)(iv)(B)( 2)( iii) “intended users,” but we do not explicitly require such information to be there.

Comments. One commenter requested that DSIs based on studies or recommendations from Federal Agencies should be exempt from any other reporting requirements other than identifying the Agency and the study.

Response. We decline to exempt any DSIs described in § 170.315(b)(11) from any of the applicable reporting requirements based on where the recommendations originate. We believe that recommendations from a federal agency, such as the Centers for Disease Control and Prevention, should include all the source attributes, not only the bibliographic citation, as is suggested by the commenter. For the same reason that transparency would be helpful for any evidence-based DSI, so too would transparency be valuable for DSIs based on studies or recommendations from federal agencies.

Comments. Numerous commenters supported the FAVES framework described in the HTI–1 Proposed Rule, noting that these concepts reflect a consensus view of the characteristics of high-quality Predictive DSIs. One commenter expressed concern that the effectiveness in regulating source attributes would be hampered by reliance on highly defined input fields which can be made subject to political analysis ( e.g., FAVES) and related noncomputational tests to guide to desired political outcomes, and instead suggested that ONC, rather than focusing on redesign of models and model parameters, instead emphasize transparency as to when an AI algorithm is being used.

Response. We appreciate the many statements of support for our framing of “high-quality,” predictive algorithms to mean that such algorithms are fair, appropriate, valid, effective, and safe, or FAVES. However, we do not believe a Program requirement for Health IT Modules to indicate when an AI algorithm was used to support decision-making is appropriate (as users should already understand if they're using a predictive AI to support their decision-making) nor sufficient for users to understand the quality of such AI algorithms. We believe that defined source attribute categories, coupled with a description of the characteristics that make up a high-quality Predictive DSI, are necessary to provide consistent information that will more effectively promote the use of those Predictive DSI where appropriate. Further, we note that while we have defined input fields, we have not established requirements for specific measures or identified specific thresholds for content that is related to those categories.

Comments. Several commenters encouraged ONC to work with interested parties to further develop guidance and standards. Specifically, one commenter urged ONC and HHS to convene interested parties to develop a consensus set of meta-data that should and, must be, transparently provided by DSI developers, and strongly supported ONC requiring a standard representing a Structure Product Label for Predictive Decision Support. One commenter encouraged additional regulatory parameters and encouraged ONC to consider requirements for regular, algorithmic impact assessments that analyze data sets, biases, and how users interact with the systems, and the overall design and monitoring of system outputs, as well as to include expressly incorporating data-set best practices and data standards requirements.

Response. We appreciate these comments and will continue to collaborate with interested parties inside and outside of government to ensure that information resulting from our transparency requirements is meaningful for patient care and decision-making.

Given the comments received from a range of interested parties, and to clarify the scope of information required for an applicable Predictive DSI, we have finalized our proposals in § 170.315(b)(11)(iv)(B) with modification. We note that the information required here as source attribute information is similar to the “meta-data” described by commenters. First, rather than include references to evidence-based source attributes as proposed, we have added new subparagraphs as part of the “Intervention details” source attribute at § 170.315(b)(11)(iv)(B)( 1) to include similar general attribute information. Specifically, at § 170.315(b)(11)(iv)(B)( 1)( i) we require “The name and contact information for the developer of the intervention,” and at § 170.315(b)(11)(iv)(B)( 1)( ii) we require “Funding source of the intervention,” which are substantially similar to the proposed inclusion of bibliographic information (since citations include the name and contact information for corresponding authors) and “developer of the intervention and “Funding source of the intervention” is directly parallel to “Funding source of the intervention development technical implementation” all of which we proposed to apply to Predictive DSIs in the HTI–1 Proposed Rule. Commenters noted, and we agree, that bibliographic citation of the intervention finalized at § 170.315(b)(11)(iv)(A)( 1) likely would not be relevant for all Predictive DSIs and other source attributes specific to evidence-based DSIs at § 170.315(b)(11)(iv)(A) were duplicative of source attributes in § 170.315(b)(11)(iv)(B).

Second, we have made explicit in regulation text several requirements described in the HTI–1 Proposed Rule's preamble to ensure that health IT developers clearly understand the source attribute requirements applicable to Health IT Modules presented for certification to § 170.315(b)(11). We have finalized these requirements to address many commenters' concerns regarding proprietary information and to help convey at what level of detail Predictive DSI source attributes should be available for a limited set of identified users to record, change, and access.

Comments. We received numerous comments from interested parties indicating that more clarity was needed to help communicate the scope and detail of information included as source attributes in what is now finalized at § 170.315(b)(11)(iv)(B).

Response. We agree and have finalized regulation text at § 170.315(b)(11)(iv)(B) to clarify the scope and detail of information required to be available for user review. We note that these explicit requirements in regulation text mirror the requirements described previously in preamble or represent a subset of requirements previously described in preamble. We also reiterate our preamble discussion that the requirements do not require disclosing or sharing IP or proprietary information existing in the developer's health IT, including other parties' IP and proprietary information.

Intervention Details

We proposed three source attributes related to details of predictive models and their proper use in § 170.315(b)(11)(vi)(C)( 1) “Intervention Details,” Including “Output of the intervention,” “Intended use of the intervention,” and “Cautioned out-of-scope use of the intervention.” We refer readers to 88 FR 23789–23790 for a detailed discussion of our proposed rationale for these source attributes as well as examples and additional instruction, which we have made explicit in the regulation text below.

We have finalized § 170.315(b)(11)(iv)(B) (1) as follows: “Details and output of the intervention, including: (i) Name and contact information for the intervention developer; (ii) Funding source of the technical implementation for the intervention(s) development (for which we have modified the wording order from the HTI–1 Proposed Rule to make the source attribute read clearer and we have also made this corresponding change for evidence-based DSIs as well); (iii) Description of value that the intervention produces as an output; and (iv) Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output.”

We have finalized § 170.315(b)(11)(iv)(B) (2) “Purpose of the intervention, including: (i) Intended use of the intervention; (ii) Intended patient population(s) for the intervention's use; (iii) Intended user(s); and (iv) Intended decision-making role for which the intervention was designed to be used/for ( e.g., informs, augments, replaces clinical management).”

We have finalized § 170.315(b)(11)(iv)(B) (3) as follows “Cautioned out-of-scope use of the intervention, including: (i) Description of tasks, situations, or populations where a user is cautioned against applying the intervention; (ii) and Known risks, inappropriate settings, inappropriate uses, or known limitations.”

Intervention Development

We proposed at 88 FR 23790 three source attributes related to model development in § 170.315(b)(11)(vi)(C)( 2), “Intervention Development,” including “Input features of the intervention including description of training and test data,” “Process used to ensure fairness in development of the intervention,” and “External validation process, if available.” We refer readers to 88 FR 23790–23795 for a detailed discussion of these source attributes in the HTI–1 Proposed Rule.

We have finalized § 170.315(b)(11)(iv)(B) (4) as follows “Intervention development details and input features, including at a minimum: (i) Exclusion and inclusion criteria that influenced the data set; (ii) Use of variables in 170.315(b)(11)(v)(A) (5)–(13) as input features; (iii) Description of demographic representativeness according to variables in § 170.315(b)(11)(iv)(A) (5)–(13) including, at a minimum, those used as input features in the intervention; and (iv) Description of relevance of training data to intended deployed setting.”

We have finalized § 170.315(b)(11)(iv)(B) (5) as follows “Process used to ensure fairness in development of the intervention, including: (i) Description of the approach the intervention developer has taken to ensure that the intervention's output is fair; and (ii) Description of approaches to manage, reduce, or eliminate bias.”

We have finalized § 170.315(b)(11)(iv)(B) (6) as follows “External validation process including: (i) Description of the source, clinical setting, or environment where an intervention's validity and fairness has been assessed, other than the source training and testing data; (ii) Party that conducted the external testing; Description of demographic representativeness of external data according to variables in § 170.315(b)(11)(iv)(A) (5)–(13) including, at a minimum, those used as input features in the intervention; and Description of external validation process.”

Quantitative Measures of Intervention Performance

We proposed at 88 FR 23791–23792, five source attributes relevant to validation or evaluation of the performance (including accuracy, validity, and fairness) of the predictive model and evaluation of its effectiveness in § 170.315(b)(11)(vi)(C)( 3) “Quantitative measures of Intervention Performance,” including “Validity of prediction in test data,” “Fairness of prediction in test data,” “Validity of prediction in external data, if available,” “Fairness of prediction in external data, if available,” and “References to evaluation of use of the model on outcomes, if available.” Together, these source attributes were intended to be a presentation of the measure or set of measures related to the model's validity (often referred to as performance) and fairness when tested in data derived from the same source as the initial training data as well as when tested in data external to—that is, from a different source than—the primary training data. “References to evaluation of use of the model on outcomes, if available,” are bibliographic citations or links to evaluations of how well the intervention, or model on which it is based accomplished specific objectives such as reduced morbidity, mortality, length of stay or other important outcomes.

We have finalized § 170.315(b)(11)(iv)(B)( 7) as follows “Quantitative measures of performance, including: (i) Validity of intervention in test data derived from the same source as the initial training data; (ii) Fairness of intervention in test data derived from the same source as the initial training data; (iii) Validity of intervention in data external to or from a different source than the initial training data; (iv) Fairness of intervention in data external to or from a different source than the initial training data; and (v) References to evaluation of use of the intervention on outcomes, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other important outcomes.”

Ongoing Maintenance of Intervention Implementation and Use

At 88 FR 23792, we proposed three source attributes related to the “ongoing maintenance of intervention implementation and use,” including, “Update and continued validation or fairness assessment schedule,” “Validity of prediction in local data, if available,” and “Fairness of prediction in local data, if available.” These source attributes were a description of the process and frequency by which the model's performance is measured and monitored in the local environment and corrected when risks related to validity and fairness are identified.

We have finalized § 170.315(b)(11)(iv)(B) (8) as follows “Ongoing maintenance of intervention implementation and use, including: (i) Description of the process and frequency by which the intervention's validity is monitored over time; (ii) Validity of intervention in local data; (iii) Description of the process and frequency by which the intervention's fairness is monitored over time; and (iv) Fairness of intervention in local data.”

Update and Continued Validation or Fairness Assessment Schedule

At 88 FR 23792 we proposed a source attribute, “ Update and continued validation or fairness assessment schedule ” and described it as including “the process and frequency by which the model's performance is measured and monitored in the local environment and corrected when risks related to validity and fairness are identified.” Information from this attribute is important to assess whether the model is up to date or may reflect outdated trends.

We have finalized § 170.315(b)(11)(iv)(B)( 9) as follows “Update and continued validation or fairness assessment schedule, including: (i) Description of process and frequency by which the intervention is updated; and (ii) Description of frequency by which the intervention's performance is corrected when risks related to validity and fairness are identified.”

ix. Missing Source Attribute Information

At 88 FR 23795–23796 we proposed that a Health IT Module certified § 170.315(b)(11) would need to clearly indicate when a source attribute listed is not available for the user to review, including in two specific circumstances. First, we proposed that for source attributes that include the “if available” phrase, a Health IT Module must clearly indicate when such source attribute is not available for review. Second, we proposed that when a Health IT Module enables or interfaces with a DSI developed by other parties that are not developers of certified health IT, that Health IT Module must clearly indicate when any source attribute is not available for the user to review. We explained that this meant that a Health IT Module that supports a DSI developed by other parties that are not developers of certified health IT would have needed to clearly indicate when any attribute listed is not available for the user to review, regardless of whether the DSI is a Predictive DSI, as defined at § 170.102, or an evidence-based DSI.

At 88 FR 23796, we clarified that “ other parties, ” as used in our proposal, included any party that develops a DSI, a model, or an algorithm that is used by a DSI and is not a developer of certified health IT. These could include, but were not limited to: a customer of the developer of certified health IT, such as an individual health care provider, provider group, hospital, health system, academic medical center, or integrated delivery network; a third-party software developer, such as those that publish or sell medical content or literature used by a DSI; or researchers and data scientists, such as those who develop a model or algorithm that is used by a DSI.

We reiterated that while we did not prescribe how a certified Health IT Module would need to indicate that an attribute was missing that the certified Health IT Module would need to communicate an attribute was missing unambiguously and in a conspicuous manner to a user. We noted that these “ other parties ” may or may not have a contractual relationship with the developer of certified health IT. However, we sought comment on whether we should require developers of certified health IT with Health IT Modules that enable or interface with Predictive DSIs to display source attributes for other parties with which the developer of certified health IT has a contractual relationship.

Comments. We received mixed comments supporting and opposing our proposal to require a Health IT Module to clearly indicate when a source attribute is not available for the user to review. Among those who opposed our proposal, they conveyed that indicating to a user when a source attribute was unavailable would create burdens on health IT developers who do not readily have access to source attribute information and would position health IT developers to enforce information gathering requirements on other companies, including third-party vendors with which the health IT developer has no formal contract and health IT customers that create clinical decision support data. Many commenters who opposed this proposal supported an alternative requirement that would require certified developers to (1) provide source attributes and indicate when information was missing for those interventions they themselves authored ( i.e., self-developed interventions) and (2) for those interventions that were developed by other parties with which the developer of certified health IT worked to implement into their Health IT Modules as opposed to all other parties, regardless of the health IT developer's relationship with those other parties. In other words, commenters suggested limiting the transparency requirement to those other parties the health IT developer has a contractual relationship with or to require health IT developers to include functionality to display the information and letting their customers decide whether to display information about their own Predictive DSI or that of other developers with whom the customers have a contractual relationship.

Response. We thank commenters for their concerns. We agree with commenters regarding the burden and implementation issues associated with identifying missing information as we proposed and have made changes to the scope in response. In particular, we have addressed the concerns raised about Predictive DSIs developed by other parties with which the developer of certified health IT has no formal relationship. The finalized policy, described below more closely aligns with the commenters' alternative policy, which we believe addresses these concerns.

While we noted in the HTI–1 Proposed Rule that missing source attribute information would be foundational for users' understanding of the DSI regardless of whether the intervention developer was a developer of certified health IT, a customer of the developer of certified health IT, an academic health system, integrated delivery network, a third-party software developer, or other party (88 FR 23795), we also acknowledged that we understood there may be circumstances where a developer of certified health IT may not have information pertaining to a source attribute for a Health IT Module to enable such user review.

In response to public comments received, we have made two overall adjustments. First, we did not finalize our proposals for missing source attributes as it relates to other parties as proposed. This is because, as discussed elsewhere in this section, we have constrained the overall scope of the certification criterion and the developer of the certified Health IT Module's accountability to those Predictive DSIs supplied by the health IT developer as part of its Health IT Module. As a result, in circumstances where a developer of certified health IT has not supplied an other party's Predictive DSI as part of its Health IT Module the developer is not accountable for the unavailability of those Predictive DSI's source attribute information. Second, we have finalized a certification requirement for Health IT Modules to indicate when information is not available for specific source attributes only. Specifically, we have finalized at § 170.315(b)(11)(v)(A)( 2) requirements that for Predictive DSIs, a Health IT Module must indicate when information is not available for review for source attributes in § 170.315(b)(11)(iv)(B)( 6); (b)(11)(iv)(B)( 7)( iii), ( iv), and ( v); (b)(11)(iv)(B)( 8)( ii) and ( iv); and (b)(11)(iv)(B)( 9). We note that the implication of this finalized policy is twofold: (1) developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) must enable a limited set of identified users to access complete and up-to-date plain language descriptions for all source attributes, except those listed in § 170.315(b)(11)(v)(A)( 2); and (2) developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) must enable such access for evidence-based and Predictive DSIs at least when those DSIs are supplied by the health IT developer as part of its Health IT Module.

We are aware that, in some limited circumstances, information for specific source attributes related to Predictive DSIs supplied by the health IT developer as part of its Health IT Module may not be available nor re-creatable. For example, health IT developers that supply Predictive DSIs that use models provided through the peer reviewed literature, such as ASCVD, eGFR, APACHE IV, and LACE+ models referenced elsewhere in this final rule, may not have access to training data that would allow them to: 1) provide a description of demographic representativeness of the training data (§ 170.315(b)(11)(iv)(B)( 4)( iii)); 2) generate measures of validity in test data derived from the same source as the initial training data (§ 170.315(b)(11)(iv)(B)( 7)( i)); and 3) generate measures of fairness in test data derived from the same source as the initial training data (§ 170.315(b)(11)(iv)(B)( 7)( ii)). In cases where information is only available through published literature, developers may provide information for these source attributes that indicate that the relevant information is not available and that it cannot be replicated. In these cases, we encourage organizations to perform external validation of these models and we believe that providing users information on the results of that work will be of high value. We note that where source attribute information is available for Predictive DSIs in these scenarios, or where source attribute information can be extrapolated from the literature ( e.g., intended use, cautioned out-of-scope use, or intended population, etc.) source attribute information should be accessible and modifiable consistent with requirements in § 170.315(b)(11)(v).

Comments. Commenters that expressed support for this proposal commended our efforts and requested we strengthen this provision to require that all source attribute information is available for user review. Some commenters expressed support for the proposal stating that it would send a signal to health care providers about the trustworthiness of a DSI tool and encourage AI developers to be transparent. One commenter expressed concern that our proposal would allow health IT developers to opt-out of reporting information and allowing developers to indicate when source attributes are missing should be the exception and not the rule. Another commenter expressed concern that this provision places no limits on how much or what type of data can be missing while still complying with source data transparency requirements and could incentivize developers to not provide any data that might show bias or lead to any type of negative conclusion by potential users.

Response. We thank commenters for their support. As addressed more fully in the response directly above, we have made substantial adjustments to the certification criterion's scope and health IT developers accountability expectations. As a result of these changes, we have also addressed commenter concerns that there would be no limit on how much or what type of data can be missing. We have finalized in § 170.315(b)(11)(v)(A)( 2) that only source attributes in § 170.315(b)(11)(iv)(B)( 6); (b)(11)(iv)(B)( 7)( iii), ( iv), and ( v); (b)(11)(iv)(B)( 8)( ii) and ( iv); and (b)(11)(iv)(B)( 9) may be missing and in these circumstances a health IT developer must indicate when information is not available for review.

Comments. Some commenters expressed concern that the proposal to require Health IT Modules to display missing source attributes could result in unfair market dynamics, in which developers of certified health IT will make available full and complete source attribute information for their homegrown or native DSIs while being less inclined to collect and meaningfully display such information from other parties developing and offering Predictive DSIs. Several commenters noted that the proposal would not compel third-party creators to provide the information to the health IT developer, or to renegotiate existing contracts to compel the provision of source attributes.

Response. We thank commenters for these concerns and suggestions. We did not propose and we have not finalized a policy that regulates other parties and this final rule does not compel other parties to provide source attribute information to developers of certified health IT. Rather, we believe there is sufficient market-driven motivation for other parties to provide source attribute information for Predictive DSIs they author or develop to health care providers who seek to use their Predictive DSI's in addition to any of the ones supplied by a developer of certified health IT as part of its Health IT Module. We believe health IT users are likely to develop the expectation that information is available through source attributes and trust and choose to use Predictive DSIs that have the information contained in source attributes compared to those that do not, which may also create competitive pressure in the market to provide source attribute information. For example, the market incentives consumers have when choosing between vehicles that have complete history reports regarding accident damages, manufacturer buybacks, registration records, odometer readings, and ownership transfers, and those vehicles that do not. We believe similar market incentives will result in more source attribute information being made available for user review than would be the case absent the requirement to indicate when source attributes were not available for review.

In response to the commenter concerned about unfair market dynamics, we note that we have finalized a requirement that Health IT Modules must be capable of displaying source attributes from other parties and for users to be able to modify attributes for those Predictive DSI. But that is where the finalized requirements stop. With the exception of Predictive DSIs authored by the health IT developer or those it expressly chooses to supply as part of its Health IT Module, we have not required health IT developers with Health IT Modules certified to § 170.315(b)(11) to receive, acquire, or otherwise produce source attributes related to other party DSIs. We encourage those other parties to work with their customers to ensure that source attribute information is full and complete, thereby addressing any potentially unfair market dynamics.

Comments. Another commenter suggested that developer of the other system, at most, could denote if a DSI it interfaces with is in fact a third-party model, thus informing the user of the need to seek out any desired information from the primary developer of the DSI in question.

Response. As part of this final rule's focus on providing information only for Predictive DSIs supplied in Health IT Modules, we decline to require that Health IT Modules display or “denote” when another system includes a third-party model.

Comments. Commenters stated that communicating that a model is third-party is sufficient and stated that while the proposed language of saying source attribute information is “not available for user review” is both unnecessarily pejorative to the third party and misleading to the end user.

Response. We have finalized at § 170.315(b)(11)(v)(B)( 1) that Health IT Modules must “Enable a limited set of identified users to record and change source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section,” but have left flexibility to developers of certified health IT and their customers to choose if and how to indicate that information is missing, when they believe doing so is valuable, so that they may avoid pejorative and misleading language.

Comments. One commenter expressed concern with the phrase “ other parties” because it could encompass healthcare delivery organizations that self-develop Predictive DSI for “in-house” use to augment their purchased EHR system and requested an exemption from certain requirements, and that they not be penalized by ONC or their EHR vendor who could pass on “costs” to use their “in-house” tools.

Response. We thank the commenter for their concern. We believe this final rule's focus on providing information only for Predictive DSIs supplied by health IT developers in their Health IT Modules will reduce concerns around a need for specific exemptions or that developers of certified health IT might pass on costs, since those developers are only likely to incur costs for those Predictive DSI they supply. Predictive DSI that a healthcare delivery organization self-developed and used to augment their Health IT Module would likely not be considered supplied by health IT developers.

As noted previously in this final rule, we have maintained our description of “ other parties. ” For the purposes of the Program, compliance clarity, and distinguishing a health IT developer's own authored and supplied Predictive DSIs from everyone else, we use the phrase “ other party, ” which could include a health care provider who self-develops a Predictive DSI. That said, as we have conveyed this final rule's requirements, being described as an other party imposes no specific regulatory compliance requirement.

x. Authoring and Revising Source Attributes

At proposed § 170.315(b)(11)(vi)(E), we proposed that Health IT Modules certified to § 170.315(b)(11) support the ability for a limited set of identified users to author ( i.e., create) and revise source attributes and information provided for user review beyond the specific source attributes we enumerated (88 FR 23796–23797). This proposal applied to source attributes related to both evidence-based DSIs and Predictive DSIs that would be enabled by or interfaced with a certified Health IT Module, including any Predictive DSIs that could have been developed by users of the certified Health IT Module, and we described specific examples in the HTI–1 Proposed Rule. While we did not propose to require a developer of certified health IT to be directly involved in the authoring or revision of source attribute information provided for user review, we proposed that the certified Health IT Module would need to support the technical ability for a limited set of identified users to create new or revised attribute information alongside other source attribute information proposed as part of § 170.315(b)(11)(vi)(A) and (C).

Comments. A majority of commenters did not support the proposal that Health IT Modules certified to § 170.315(b)(11) support the ability for a limited set of identified users to author ( i.e., create) and revise source attributes and information provided for user review beyond what was proposed. One commenter supported the concept of hospitals and providers creating their own Predictive DSI models and suggested that developers should only be expected to create functionality to allow users to enter their own source attributes and that developers should not have responsibility for gathering that information for users for input into the products. One commenter expressed concern that it is unclear whether the expectation is that developers must allow for customers to revise the source attributes that developers have themselves defined for DSIs they have developed, noting that allowing revisions would seem problematic as it could inappropriately alter the meaning and information being relayed to end-users. Commenters recommended that we clearly indicate that this requirement applies solely to additional/supplementary source attributes for DSIs developed by the developer of certified health IT themselves stating that DSIs that are not directly implemented or enabled by the developer should be out of scope for the criterion. Commenters were especially concerned that the proposal failed to define the intent for, or characteristics of, the limited set of identified users and would enable those users to create extra regulatory requirements for developers of certified Health IT Modules.

Response. We appreciate the comments and believe that coupled with the proposed scope for the certification criterion that some commenters may have misinterpreted the intent behind our proposal and how the technical capabilities for a Health IT Module would play out as part of implementation. We note that several source attributes, particularly those now finalized in § 170.315(b)(11)(iv)(B)( 6)–( 9) pertain to activities that may occur within individual customer sites, so that processes to measure validity and fairness, as well as the results of those processes, are likely to differ across customer sites. We believe individual customers will have substantial value in revising these source attributes. We clarify that developers of certified health IT are not responsible for content recorded, changed, or accessed by these users and are not responsible for gathering information for or from users that wish to record or change source attribute information.

We nevertheless understand commenters' concerns related to modification of source attributes related to Predictive DSIs that are developed by health IT developers. We clarify that developers of certified health IT are not responsible for the accuracy or use of source attribute information that is modified by their users. Rather, developers of certified health IT are required to have Health IT Modules that support the capability for their users to author or revise source attribute information. We emphasize that this capability is not dependent on the entity that developed the Predictive DSI or related source attributes and we decline to limit this capability to only those additional/supplementary source attributes for DSIs developed by a developer of certified health IT. We note that a Health IT Module is required to enable a “limited set of identified users,” to author and revise source attributes. We believe this stipulation ensures that a Health IT Module is capable of enabling some specified users, but not all users, to have the capability to author and revise source attributes and we believe this mitigates concerns around inappropriate alteration. This requirement will not provide these users with the ability to create additional regulatory requirements but simply to display information related to source attributes of their choosing. We note that several certification criteria include the phrase “limited set of identified users,” including the CDS criterion at § 170.315(a)(9), which developers of certified health IT have had more than a decade of experience supporting.

Comments. Some commenters did not agree with the proposal that Health IT Modules certified to § 170.315(b)(11) support the ability for a limited set of identified users to author ( i.e., create) and revise source attributes and information provided for user review beyond what was proposed in § 170.315(b)(11)(vi)(A) and (C). These commenters noted that it could be burdensome on device manufactures, be at odds with FDA device requirements, adulterate the functionality of the device, and could possibly invalidate any testing and validity provided by the developers or require such robust testing for all permutations that quality and cost could be impacted. Commenters were concerned about the impact on FDA approved devices, observing that allowing third-party developers and users to alter source attribute information, including information related to the “intended use” of the device, may be considered an alteration to the device and impact FDA approval.

Response. We appreciate commenters' concerns regarding FDA-approved medical devices and alterations to the devices intended use source attribute. We note that the source attribute related to intended use is a description of what the output of the Predictive DSI should be used for and not a bound indication of what a devices may be approved to do. While we do not expect users to change the intended use of a Predictive DSI, the requirement is that a Health IT Module enable a limited set of users to change and record source attribute information. We believe that developers of certified health IT and their customers are best positioned to jointly decide how broadly to provide the ability to change and record source attributes and under what circumstances. Customers could then decide what set of users should have the ability to record and change source attribute information in the capabilities adopted in final § 170.315(b)(11)(iv)(A) and (B). In many cases, we believe that FDA requirements and the information included as source attributes are closely aligned, limiting burden on developers. Where that is not the case, we believe the information provided as source attributes will have substantial values to users commensurate with implied burden. Though required, developers concerned about changes to their original source attribute information are free to include a capability to allow users to review the original source attributes even when the information has been changed by end users.

We have finalized our requirements related to revising source attribute information with modifications at § 170.315(b)(11)(v)(B)( 1), which requires that a Health IT Module must enable a limited set of identified users to record and change source attributes in § 170.315(b)(11)(iv)(A) and (b)(11)(iv)(B). As previously discussed, § 170.315(b)(11)(v)(B) is a modified version of proposed § 170.315(b)(11)(iv) and § 170.315(b)(11)(vi)(E), combining the “author and revise” concepts of § 170.315(b)(11)(iv)(E) with the “review” concept in § 170.315(b)(11)(iv). In finalizing this language, we intend to clearly convey that individuals can record and change information within the source attributes listed at § 170.315(b)(11)(iv)(A) and (b)(11)(iv)(B).

We are also aware of substantial activity by the public, industry groups, and other advocacy organizations to further transparency related to Predictive DSIs. Along those lines, we have observed that variations exist with respect to each initiative's priorities and that there is not strong consensus among these groups related to the information included as source attributes or transparency information. As technology related to Predictive DSIs continues to evolve and as industry consensus matures, we expect that new information may need to be made available through source attributes for new models. In recognition of the fact that this final rule now sets a consistent, industry-wide baseline set of source attributes on which these groups may wish to build, we have retained a requirement at § 170.315(b)(11)(v)(B)( 2) around authoring source attributes in addition to those listed in § 170.315(b)(11)(iv)(B). This capability will help support health care providers who wish to stay at pace with industry consensus around transparency and include additional source attribute information using their certified health IT to do so.

In § 170.315(b)(11)(v)(B)( 2) we have finalized that for Predictive DSIs, the Health IT Module must enable a limited set of identified users to record, change, and access additional source attribute information not specified in paragraph (b)(11)(iv)(B). First, we have limited this capability to only Predictive DSI source attributes in § 170.315(b)(11)(iv)(B), whereas our proposal applied to both evidence-based and Predictive DSIs. This is intended to be responsive to commenters who worried that the scope of this capability was too burdensome to implement. Second, we have modified the capability from “author and revise source attributes beyond those listed” to the capability to “record, change, and access additional source attribute information not specified.” We believe this more clearly articulates the intent of the policy and addresses concerns regarding questions posed by interested parties on what “beyond,” meant within the context of their obligations. We clarify that developers of certified Health IT Modules are not responsible for the content recorded, changed, or accessed by these users.

xi. Intervention Risk Management (IRM) Requirements for Predictive Decision Support Interventions

At 88 FR 23797–23808, we proposed to establish “intervention risk management” (IRM) requirements. We proposed at 88 FR 23797 to require that by December 31, 2024, a developer of certified health IT that attested “yes” as part of our other proposal would need to employ or engage in certain IRM practices for all Predictive DSIs, as we proposed at 88 FR 23785 to define in § 170.102, that the developer's certified Health IT Module enables or interfaces with. We also proposed that developers of certified health IT analyze potential risks and adverse impacts associated with a Predictive DSI for the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy at § 170.315(b)(11)(vii)(A)( 1) (88 FR 23799–23801). Similarly, we proposed that developers of certified health IT implement practices to mitigate risks associated with intervention Predictive DSIs at § 170.315(b)(11)(vii)(A)( 2) (88 FR 23801–23802). And, related to governance, we proposed that developers of certified health IT would need to establish policies and implement controls for Predictive DSI governance, including how data are acquired, managed, and used in a Predictive DSI at § 170.315(b)(11)(vii)(A)( 3) (88 FR 23802–23803).

With respect to documentation, we proposed at § 170.315(b)(11)(vii)(B) that developers of certified health IT compile detailed documentation of IRM practices and upon request from ONC make available such detailed documentation for any Predictive DSI that their certified Health IT Module enables or interfaces with (88 FR 23803–23804). We also proposed at § 170.315(b)(11)(vii)(C) to require developers of certified health IT to submit summary information to their ONC–ACB regarding IRM practices listed via a publicly accessible hyperlink that would allow any person to directly access the information without any preconditions or additional steps (88 FR 23804). Consistent with Program implementation for similar documentation requirements (84 FR 7484), we proposed that for this proposed summary information, the required documentation would need to be submitted to ONC–ACBs for review prior to issuing a certification (88 FR 23805).

Finally, we proposed at § 170.315(b)(11)(vii)(D) to require that developers of certified health IT review annually and, as necessary, update both detailed documentation and summary information associated with the certification criterion (88 FR 23805). We also proposed to establish a deadline of December 31, 2024, for developers of certified health IT with Health IT Modules to which the proposed requirements in that section apply to engage in IRM practices and develop both detailed documentation and summary information (88 FR 23797). This proposed deadline corresponded with other proposals in the HTI–1 Proposed Rule, including our proposed to update the Base EHR definition (88 FR 23808).

Comments. Commenters both supported and opposed our proposed IRM requirements at § 170.315(b)(11)(vii), with those in support noting the proposed risk management practices of risk analysis, risk mitigation, and governance are essential for ensuring the trustworthiness of Predictive DSIs. One commenter suggested that ONC strengthen its risk analysis requirements to include intended and reasonably expected DSI use(s), DSI evidence of safety, DSI efficacy, DSI level of automation, and conditions of DSI deployment, whereas another commenter recommended ONC limit its risk analysis requirements to predictive clinical DSIs. Commenters were especially supportive of our proposal to adopt NIST's AI Risk Management Framework (AI RMF) because they noted the characteristics in the proposal provide a robust framework to help with risk mitigation. Some commenters recommended that we follow the Congressionally-created National Artificial Intelligence Advisory Committee (NAIAC) recommendation to use either the NIST AI RMF or similar processes and policies that align with NIST AI RMF. One commenter was supportive to use the NIST Characteristics for FAVES, but recommended revisions to the Fairness, Intelligibility, and Safety characteristics. One commenter who supported the proposal suggested that ONC should strengthen the proposed requirements to explicitly require that a health IT developer's risk mitigation practice include additional information on addressing bias, safeguarding privacy, security interests, and personal information, and create a full feedback loop.

Response. We appreciate these comments and agree that risk management practices are essential for ensuring the trustworthiness of Predictive DSIs and that these practices would promote transparency and accountability within healthcare. As described further in this section we have finalized in § 170.315(b)(11)(vi) substantially similar versions of our proposals. The finalized certification criterion requires that IRM practices must be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, including risk analysis, risk mitigation, and governance. We have also finalized modified versions of what we proposed related to IRM summary information in § 170.523(f)(1)(xxi) as well as the annual review and updated documentation requirements in § 170.402(b)(4). We have not finalized our proposal that developers of certified health IT compile detailed documentation of IRM practices listed in § 170.315(b)(11)(vii)(A) and upon request from ONC make available such detailed documentation for any Predictive DSI that their certified Health IT Module enables or interfaces with.

We thank commenters for their support of our proposal's consistency with the NIST AI RMF and the National Association of Insurance Commissioners (NAIC) recommendation to use either the NIST AI RMF or similar processes and policies that align with the NIST AI RMF. While we encourage the use of a framework to help facilitate IRM and adapted the NIST AI RMF concepts and emphasis areas, conformance with this certification criterion does not require the use of any particular framework, approach, or methodology for providing information about risk management practices. As noted in HTI–1 Proposed Rule (88 FR 23798), we have left this flexibility given a lack of healthcare sector-specific guidance and the nascency of several emerging efforts for risk management of predictive software.

We appreciate commenters' suggestions on additional characteristics and additional kinds of risks that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) should include as part of their IRM practices. However, we remained consistent with what we proposed and decline to add further characteristics. We believe that the eight areas we have finalized represent consensus focus areas, are based on the NIST AI RMF, and would be most relevant to Predictive DSIs. We will monitor implementation of this requirement and may consider modifications to these characteristics in future rulemaking.

Comments. Commenters not in support of the IRM requirements proposed at § 170.315(b)(11)(vi), expressed significant concerns that they would require disclosing IP or proprietary information, could compromise patient privacy, and increase administrative burdens. Other commenters did not support the IRM requirements because they thought they were too broad, noting that requiring a developer of certified health IT to perform IRM practices over a third party's DSI tool is neither feasible or competitively rational and recommended that we limit the scope so that developers are accountable for IRM practices for its own DSI only. Other commenters that did not support the IRM proposals urged ONC to consider a risk-based DSI approach that would classify high, moderate, and low risk DSIs and would provide developers with appropriately scaled risk-based controls based on potential harm to individual patients and populations. One commenter expressed concern that some developers may engage in risky practices that result in harm or privacy violations and requested more clarity on how certification criteria would exclude developers from engaging in these practices. One commenter expressed concern that there is not enough time for developers to meet the December 31, 2024, deadline due to the time to develop and implement the requirements and requested additional time to address the eight characteristics of risk.

Response. We thank commenters for their concerns and suggestions. As we have noted throughout this rulemaking, we believe that such transparency is a prerequisite for high-quality Predictive DSIs to be trusted by clinicians, patients, health systems, software developers, and other interested parties. When we developed the proposed IRM requirements, we sought a balance between limited prescriptiveness and sufficient detail to enable robust and broadly applicable reporting of information on risk management practices to users and the public. Our proposed requirements focused on potential risks and adverse impacts (harm) in eight areas, that include privacy and fairness, that may be associated with each Predictive DSI that is authored by the health IT developer.

In consideration of the feedback we received, we believe that the finalized IRM requirements strike the best balance, especially given that we have not established requirements for specific measures. Rather, we have given maximum flexibility to developers of certified health IT to determine which information best fits their unique circumstances and Predictive DSI use cases. We encourage developers of certified health IT to examine industry resources, such as the NIST AI RMF or the Health Equity Across the AI Lifecycle (HEAAL) framework, as part of these requirements.

Further, as stated in the HTI–1 Proposed Rule (88 FR 23799), we believe that many such developers of certified health IT already employ or engage in IRM practices to comply with existing certification criteria (§ 170.315(g)(3) “safety-enhanced design” (SED) and § 170.315(g)(4) Quality management systems (QMS)). Thus, we continue to believe that the finalized requirement to provide information on these practices represents a low-level of burden for those developers. We believe that our IRM practice requirements are important for several reasons. First, all developers of certified health IT that seek certification to § 170.315(b)(11) and supply Predictive DSIs as part of their Health IT Module will become familiar with foundational IRM practices. Second, the public disclosure of the summary information of IRM practices employed or engaged by the developer of certified health IT, as described further below, will provide transparency to purchasers (potential users), users, and other interested parties, and contribute to appropriate information to help guide medical decisions. Lastly, our finalized requirements in § 170.315(b)(11)(vi)(A) will encourage development of healthcare-specific, consensus, and industry-based best practices for risk management.

We appreciate the concerns expressed about IP and proprietary information, patient information privacy, and administrative burden. As noted, as part of this certification criterion's preamble we have made scope adjustments in response to public comment that we believe substantially address these concerns. The finalized requirements for risk analysis and risk mitigation are limited to only those Predictive DSIs supplied by the developer of health IT as part of its Health IT Module. We have also clarified our expectations for governance requirements. With the exception of other party Predictive DSI's supplied by developers of health IT as part of their Health IT Module, we have not finalized the proposals (88 FR 23803) that caused commenters' concerns regarding the developer of certified health IT performing “IRM practices over a third party's DSI.” Specifically, we have not finalized that developers review risk management information from other parties nor that developers include risk management information from other parties as part of the documentation requirement.

We appreciate the concern expressed about information privacy and harm. We expect that model developers will use data for training and testing consistent with applicable law, patients' expectations, and any patient consent or preference given. We believe the scope changes we have made as part of this finalized certification criterion along with the high degree of flexibility we provide to developers of certified health IT to establish appropriate risk management practices mitigate concerns related to compromising IP, proprietary information, and patient privacy. While we appreciate the concerns raised by some commenters, based on the final certification criterion's scope, we believe they are outweighed by the need to promote greater and more meaningful disclosure of information by developers of health IT certified. We disagree with the claims that our requirements for summary information about risk management practices would result in disclosing IP or proprietary information as we are entrusting developers of certified health IT to disclose information at a level of detail according to their own judgments. Furthermore, based on the scope of the final certification criterion, it is reasonable to assume that developers of certified health IT are experts on their own products and services and possess sophisticated technical and market knowledge related to the implementation and use of health IT in a variety of settings in which their products are used. Through their accumulated experience developing and providing health IT solutions to their customers, health IT developers should be familiar with the types of risks that most users encounter, and therefore must describe these in sufficient detail to provide potential customers, patients, or researchers, with the information they need to make informed applicability, scope, and use decisions.

As for recommendations that we take a risk-based approach to IRM requirements, we appreciate the comment. However, the Program is not predicated on levels of risk and our requirements for certification to the DSI (formerly CDS) criterion has been and continues to be agnostic to specific use cases, intended uses, and risks. We reiterate that we are not establishing requirements for specific measures. Rather, we are giving maximum flexibility for developers of certified health IT to determine which information best fits their unique circumstances and Predictive DSI use cases.

As noted in the HTI–1 Proposed Rule (88 FR 23802), developers of certified health IT have the flexibility to choose an approach to meeting this requirement that addresses their own unique circumstances for their Predictive DSIs. However, we encourage developers to implement policies and controls to evaluate whether risk analysis and risk mitigation practices are being carried out as specified; to consider how policies and controls are monitored and updated; and to plan a schedule for updating those policies and controls. Policies and controls should include details on roles, responsibilities, staff expertise, authority, reporting lines, and continuity. We further encourage developers to have accountability and escalation policies and controls related to how management oversees the development, deployment, and management of Predictive DSIs. These policies and controls should describe the developer of certified health IT's decision-making parameters or programs and include how management is held accountable for the impact of Predictive DSIs. We encourage developers to identify staff that are responsible for Predictive DSIs and related models and to develop policies to hold those staff accountable to the developer's established policies and procedures. We believe that developers should plan escalation processes that permit significant issues with Predictive DSI development, integration, or use to reach appropriate levels of management and describe standards for timely resolution of issues with Predictive DSIs and related models. If the developer uses a third party to assess risk, the developer should describe processes for determining whether assessments performed by a third party meet the standards and controls set forth in the developer's governance framework.

We appreciate the commenter's concerns about meeting the December 31, 2024, deadline, and the desire for an extension. We note that in prioritizing this certification criterion, we have finalized longer timelines for the adoption of other standards and certification criteria with, for example, a compliance date of January 1, 2026. We believe the extended dates for conformance with these other standards and certification criteria will make it more feasible for the industry to meet the December 31, 2024, deadline for the finalized requirements in § 170.315(b)(11). We discuss timing requirements in more detail below in the section on modifications to the “Base EHR.”

After consideration of public comments received, we have finalized with modifications our proposed requirements for IRM practices. Specifically, we have finalized in § 170.315(b)(11)(vi) that IRM practices must be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module. This finalized requirement applies to Predictive DSIs “supplied by the health IT developer as part of its Health IT Module,” which establishes an equivalent scoping between what we proposed under the attestation statement in proposed § 170.315(b)(11)(v) and what we have finalized in § 170.315(b)(11)(vi). As proposed, only those developers that attested “yes,” would have had to employ or engage in IRM practices and as finalized, only developers that supply Predictive DSIs are required to apply IRM practices. We have finalized § 170.315(b)(11)(vi)(A) requiring that Predictive DSIs must be subject to analysis of potential risks and adverse impacts associated with the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy, which is substantially similar to what we proposed. We have finalized § 170.315(b)(11)(vi)(B) requiring that Predictive DSIs must be subject to practices to mitigate risks, identified in accordance with (b)(4)(ii)(A) of this section, which is substantially similar to what we proposed. We have finalized § 170.315(b)(11)(vi)(C) requiring that Predictive DSIs must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used, for all Predictive DSIs supplied by the health IT developer as part of its Health IT Module, which is substantially similar to what we proposed.

We have also finalized requirements in § 170.523(f)(1)(xxi) as part of the Principles of Proper Conduct for ONC–ACB's that an ONC–ACB shall, where applicable, ensure that summary information of the IRM practices listed in paragraph § 170.315(b)(11)(vi) is submitted by the health IT developer via publicly accessible hyperlink that allows any person to access the summary information directly without any preconditions or additional steps. We have finalized this requirement as a combination of what we proposed in § 170.315(b)(11)(vii)(C) and what we proposed as a modification the Principles of Proper Conduct for ONC–ACB in § 170.523(f)(1)(xxi)

Finally, as stated previously, we have finalized a new Assurances Maintenance of Certification requirement in § 170.402(b)(4) that requires developers of Health IT Modules certified to § 170.315(b)(11), starting January 1, 2025, and on an ongoing basis thereafter, review and update, as necessary, source attribute information in § 170.315(b)(11)(iv)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). This requirement is substantially similar to what we had included in our proposal (such as § 170.315(b)(11)(vii)(D)). We provide additional details on § 170.402(b)(4) in previous comment responses in section III.C.5.v. “Predictive Decision Support Interventions, Attestation for Predictive Decision Support Interventions,” of this final rule.

We reiterate that ONC has not adopted specific risk analysis metrics or risk mitigation practices beyond describing eight characteristics in § 170.315(b)(11)(vi)(A) and we note that developers of certified health IT may vary their IRM practices based on their understanding of the risk of each Predictive DSI.

Comments. Several commenters expressed concerns that the nature of the proposed documentation required in the IRM disclosure requirements that developers would have to meet would require a third-party developer to share proprietary technical and governance information and requested clarification on the level of detail required in documentation that IRM practices are employed. One commenter requested clarification on how developers of health IT would meet the proposed documentation requirements in § 170.315(b)(11)(vii)(B) when they would need to obtain the documentation from third-party developers. Several commenters did not support our IRM proposals due to the burdens it would place on health IT developers and recommended that we limit the IRM proposals to health IT developers who develop their own Predictive DSI models.

Response. We thank commenters for their concerns. After consideration of these comments, we have not finalized the requirements described in the HTI–1 Proposed Rule preamble for developers of certified health IT to receive or have access to risk management information for Predictive DSIs developed by other parties (and that are not supplied by the developer as part of its Health IT Module). After consideration of these comments, we have not finalized the requirements described in the HTI–1 Proposed Rule (88 FR 23803) preamble for developers of certified health IT to receive or have access to risk management information for Predictive DSIs developed by other parties (and that are not supplied by the developer as part of its Health IT Module). This means there are no expectations that developers review risk management information from other parties with whom they have no relationship and with whom they have not expressly chosen to supply a Predictive DSI as part of their Health IT Module. This also excludes all other party Predictive DSIs that their customers choose to implement as well as any Predictive DSIs that their customers author.

Comments. Several commenters believed that developers, and not health care providers, should ultimately be responsible for the tools they create and bear responsibility for harmful outcomes resulting from the tools being used as intended. Whereas other commenters suggested that the responsibility for risk assessment and mitigation should be shared with DSI providers and authors of the toolset, rather than requiring the health IT developers to accept all responsibilities.

Response. We appreciate the commenters' concerns. We agree that multiple parties share responsibility for risk assessment and mitigation and the safe application of Predictive DSI, and note that this rule does not alter any party's responsibility for exercising sound professional judgment in making clinical decisions and complying with applicable laws. Developers and health care providers should implement practices in full awareness that this final rule will not change their responsibility under other applicable law. We have finalized requirements aligned with our authorities for developers of certified health IT, and we anticipate these requirements for IRM practices will help spur much-needed conversations across providers and their health IT partners on how best to analyze, mitigate, and govern risks associated with Predictive DSIs.

As noted in the HTI–1 Proposed Rule, we are aware that, in addition to developers of certified health IT, users, such as healthcare organizations and clinicians, have responsibilities related to Predictive DSIs, including intervention or model risk management during implementation and use, as well as model validation (88 FR 23805). For example, we believe it is important that users maintain strong governance and controls to help manage model risk and how they will use outputs from interventions in decision-making, including monitoring any potential impacts of model use. Users of a Predictive DSI are also best able to report on how the Predictive DSI performs in real world and local settings, which can differ from their performance during testing.

Comments. One commenter expressed concern that the proposal was too broad and recommended that ONC exclude from its transparency and risk management requirements any DSI tools that are created by a health care provider organization for its own use, with no intent to commercialize the tool(s). One commenter expressed concern that ONC did not account for the difference between “AI Developers” and “AI Deployers” noting that each has unique and distinct roles, and risk analysis requirements should account for these separate roles.

Response. We appreciate the feedback. As we have noted as part of the certification criterion's discussion throughout this final rule, we have adjusted the scope of the certification criterion and clarified health IT developer responsibilities compared to health care providers and other parties. We clarify, based on the scope and policy for the final certification criterion, that “DSI tools created by a health care provider” for its own use are not in scope for Program requirements. More to the point, such health care providers will benefit from this final certification criterion's requirements because updated certified health IT will include more supportive capabilities for DSI transparency that they will be able to use for their own purposes. We appreciate the comment for differentiating between “AI Developers” and “AI Deployers,” however, we decline to establish different IRM practice requirements for different roles that may, or may not, exist across organizational boundaries. Our requirements pertain specifically to developers of certified Health IT Modules that supply Predictive DSIs as part of their Health IT Module.

Comments. Several commenters expressed concern about the potential liability of health IT developers and health care providers. One commenter expressed concern that some developers may attempt to shift liability for poor performing tools and recommended that the developer of the tool should bear the responsibility of ensuring optimal performance of the tool they developed and should bear the brunt of the liability when errors occur. One commenter recommended that we strengthen the requirements around IRM practices by requiring developers of certified health IT with Health IT Modules that enable or interface with Predictive DSIs to carry liability insurance that covers contingent bodily injury due to technology errors and omissions.

Response. We appreciate the commenter's concern for liability and accountability. We believe that our requirements for transparency in both performance, as indicated by the information required as part of source attributes, and in IRM practices will help users determine if tools are poor performing and make subsequent decisions on whether and how to use such tools. In general, these comments are outside of the scope of this rulemaking, and we decline to require liability insurance as part of our requirements and believe that issues of liability are outside the scope of this rulemaking. Those concerned or curious about it should reference federal, state, or tribal laws and regulations—or reliable sources information.

Comments. One commenter expressed concern that there is no requirement for real world testing in an uncontrolled environment and urged ONC require these activities are tested in real world scenarios before they are adopted to ensure DSIs are successful.

Response. We thank the commenter for their suggestion to require real world testing of Predictive DSIs. We note that among the source attributes listed in § 170.315(b)(11)(iv) there are two that would enable users to know if a Predictive DSI was tested for fairness at § 170.315(b)(11)(iv)(B)( 8)( iii) and (iv) and validity in local data at § 170.315(b)(11)(B)(iv)( 8)( i) and ( ii). These source attributes are intended to support such real world testing; however, we are not requiring that such testing be done, so as noted within the certification criterion these source attributes may be missing. We also note that Health IT Modules certified to § 170.315(b)(11) must participate in real world testing as a Condition and Maintenance of Certification requirement as stipulated in § 170.405.

Risk Analysis

In the HTI–1 Proposed Rule (88 FR 23798–23799), we proposed to require developers of certified health IT to analyze potential risks and adverse impacts associated with a Predictive DSI that their certified Health IT Modules enable or interface with. NIST's AI RMF describes seven characteristics of trustworthy AI, and we proposed to adapt these concepts and require that developers of health IT with certified Health IT Modules that enable or interface with Predictive DSIs employ or engage in risk management practices related to the following characteristics: (1) validity; (2) reliability; (3) robustness; (4) fairness; (5) intelligibility; (6) safety; (7) security; and (8) privacy. We did not propose or describe risk tolerance associated with the eight characteristics, as we believe these should be decisions made by those involved with the design, development, deployment, and use of the technology. We proposed that developers of certified health IT must analyze the potential risks and adverse impacts, associated with a Predictive DSI that their certified Health IT Modules enable or interface with, related to lack or failure in the eight characteristics.

Comments. Several commenters were concerned that ONC did not establish or define regulatory baselines, measures, or thresholds for what constitutes FAVES for Predictive DSIs and noted that providers are not trained to independently assess whether a Predictive DSI was FAVES, nor is there a commonly accepted standard for review. Several commenters expressed concern that the IRM proposals could be duplicative of other federal agencies and could create conflicting regulatory schemes and urged ONC to consult and collaborate with federal partners and build on existing federal efforts to ensure bias, discrimination, and other health equity concerns were addressed through a unified AI government framework. One commenter recommended that the proposed “Safety” characteristic should explicitly exclude FDA-authorized AI and machine learning medical devices because they believe that a risk assessment for these tools is best made by the FDA due to their expertise in medical and clinical safety and being uniquely positioned to draw conclusions and develop guidelines for the safe and appropriate use of AI and machine learning tools.

Response. Given the broad uses of Predictive DSIs, ONC did not seek to establish specific baselines, measures, or thresholds for what constitutes FAVES in the HTI–1 Proposed Rule. These measures are likely to vary based on specific technologies and uses of Predictive DSI. In many cases, the safety and effectiveness of a software function, including clinical decision support or other kinds of decision support interventions, is within the purview of FDA regulatory oversight, when such functionality meets the definition of a “device” under the FD&C Act. As previously noted, ONC and FDA support a harmonized and complementary approach to predictive technology in accordance with our existing intersecting regulatory oversight. We sought to ensure there would be limited, if any, contradictory requirements. We note that we have afforded substantial flexibility to developers in practicing IRM. For tools that have been authorized by the FDA, we believe it would be appropriate for developers to provide information on FDA authorization as part of the “Safety” characteristic. Furthermore, given the intersecting interest across the Department to address the use of AI in health, we consulted extensively with our HHS partners at AHRQ, FDA, and OCR as well as our federal partners at the FTC and VA in developing the HTI–1 Proposed Rule to advance our shared goals of promoting greater trust in Predictive DSIs in healthcare that are fair, appropriate, valid, effective, and safe to deliver patient care, enable an effective marketplace, and greater competition.

After consideration of these comments, we have finalized requirements at § 170.315(b)(11)(vi)(A) that for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, the Predictive DSI must be subject to analysis of potential risks and adverse impacts associated with Predictive DSI the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy. We note that we have narrowed the scope of Predictive DSIs for which a developer is expected to analyze risks and adverse impacts to only those Predictive DSIs that are supplied by the health IT developer. As stated previously, this is in response to public comments concerned with the overall scope of our IRM practice requirements and the related burdens, difficulty, and concerns around potential proprietary information related with getting such information from other parties.

Risk Mitigation

In the HTI–1 Proposed Rule, we proposed to require implementation of practices to mitigate risks associated with Predictive DSIs (88 FR 23801). In the HTI–1 Proposed Rule, we proposed § 170.315(b)(11)(vii)(A)( 2) to require implementation of practices to mitigate risks associated with Predictive DSIs (88 FR 23801). We noted that risk mitigation practices should seek to address adverse impacts or minimize anticipated negative impacts of Predictive DSIs on patients and populations. We stated model risk mitigation should include disciplined and knowledgeable development and implementation practices that are consistent with the real-world context of the model's use, intended specific application of the model, and goals of the model user.

Comments. One commenter expressed concern that some developers may engage in risky practices that result in harm or privacy violations and requested more clarity on how certification criteria would exclude developers from engaging in these practices. One commenter encouraged ONC to clearly define the types of risks or harms that would disqualify a developer from Program certification. One commenter expressed concern that our proposal lacked requirements for DSI systems on managing complaints, post market surveillance, and error or misuse detection guidance, as well as reporting requirements related to these issues.

Response. We thank commenters for their concerns. We note that developers should implement practices in full awareness that this final rule will not change their responsibility under other applicable laws, including those that provide legal protections to minimize risk practices and prohibit discrimination. We expect that model developers will use data for training and testing consistent with applicable law, patients' expectations, and any patient consent or preference given. We decline to further specify practices that would disqualify a developer from the Program, beyond the eight characteristics that must be addressed. As it relates to managing complaints and reporting requirements, we note that ONC has long maintained a “health IT inquiry and feedback portal,” available where users and the public can file complaints and ask questions about products certified under the Program. We also reiterate that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) will be required to engage in real world testing per requirements at § 170.405.

Comments. Several commenters supported our proposal for risk mitigation requirements. Several commenters recommended that ONC adopt a tiered or risk-based approach to IRM practices and adopt requirements that would only apply to applications that present a meaningful risk to patients, allowing ONC to focus on high risk DSIs. These commenters generally supported the assessment of risk in predictive models but stated that requiring all models to adhere to the same set of compliance and regulatory rigor seems both unnecessary and overly burdensome. Some of these commenters also thought a risk-based approach was appropriate for determining whether and which disclosure requirements were necessary to prevent stifling innovation and prevent overly restrictive reviews.

Response. We appreciate the comments supporting our proposal for risk mitigation. We decline to accept the recommendation to take a risk-based DSI approach as suggested. We reiterate that the Program is not predicated on levels of risk and the DSI criterion will continue to be agnostic to specific use cases, intended uses, and risks. As stated in the HTI–1 Proposed Rule (88 FR 23799), we will require the developers of certified health IT engage in and document risk management practices related to eight characteristics: (1) validity; (2) reliability; (3) robustness; (4) fairness; (5) intelligibility; (6) safety; (7) security; and (8) privacy. However, we have provided substantial flexibility in the risk management practices developers engage in within those characteristics and the associated documentation. Developers may therefore choose to apply different levels of rigor to the risk analysis, risk mitigation, and governance of different Predictive DSIs. Similarly, developers of certified health IT may choose to apply different levels of detail describing their approaches to risk management practices as part of the summary information that must be summited per requirements in § 170.523(f)(1)(xxi).

This approach also aligns with HIPAA Security Rule requirements for covered entities and business associates. HIPAA covered entities, such as health care providers and health plans, are generally among the customers of developers of certified health IT. In many cases, developers of certified health IT serve as HIPAA business associates to their covered entity customers, such as health care providers or health plans, and thus must comply with the HIPAA Security Rule. The HIPAA Security Rule requires covered entities and business associates to identify and assess risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI (“ePHI”) when conducting the risk analysis and risk management required by the Security Rule, including any risks of third-party access to a covered entity's or business associate's information systems that contain electronic protected health information.

As noted in the HTI–1 Proposed Rule, similar to when a HIPAA covered entity or business associate engages with a cloud service provider, a developer of certified health IT, supplying an other party -developed Predictive DSI as part of its Health IT Module, should understand the ways in which the technology or solution offered by the other party would seek to connect to or integrate with the certified health IT developer's product(s), so that the covered entity or business associate can appropriately conduct its own risk analysis and establish risk management policies, as well as enter into appropriate Business Associate Agreements (BAAs). For example, a health IT developer providing certified health IT as a business associate may consider including in its risk analysis any risks associated with a decision by a covered entity to connect or integrate an other party's Predictive DSI with the developer's certified health IT products. Under the HIPAA Security Rule, business associates have an independent obligation to identify and manage risks, regardless of whether or not a BAA exists. If a business associate relationship exists and a BAA does not exist, the absence of a BAA does not relieve the business associate from HIPAA Security Rule obligations.

After consideration of these comments, we have finalized at § 170.315(b)(11)(vi)(B) that for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, the Predictive DSI must be subject to practices to mitigate risks, identified in accordance with § 170.315(b)(11)(vi)(A). We note that we have narrowed the scope of Predictive DSIs for which a developer is expected to mitigate risks to only those Predictive DSIs that are supplied by the health IT developer as part of its Health IT Module. As stated previously, this is in response to public comments concerned with the overall scope of our proposed IRM practices requirements and the related burdens, difficulty, and potential proprietary information concerns related with getting such information from other parties.

Governance

In the HTI–1 Proposed Rule, we proposed § 170.315(b)(11)(vii)(A)( 3) to require that developers of certified health IT establish policies and implement controls for Predictive DSIs (88 FR 23802). We proposed that a developer of a certified Health IT Module that enables or interfaces with a Predictive DSI must establish policies and implement controls for how data are acquired, managed, and used for said Predictive DSI. Governance should encompass models, software and data developed or provided by other parties as well as internally developed interventions.

At 88 FR 23802–23803, we provided a discussion of the flexibility developers of certified health IT would have to choose an approach to meeting this proposed requirement that addresses their own unique circumstances for their Predictive DSIs. This included setting and enforcing priorities for managing and using data as a strategic asset, which is a concept that identifies key activities of data governance as data identification, data management policy, data issues management, data assessment, data oversight, and data communications.

Comments. Several commenters supported our requirement to include “governance” as part of the IRM practices. However, many commenters also expressed concern regarding our expectation that developers of certified health IT review governance information from other parties or that other parties provide the developer of certified health IT with relevant IRM information so that such information may be available for both detailed and summary documentation.

Response. We appreciate commenters' concerns. In response to public comments, we have not finalized the requirements described in the HTI–1 Proposed Rule for developers of certified health IT to receive or have access to specific risk management information from other parties except when the health IT developer supplies an other party Predictive DSI as part of its Health IT Module. We have finalized as part of Governance requirements in § 170.315(b)(11)(vi)(C), that for each Predictive DSI supplied by the developer as part of its Health IT Module, the Predictive DSI must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used. As a result, we clarify that the expectation described in the HTI–1 Proposed Rule that developers receive or have access to risk management information for Predictive DSIs developed by other parties is generally inapplicable, unless the developer of health IT is the one supplying the other party' s Predictive DSI as part of its Health IT Module.

The NIST AI RMF Govern Section 6 discusses a need for policies and procedures to be in place to address AI risks and benefits arising from third-party software and data. We note that while not required to follow the NIST AI RMF, developers of certified health IT may wish to review Govern Section 6 as this section provides a number of suggested actions and documentation questions that we believe would be informative towards meeting governance requirements. Similarly, The Office of the Comptroller of Currency similarly described several best practices related to risk management of models developed by third parties, including seventeen specific items included on its internal control questionnaire. Many of these practices could apply to the development of governance processes pertaining to risk management of models authored by other parties including, for example, “When relying on third-party models, does management obtain ongoing performance monitoring and outcomes analysis of the model conducted by third parties”.

Compile Detailed IRM Practice Documentation

In the HTI–1 Proposed Rule, we proposed that a health IT developer that attests “yes” as part of proposed § 170.315(b)(11)(v)(A) would need to compile detailed documentation regarding IRM practices and upon request from ONC make available such detailed documentation to ONC for any Predictive DSI, as defined in § 170.102, that the certified Health IT Module enables or interfaces with (88 FR 23803). We noted our belief that a developer of certified health IT subject to this proposed requirement should be able to provide detailed documentation of their IRM practices, if ONC requests such information, without much effort because this information should be a byproduct of employing or engaging in IRM practices.

Comments. Several commenters were not supportive of the proposed requirements for detailed documentation of IRM practices and expressed concern that including the term “interfaces with” as it relates to the proposed IRM practices results in a policy that is too broad. Specifically, commenters noted that obtaining detailed documentation related to a third party's DSI tool is neither feasible nor competitively rational and recommended that we limit the scope so that developers are accountable for IRM practices for its own DSI only. One commenter requested clarification on how developers of health IT would meet the proposed documentation requirements when they would need to obtain documentation from third-party developers.

Response. As discussed throughout this section, we have finalized a more specific and limited scope for Predictive DSIs that are supplied by the health IT developer as part of its Health IT Module. After consideration of these comments, we have not finalized the proposals requiring developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) to compile detailed documentation regarding the IRM practices listed in paragraph (b)(4)(iii) of this section and upon request from ONC, make available such detailed documentation for each Predictive DSI.

Request for Comment

• Users of Certified Health IT and Predictive DSI Management

This request for comment included in the HTI–1 Proposed Rule (88 FR 23805–23806) focused on the DSI section, and we sought input on shared responsibilities with users related to FAVES DSIs, including intervention or model risk management during implementation (deployment) and use, as well as model validation. We welcomed technical and policy comments on this section. We received many insightful comments on this request for comment. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.

• Data Practices and Governance: Ethical, Legal, and Social Implications of Data Collection and Use

This request for comment included in the HTI–1 Proposed Rule (88 FR 2380– 23807) focused on the DSI section and related to ONC's authorities under the HITECH Act and the Cures Act with respect to adopting standards, implementation specifications, and certification criteria as part of the Program, overseeing developers of certified health IT through Conditions and Maintenance of Certification requirements, and serving in a coordinating role with respect to health IT. We welcomed technical and policy comments on this section. We received many insightful comments on this request for comment. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking. We will also share relevant comments with our federal partners in the Department.

• Technical Data Standards and Data Management: Electronic Data Source, Capture, and Use

This request for comment included in the HTI–1 Proposed Rule (88 FR 23808) focused on the DSI section and how ONC can further support standardization and harmonization in these areas. We welcomed technical and policy comments on this section. We received many insightful comments on this request for comment. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.

xii. Public Disclosure and Availability of Summary Documentation and Corresponding Proposals for ONC–ACBs in § 170.523(f)(1)(xxi)

In the HTI–1 Proposed Rule, we proposed that a health IT developer that attested “yes” consistent with our other proposals would need to submit summary information of the IRM practices to its ONC–ACB via publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps (88 FR 23804). We also proposed a new Principle of Proper Conduct for the ONC–ACBs to require ONC–ACBs to report the proposed summary information that they received from developers of certified health IT on the Certified Health IT Product List (CHPL) for the applicable Health IT Modules. We noted our belief this new Principle of Proper Conduct is consistent with existing public disclosure requirements ( e.g., 45 CFR 170.523(f)(1)(xii) and § 170.523(f)(1)(xx)) under the Program and would help ensure accountability for the public availability of information. We proposed to require that this summary information be made available to ONC–ACBs via publicly accessible hyperlink by December 31, 2024.

We stated that “summary information” should describe risk management practices we enumerated in our proposals for the Predictive DSIs with which a certified Health IT Module enables or interfaces within general terms. We noted that “summary information,” is not specific to any single Predictive DSI. Rather, the information pertains to the suite or portfolio of Predictive DSIs enabled by or interfaced with the certified Health IT Module. We noted that the summary information likely encompasses variation in risk management practices for different kinds of Predictive DSIs.

Similar to our policy associated with the API-focused certification criteria in § 170.315(g)(10)(viii)(B), at 88 FR 23805, we proposed that all IRM documentation be available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. We clarified that for the proposed IRM documentation, summary information would need to be submitted to the developer of certified health IT's ONC–ACB for review prior to issuing a certification. The availability of documentation as part of the certification process is also consistent with existing requirements for API documentation in § 170.315(g)(10)(viii)(B) (API documentation requirements were proposed in the Cures Act Proposed Rule (84 FR 7484) and finalized in the ONC Cures Act Final Rule (88 FR 25748)).

To support submission of documentation, and consistent with other Principles of Proper Conduct in § 170.523(f)(1), we proposed a new Principle of Proper Conduct for IRM practice documentation in § 170.523(f)(1)(xxi) that ONC–ACBs report the information required in § 170.315(b)(11)(vii)(C) on the CHPL for the applicable certified Health IT Modules. We believe this new Principle of Proper Conduct will assist in promoting greater transparency for the Program and will strengthen ONC–ACB oversight regarding IRM documentation.

Comments. Several commenters expressed concern with the proposed requirement to make summary information about IRM practices available publicly because they believed it would require developers to risk revealing their intellectual property or proprietary information, increase administrative burdens, provide little value to the public, and potentially create imbalance in the marketplace. A few commenters suggested that the non-public information that the developer makes available to prospective and existing clients as part of Program certification requirements is sufficient to demonstrate adequate IRM practices. Another commenter recommended flexibility for health care providers that develop health IT solutions specific for use within their EHR platform so that disclosure of proprietary model information would be permissive.

Response. We appreciate and understand commenters concerns about revealing proprietary information. However, we do not agree that intellectual property or trade secrets are jeopardized through publication of summary risk management information. Our final policy gives developers of certified health IT flexibility to determine what information to describe at what level of detail they feel is most appropriate. To clarify, the summary information of IRM practices requirement do not need to include public disclosure of specific information on code, model tuning, parameter or hyperparameter selection, or details on how individual input or output variables were selected or operationalized, which we understand to form the underpinnings of developers concerns related to intellectual property. We encourage developers to provide information that they determine would be useful to inform potential users of whether a model is FAVES without providing information at the level of detail that might constitute proprietary information.

We recognize there may be some burden associated with making summary information of IRM practices publicly available but we believe the benefits of such transparency outweigh those burdens, especially given that we have not required generation of more detailed IRM practice information as proposed. A primary objective of our policy is to increase trust in the development and use of Predictive DSIs and this includes making summary information on risk management practices available to patients, researchers, policymakers, and other interested parties.

Comments. Some commenters expressed support for the proposed requirement to make summary information regarding IRM publicly accessible. One commenter urged ONC to include an additional requirement to require a developer to enclose an intelligible end-user fact sheet that would disclose data used for training, potential risks, concerns for bias, performance, and generalizability, at a minimum, and in clear, concise language.

Response. We appreciate the comments and suggestions. We note that much of the information the commenters requested is included within the source attributes listed at § 170.315(b)(11)(iv). We decline at this time to require developers to disclose source attribute information publicly, but we have finalized the requirement to publicly disclose summary of IRM practices.

After consideration of these comments, we have finalized requirements proposed in § 170.523(f)(1)(xxi) requiring that ONC–ACBs shall, where applicable, ensure that summary information of the IRM practices listed in paragraph § 170.315(b)(11)(vi) is submitted by the health IT developer via publicly accessible hyperlink that allows any person to access the summary information directly without any preconditions or additional steps.

xiii. Annual Review

Finally, in the HTI–1 Proposed Rule at § 170.315(b)(11)(vi)(D), we proposed to require developers of certified health IT that attested “yes” to review annually and, as necessary, update detailed and summary documentation (88 FR 23805). We noted that we viewed the detailed documentation required as being a by-product of the proposed requirement for the developer of certified health IT to engage or employ in IRM practices. Thus, we expect that developers of certified health IT subject to this proposed requirement would review documentation associated with their IRM practices annually and, as necessary, update their documentation. Further, we noted our belief that developers of certified health IT that attested “yes” would consider risk as part of ongoing development cycles, and these risks should be assessed in a timely manner so that risk analysis documentation is up to date. Similar to the HIPAA Security Rule, which requires covered entities and business associates to conduct ongoing risk analysis, we proposed that developers of certified health IT with Health IT Modules that enable or interface with Predictive DSIs review their IRM practices and update their documentation as necessary.

As noted in the HTI–1 Proposed Rule, we considered an annual review as a way to establish a minimum expectation for updating IRM documentation, and believed that would be good for Predictive DSIs to undergo a full validation process at some fixed interval, including updated documentation of all related activities (88 FR 23805). As noted in the HTI–1 Proposed Rule, we considered an annual review as a way to establish a minimum expectation for updating IRM documentation, and we believed that would be good practice for Predictive DSIs to undergo a full validation process at some fixed interval, including updated documentation of all related activities (88 FR 23805). While we did not propose more frequent reviews, we stated those may be appropriate for developers of certified health IT that have Health IT Modules that enable or interface with numerous or complex Predictive DSIs.

Comments. We did not receive substantive feedback regarding this requirement for annual review.

Response. As a result, consistent with all other policy changes we have made for this final certification criterion, we have finalized requirements in § 170.402(b)(4) that developers with Health IT Modules certified to § 170.315(b)(11), starting January 1, 2025 and on an ongoing basis thereafter review and update, as necessary, information in § 170.315(b)(11)(v)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). As noted previously (see prior comment responses in “v. Predictive Decision Support Interventions, Attestation for Predictive Decision Support Interventions”), we have determined that a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification is necessary to fully implement our policy objectives and proposals. We believe that this finalized policy is substantially similar to what we proposed in § 170.315(b)(11)(vii)(D). Moreover, we believe that this finalized policy maintains a substantially similar, or reduces, scope for developers of certified health IT, depending on whether they supply a Predictive DSI as part of its Health IT Module. For developers of certified health IT that would have attested “no” to our proposed attestation statement, these developers do not supply a Predictive DSI as part its Health IT Module and, therefore, do not have IRM practices or IRM summary information that needs to be reviewed and updated. For developers of certified health IT that would have attested “yes” to our proposed attestation statement, these finalized requirements are a reduction in scope given our focus on Predictive DSIs supplied by a health IT developer as part of its Health IT Module, as compared to our proposed scope of Predictive DSIs enabled or interfaced with a Health IT Module. The requirements proposed are the same as the requirements finalized for these developers of certified health IT that must review and update, as necessary, risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi).

As for the finalized requirement in § 170.402(b)(4) to review and update source attribute information in § 170.315(b)(11)(v)(A) and (B), we believe this is a clearer articulation of our intention proposed at § 170.315(b)(11)(vi)(A) and (C). This annual review process clarifies expectations that developers of certified health IT must review and update, as necessary, on an ongoing basis the source attribute information that was proposed to be available for user review in § 170.315(b)(11)(vi)(A) and (C).

xiv. Update From Clinical Decision Support to Decision Support Intervention Criterion

At 88 FR 23808, we proposed modifications to the Base EHR definition in § 170.102 to identify that a Health IT Module can be certified to either § 170.315(a)(9) or § 170.315(b)(11) to satisfy the definition for the period up to and including December 31, 2024. We also proposed that § 170.315(a)(9) would no longer be included as part of the Base EHR definition after December 31, 2024. Rather, only § 170.315(b)(11) and not § 170.315(a)(9) will be available as a certification criterion to satisfy the definition of Base EHR beginning January 1, 2025.

Additionally, in § 170.315(a)(9)(vi) we proposed that the adoption of § 170.315(a)(9) would expire on January 1, 2025, for purposes of the Program. Together, these proposals identified the dates when § 170.315(b)(11) replaces § 170.315(a)(9) in the Base EHR definition, and they indicated when Health IT Modules certified to § 170.315(a)(9) will need to be certified to § 170.315(b)(11) to maintain compliance with the Base EHR definition.

Comments. Several commenters were not supportive of the proposed requirement to developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) who wish for those Health IT Modules to continue to meet the Base EHR definition would need to certify those Health IT Modules to § 170.315(b)(11) by December 31, 2024, and requested that the timeframe be extended due to the feasibility of implementation. Specifically, commenters requested a compliance timeframe of 24–36 months from final rule to design, program, test, certify, deploy to customers and real word test any new certification requirements for DSI.

Response. We thank commenters for their comments regarding our proposal to modify the Base EHR definition in § 170.102 to identify the dates when § 170.315(b)(11) replaces § 170.315(a)(9) in the Base EHR definition. As part of a broader timing strategy, and in acknowledgement of the important work related to Predictive DSI transparency that is needed now, we have finalized our proposal that the reference to § 170.315(a)(9) as part of the Base EHR definition in § 170.102, thus its availability as a certification criterion in the Program, would expire January 1, 2025. We have finalized that developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) who wish for those Health IT Modules to continue to meet the Base EHR definition would need to certify those Health IT Modules to § 170.315(b)(11). We also note for purposes of the Program that the certification criterion at § 170.315(a)(9) expires on January 1, 2025.

b. Updates to Real World Testing Condition for CDS Criterion

At 88 FR 23808–23811, we proposed to revise § 170.405(a) to include § 170.315(a)(9) within the list of certification criteria for which a developer of certified health IT with Health IT Module(s) certified to such criteria must successfully test the real world use of those Health IT Module(s) for interoperability in the type of setting in which such Health IT Module(s) would be or are marketed. As proposed, this meant that a developer of certified health IT with a Health IT Module certified to § 170.315(a)(9) would be subject to the requirements set forth in § 170.405(a) (88 FR 23808). We noted that the effects of including Health IT Modules certified to § 170.315(a)(9) in § 170.405(a) and the effect of proposing a revised version of the CDS criterion in § 170.315(b)(11) would require developers of certified health IT certified to § 170.315(a)(9) and § 170.315(b)(11) to follow the testing plans, methods, and results reporting; submission dates; and August 31 deployment deadline requirements in § 170.405(b) similar to the requirements of other applicable certification criteria listed in § 170.405(a) (88 FR 23809). We anticipated that if finalized as proposed this would mean that Health IT Modules certified to § 170.315(a)(9) would be subject to the real world testing Condition and Maintenance of Certification requirements beginning with the 2023 real world testing cycle.

Comments. Commenters were mixed in their support and opposition to our proposal to add § 170.315(a)(9) to the list of applicable certification criteria for the real world testing Condition and Maintenance of Certification requirement in § 170.405(a) and thus requiring developers certified to § 170.315(a)(9) or § 170.315(b)(11) to participate in real world testing plan and results submission. Commenters that did not support including § 170.315(a)(9) in the list of applicable criteria for real world testing Condition and Maintenance of Certification requirements stating that it would be infeasible, and a poor investment of time and resources given the possible timing of this final rule publication in conjunction with requirements for 2024 real world testing plan submissions in November of 2023. Commenters stated that it would create significant developer burden to meet this requirement for a criterion that developers could not certify to after December 31, 2024. Many of these commenters instead said we should limit real world testing requirement to developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11). Commenters suggested that by only including § 170.315(b)(11) then ONC and developers could focus resources on a revised criterion instead of a retired criterion. Commenters also recommended a phased approach for the inclusion of Predictive DSI into real world testing given the burden on developers to implement other proposals in the rule, notably the new Insights Condition and Maintenance of Certification requirements.

Commenters who were supportive of the proposal to add § 170.315(a)(9), thus requiring developers certified to § 170.315(b)(11) to participate in real world testing, stated that it would have the benefit of testing predictive models in a diverse range of real world clinical settings, thereby creating a more accurate, comprehensive, and contextual understanding of a model's performance. Commenters noted that including CDS will help ensure implementation of the CDS Criterion, future certification criteria, and other elements discussed in this rule are effective, efficient, minimally burdensome, and beneficial, and would ensure intended performance in practice. One commenter stated that adding CDS to real world testing will give developers an opportunity to determine if the user community is using their interventions, and if so, the ability to determine how the interventions are being used. Lastly, one commenter believed that testing decision support intervention technology and predictive models successfully for real world use enhances interoperability and patient care experience in which certified Health IT Modules would be marketed.

Response. We appreciate comments regarding our proposal to revise § 170.405(a) to include § 170.315(a)(9). Given the mixed support from commenters and finalization of our policy to replace § 170.315(a)(9) with § 170.315(b)(11) as of January 1, 2025, we have not finalized our proposal to modify § 170.405(a) to include Health IT Modules certified to § 170.315(a)(9). We agree with commenters that requiring developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) to engage in real world testing for only the period of time before the revised criterion expires is unnecessary. We continue to believe there is value for developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) to demonstrate how their support of evidence-based CDS and linked referential CDS positively impacts patient care through real world testing plans and results; however, we think it would be more important for developers of certified health IT to spend time and resources conforming to requirements in § 170.315(b)(11) and § 170.402(b)(4) by January 1, 2025.

We note that because all criteria in § 170.315(b) are already subject to real world testing requirements in § 170.405, Health IT Modules certified to § 170.315(b)(11) prior to August 31, 2024, would need to, among other requirements, address each of the elements in § 170.405(b)(1)(iii)(A) through (G) in their real world testing plans by December 15, 2024, and submit results based on those plans no later than March 15, 2026.

We appreciate those commenters who supported our proposals for real world testing because it would have various benefits for more accurate, comprehensive, and contextual understanding of a model's performance. We also appreciate the commenters that stated how real-world testing will give developers an opportunity to determine if the user community is using their interventions, and if so, the ability to determine how the interventions are being used. We agree and we encourage developers of certified health IT to consider ways to demonstrate validity or fairness of Predictive DSIs in local data as a means to fulfill the requirements for real world testing plans and results.

Comments. A minority of commenters did not support including either § 170.315(a)(9) or § 170.315(b)(11) in real world testing and stated neither certification criterion appropriately fit the stated intent for the scope of Real world Testing Condition and Maintenance of Certification. One commenter recommended including § 170.315(a)(9) in real world testing, with the proposed updates, but only if ONC would keep § 170.315(a)(9) as a certification criterion and add § 170.315(b)(11) as a separate certification criterion, noting that requiring real world testing for Predictive DSI immediately after development and implementation is overly burdensome for developers.

Response. We appreciate these comments and we have not finalized our proposal to modify § 170.405(a) to include Health IT Modules certified to § 170.315(a)(9). We note that certification criteria at § 170.315(b) are already subject to real world testing requirements identified in § 170.405; thus, Health IT Modules certified to § 170.315(b)(11) will be subject to the same requirements currently applied to Health IT Modules certified to § 170.315(b)(1), for example. We believe real world testing would not be overly burdensome with the implementation of the DSI requirements under § 170.315(b)(11).

Comments. A few commenters questioned the logistics of real world testing CDS and DSI criteria and sought clarity on how the proposed real world testing plan will be assessed. Specifically, one commenter sought clarity on how real world testing would impact a health plan's existing operations. One commenter suggested that certification testing could be accomplished using a test data set that incorporates synthetic patient records containing a wide range of demographic and health condition information, including rare diseases and conditions, noting that DSI training and testing data should be developed in collaboration with provider, patient, research, and health IT partners and made available to all parties in a standardized, computable format. In the interest of program flexibility, one commenter suggested that real world testing of CDS should allow for some types of survey or questionnaire form for providers to offer feedback on the value and use of CDS in the EHR rather than trying to capture analytics or metrics on CDS use from the EHR as developers are required to do with other real world testing criteria.

Response. We note that we did not propose any changes to the requirements of real world testing plans and results submission, which are currently described in § 170.405(b)(1)–(2). We also invite readers to review discussion in the ONC Cures Act Final Rule at 85 FR 25766 and visit the numerous resources we have developed to support ongoing implementation of the real world testing Condition and Maintenance of Certification requirements at https://www.healthit.gov/topic/certification-ehrs/real-world-testing.

6. Synchronized Clocks Standard

We proposed at 88 FR 23811 to remove from 45 CFR 170.210(g) the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905). However, we proposed to amend 45 CFR 170.210(g) so that Health IT Modules certified to applicable certification criteria continue to utilize any Network Time Protocol (NTP) standard that can ensure a system clock has been synchronized and meets time accuracy requirements. The applicable certification criteria that either reference the NTP standard, revised in § 170.210(g), or cross-reference a provision that references § 170.210(g), include § 170.315(d)(2), § 170.315(d)(3), § 170.315(d)(10), and § 170.315(e)(1) (88 FR 23811).

Comments. Commenters, including health information technology companies, consumer and patient advocacy groups, health IT expert organizations, and professional trade associations, uniformly agreed with our proposal to remove the named standard in § 170.210(g) and instead require the date and time recorded utilize a system clock that has been synchronized using any NTP standard. Several commenters welcomed the flexibility offered by this approach to use updated versions of NTP or specified versions of NTP, such as Microsoft's MS–SNTP. One commenter noted support for our proposal but urged consistency across organizational networks and systems to ensure that the same network time protocol is used across all servers and platforms.

Response. We appreciate the commenters' support for this proposal. We have finalized the changes as proposed, including the removal of a named standard in § 170.210(g), but we will require Health IT Modules to utilize a system clock that has been synchronized using any NTP standard.

Comments. A health IT expert organization requested ONC comment on the NTP test procedure by either explicitly removing the demonstration requirement or describing a test procedure to demonstrate time server accuracy to accommodate a variation in time services used.

Response. We thank the commenter for the comment. While the request is outside the scope of this final rule because conformance methods, including testing procedures, are not determined as part of notice and comment rulemaking, we will consider updating the test procedures in the future.

7. Standardized API for Patient and Population Services

In the HTI–1 Proposed Rule, we proposed to reorganize § 170.215 to delineate the purpose and scope more clearly for each type of standard or implementation specification (88 FR 23812). We refer readers to the HTI–1 Proposed Rule (88 FR 23812) for additional background history. We proposed to revise the structure of § 170.215 as follows:

Application Programming Interface Standards.

(a) API base standard.

(b) API constraints and profiles.

(c) Application access and launch.

(d) Bulk export and data transfer standards.

(e) API authentication, security, and privacy.

Comment. We received one comment supporting the revision of the structure of the API related standards.

Response. We thank the commenter for their support. We have finalized the revised structure of § 170.215 as proposed. This restructuring will impact cross-references in the certification criterion at § 170.315(g)(10) in several subparagraphs, including § 170.315(g)(10)(i)(A) and (B); § 170.315(g)(10)(ii); § 170.315(g)(10)(iv)(A) and (B); § 170.315(g)(10)(v)(A)( 1)( i) and ( ii); § 170.315(g)(10)(v)(A)( 2)( i) and ( ii); § 170.315(g)(10)(v)(B); and § 170.315(g)(10)(vii).

a. Native Applications and Refresh Tokens

In an interim final rule (IFR) published on November 4, 2020 (85 FR 70064), we addressed an ambiguity regarding how our refresh token requirements, in § 170.315(g)(10)(v)(A), would apply to “native applications.” In response to public feedback in the IFR and subsequent interaction with interested parties, a history of which can be found in the HTI–1 Proposed Rule (88 FR 23812), we proposed in the HTI–1 Proposed Rule to remove mention of “applications capable of storing a client secret” from § 170.315(g)(10)(v)(A)( 1)( ii) and § 170.315(g)(10)(v)(A)( 2)( ii), as well as to revise § 170.315(g)(10)(v)(A)( 1)( ii) to state, “A Health IT Module's authorization server must issue a refresh token valid for a period of no less than three months to applications using the `confidential app' profile according to an implementation specification adopted in § 170.215(c)” (88 FR 23813). We also proposed to revise § 170.315(g)(10)(v)(A)( 2)( ii) to state, “A Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications using the `confidential app' profile according to an implementation specification adopted in § 170.215(c)” (88 FR 23813). We stated that these proposed revisions would better reflect a Health IT Module's obligation for first time and subsequent connection refresh tokens using concepts familiar to industry and according to the HL7 FHIR SMART Application Launch Framework Implementation Guide (IG). We noted that existing requirements for Health IT Modules to issue a refresh token to native applications, consistent with § 170.315(g)(10)(v)(A)( 1)( iii), remained unchanged.

We also stated in the HTI–1 Proposed Rule that we would continue to monitor implementation of § 170.315(g)(10), engage with the standards development community, and provide information through existing ONC Certification Companion Guides (CCGs), the ONC API Resource Guide, and other educational materials.

Comments. Many commenters expressed support for our proposal to revise § 170.315(g)(10)(v)(A)( 1)( ii) and ( 2)( ii) to reference the “confidential app” profile defined in the HL7 FHIR SMART Application Launch Framework IG as part of our refresh token support requirements. Several of these commenters expressed appreciation for our reference to an industry standard and noted the important role of this standard for driving consistent implementations and interoperability.

Response. We appreciate the feedback from commenters. We have finalized our revisions to § 170.315(g)(10)(v)(A)( 1)( ii) and ( 2)( ii) as proposed.

Comments. Some commenters raised concerns around the impacts to app developers of breaking API changes, particularly changes that affect refresh token validity. These commenters suggested requirements that app developers be given advance notification of upcoming breaking changes that affect refresh tokens.

Response. We appreciate these commenters' concerns and suggestions. We remind commenters of the scope of our revisions to § 170.315(g)(10)(v)(A)( 1)( ii) and ( 2)( ii ) in this final rule, and specifically note that our revisions do not change certain previously finalized requirements around refresh tokens, namely that Health IT Modules certified to § 170.315(g)(10) must issue refresh tokens valid for a period of no less than three months. We also remind commenters of our existing API Conditions and Maintenance of Certification requirements at 45 CFR 170.404, which apply to developers of certified health IT with Health IT Modules certified to § 170.315(g)(10). Specifically, at § 170.404(a)(4)(iii), we have “service and support obligations” that Certified API Developers must abide by. These obligations include requirements for Certified API Developers to “make reasonable efforts to maintain the compatibility of its certified API technology and to otherwise avoid disrupting the use of certified API technology in production environments” by API Users. While we appreciate the specific suggestions from commenters for added requirements, we decline to add these requirements in this final rule. In the circumstance where a Certified API Developer must make a change to their technology that affects refresh token validity, we expect that the Certified API Developer abide by the obligations referenced above to enable the continued and effective production use of their certified API technology.

Comments. Some commenters suggested that refresh tokens for non-patient facing applications should be reviewed on a case-by-case basis for security reasons. One commenter asked that we clarify that apps may, at times, be required to request a new token with new access scopes instead of using a refresh token and that this is not a violation of our refresh token policies. Another commenter suggested that we change the requirements for the duration of refresh tokens and that three months is not always appropriate in all cases.

Response. We appreciate these suggestions from commenters. We do not agree that we should include separate requirements for refresh tokens that apply only in non-patient facing application use cases at this time. We remind this commenter of what we stated in the ONC Cures Act Final Rule at 85 FR 25746—25747 when responding to commenters who similarly raised security concerns and suggested we finalize different requirements for refresh tokens based on patient versus non-patient facing application use cases. Those sections of the ONC Cures Act Final Rule also clarify what implementers of § 170.315(g)(10)-certified Health IT Modules are allowed to do regarding refresh token length and clarify what practices we see as restricted. We stated in the ONC Cures Act Final Rule that “[r]efresh tokens are commonly used in healthcare and other industries” and that “implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from changing the length of refresh tokens for users of the API including patients and providers to align with their institutional policies.” We also stated that “implementers of § 170.315(g)(10)-certified Health IT Modules should be mindful of information blocking provisions applicable to them and that requiring patients to re-authenticate and re-authorize at a high frequency could inhibit patient access and implicate information blocking” (85 FR 25747).

Regarding duration of refresh tokens, we again remind commenters of what we clarified in the ONC Cures Act Final Rule where we noted that “we believe a refresh token valid for a period of three months is sufficient to balance persistent access and security concerns” (85 FR 25747). We also stated that implementers ( e.g., hospitals) “of § 170.315(g)(10)-certified Health IT Modules are not prohibited from changing the length of refresh tokens for users of the API, including patients and providers, to align with their institutional policies. Further, implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from implementing their § 170.315(g)(10)-certified Health IT Modules in accordance with their organizational security policies and posture, including by instituting policies for re-authentication and re-authorization ( e.g., providers and/or patients could always be required to re-authenticate and re-authorize after a set number of refresh tokens have been issued)” (85 FR 25747). Further, we clarify that § 170.315(g)(10)-certified Health IT Modules may require a new authorization request from an application to provision that application with scopes not already granted.

In acknowledgement of the comments received, we have finalized our requirements in § 170.315(g)(10)(v)(A)( 1)( ii) and ( 2)( ii) to reference the “confidential app” profile defined in the HL7 FHIR SMART Application Launch Framework as proposed.

b. FHIR United States Core Implementation Guide Version 5.0.1

In the HTI–1 Proposed Rule, 88 FR 23813 to 238144, we included a proposal to adopt the FHIR US Core IG v5.0.1 in § 170.215(b)(1)(ii) and incorporate it by reference in § 170.299. We noted that based on the annual US Core release cycle, the FHIR US Core IG v6.0.0 would likely be published between the release of the HTI–1 Proposed Rule and our finalization of this final rule. Assuming the FHIR US Core IG v6.0.0 was published prior to the release of this final rule, we stated that we would consider adopting v6.0.0 rather than v5.0.1. We stated our belief that the FHIR US Core IG v6.0.0 would support the data elements and data classes in USCDI v3, which we also proposed to adopt in the HTI–1 Proposed Rule.

In addition, we proposed to update some of the cross-references to the FHIR US Core IG v3.1.1 in § 170.215(a)(2) in § 170.315(g)(10)(i)(A) and (B), (ii)(A) and (iv)(A) to instead refer to FHIR US Core IG v5.0.1. Finally, we proposed to restructure the standards in § 170.215 to better categorize API standards and to enable simultaneous use of different versions of IGs for a set period. For example, we proposed categorizing the US Core IG v3.1.1 in § 170.215(b)(1)(i) as part of a group of standards for constraining and profiling data elements, and we proposed that the adoption of this standard would expire on January 1, 2025. We proposed to include the US Core IG v5.0.1 in this same group in § 170.215(b)(1)(ii).

Comments. Commenters overwhelmingly supported our proposal to advance the version of the FHIR US Core IG included in § 170.215 and incorporated by reference in § 170.299. Most of the commenters specifically voiced support for including the FHIR US Core IG v6.0.0, which was published in May 2023 and supports the data elements and data classes in USCDI v3. We did not receive any comments in favor of adopting the FHIR US Core IG v5.0.1 rather than v6.0.0. Commenters noted that the FHIR US Core IG v6.0.0 aligns with our proposals elsewhere in the HTI–1 Proposed Rule, including our proposals to adopt USCDI v3 and the SMART v2 IG.

We received only one comment in opposition to the proposal to advance the version of the FHIR US Core IG, which expressed concerns about the limited amount of time for developers to test and implement v5.0.1. While still supportive of advancing the version of the FHIR US Core IG, several other commenters also expressed concerns about the timelines for adoption of the latest version. These commenters urged ONC to acknowledge the development time and effort required to support a newer version of the US Core FHIR IG and consider extending the deadline for certification to a newer version.

Response. We thank the commenters for their support. The HL7 standards development community published FHIR US Core 6.0.0 in May 2023. As anticipated, FHIR US Core 6.0.0 added new and updated FHIR profiles to represent new data elements and classes included in USCDI v3. We considered adopting FHIR US Core 5.0.1 and FHIR US Core 6.0.0 and using the Standards Version Advancement Process (SVAP) to enable developers of certified health IT to use FHIR US Core 6.1.0 to certify Health IT Modules that require support of the USCDI. However, we concluded that this would be insufficient to achieve our policy objectives for improved interoperability and lead to misalignment in the marketplace. This is because use of the SVAP by developers of certified health IT is voluntary and experience to-date indicates that a minority of developers of certified health IT choose to avail their Health IT Modules to use newer standards. Adopting FHIR US Core 6.1.0 establishes a consistent baseline across all Health IT Modules certified to criteria that reference the USCDI and provides clarity to developers of certified health IT regarding which version of the US Core IG they are expected to use in support of USCDI v3 and which version they can expect to encounter when interacting with other actors in the health IT ecosystem, industry-wide.

After the publishing of FHIR US Core 6.0.0, HL7 found errors with how the guide implemented data elements in USCDI v3 and had to make updates to the specification to align with USCDI v3 and ensure that USCDI v3 can be implemented in Health IT Modules. Adopting FHIR US Core 6.1.0 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real world implementation (see, for example, 85 FR 25677 and 25708).

We have finalized the adoption of the FHIR US Core 6.1.0 in § 170.215 and incorporated it by reference in § 170.299. We have also finalized our proposal to restructure the standards in § 170.215 and adopted the FHIR US Core 6.1.0 at § 170.215(b)(1)(ii). Likewise, we have finalized our proposal to categorize the FHIR US Core IG v3.1.1 in § 170.215(b)(1)(i) as part of a group of standards for constraining and profiling data elements and have finalized our proposal that the adoption of this standard would expire on January 1, 2026. With regard to concerns about compliance dates, we refer readers to the discussion in section II.C (General Comments on the HTI–1 Proposed Rule) of this final rule.

c. FHIR Endpoint for Service Base URLs

In the ONC Cures Act Final Rule, we finalized API Maintenance of Certification requirements in 45 CFR 170.404(b)(2) which contain a specific provision requiring Certified API Developers, for Health IT Modules certified to the certification criterion in § 170.315(g)(10), to publicly publish certain “service base URLs”—otherwise known as “endpoints”—for all their customers and in a machine-readable format at no charge (85 FR 25764—25765). These electronic endpoints are the specific locations on the internet that make it possible for apps to access EHI at the patient's request.

As we developed these service base URL publication requirements in the ONC Cures Act Final Rule, we acknowledged the importance of industry alignment and standardization in this area by indicating that we “strongly encourage API Technology Suppliers, health care providers, HINs and patient advocacy organizations to coalesce around the development of a public resource or service from which all interested parties could benefit” (84 FR 7494). We ultimately did not adopt specific standards for the publication format of these service base URLs in the ONC Cures Act Final Rule to provide industry an opportunity to coalesce on specifications. We finalized § 170.404(b)(2) to require that Certified API Developers must make their service base URLs freely accessible and in a machine-readable format at no charge (85 FR 25765).

However, since the ONC Cures Act Final Rule was published, we have found that developers with publicly discoverable endpoint lists have defined their own bespoke publication approaches and unique formats. This variability across developers of certified health IT in the format they are using to publish their service base URLs indicates the industry has not coalesced around a common framework or approach. Research conducted through ONC's Lantern Project confirms this variability among developers of certified health IT, which is hindering maturation of a vibrant app ecosystem for patients and the healthcare community, a primary objective within the Federal Health IT Strategic Plan.

The inconsistent implementation of our service base URL requirement has also rendered important data meant to facilitate connections to endpoints difficult to access. Specifically, the organization details of the API Information Source associated with a service base URL is not always available, and even when available, is not always available in a format that can be readily used. Patient-facing apps require access to these service base URLs to provide patients access to information maintained by specific provider organizations that deploy certified API technology ( i.e., API Information Sources). Without standardized formats and an ability to search for service base URLs, patients are hindered in their ability to find which service base URL(s) refer to their provider. Similar barriers exist for others involved in healthcare seeking to leverage apps for interoperability.

Additionally, it is difficult to map multiple, unique organizations to service base URLs. Experience to-date indicates that the name of the organization associated with a service base URL is typically formatted as free text ( i.e., String). A single String is unable to represent the complexity of healthcare systems, where a system can contain many subsystems, or where a FHIR API URL can support a set of systems. Including all organizations that are serviced by a service base URL is important for discovery of which service base URL serves a particular health care provider, which in turn would allow API users to access relevant EHI through that service base URL. Having all healthcare organizations serviced by the service base URL accessible and in a standardized format would help app developers easily fetch information to enable patients and other users to access, exchange, and use information.

To address the inconsistencies in service base URL publication and challenges with mapping, we proposed in the HTI–1 Proposed Rule to revise the requirement in § 170.404(b)(2) to include new data format requirements (88 FR 23814). We anticipated that these new specifications would establish standards for industry adoption and better facilitate patient access to their health information. In the revised § 170.404(b)(2), we also proposed to incorporate the following existing requirements in § 170.404(b)(2)(i) and (ii): a Certified API Developer must publish service base URLs “[f]or all of its customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source;” and publish these service base URLs “at no charge” as part of proposed § 170.404(b)(2). We proposed that Certified API Developers publish these standardized details by December 31, 2024.

In § 170.404(b)(2)(i), we proposed to require that service base URLs must be published in “Endpoint” resource format according to the FHIR standard adopted in § 170.215(a) (88 FR 23814). Additionally, in § 170.404(b)(2)(ii) and subparagraphs § 170.404(b)(2)(ii)(A) and § 170.404(b)(2)(ii)(B), we proposed to require that organization details such as name, location, and provider identifiers ( e.g., National Provider Identifier (NPI), CMS Certification Number (CCN), or health system ID) for each service base URL must be published in US Core “Organization” resource format according to the implementation specifications adopted in § 170.215(b)(1) (we note that elsewhere in this final rule, in section III.C.7.b, we discuss the proposal to move US Core IGs to § 170.215(b)(1)), with the “Organization.endpoint” element referencing the service base URLs managed by this organization.

We proposed the Endpoint and Organization resource formats because they are based on the FHIR Release 4 and US Core IG industry standards that are already adopted for use in the Program in § 170.315(g)(10). We specifically proposed the FHIR “Endpoint” resource because it is used for representing technical endpoint details and contains a required “address” element that, according to the FHIR R4 standard, contains “the technical base address for connecting to this endpoint.” We noted that Certified API Developers would be able to populate this element, in each of their published “Endpoint” resources, with a service base URL that can be used by patients to access their EHI.

We additionally proposed the US Core “Organization” resource because it can be used to represent important contextual information around a service base URL (88 FR 23814 through 23815). We noted that the US Core “Organization” resource contains an optional “endpoint” element that can be used to reference “technical endpoints providing access to services operated for the organization.” To standardize a link between published “Endpoint” resources and organization details relating to the organization that services these endpoints, we proposed to require, in § 170.404(b)(2)(ii)(A), that this optional “endpoint” element be populated on publicly published “Organization” resources and that they reference the “Endpoints” managed by the organization. We noted that “publicly published” meant that the information is made publicly available and noted that ONC will host a link to developers' service base URL list on the Certified Health IT Product List (CHPL) or another website hosted by ONC. We stated that this information would give the public a standard way of knowing how published “Endpoint” and published “Organization” resources are linked and which organization details apply to which service base URLs.

Additionally, we noted in the HTI–1 Proposed Rule that the US Core “Organization” resource contains a “mandatory” element called “name” that contains a “name used for the organization” (88 FR 23815). In addition to this required element, we proposed in § 170.404(b)(2)(ii)(B) to require Certified API Developers to make available “must support” elements of organization location and provider identifier(s) using the US Core “Organization” resource. An organization's location could be an address that is populated in the “address” element of the US Core “Organization” resource; and a provider identifier could be a National Provider Identifier (NPI), Clinical Laboratory Improvement Amendments (CLIA) number, or other health system ID populated in the “identifier” element. We noted that this information helps contextualize service base URLs and enables application developers to more easily and consistently provide patients access to their electronic health information.

Finally, we proposed, in § 170.404(b)(2)(iii), requirements for collection and maintenance of Endpoint and organization resources. Specifically, in § 170.404(b)(2)(iii)(A), we proposed to require that these resources be collected in a “Bundle” resource, according to the FHIR standard adopted in § 170.215(a), that the Certified API Developer would publicly publish (88 FR 23815). According to the FHIR specification, a “Bundle” acts as “a container for a collection of resources” and is widely used in use cases, such as returning search results and grouping resources as part of a message exchange. Given the broad use of the “Bundle” resource throughout the FHIR specification ( e.g., FHIR search), we noted in the HTI–1 Proposed Rule our expectation that most FHIR clients and FHIR application developers would be familiar with the “Bundle” resource and be able to parse “Bundle” resources electronically and extract relevant information from them for use in their application. Alternatively, we considered a different format for requiring that the Endpoint and Organization resources be collected for publication. We also considered the Newline Delimited JSON (ndjson) format (88 FR 23815). According to the ndjson specification, this format is convenient for publishing “structured data that may be processed one record at a time.” The ndjson format is an efficient way for machines to parse large amounts of data given that the entire file does not need to be read into memory before parsing. As we noted in the HTI–1 Proposed Rule, we expect that these “Endpoint” and “Organization” JSON resource lists may be large, depending on the developer of certified health IT's client base. We noted our expectation that most Certified API Developers would be familiar with this format because it is included as an underlying standard in the FHIR Bulk Data Access IG required for certification to § 170.315(g)(10). Given the simplicity of the ndjson standard, we also noted our expectation that most FHIR clients and FHIR application developers would easily be able to parse ndjson files electronically and extract relevant information from them for use in their application.

We also proposed, in § 170.404(b)(2)(iii)(B), that Certified API Developers review Endpoint and Organization resources quarterly and, as necessary, update the information (88 FR 23815). We recognized that as customers upgrade and install new health IT, data provided in the Endpoint and Organization resources will change. In the HTI–1 Proposed Rule, we noted that a one-time publication of the developer's current list of endpoints for active customers upon certification to the § 170.315(g)(10) criterion will only meet initial certification requirements, and we proposed to establish in § 170.404(b)(2)(iii)(B) a requirement that Certified API Developers maintain this information over time. We also noted that failure to maintain the service base URLs and ensure the associated organization information remains up to date and free of errors or defects on a quarterly basis would be considered a violation of this Condition and Maintenance of Certification requirement and may result in corrective action. We clarified that any endpoint or organization information that is out of date, incomplete, or otherwise unusable for more than 90-days would be considered in violation of this proposed requirement.

Comments. The majority of commenters support the continued development and standardization of publication formats for FHIR “service base URLs” otherwise known as “endpoints,” noting that standardization would better facilitate interoperability and address challenges that exist in operationalizing connections to FHIR servers for facilitating patient access. Many of these supportive commenters cautioned that our proposal does not align with the direction of industry and one commenter raised a particular concern that our proposal is not based in implementation experience and has not been informed by a draft implementation guide. Another commenter noted that since we are proposing that the “endpoint” element in the US Core “Organization” resource be used to reference FHIR R4 “Endpoint” resource(s), we should make specific and clear reference to the applicability of FHIR R4 and its detailed standards on Endpoint. Most of these commenters also offered suggestions on how we should change our proposal by citing the Argonaut implementation guide for Patient-access Brands as standard and the industry driven approach we should consider referencing for this endpoint publication use case.

Response. We thank the commenters for their support of the continued development in this space and suggestions for improvement. The “Patient-access Brands” conceptual model, developed by the FHIR community through the Argonaut Project, has advanced significantly since publication of the HTI–1 Proposed Rule. A connectathon, which is an event where the FHIR community gathers and tests emerging FHIR standards, was held in May 2023 and it included developers of certified health IT and app developers who tested the real-world feasibility of the Patient-access Brands model. Additionally, at the September 2023 HL7 Working Group Meeting, the FHIR community discussed and finalized new changes to the Patient-access Brands model. Currently, the Patient-access Brands model is incorporated into a section of the continuous build draft version of the SMART App Launch IG. This indicates that the Patient-access Brands model is now a draft specification and is on track for publication in a future version of the SMART App Launch IG.

We agree with commenters that the Patient-access Brands specification is a key standardized approach for the endpoint publication use case and we are committed to aligning our requirements with industry efforts. In the HTI–1 Proposed Rule, our proposal generally aligned with the current draft Patient-access Brands specification by calling for the use of “Organization” and “Endpoint” FHIR resources for representing endpoints ( e.g., service base URLs) and corresponding organization ( e.g., API Information Source) details in a standardized format.

Additionally, in the HTI–1 Proposed Rule, our proposal, similarly to the current draft of Patient-access Brands specification, called for the use of the “endpoint” element in the US Core “Organization” resource for linking “Endpoint” resources and organizational details relating to the organization that services this endpoint. However, our proposal in the HTI–1 Proposed Rule is not an exact match of the underlying construct defined in the Patient-access Brands specification. One key difference that could result in incompatibilities between our requirements and the industry led efforts in the Patient-access Brands specification is that we referenced the US Core profile of the base FHIR “Organization” resource, while the Patient-access Brands specification includes its own custom profile of the base FHIR “Organization” resource. Both profiles are based off the base FHIR “Organization” resource, but they each contain their own sets of constraints to best match their use cases.

Based on commenter feedback, we do not believe it is necessary for us to impose US Core level “Organization” resource constraints and reference the FHIR “Organization” resource via the US Core IG at this time. We agree with the commenter who recommended a specific and clear reference to the applicability of FHIR R4. We realize that we introduced some unnecessary confusion by referencing two separate but related standards, namely FHIR R4 and US Core, in separate paragraphs of our proposed criterion updates in § 170.404(b)(2). To simplify our requirements and make a more specific and clear reference to FHIR R4, we believe it is necessary to reference one standard, namely FHIR R4. We also agree with the many commenters who emphasized the importance of considering and not conflicting with the standards developed by the FHIR community for the endpoint publication use case, and we believe that referencing the more general FHIR R4 standard for our Program reduces the risk of conflicting requirements.

To generalize our proposal, respond to commenter feedback, and to align our requirements with emerging industry standards for the endpoint discovery use case, we have finalized a modified version of our proposed requirements at § 170.404(b)(2). We have modified the standard referenced in § 170.404(b)(2)(ii) to require the use of the base FHIR “Organization” resource instead of the more constrained US Core-profiled version of the base FHIR “Organization” resource. Specifically, we have revised § 170.404(b)(2)(ii) to reference the standard adopted in § 170.215(a). We emphasize that subparagraphs of finalized § 170.404(b)(2)(ii)(A) and (B) remain largely unchanged, meaning that Certified API Developers will still be required to reference “Endpoint” resources using the “endpoint” element in the “Organization” FHIR resource and will still be required to publish organization details such as name, location, and facility identifier. With this modification, we have finalized a policy that is less prescriptive than what we proposed. By referencing the base FHIR “Organization” resource, instead of the US Core-profiled “Organization” resource, Certified API Developers have more flexibility to support the “Organization” resource without minimal element constraints and no elements are marked as “must support.” We note that when proposing the US Core “Organization” resource profile, we referenced certain mandatory and “must support” elements contained in that profile, including “address,” “name,” and “identifier.” We did not adopt these constraints; rather, we are leaving it up to the Certified API Developer to determine how best to publish the required organization details using the base FHIR standard instead of the more constrained US Core IG. Overall, this change will provide industry with more flexibility to meet Program requirements as standards evolve. We have finalized our proposal in § 170.404(b)(2) to require Certified API Developers to publish these standardized details by December 31, 2024, as proposed. We clarify that for the time period between when this final rule is effective and December 31, 2024, that Certified API Developers may fulfill their obligations at § 170.404(b)(2) by publicly publishing the service base URLs for all customers in a machine-readable format at no charge.

This modification supports our goal of addressing the inconsistent implementation of our service base URL requirement and better facilitates patient access to their health information by requiring the use of a consistent data format, while also reflecting feedback received from software developers, technology companies, and standards developer interested parties. This modification also better aligns our requirements with the underlying data format constructs currently defined in the leading, and still emerging, industry specification in this area, namely the Patient-access Brands specification. We hope to give Certified API Developers the option of using the data format structure in Patient-access Brands specification to publish their service base URLs and organization data we require without being in conflict with our data format requirements for the Program. We note that at the time of publication of this final rule, the Patient-access Brands specification is still in draft form and may evolve over time, including the addition of breaking changes. We will consider the Patient-access Brands specification for adoption in future rulemaking as it develops.

Comments. In addition to the Patient-access Brands specification, several commenters noted the Directory IG for TEFCA as a standard to consider for the endpoint publication use case. All but one of these commenters cited the Directory IG for TEFCA alongside the Patient-access Brands specification and advocated for the alignment of TEFCA with the Patient-access Brands specification. One commenter advocated specifically for changes to our proposal based on the Directory IG for TEFCA, stating that we should consider it for defining the format of FHIR “Organization” and “Endpoint” resources for the endpoint publication use case.

Response. We appreciate the notes from commenters pointing us to other work in the endpoint publication space to consider. The Directory IG for TEFCA is under active development and is being designed to support the TEFCA use case and the participants within that framework. We agree that this IG is an important standard to keep in mind for supporting the endpoint publication use case more broadly but, because it already includes constraints and extensions that go beyond the relatively small set of elements we proposed requiring of developers, we do not agree with the commenter who suggested using it for specifying the format of FHIR “Organization” and “Endpoint” resources used for publishing endpoints in our Program at this time. However, we note that because we have finalized an approach in § 170.404(b)(2) that references the base FHIR standard, Certified API Developers have the flexibility to consider using “Organization” and “Endpoint” FHIR resources profiles, such as the profiles in the Directory IG for TEFCA, to meet our requirements.

Regarding the suggestions to align TEFCA with the Patient-access Brands specification, we thank commenters for this suggestion but note that it is outside the scope of the proposals related to TEFCA in the HTI–1 Proposed Rule. We will continue to monitor the development of these standards and may take them into consideration in future rulemaking.

Comments. A number of commenters asked that we clarify the intended use of the organization details we proposed to be published. More specifically, commenters asked that we clarify that we expect organization or facility level identifiers, rather than individual practitioner identifiers, to be published. Many of these commenters noted that the publication of individual practitioner identifiers is out of scope for our intended use case. Additionally, one commenter noted the active work on a National Directory FHIR IG and said that it would be an approach to consider if we intend for practitioner level identifiers to be published.

Response. We appreciate commenters' input and suggestions for clarity. We intend for these additional organization details to be used by app developers to help them map organizations to endpoints which, in turn, helps patients find the organization(s) they want to allow an app to access data from. We clarify that facility or organization level identifiers are sufficient to satisfy our proposed publication requirements. Facility level identifiers, for the purposes of certification to these Endpoint publication requirements, include identifiers such as: a National Provider Identifier (NPI), Clinical Laboratory Improvement Amendments (CLIA) number, CMS Certification Number (CCN), or other health system ID. Support for one of these identifier types is sufficient, meaning Certified API Developers are not required to publish individual NPIs as a floor for certification. Different identifiers may be used depending on the customers a Certified API Developer has. We have updated our regulatory text at § 170.404(b)(2)(ii)(B) to more clearly state that “[e]ach Organization resource must contain the organization's name, location, and facility identifier.”

For clarity and consistency, we have also updated our regulatory text at § 170.404(b)(2), and the relevant preamble text in this final rule, to replace the word “organizational” with “organization.” The phrase “organization details” more accurately represents the details we are referring to and is a consistent phrase to use in lieu of our mixed use of “organizational” and “organization” in the HTI–1 Proposed Rule.

Regarding the comment on the active work on a National Directory FHIR IG, we thank this commenter for pointing this out. Because we have not required the publication of individual provider-level identifiers, we are not considering this IG for the endpoint publication use case in our Program. We emphasize again that because we have finalized an approach in § 170.404(b)(2) that references the base FHIR standard, Certified API Developers have the flexibility to consider using “Organization” and “Endpoint” FHIR resources profiles, such as the profiles in the National Directory FHIR IG, to meet those requirements.

Comments. A couple of commenters asked that we clarify our requirements for elements in the Endpoint and Organization FHIR resources if we are updating to US Core version 6.

Response. We thank the commenters and we note that, given the changes we have made to § 170.404(b)(2)(ii) (see response to comments above), US Core is no longer in scope. We have modified the standard referenced in § 170.404(b)(2)(ii) to require the use of the base FHIR “Organization” resource instead of a US Core-profiled “Organization” resource.

Comments. A few commenters responded to our invitation for comment on whether we should finalize our proposal to adopt a requirement for FHIR Endpoint and Organization resources to be made publicly available according to the FHIR Bundle format or if we should finalize the requirement to use a ndjson format. These commenters were generally split on which format they prefer. One commenter noted that large FHIR Bundles are challenging to parse. Another commenter suggested that we align with a format that is most compatible with Lantern to support certification.

Response. We appreciate these responses and suggestions from commenters. We have finalized, at § 170.404(b)(2)(iii)(A), our requirement for FHIR Endpoint and Organization resources to be collected in FHIR Bundle resource format. We recognize that large FHIR Bundles may be hard to parse given their size, but we anticipate that app developers will have the technology and access to the tools needed to parse large machine-readable artifacts. We also note that the current draft Patient-access Brands specification calls for the use of FHIR Bundles to collect FHIR Endpoint and Organization details. We believe that our finalized requirement for publication using the FHIR Bundle resource format sufficiently supports app developers and aligns with industry direction.

We thank commenters for supporting Lantern, which is an open-source tool developed by ONC and the MITRE corporation “that monitors and provides analytics about the availability and adoption of FHIR API service base URLs (endpoints) across healthcare organizations in the United States.” We anticipate that Lantern and other FHIR tools will be able to take advantage of our standards-based and machine-readable approach to monitor and discover FHIR endpoints. We also note that the Program will continue to explore ways to support conformance and certification to these requirements to enable patients and other users to access, exchange, and use information via discoverable FHIR APIs.

Comments. One commenter suggested that both human readable and machine-readable Endpoint metadata be made available on the CHPL.

Response. We thank this commenter for their suggestion. We acknowledge that human readable Endpoint metadata may be useful for some use cases, but we do not believe that is a necessary additional requirement to put on Certified API Developers in our Program. We note that by requiring machine-readable publication using a standardized FHIR format, developers can consider developing their own tools or leveraging existing community tools ( e.g., Lantern) that render FHIR data into human readable formats.

Comments. One commenter explicitly expressed support for the quarterly review timeline we proposed for Certified API Developers in § 170.404(b)(2)(iii)(B), while two commenters recommended changes to the timeline. The two commenters who recommended changes indicated that a quarterly review minimum was too long given that inaccurate organization details and non-functioning endpoints significantly hinders interoperability. One of these two commenters suggested the review timeline be one week and the other suggested that ONC notify organizations of any inaccurate information after 30 days and find them in violation if no corrective updates are made after 60 days.

Response. We appreciate the feedback and thoughtful suggestions for possible improvement from commenters. We agree that this information needs to remain up to date to ensure application developers can easily and consistently provide patients access to EHI. We also acknowledge the need to consider the burden on Certified API Developers to keep their customers' endpoint information up to date. To balance value and burden, we have finalized the review timeline as proposed and have finalized a quarterly review timeline as the requirement. In response to commenters' suggestion that ONC monitor and notify interested parties of inaccurate information and initiate corrective action after 60 days, we note that we have a defined process to elevate concerns of non-conformity and we urge users or other interested parties to leverage this process.

Comments. Many commenters suggested that ONC work on a process for validating and monitoring these endpoints. Many of these commenters also suggested that we develop a directory of these endpoints. One commenter specifically cited our Lantern tool as a central place where these endpoints could be submitted and validated.

Response. We thank the commenters for their feedback and suggestions. All Certified API Developer published Endpoint and Organization FHIR resource Bundles will be available publicly via the CHPL. Links to these Bundles are collected during the certification process by the ONC-Authorized Certification Bodies (ONC–ACB) and posted on a product's CHPL listing following successful certification. This public data can be used by anyone for collection and monitoring. This includes ONC's open-source Lantern tool. ONC hosts a public instance of this tool at https://lantern.healthit.gov/ and collects data into this instance from many sources, including the CHPL, to monitor and provide analytics about the availability and adoption of FHIR API endpoints. We encourage interested parties to visit the Lantern tool and we will continue to consider ways to ensure that service base URLs required in the Program continue to support individuals' access to their health information.

Comments. A few commenters expressed concern over the burdens and challenges for EHR developers to collect this information from their customers and be responsible for it being up to date. This included comments that Certified API Developers should not be penalized if and when their customers do not provide this information. One commenter asked that ONC clarify that Certified API Developers can rely on assurances provided by their customers that this information is valid and up to date, because it will not be feasible for developers to independently validate the information, and that Certified API Developers should instead only be expected to publish information for customers that provide details to the Certified API Developers, rather than an expectation that endpoint and organization detail lists are comprehensive. A couple of commenters suggested the introduction of a CMS attestation for providers and hospitals to be responsible for this information and keeping it up to date.

Response. We appreciate the feedback from commenters and acknowledge these concerns from Certified API Developers about gathering endpoint and organization information from their customers and being responsible for its publication. However, we did not propose and have not finalized any changes to our existing policy at § 170.404(b)(2) that requires Certified API Developers to publicly publish the service base URLs for all of their customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. As we said in the ONC Cures Act Final Rule with regards to publication of service base URLs, we believe that Certified API Developers will have adequate relationships with API Information Sources in the process of providing Health IT Modules certified to § 170.315(g)(10) to gather the necessary information (85 FR 25765). We believe that these same relationships are adequate for Certified API Developers to be able to collect and publish service base URLs, organization names, organization locations, and facility identifiers on behalf of their customers. We do not agree that it will be infeasible for Certified API Developers to provide validated URLs for customers that locally deploy certified API technology because details related to customer names, organization locations, and facility identifiers should be routinely and readily available during the business process ( i.e., a Certified API Developer licensing or selling use of certified API technology to a customer). We remind commenters of our focus for this criterion on service base URLs and related organization details for Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI. We believe that the effort needed to collect this information is warranted given the critical role it plays in enabling third-party apps to access EHI at a patient's request.

We appreciate the feedback and suggestions from commenters on potential points of intersection between our requirements and CMS requirements. Updates to CMS programs are out of scope of this rule, but we encourage commenters to submit such ideas to CMS.

Comments. A few commenters suggested that we work with CMS and other federal partners to ensure our requirements do not duplicate other efforts and to ensure that the necessary infrastructure is in place to support this requirement. One commenter specifically cited CMS's ongoing effort to develop a national directory.

Response. We appreciate the feedback from commenters. We will continue to coordinate and work with our federal partners, including CMS, on points of intersection for potential future rulemaking.

d. Access Token Revocation

In the ONC Cures Act Final Rule, we established a requirement in § 170.315(g)(10)(vi) that for Health IT Modules certified to § 170.315(g)(10), the Health IT Module's authorization server must be able to revoke an authorized application's access at a patient's direction (85 FR 25945). This required capability is intended to enable patients to “definitively revoke an application's authorization to receive their EHI until reauthorized, if ever, by the patient” (85 FR 25747). We noted in the ONC Cures Act Final Rule that we finalized § 170.315(g)(10)(vi) as a functional requirement to allow health IT developers the ability to implement it in a way that best suits their existing infrastructure and allows for innovative models for authorization revocation to develop (85 FR 25747). We understand that a lack of specificity in the current requirement has led to some confusion among health IT developers and application developers.

As part of health IT developers' implementation of these requirements, we have received feedback regarding the implementation of authorization revocation, specifically around the revocation of access tokens. Health IT developers have requested clarification regarding letting access tokens expire in lieu of immediate access token revocation for the purposes of certification testing. The Oauth 2.0 Token Revocation specification, RFC 7009, describes expiration of short-lived access tokens as a design option for authorization servers to revoke an application's access. This design option conforms with industry standard practice and may reduce health IT developer burden as the Health IT Module would not have to perform token introspection for each resource request nor maintain a database of valid access tokens.

In the HTI–1 Proposed Rule, we proposed to revise the requirement in § 170.315(g)(10)(vi) to specify that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request (88 FR 23816). This requirement aligns with industry standard practice of short-lived access tokens as specified in internet Engineering Task Force (IETF) Request for Comments (RFC) 6819, IETF RFC 7009, and Section 7.1.3 of the SMART Application Launch Framework version 1.0.0, which states that “Access tokens SHOULD have a valid lifetime no greater than one hour. Confidential clients may be issued longer-lived tokens than public clients.” This policy would provide clarity and create a consistent expectation that developers revoke access within 1 hour of a request, regardless of their internal approach to fulfilling a patient's request to revoke access. This policy would also assure patients that once requested, an application's access to their data would be revoked within 1 hour. This would also support situations where a patient may have an unexpected change in their privacy concerns and seek to curtail access to their information.

Comments. The majority of commenters supported our proposal to revise § 170.315(g)(10)(vi) to specify that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request. Several commenters, including health IT companies, medical software companies, professional trade associations, some healthcare systems, and consumer/patient advocacy groups agreed with our rationale that such a requirement supported patients' direct control over the applications that have access to their EHI, and that the requirement is consistent with industry standards.

Response. We appreciate the feedback from commenters. We believe our proposal would assure patients that once requested, an application's access to their data would be revoked within 1 hour and that such revocation could be supported by all Health IT Modules regardless of their internal approach to fulfilling a patient's request to revoke access. We appreciate the overall strong support for our proposal that, for Health IT Modules certified to § 170.315(g)(10), the Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request. We have adopted our proposal in § 170.315(g)(10)(vi) without revisions.

Comments. A small number of commenters opposed our proposal, for differing reasons. A healthcare system and a medical software company commented that 1 hour is too long a period of time to execute a revocation request, and a trade organization said 1 hour was too short. Two commenters worried about implications related to information blocking, including a professional trade association that said that providers should be able to request that an app developer delete any data received through the API between when the request was made and when access had been revoked without trigging information blocking concerns, and a medical software company worried about information blocking claims if revocation within 1 hour was not feasible due to technical challenges, such as a network outage at a cloud provider.

Response. We appreciate these commenters' concerns. However, we note that this proposed requirement aligns with industry standard practice of short-lived access tokens as specified in IETF RFCs 6819 and 7009. We also note that this 1-hour requirement does not preclude a Health IT Module from revoking access in a shorter timeframe; rather, it establishes a maximum timeframe for the revocation of access once requested. Based on community feedback, we respectfully disagree with the commenter indicating that 1 hour is not enough time to process such a request; industry consensus, as discussed above with the IETF RFCs, and experience with implementing the Program requirement to-date, indicates that many, if not most, requests can be easily fulfilled within 1 hour. We have established this timeframe to clearly delineate Program expectations, which did not previously exist. Finally, we appreciate commenters' concerns regarding information blocking; however, we currently do not provide an exception specific to access token revocation and we decline to do so at this time. We also invite readers to review the discussion regarding the Infeasibility Exception, finalized by the ONC Cures Act Final Rule in § 171.204 (85 FR 25866–25875), and our discussion of the Infeasibility Exception and its responding to requests condition (§ 171.204(b)) discussed in section IV.C.1 of this final rule.

Comments. One commenter from a health system recommends that the ONC liaise with the Federal Trade Commission (FTC) to consider introducing a requirement such that, when consumer apps that access, exchange, or use personal health records experience a breach and are required to notify users of such a breach, those apps also include easy-to-understand instructions about how to revoke access to that application via certified health IT products and the timeframe in which such revocation must occur.

Response. We appreciate the comment and will continue to coordinate and work with our federal partners, including the FTC, on points of intersection for potential future rulemaking.

We appreciate the overall strong support for our proposal that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request and we have adopted our proposal in § 170.315(g)(10)(vi) without revisions.

e. SMART App Launch 2.0

In the ONC Cures Act Final Rule, we adopted the HL7 FHIR SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART v1 Guide), a profile of the Oauth 2.0 specification, in § 170.215(a)(3) (85 FR 25741). The SMART v1 Guide provides reliable, secure authorization for a variety of app architectures through the use of the Oauth 2.0 standard. This IG defines various capabilities for app support, known as the “SMART on FHIR Core Capabilities” (85 FR 25741). As part of adopting the implementation specification in § 170.215(a)(3), the ONC Cures Act Final Rule required support for these “SMART Core Capabilities,” which enable applications to securely perform standardized authentication and authorization as part of enabling receipt of patient EHI via a FHIR API.

In the ONC Cures Act Final Rule, the § 170.315(g)(10) “Standardized API for patient and population services” certification criterion required support for capabilities from the SMART v1 Guide as described in § 170.215(a)(3) to enable apps to securely perform authentication and authorization with the Health IT Module in a standardized manner. Additionally, the § 170.315(g)(10) criterion included additional requirements for technical capabilities specified in the SMART v1 Guide, requiring support for the issuance of “refresh tokens” valid for a period of no less than three months. This requirement was intended to reduce patient and provider burden to receive patient EHI using an application of their choice by potentially reducing the number of re-authorizations of the application. Support for refresh tokens facilitates patient and provider receipt of patient EHI by enabling an application to be authorized to receive data in a persistent manner, without requiring re-authorization of the application while the refresh token is valid. The § 170.315(g)(10) criterion required support for the issuance of refresh tokens valid for a period of no less than three months, so that an application could potentially be authorized to receive patient EHI for at least a three-month period without requiring re-authorization.

As part of the adopted implementation specification, we explicitly required mandatory support of the “SMART Core Capabilities” for Program testing and certification, and we stated that by requiring the “permission-patient” “SMART Core Capability” in § 170.215(a)(3), Health IT Modules presented for testing and certification to § 170.315(g)(10), via cross-references to § 170.215(a)(3), must include the ability for patients to authorize an application to receive their electronic health information (EHI) based on FHIR resource-level scopes (85 FR 25741, 25746). Practically, this means that patients would need to have the ability to authorize access to their EHI at the individual FHIR resource-level, from one specific FHIR resource ( e.g., “Immunization”) up to all FHIR resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2). This capability gives patients increased control over how much EHI they authorize applications of their choice to receive.

The SMART App Launch Implementation Guide Release 2.0.0 (SMART v2 Guide) is the next major release of the SMART App Launch IG. The SMART v2 Guide updates the features of the SMART v1 Guide by including revisions aligning with industry consensus to provide technical improvements and reflect security best practices. The SMART v2 Guide technical enhancements improve the authentication and authorization security layer provided by the SMART v1 Guide and enables increased capabilities and functionality for individual control of EHI. Therefore, we proposed to adopt the SMART v2 Guide in § 170.215(c)(2), and we proposed that the adoption of the SMART v1 Guide in § 170.215(c)(1) would expire as of January 1, 2025 (88 FR 23816). We clarified that both the SMART v1 Guide and SMART v2 Guide will be available for purposes of certification where certification criteria reference § 170.215(c) until the expiration date of January 1, 2025, after which time only the SMART v2 Guide will be available for certification.

As part of this proposal, we proposed to adopt several sections specified as “optional” in the SMART v2 Guide as “required” for purposes of the Program for certification criteria that reference § 170.215(c). Specifically, we proposed to adopt all Capabilities as defined in “8.1.2 Capabilities,” which include but are not limited to (1) backward compatibility mapping for SMART v1 scopes as defined in “3.0.2 Scopes for requesting clinical data;” (2) asymmetric client authentication as defined in “5 Client Authentication: Asymmetric (public key);” and granular scopes as defined in (3) “3.0.2.3 Finer-grained resource constraints using search parameters.” Additionally, we proposed to require support for the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” Capability Sets from “8.1.1 Capability Sets.” Also, we proposed to adopt token introspection as defined in “7 Token Introspection.” Again, we clarified that for the period before January 1, 2025, Health IT Modules certified to certification criteria that reference § 170.215(c) may use either SMART v1 or SMART v2 for certification (88 FR 23817).

Further, we noted that the SMART v2 Guide includes section 3.0.2.3 “Finer-grained resource constraints using search parameters,” and associated “3.0.2.4 requirement for support” and “3.0.2.5 experimental features,” which present concepts for further development within the SMART v2 Guide (88 FR 23817). Together, these optional functionalities will enable more granular control for individuals, clinicians, and other users to share information with apps of their choice in more explicit ways. The granular scope functionality would empower patients and providers to share health data in a more granular fashion, which would improve confidence in the use of third-party apps by allowing app users to decide which specific type of EHI they share with the app. These functionalities would help address privacy and security concerns of third-party app access to health data and further patient empowerment by providing the ability to limit an app's access to a granular, minimum set of health data, as determined by the app user. We proposed these sections for adoption as part of SMART v2 Guide with the understanding that either the SMART v2 Guide or another implementation guide such as the US Core Implementation Guide will define more specific requirements for finer-grained resource constraints using search parameters.

Comments. There was near universal support for adoption of the SMART v2 Guide among commenters, including health IT companies, software and IT firms, advocacy organizations, and health systems. Several commenters noted that the SMART v2 Guide would play a crucial role in promoting health data interoperability and facilitating seamless data exchange between healthcare systems and applications. However, there was strong support among many of these interested parties to adopt the newest balloted version of the SMART App Launch Implementation Guide, Release 2.1. (SMART v2.1 Guide), rather than the SMART v2 Guide. Several commenters highlighted the benefits of the SMART v2.1 Guide, including improved FHIR Context management and App State capability. Some commenters also recommended ONC require support for browser-based apps, including requirements from the SMART v2.1 Guide.

Response. We thank the commenters for their support. We have finalized the adoption of the SMART v2 Guide subject to modifications described later in this section. We believe that adoption of the SMART v2 Guide will enable an improved and more secure authorization process for applications to receive EHI from Health IT Modules. We appreciate commenters' input regarding adoption of the subsequent release of the SMART v2.1 Guide. We acknowledge there are noteworthy updates included in the SMART v2.1 Guide. However, given that the SMART v2 Guide has already been an established part of the Program via SVAP and rigorously tested as a result, we believe adopting the SMART v2 Guide as a baseline requirement is more appropriate at this time. We will consider potential ways the SMART v2.1 Guide could be included in the Program in the future, including through SVAP. We also clarify that browser-based apps fitting the definition of “public clients”, or “native applications” as defined in internet Engineering Task Force Request for Comments 6749 (RFC 6749), are required to be supported by Health IT Modules certified to the § 170.315(g)(10) criterion, per the requirements of that criterion. Such relevant requirements for supporting “public clients” and “native applications” include the data response, search, registration, secure connection, authentication and authorization for patient and user scopes, and authorization revocation requirements in the § 170.315(g)(10) criterion, respectively at § 170.315(g)(10)(i)(A), § 170.315(g)(10)(ii)(A), § 170.315(g)(10)(iii), § 170.315(g)(10)(iv)(A), § 170.315(g)(10)(v)(A), and § 170.315(g)(10)(vi).

Comments. Commenters were mixed in their recommendations on our proposal to expire the use of the SMART v1 Guide as part of the Program on January 1, 2025, effectively requiring use of only the SMART v2 Guide for applicable certification criteria after that date. Among those interested parties that commented, professional associations urged ONC to finalize the timeline as proposed. Health information technology companies and one health system requested additional time, indicating that the proposed expiration timeframe of January 1, 2025, does not give organizations sufficient time to develop, test, and implement necessary changes to systems and processes.

Response. We thank the commenters for their input. We acknowledge the benefits of extending the timeframe in which the SMART v1 Guide is available for certification. Taking this into consideration, we have modified our proposal as suggested by commenters who recommended more time to adopt only the SMART v2 Guide. We have, therefore, finalized our modified proposal that the adoption of the SMART v1 Guide implementation specification expires on January 1, 2026, and we clarify that following expiration of the SMART v1 Guide, the SMART v2 Guide will be the only valid standard for certification criteria that reference § 170.215(c).

i. SMART v2 Guide New and Revised Features Proposed for Adoption

The SMART v2 Guide introduces new or revised requirements to the previous version of the implementation guide, SMART v1 Guide. Major requirements new to the SMART v2 Guide include support for the OAuth 2.0 security extension Proof Key for Code Exchange (PKCE), as well as a revision of the scope syntax. The SMART v2 Guide includes requirements that both the EHR and all apps support the OAuth 2.0 security extension PKCE. PKCE is an industry standard security extension for OAuth 2.0 to mitigate the known security vulnerability of authorization code interception attacks. The requirement of support for PKCE especially improves the security of native apps, or apps that operate from an individual's phone or tablet, which were particularly vulnerable to authorization code interception attacks.

Another major change included in the SMART v2 Guide is revision of the syntax of scopes provided to apps. To align with the FHIR interactions of “Create,” “Read,” “Update,” “Delete,” “Search,” collectively known as “CRUDS,” scopes are constructed to consist of combinations of five types of permissions corresponding to the CRUDS interactions. The use of this CRUDS scope syntax permits improved patient choice for persistent access as more specific combinations of permissions can be granted to apps as opposed to the scope syntax used in the SMART v1 Guide, which only used two permission types of “read” and “write.”

New feature: PKCE

One of the major security improvements in the SMART v2 Guide is the requirement that all apps support the OAuth 2.0 security extension Proof Key for Code Exchange (PKCE). PKCE is designed to mitigate the known security vulnerability of authorization code interception attacks, with native apps especially targeted. According to IETF RFC 7636, the request for comment which defines the PKCE extension, this attack can be used to illegitimately obtain an access token from the authorization server and thus obtain server data in an unauthorized manner. PKCE mitigates this vulnerability by creating cryptographically random keys for every authorization request. The authorization server performs proof of possession of the secret key by the client. This mitigates the vulnerability as an attacker who intercepts the authorization code cannot redeem it for an access token as they do not possess the secret key associated with the authorization request.

Support for PKCE is important because PKCE makes health app access of patient health information more secure in a standardized manner. ONC recognizes healthcare participants and patients are interested in the secure use of health apps, including native apps, to access health information. PKCE support makes the granting of access to health information via health apps more secure by mitigating the known vulnerability of authorization code interception attacks. We believe the support of PKCE would further our goal of secure access of health information without special effort by further securing health app access, especially for native apps. Therefore, we proposed to require the support of PKCE as specified in the SMART v2 Guide (88 FR 23817).

Comments. All comments received from interested parties supported adoption of the OAuth 2.0 security extension PKCE in the SMART v2 Guide. Many commenters noted that adoption and required support for PKCE is aligned with industry best practice and forthcoming updates to OAuth in draft version 2.1.

Response. We thank the commenters for their support. We believe the support of PKCE would further our goal of secure access of health information without special effort by further securing health app access, especially for native apps. Therefore, we have finalized adoption of the SMART v2 guide with inclusion of PKCE. This means that Health IT Modules presented for testing and certification to § 70.315(g)(10) must support PKCE.

New Feature: CRUDS scope syntax

Another major update in the SMART v2 Guide is the revision of the scope syntax to align with the FHIR REST API interactions for FHIR resources. Previously in the SMART v1 Guide, scope syntax for FHIR resources was delineated in terms of combinations of “read” and “write” permissions. The SMART v2 Guide revises this scope syntax by splitting “read” permissions into two types of permissions which correspond to FHIR REST API interactions, “Read” and “Search.” Similarly, the “write” permissions from the SMART v1 Guide are split into “Create,” “Update,” and “Delete.” This alignment of scope syntax to the FHIR REST API interactions permits Health IT Module authorization servers to provide greater specificity regarding which permissions are granted in scopes to apps and has the benefit of improved technical clarity to health IT and application developers. This additional specificity for scopes also improves a patient's control over how an app accesses their health data by clarifying for the patient what specific type of API interactions are permitted to the app. For example, under this new syntax the patient could specifically permit an app “read” access to a FHIR resource but deny “search” access for the same FHIR resource.

As stated in the ONC Cures Act Final Rule at 85 FR 25742, the § 170.315(g)(10) certification criterion only requires health IT developers to support “read” capabilities according to the standard and implementation specifications adopted in § 170.215(a) and in § 170.215(b)(1), including the mandatory capabilities described in “US Core Server Capability Statement.” Our proposal aligns with this existing policy for § 170.315(g)(10) by proposing to require that only “Read” and “Search” permissions as specified in the SMART v2 Guide be supported for certification to the § 170.315(g)(10) criterion.

Comments. Comments from health IT companies supported our proposals to adopt the SMART v2 revised scope syntax of “Create,” “Read,” “Update,” “Delete,” and “Search,” or CRUDS. They noted that the new syntax supports flexible and patient-friendly user interfaces (UI). One commenter noted that ONC should maintain current policy allowing developers the flexibility to present authorization scopes in a more user-friendly format, such as by logically grouping FHIR resource-level scopes, as long as users are able to grant FHIR resource-level scope authorizations, if requested. We also received a comment recommending against requiring support for wildcard scopes as defined in the SMART v2 Guide due to concerns about data management and security in patient access use cases.

Response. We thank the commenters for their support and comments. In consideration of the comments received, we have finalized as proposed the requirement for Health IT Modules certified to § 170.315(g)(10) to support the SMART v2 scope syntax for the “Read” and “Search” permissions as specified in the SMART v2 Guide. We clarify that Health IT Modules supporting the SMART v2 Guide scope syntax and the “permission-patient” capability from the SMART v2 Guide are not required to support wildcard scopes relating to authorization to receive a single patient's data. Instead, we align with the policy as mentioned in the ONC Cures Act Final Rule (85 FR 25741) that as part of supporting the “permission-patient” capability, Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their EHI based on FHIR resource-level scopes.

ii. SMART v2 Optional Features Proposed as Required by ONC

We proposed to require all Capabilities as defined in “8.1.2 Capabilities” and the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” Capability Sets from “8.1.1 Capability Sets” (88 FR 23817 through 23819). First, the SMART v2 Guide introduces functionality specified as optional in the implementation guide. We proposed to make several of these optional functionalities required as part of the proposed implementation specification, and therefore required for certification criteria that reference proposed § 170.215(c)(2) (88 FR 23818).

Second, the SMART v2 Guide introduces an optional profile for authorization servers to support asymmetric client authentication for confidential clients. We proposed to require Health IT Modules support asymmetric client authentication as an option for confidential clients during the process of authentication and authorization when granting access to patient data.

Third, the SMART v2 Guide also introduces a new optional feature of granular scope constraints using search parameters. This feature uses the FHIR REST API search parameter syntax to specify permissions more granular than the FHIR resource level, which was the maximum granularity of scopes in the SMART v1 Guide. We proposed to require “3.0.2.3 Finer-grained resource constraints using search parameters” with the clarification that Health IT Modules certified to § 170.315(g)(10) must minimally be capable of handling finer-grained scopes using the “category” parameter for (1) the Condition resource with Condition sub-resources Encounter Diagnosis, Problem List, and Health Concern and (2) the Observation resource with Observation sub-resources Clinical Test, Laboratory, Social History, SDOH, Survey, and Vital Signs. We note that the requirements denoted in “3.0.2.3 Finer-grained resource constraints using search parameters” would be required as part of implementing the “permission-v2” capability defined in “8.1.2 Capabilities”. We anticipated that the US Core IG would provide guidance for developers to support a minimum number of search parameters, and this minimum list would be consistent with the optional scopes described in section “3.8 Future of US Core” of the US Core IG v6.1.0.

Fourth, the SMART v2 Guide revises how capabilities are categorized. The “SMART Core Capabilities” in the SMART v1 Guide define capabilities supported by the server and are made available to inform clients of supported functionality. “Capabilities” are grouped into “Capability Sets” to define the functionalities required for a specific use case. The SMART v2 Guide restructures how “Capabilities” are organized, and no longer includes “SMART Core Capabilities.” Instead, the SMART v2 Guide includes a list of “Capabilities” and “Capability Sets.”

Finally, the SMART v2 Guide introduces a new requirement to support POST-based authorization for the client authorization request. This new requirement in the SMART v2 Guide is adapted from the OpenID Connect Core specification and is related to the requirement in § 170.315(g)(10)(v)(A)( 1)( i), which requires a Health IT Module to support authentication and authorization during the process of granting access to patient data according to the SMART App Launch and OpenID Connect Core standards. The SMART v2 Guide includes the “authorize-post” capability under “Capabilities” for servers to indicate support for this requirement. To align with this new technical requirement in the SMART v2 Guide and the authorization and authentication requirement in § 170.315(g)(10)(v)(A)( 1)( i), we proposed to require the “authorize-post” capability (88 FR 23819).

Comment. Overall, commenters were supportive of ONC's proposals to adopt optional features in the SMART v2 Guide as required for the Program. Several commenters supported adoption of all optional features; several others supported adoption of all optional features except for “authorize-post” capability (also referred to as HTTP POST by commenters); and a minority of commenters also commented against including the “permission-online” capability. There was a comment recommending revision to the language of the token introspection proposal in § &170.315(g)(10)(vii), since the SMART v1 Guide does not include a guidance section regarding token introspection. We also received a comment requesting clarity regarding requirements to independently support SMART v2 scopes separately from SMART v1 scopes.

Response. We thank the commenters for their support and comments. We believe requiring the proposed optional features will improve the capability of applications to be authorized by users to securely receive EHI. We clarify the “authorize-post” capability is not an optional capability and is required as per the SMART v2 Guide as a method to obtain an authorization code from the authorization server. To align with the requirement as per the implementation guide, we have finalized the proposal to require the “authorize-post” capability. We encourage interested parties to participate in the development of the SMART App Launch IG if there are enhancements or technological advances regarding this capability. We proposed to require the “permission-online” capability, as part of our proposal to require all “Capabilities” as defined in “8.1.2 Capabilities,” which would enable an application to receive authorization to receive EHI while the user is logged in. In consideration of comments we received, we believe additional clarity is necessary regarding the specific authorization contexts in which this capability would be required. Also, further insight is needed regarding the use cases in which this capability provides utility beyond the “permission-offline” capability included in the proposal. Therefore, we are modifying our proposal to exclude the “permission-online” capability from the requirements of § 170.215(c)(2). Thus, we have finalized our proposal to require all Capabilities as defined in “8.1.2 Capabilities” and the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” Capability Sets from “8.1.1 Capability Sets” of the SMART v2 Guide, except for the “permission-online” capability. We also note that since we have finalized our proposal to expire use of the SMART v1 Guide as part of the Program on January 1, 2026, that after that date certification to § 170.315(g)(10) would effectively require that token introspection be supported as described in the SMART v2 Guide. Additionally, regarding independently supporting SMART v2 and SMART v1 scopes, we note that this proposal requires the “permission-v1” and “permission-v2” capabilities as defined in the SMART v2 Guide, which define how such scopes must be supported. We clarify that the SMART v2 Guide scopes must be supported independently of the SMART v1 Guide scopes as per the “permission-v2” capability in the SMART v2 Guide, and that the SMART v1 Guide scopes must be supported as per the “permission-v1” capability in the SMART v2 Guide. Support for scopes in this manner enables the updated SMART v2 Guide scope syntax to be used by applications while also maintaining backwards compatibility with the SMART v1 Guide scopes for legacy applications.

Comments. We received support from a majority of commenters that addressed ONC's proposals for support of the SMART v2 Guide's optional capability “3.0.2.3 Finer-grained resource constraints using search parameters,” including our proposal to use the “category” parameter for (1) the Condition resource with Condition sub-resources Encounter Diagnosis, Problem List, and Health Concern and (2) the Observation resource with Observation sub-resources Clinical Test, Laboratory, Social History, SDOH, Survey, and Vital Signs. Multiple commenters appreciated this degree of specificity and encouraged ONC to finalize this approach without further specifying in future rulemaking; instead, many of these commenters said ONC should rely on future versions of the US Core Implementation Guide to instruct further specification of other FHIR resource constraints. One health IT company recommended that we do not align scopes requirements to “search operations,” and instead adopt authorization scopes no more granular than the “category” level for FHIR resources such as Condition, Observation, Medication Request, and Diagnostic Report.

Response. We appreciate commenters' feedback and have finalized the requirements as proposed. We note that the finalized requirements regarding “3.0.2.3 Finer-grained resource constraints using search parameters” are required as part of implementing the “permission-v2” capability defined in “8.1.2 Capabilities”. We also note that the requirements of this proposal to support finer-grained scopes using search parameter syntax and the “category” parameter are intended to align with capabilities and guidance as included in the SMART v2 Guide and FHIR US Core 6.1.0 implementation guide. We believe that establishing minimal conformance requirements at the category level for the Condition and Observation resources using specifications and guidance from these implementation guides will both ensure that Health IT Modules are capable of supporting the finer-grained resource constraints capability without being overly prescriptive in setting expectations for how the Health IT Module implements such capabilities.

Comments. Several commenters suggested that ONC adopt capabilities and standards that were outside the scope of our proposals, including “rich authorization requests,” “push authorization requests, as defined by RFC 9126,” and anti-malware capabilities, identity threat detection and response systems, the adoption of sender-constrained tokens, and OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) specification.

Response. We thank the commenters for their recommendations, but we note that these comments are outside the scope of our proposals. We decline to accept the recommendations to adopt these capabilities, but we encourage industry to continue highlighting potential capabilities for future consideration in the Program. We also encourage interested parties to participate in the development and refinement of standards and implementation guides such as the SMART App Launch Implementation Guide.

8. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)

In the 2015 Edition Final Rule (80 FR 62601), ONC required the recording, capture, and access to a patient's sex, sexual orientation, and gender identity for Health IT Modules certified to the “Demographics” certification criterion (§ 170.315(a)(5)) (80 FR 62747). This rule also defined a required set of standardized terminology to represent each of these data elements (80 FR 62618–62620). Since then, ONC has received recommendations through the Health Information Technology Advisory Committee (HITAC) and public feedback that the current terms and terminologies used to represent sex, gender identity, and sexual orientation are limited and need to be updated.

Meanwhile, the healthcare industry had similarly taken note of the need for precision for ideas encompassed in terms such as “sex” and “gender” and launched the Gender Harmony Project to capture these concepts consistently within healthcare. The Gender Harmony Project introduced for the health IT context the concepts “Sex for Clinical Use” (SFCU), “Recorded Sex or Gender” (RSG), “Name to Use,” and “Pronouns.” The Gender Harmony Project defines Sex for Clinical Use as a category that is based on clinical observations typically associated with the designation of male and female; Name to Use provides the name that should be used when addressing or referencing the patient; Recorded Sex or Gender is the documentation of a specific instance of sex and/or gender information; and Pronouns are determined by a patient and used when referring to the patient in speech, clinical notes, and in written instructions to caregivers ( e.g., she/her/hers or they/them). Sex for Clinical Use, Name to Use, Recorded Sex or Gender, and Pronouns are currently not present in the certification criteria.

We outline our proposals as discussed in the HTI–1 Proposed Rule to modify the “Demographics” certification criterion (§ 170.315(a)(5)) (88 FR 23820):

We proposed to rename § 170.315(a)(5) from “demographics” to “patient demographics and observations,” to acknowledge that the data elements being proposed are broader than demographics information, as we look to promote a more inclusive healthcare system.

We proposed to add the data elements “Sex for Clinical Use” in § 170.315(a)(5)(i)(F), “Name to Use” in § 170.315(a)(5)(i)(G), and “Pronouns” in § 170.315(a)(5)(i)(H) to the “patient demographics and observations” certification criterion (§ 170.315(a)(5)). This addition reflects concepts developed by the HL7 Gender Harmony Project and help promote inclusivity in care delivery.

We proposed to revise the terminology standards specified for “Sex” in § 170.315(a)(5)(i)(C). Prior to issuing the HTI–1 Proposed Rule, ONC received significant feedback reflecting the need to be more inclusive in the terminology representing the data element. As such, ONC proposed to revise the fixed list of terms for “Sex” in § 170.315(a)(5)(i)(C), which are represented by HL7® Value Sets for Administrative Gender and NullFlavor in § 170.207(n)(1). We proposed to ultimately replace § 170.207(n)(1) with the SNOMED CT® U.S. Edition code set proposed in § 170.207(n)(2). In order to be less disruptive to developers of certified health IT, we proposed to provide flexibility and allow recording the element using the specific codes represented in § 170.207(n)(1) for the time period up to and including December 31, 2025, to provide enough time to transition their health IT systems to SNOMED CT® U.S. Edition by January 1, 2026. By having § 170.207(n)(1) expire at the end of 2025 and adding § 170.207(n)(2) as a requirement for Health IT Modules certified to § 170.315(a)(5) beginning January 1, 2026, we proposed to enable health IT developers to specify any appropriate value from the SNOMED CT® U.S. Edition code set with the standard specified in § 170.207(n)(2). We proposed to require that Sex for Clinical Use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in § 170.207(c)(1).

Additionally, we proposed to replace the terminology standards specified for Sexual Orientation in § 170.315(a)(5)(i)(D), and Gender Identity in § 170.315(a)(5)(i)I. ONC has received significant feedback reflecting the need to be more inclusive in the terminology representing each of these data elements. As such, ONC proposed to revise the fixed list of terms for Sexual Orientation in § 170.315(a)(5)(i)(D), and Gender Identity in § 170.315(a)(5)I(E), which are represented by SNOMED CT® U.S. Edition and HL7® Value Set for NullFlavor in § 170.207(o)(1) and (2), and ultimately replace it with the SNOMED CT® U.S. Edition code set specified in § 170.207(o)(3).

We further proposed to set an expiration date of January 1, 2026, for the adoption of the values sets referenced in § 170.207(o)(1) and (o)(2). This allows the use of either the value sets in § 170.207(o)(1) and (o)(2) or the standard proposed in § 170.207(o)(3) beginning on the effective date of a final rule and transitioning to allow only the use of the adopted standard in § 170.207(o)(3) after December 31, 2025. Consistent with our policies in sections III.A and III.C.11, developers of certified health IT with Health IT Modules certified to criteria that reference § 170.207(o)(1) or (o)(2) would have to update those Health IT Modules to § 170.207(o)(3) and provide them to customers by January 1, 2026.

We also proposed to add Sex for Clinical Use (SFCU) as a new data element in § 170.315(a)(5)(i)(F). SFCU is a category based upon clinical observations typically associated with the designation of male and female. It &ports context specificity, is derived from observable information, and is preferably directly linked to &e information this element summarizes. SFCU represents a patient's sex relevant to a specific clinical setting. This is valuable when providing care for a patient whose condition or treatment is dependent on their sex as determined by observing and evaluating, for example, a patient's hormonal values, organ inventory, genetic observations, or external genital morphology. SFCU may differ from a patient's sex as recorded on a birth certificate or driver's license. We further clarified, that while there may be multiple values of SFCU tied to different events, such as requesting a laboratory test or imaging study, we proposed to require health IT developer be able to record at least one value of SFCU. Additionally, in order to align with current industry practice and to provide flexibility to health IT developers, we proposed that health IT be capable of recording SFCU using the LOINC® terminology code set standard specified in proposed § 170.207(n)(3).

We proposed to add new data elements Name to Use in § 170.315(a)(5)(i)(G) and Pronouns in § 170.315(a)(5)(i)(H), respectively, to advance the culturally competent care for lesbian, gay, bisexual, transgender, queer, intersex, asexual, and all sexual and gender minority (LGBTQIA+) people. Multiple values for a given patient may be valid over time. We require at least one value for Pronouns and Name to Use be recorded. Additionally, in order to align with current industry practice and to provide flexibility to health IT developers, we proposed that health IT be capable of recording Pronouns using the LOINC® terminology code set standard specified in proposed § 170.207(o)(4).

In addition to the other data elements proposed, the HL7 Gender Harmony Project created an element named Recorded Sex or Gender (RSG). RSG documents a specific instance of sex and/or gender information. RSG is considered a complex data element that includes provision for a sex or gender value, as well as reference to the source document where the value was found, whereas Sex is a simple data element. RSG provides an opportunity for health IT developers to differentiate between sex or gender information that exists in a document or record, and from Sex for Clinical Use (SFCU) which is designed to be used for clinical decision-making. In the HTI–1 Proposed Rule, ONC asked commenters to evaluate two options and provide feedback regarding whether Recorded Sex or Gender as defined by the HL7 Gender Harmony Project should be incorporated into 170.315(”)(5) “patient demographics and observations” (88 FR 23820).

Comments. Some commenters did not support the proposed deadline and instead suggested a deadline of 24 months after the effective date of the final rule as this would be in line with the proposed “timeliness” provisions of the Assurances Condition and Maintenance of Certification requirements. Other commenters specifically proposed December 31, 2025, for the adoption of new and updated certification criteria.

Response. We thank the commenters for the comments suggesting an extension to the proposed effective dates. In assessing the overall burden and proposed timeframes, we have revised the compliance dates to allow for 24 months for compliance and finalized the adoption of § 170.315(a)(5) with a compliance date of January 1, 2026. We have also revised the “timeliness” requirement in the Assurances Condition to avoid confusion.

Comments. Most commenters supported the addition of Sex for Clinical Use, Name to Use, Sex, and Pronouns to § 170.315(a)(5) “patient demographics and observations.” Some commenters noted that comprehensive demographic data supports holistic understanding of patients' background, leading to culturally competent and patient-centered care. Commenters also encouraged ONC to continue collaborating with the HL7 Gender Harmony Project to provide more detail regarding the definitions and supporting terminologies—supporting the ability for people to provide more nuanced information about themselves to best inform care. Commenters also suggested that ONC explore how Sex for Clinical Use could be expanded to incorporate organ inventory and hormone levels. One commenter suggested that ONC promote Sex for Clinical Use as a repeatable set of observations. Another commenter suggested that the addition of Pronouns, Name to Use, and Sex for Clinical Use would create unnecessary confusion, increased medical risk, and religious conscience concerns. Other commenters expressed concern that it will be difficult to collect Sex for Clinical Use as the clinician interacting with the patient may not have the information necessary to provide a value. Some commenters expressed concern about the complexities of dealing with context-specific Sex for Clinical Use data.

Some commenters expressed concern that there is not sufficient information or guidance for programs and health IT to implement Sex for Clinical Use, therefore it should not be included in § 170.315(a)(5) “patient demographics and observations.” Several commenters suggested that ONC wait to add any data elements to “patient demographics and observations” until the data elements are part of USCDI. Other commenters supported the addition of Sex for Clinical Use, Name to Use and Pronouns to the “patient demographics and observations” criterion rather than USCDI, as adding to USCDI and then SVAP would greatly slow adoption since SVAP is optional.

Response. ONC thanks the commenters expressing support for Name to Use, Pronouns, and Sex for Clinical Use. Including “patient demographics and observations” criterion in this final rule provides time for Health IT Modules to incorporate support for capture of this important data prior to requiring exchange.

ONC collaborates closely with the HL7 Gender Harmony project team and as a result has finalized the descriptive data name change of “Sex for Clinical Use” to “Sex Parameter for Clinical Use” in § 170.315(a)(5)(i)(F). ONC will continue to support efforts to expand the scope of the HL7 Gender Harmony Project to explore how more specific information about a person's physical characteristics ( e.g., organ inventory and hormone levels) can be collected and exchanged to inform Sex Parameter for Clinical Use. We have finalized as proposed (88 FR 23820) that the Health IT Module must be able to record at least one value for Sex Parameter for Clinical Use for each patient and note that there may also be multiple values tied to different events, such as requesting a laboratory test or imaging study, allowing for and encouraging more than one. We recognize that the Sex Parameter for Clinical Use data element may be a new concept to some. However, we note that developers of certified health IT have the flexibility to configure their user interface and to capture and display these data in clinical workflows consistent with their own design decisions.

ONC appreciates the concerns expressed by some commenters about lack of guidance to implement Sex Parameter for Clinical Use (formerly Sex for Clinical Use); however, at the time of this final rule, HL7 has published updated specifications that provide specific exchange guidance that may then inform incorporation into health IT workflows. ONC has identified Sex Parameter for Clinical Use, Name to Use, and Pronouns as key to implementing ONC's priorities to support health equity and access for LGBTQIA+ communities. We have also finalized what was proposed to specify that at least one Name to Use and Pronouns must be recorded for each patient.

With regards to the comment suggesting that collection of these data elements would create unnecessary confusion, increased medical risk, and religious conscience concerns, ONC believes that these data elements are critical to supporting healthcare, health equity, and access for LGBTQIA+ communities. Our adoption of these data elements will help to advance the capability of certified health IT to exchange these data elements for use by patients and health care providers. Our adoption of these data elements does not establish a requirement for health care providers or patients to record or disclose this information, or use these capabilities. As stated above, these data elements may be new concepts to some, and ONC encourages developers of certified health IT to work with providers to develop appropriate workflows.

The “patient demographics and observations” criterion focuses on data capture and storage and not the exchange of this data, which is the focus of USCDI. Therefore, we did not accept the comment suggesting that ONC not include the data elements in § 170.315(a)(5) “patient demographics and observations” until they are included USCDI.

Comments. Commenters suggested that ONC remove Sex and retain Sex for Clinical Use because Sex for Clinical Use paired with Gender Identity provides clear information to distinguish between a clinical categorization of a person's sex used for clinical decision making and a person's self-reported Gender Identity.

Response. ONC thanks commenters for their input suggesting that Sex be removed and Sex Parameter for Clinical Use (as we have renamed Sex for Clinical Use) be retained. However, more analysis by the health IT community is necessary to determine the impact of removing Sex. Therefore, ONC declines to remove Sex.

Comments. Some commenters did not support changing the title from patient demographics to patient demographics and observations, noting that all data described within are considered demographics. Other commenters noted that the title change is confusing as the criterion now includes statistical characteristics of human populations used to identify population segments and attributes associated with a diagnostic test or procedure.

Response. We disagree with the stated concerns and do not believe that the certification criterion name change will be confusing to most in the healthcare ecosystem. The addition of the word “observations” signals that some of the data elements in this data class may not be statistical characteristics of human populations by all people evaluating the certification criterion. Accordingly, we have finalized the criterion title change as proposed.

Comments. Multiple commenters expressed concern about changing the requirement for specific code set concepts for Sexual Orientation and Gender Identity to a more general reference to SNOMED CT U.S. Edition. They also questioned whether health IT developers would be compliant if other values are exchanged such as “unknown” or “asked but did not answer.” Other commenters supported ONC's plans to move value set definitions out of regulatory text and delegate to industry groups. One commenter suggested referencing specific value sets defined in the Value Set Authority Center.

Response. ONC thanks the commenters for their input and assures them that ONC collaborates with health IT developers to develop specific values that may be exchanged, including those that indicate a standard value is not available, such as “unknown” or “asked but did not answer”. The resulting value sets may be defined in the Value Set Authority Center. Removing specific code set concepts from regulation allows health IT developers to provide options that are culturally relevant and may change on a cycle that is different from regulation.

Comments. Some commenters did not support the addition of Sex with the requirement that data values be drawn from SNOMED CT U.S. Edition. Others expressed concern that the addition of Sex may increase confusion among senders and receivers about the various data elements currently in use—administrative sex, administrative gender, and sex (assigned at birth).

Response. ONC thanks the commenters for their input regarding Sex. Health IT Modules may continue to record and exchange Sex (assigned at birth). Historically, Sex (assigned at birth), administrative sex, and administrative gender have been used to communicate sex which may be used for clinical decision making when the values were obtained from a document at some point in a patient's life or were not based on clinical observations and should not be used for clinical decision making. The addition of Sex allows health IT developers to exchange Sex without relying on document context.

Comments. Some commenters suggested that ONC remove the “patient demographics and observations” criterion entirely and rely on USCDI to promote the capture, use, and exchange of patient demographic data elements. Others suggested that all data elements listed in the “patient demographics and observations” criterion should be in USCDI prior to inclusion in regulation. These commenters referenced cases where ONC withdrew certification criteria ( e.g., Problem List, Medication List, Smoking Status).

Response. ONC thanks the commenters and acknowledges that certification criteria have been withdrawn in the past. ONC declines to remove the ”patient demographics and observations” criterion or change the scope of USCDI to include data capture and use.

The “patient demographics and observations” certification criterion includes important data elements supporting underserved communities and health equity. The USCDI scope is focused on the exchange of data element values, whereas this certification criterion focuses on health IT capabilities to collect and record certain data. In some cases, the data required to be collected and recorded is not yet in USCDI.

Comments. In the HTI–1 Proposed Rule, proposals for § 170.315(a)(5), ONC asked commenters to provide feedback regarding whether Recorded Sex or Gender as defined by the Gender Harmony Project should be incorporated into the § 170.315(a)(5) “patient demographics and observations” criterion. Responses indicate there is not agreement among interested parties, and many open issues remain related to how and when these data should be collected. One commenter suggested that ONC remove the Sex data element entirely and add Recorded Sex or Gender to delineate administrative information from Sex for Clinical Use, which is to be used when making clinical decisions.

Response. ONC thanks commenters for their thoughtful input and will not finalize the addition of Recorded Sex or Gender to § 170.315(a)(5) due to lack of community consensus. ONC will continue to support maturation of this data element through the Gender Harmony Project at HL7.

Comments. Some commenters encouraged ONC to work with interested parties to provide clarity on the differences between related data elements to ensure patients' identities are respected while important information for clinical care is captured correctly. Specifically, sharing this information via a patient access API, such as those required by the CMS quality programs for health care providers under Medicare, may cause confusion or distress to a patient. Commenters also noted that care must be taken to ensure privacy controls are in place to protect sensitive, granular health data. This information may be sold or disclosed by an application developer if agreed to in the consumer terms and agreement.

Response. We thank the commenters for their comments regarding privacy concerns and recognize the importance of addressing the privacy and confidentiality of sensitive information. Recognizing this, the Program establishes the standards, implementation specifications, and functional requirements for health IT to manage and exchange data but does not control the collection or use of data. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), which addresses patients' (and their authorized representatives') ability to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213.

Base EHR Definition

We proposed to revise and update the “demographics” certification criterion (§ 170.315(a)(5)), to rename as “patient demographics and observations,” and which is included in the Base EHR definition in § 170.102 (88 FR 23821). This means Health IT Modules would need to be updated to accommodate the additional requirements in the “patient demographics and observations” certification criterion in order to meet the Base EHR definition. We did not receive comments related to updating the Base EHR definition to include the additional requirements in the “patient demographics and observations” certification criterion, so we have finalized this revision as proposed.

In addition, because December 31, 2022 has passed, we proposed to revise the Base EHR definition by removing the reference to § 170.315(g)(8) in § 170.102 Base EHR Definition (3)(ii) and replacing the references to § 170.315(g)(10) in § 170.102 Base EHR Definition (3)(ii) and (iii) with a single reference to § 170.315(g)(10) in § 170.102 Base EHR Definition (3)(i). We did not receive comments on this proposal, so we have finalized this revision as proposed.

9. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)

We proposed to replace the fixed value set for the USCDI data element “Sex” and instead enable health IT developers to specify any appropriate value from the SNOMED CT U.S. Edition code set with the standard specified in § 170.207(n)(2) (88 FR 23821). We proposed that health IT developers can continue using the specific codes for Sex represented in § 170.207(n)(1) for the time period up to and including December 31, 2025. We note that these dates were proposed for the adoption of the associated standards in § 170.207(n), including the expiration of the adoption of the standard in § 170.207(n)(1) on January 1, 2026. As discussed in sections III.A and III.C.11, developers of certified health IT with Health IT Modules certified to criteria that reference § 170.207(n)(1) would have to update those Health IT Modules to § 170.207(n)(2) and provide them to customers by January 1, 2026. We note that, in the proposed rule regulation text in § 170.315(b)(1)(iii)(G)( 3), we inadvertently included a reference to § 170.213 (88 FR 23909) instead of including § 170.207(n)(2) as discussed in our proposal (88 FR 23821). ONC has not finalized § 170.213 as proposed in § 170.315(b)(1)(iii)(G)( 3), as § 170.213 references a version of SNOMED CT U.S. Edition that is older than the one referenced in § 170.207(n)(2). We have finalized the reference to § 170.207(n)(2) in § 170.315(b)(1)(iii)(G)( 3) to include the most recent version of SNOMED CT U.S. Edition available at the time of publication of this final rule. Health IT developers may update to a newer version if one exists at effective date of the criterion.

We also proposed a conforming update to § 170.315(b)(1) to update the listed minimum standard code sets for Problems in § 170.315(b)(1)(iii)(B)( 2) (88 FR 23821). We proposed that Health IT Modules certified to § 170.315(b)(1) use, at a minimum, the version of the standard specified in § 170.207(a)(1).

Comments. All commenters agreed with the proposal to update the transitions of care certification criterion § 170.315(b)(1)(iii)(G)( 3) to include the adoption of USCDI v3 in § 170.213(b). Some commenters noted that the updated criterion will allow better inpatient—outpatient transitions, especially for community health centers.

Response. ONC thanks commenters for their support to update the transitions of care certification criterion to include the adoption of USCDI v3. We have finalized the adoption of this proposal in this final rule.

Comments. One commenter encouraged ONC to work across HHS to enforce existing CMS and ONC requirements across products and healthcare organizations. The commenter suggests that HHS should extend transition of care data elements for claims data from payers to healthcare organizations offering primary care.

Response. ONC thanks the commenter for their input. ONC will continue to work with federal partners to promote alignment for these data concepts.

Comments. Some commenters suggested that the date to support USCDI v3 in Transitions of Care documents should be changed to December 31, 2025, or 24 months after the rule is finalized to allow health IT developers time to incorporate and test USCDI v3 data elements into Health IT Modules and develop appropriate safeguards for sensitive personal health information.

Response. ONC appreciates concerns expressed about the proposed date to allow for USCDI v3 adoption prior to including USCDI v3 data elements in transition of care documents. We have finalized the adoption of updates to § 170.315(b)(1) with a compliance date of January 1, 2026.

Comments. Some commenters expressed concern about USCDI data element Sex and its inclusion in patient matching algorithms, suggesting that time of birth is a better matching parameter than Sex. Other commenters suggested that mother's maiden name (in a child's record), birth order, and multiple birth indicators be added to the patient matching requirement.

Response. ONC thanks commenters for their input concerning appropriate data to include in patient matching algorithms. The transitions of care criterion define the minimum set of data elements to use for patient matching and does not inhibit health IT developers from using other additional data elements.

10. Patient Right To Request a Restriction on Use or Disclosure

In the HTI–1 Proposed Rule, we noted that under the HIPAA Privacy Rule, covered entities, as defined in 45 CFR 160.103, are required to allow individuals to request a restriction on the use or disclosure of their PHI for treatment, payment, or health care operations, although it does not require covered entities to accept such requests, except in certain limited circumstances (See 45 CFR 164.522(a)(1)) and 164.530(i)) (88 FR 23821). The HIPAA Privacy Rule also requires covered entities to implement policies and procedures with respect to PHI that are designed to comply with the standards, implementation specifications, or other requirements of the HIPAA Privacy Rule, including the individual right to request restrictions (See 45 CFR 164.530(i)(1)). We stated that we believe that certified health IT should support covered entities so they can execute these processes to protect individuals' privacy and to provide patients an opportunity to exercise this right to the extent feasible. However, we also noted that patient-directed privacy of data the patient deems sensitive requires attention to specific technology and policy challenges, which we recognize are not easily solved (88 FR 23821).

We proposed a new certification criterion in § 170.315(d)(14), an addition to ONC's Privacy and Security Framework under the Program in § 170.550(h), and a revision to an existing “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) to support additional tools for implementing patient requested privacy restrictions (88 FR 23822 through 23824).

We proposed to adopt a new certification criterion “patient requested restrictions” in § 170.315(d)(14) to enable a user to implement a process to restrict uses or disclosures of data in response to a patient request when such restriction is agreed to by the covered entity (88 FR 23822). This criterion was proposed specifically in support of the HIPAA Privacy Rule's individual right to request restriction of certain uses and disclosures (See also 45 CFR 164.522(a)). We proposed that this new criterion in § 170.315(d)(14) would be standards-agnostic, allowing health IT developers seeking to certify a Health IT Module to the criterion flexibility in how they design these capabilities as long as they meet the functional requirements described for certification. We specifically intended the proposed § 170.315(d)(14) to advance the technological means to support clinicians and other covered entities when honoring patient requests for the restriction of uses or disclosure of PHI through certified health IT.

We proposed to add the following in § 170.315(d)(14) for this new criterion “patient requested restrictions”:

• For any data expressed in the standards in § 170.213, enable a user to flag whether such data needs to be restricted from being subsequently used or disclosed; as set forth in 45 CFR 164.522; and
• prevent any data flagged pursuant to paragraph (d)(14)(i) of this section from being included in a subsequent use or disclosure for the restricted purpose.

We proposed that “enabl[ing] a user to flag” means enabling the user of the Health IT Module to indicate that a request for restriction was made by the patient and that the user intends to honor the request. We noted that in the case of integration with a Health IT Module certified to the revised criterion in § 170.315(e)(1), that request made by the patient could be in part automated for requests made through an internet-based method. However, the functionality under the proposed new criterion in § 170.315(d)(14) would include the ability for the user to indicate a request made via other means. We noted that such “flags” may leverage use of security labels like those included in the HL7 data segmentation for privacy (DS4P) implementation guides discussed in section III.C.10.b of the HTI–1 Proposed Rule, or other data standards such as provenance or digital signature specifications. We also noted that the use of such standards or specifications would be at the discretion of the health IT developer, and they would have the flexibility to implement the “enable a user to flag” functionality in the manner that works best for their users and systems integration expectations.

We proposed that the developer of a certified Health IT Module, under the proposed standards-agnostic approach, would have the flexibility to implement the restriction on the inclusion in a subsequent use or disclosure via a wide range of potential means dependent on their specific development and implementation constraints ( e.g., flagged data would not be included as part of a summary care record, not be displayed in a patient portal, or not be shared via an API). We proposed and sought comment on several alternatives which would add standards to the proposed new criterion and would specifically leverage HL7 dS4P IGs for the new criterion in § 170.315(d)(14). We also proposed and sought comment on alternate proposals that looked exclusively at the HL7 Privacy and Security Healthcare Classification System (HCS) Security Label Vocabulary within the HL7 dS4P IGs for a source taxonomy for the “flag” applied to the data (88 FR 23822).

We also proposed to modify the Privacy and Security Framework in § 170.550(h) to add the proposed new criterion. Specifically, we proposed to modify § 170.550(h)(iii) in reference to the certain of “care coordination” certification criteria in § 170.315(b); § 170.550(h)(v) in reference to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1); and to § 170.550(h)(viii) in reference to the § “application access” certification criteria at § 170.315(g)(7) through (g)(9) and the “standardized API for patient and population services” certification criterion at § 170.315(g)(10).

We proposed that the new “patient requested restrictions” certification criterion in § 170.315(d)(14) would be required for the Privacy and Security Framework by January 1, 2026.

We also proposed a modification to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) to support patients' ability to leverage technology to exercise their right to request restrictions of uses and disclosures under the HIPAA Privacy Rule. We proposed that a Health IT Module certified to the criterion in § 170.315(e)(1) must also enable an internet-based approach for patients to request a restriction of use or disclosure of their EHI for any data expressed in the USCDI standards in § 170.213. Specifically, we proposed to modify § 170.315(e)(1) to add a paragraph (iii) stating patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213.

We proposed that conformance with this update to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1)(iii) would be required by January 1, 2026, for Health IT Modules certified to § 170.315(e)(1). Consistent with our proposals in sections III.A and III.C.11 of the HTI–1 Proposed Rule, developers of certified health IT with Health IT Modules certified to § 170.315(e)(1) would have to update those Health IT Modules to § 170.315(e)(1)(iii) and provide them to customers by January 1, 2026.

We did not propose any changes to the current certification criteria for “security–tags—summary of–care—send” and “security–tags—summary of care—receive” in § 170.315(b)(7) and § 170.315(b)(8) respectively; however, we noted that the inclusion of the proposed new certification criterion in § 170.315(d)(14) into the Privacy and Security Framework in § 170.550(h) would mean that the proposed new certification criterion would be applicable for Health IT Modules certified to the “security tags—send” and “security tags—receive” certification criteria as well (88 FR 23822–23823). We sought comment on whether those certification criteria should also be directly modified in alignment with the proposals described in this section (88 FR 23823).

We sought comment on the capabilities we have proposed for the new criterion in relation to the HIPAA Privacy Rule individual right to request restriction of uses and disclosures of PHI. We specifically sought comment on whether the proposed new criterion should include additional functions to better support compliance with the HIPAA Privacy Rule individual right to request restriction of uses and disclosures of PHI. We also sought comment on whether the proposed new criterion should, for example, include capabilities to support HIPAA Privacy Rule provisions for emergency disclosures in § 164.522(a)(1)(iii) and (iv) or termination of a restriction under § 164.522(a)(2).

We sought public comment on each part of this proposal—the new criterion in § 170.315(d)(14), the inclusion of the request capability for patients in § 170.315(e)(1), and the requirements with the Privacy and Security Framework in § 170.550(h)—both separately and as a whole. We specifically sought comment on the feasibility of each part in terms of technical implementation and usefulness for patients and covered entities using these capabilities. We sought comment on the health IT development burden associated with implementation of the capabilities including for the individual certification criterion referenced in the Privacy and Security Framework in § 170.550(h).

In addition, we sought comment on any unintended consequences that the new criterion in § 170.315(d)(14) or the addition to the Privacy and Security Framework in § 170.550(h) might place on patients, clinicians, or other covered entities using certified health IT. We sought comment on whether, and by how much, the use of this criterion as part of broader privacy workflows might represent a reduction in manual effort for covered entities, a positive impact on uptake by patients, or other benefits such as supporting documentation of restrictions as required under the HIPAA Privacy Rule in § 164.522(a)(3).

Finally, we sought comment on methods by which we might quantify the development burden and costs as well as the potential benefits or future cost savings for the new criterion in § 170.315(d)(14), the new functionality in the existing criterion in § 170.315(e)(1), and the addition to the Privacy and Security Framework in § 170.550(h).

Comments. Overall, in response to our new proposal for Patient Requested Restrictions Criterion in § 170.315(d)(14), we received mixed input for our proposals and our alternative proposals from interested parties. Comments ranged from full support to limited support expressing various technical and policy considerations all the way to full opposition because of technical, policy, and patient care concerns. Multiple commenters expressed support for the intent behind the proposal, noting its potential to empower patients to take ownership of their data, while ensuring that providers are not engaging in information blocking for automated data flows and expressed support for the development and implementation of data segmentation technology. Multiple commenters supported giving patients a reasonable opportunity and the technical capability to make informed decisions about the collection, use, and disclosure of their EHI, noting that the functionality is increasingly necessary for ensuring patient trust.

However, in most instances where support was indicated, it was conditional. In these instances, commenters indicated concern with the implementation of the proposal, noting that if ONC were to finalize the proposal then it should be mindful of numerous considerations and challenges. Concerns ranged across many broad policy and technical topics including but not limited to implementation feasibility, unintended consequences such as impacts on patient safety and provider burden, implementation timeline and approach, importance of patient education, and intersections with existing information blocking policy as well as the Trusted Exchange Framework and Common Agreement (TEFCA).

Multiple commenters questioned the readiness of real-world tested, national standards and specifications for this proposal. One commenter suggested that developers should be given flexibility in implementing the criterion, given the breadth of activities, workflows and features in which patient data is used. Some suggested that adopting a standards-agnostic approach will allow health IT developers to determine appropriate implementation in their own systems and could lead to the future development of new, consensus-based standards informed by robust real-world implementation experience across a broad set of developers and health care provider organizations. However, multiple commenters recommended the criterion be standards-based, as based on past examples, a standards-agnostic approach would likely not successfully lead the private sector to come to consensus on their own. Some commenters indicated support for HL7 FHIR DS4P IG but felt it was not clear that it has been adequately tested and deployed in the field. Such commenters stated that ONC should move forward with support for implementations and test them before deploying as a requirement. One commenter indicated ONC should instead look at FHIR for future rulemaking. Multiple commenters recommended that we focus on establishing, with the relevant Standards Development Organizations (SDOs) as well as other relevant groups, a common infrastructure that enables patients to only document their consent rules once, while having a common definition of all relevant privacy rules across US jurisdictions. Multiple commenters recommended federally funded connectathons and other policy-driven approaches to stimulate the developer community to implement toward a particular use case with the purpose of advancing standards development.

We also received comments indicating strong opposition to the new proposal for patient requested restrictions criterion in § 170.315(d)(14). Commenters opposing the proposal shared a similar sentiment to those supporting the proposal provided certain conditions were met. These commenters stated that it is not feasible for developers to support every permutation on the use of data that a patient might request and that the proposed criterion may not provide enough control to help patients manage the complexities of their information. Commenters highlighted the complexity of managing and scaling a consent management infrastructure, especially across all the data sources where the patient's data is available. Others noted this proposal runs a high risk of allowing for a wide variety of misaligned implementation, and some felt it would increase burden and undermine benefits of interoperability.

Multiple commenters suggested that, if adopted, the new proposed criterion in § 170.315(d)(14) should be optional and that adoption of the criterion within the privacy and security framework in § 170.550(h) should not be required before CY 2030. Commenters noted that significant work would be required by health IT developers, including reconfiguration of existing EHR systems as well as other interconnected systems related to treatment, payment and operations and that ONC should allow for a 3-year implementation cycle, 2 years to develop, test and certify, and at least 1 year to roll-out the proposed criterion to customers and update workflows. In response to our request for comment related to the development burden (88 FR 23823), commenters estimated up to one-million hours for preliminary development and rollout, plus additional ongoing maintenance requirements.

We received several comments regarding how to achieve policy goals through alternative approaches and factors that should be taken into consideration—including several that are out of scope of ONC authorities, but informative of the need for alignment to related privacy laws. Several commenters stated ONC should better align with other regulators and have more explicit workflows on privacy and patient consent before adopting this proposed certification criterion in § 170.315(d)(14). One commenter also suggested that this criterion's functionality support providers implementing information sharing practices in compliance with potential future policies to protect sensitive health information regarding “highly politicized lawful health care services.” Multiple commenters recommended introducing a functional requirement aligning with the HIPAA right to request corrections and amendments to erroneous information to ensure patients have an easy path to requesting corrections or amendments to their PHI through patient portals and APIs. They also felt that this would drive participation in standardization efforts through independent patient-led governance bodies. One commenter suggested that this work be funded and supported by the institutions sharing the data and driving these exchanges, and the commenter encouraged use of established patient-created resources to evaluate fairness of engagement with patient communities. Several commenters focused on our proposals in relation to other related regulations. These commenters indicated that ONC should work with other agencies to focus on ensuring there are streamlined and complementary privacy regulations. They additionally commented that any new privacy related regulation gets compared and cross referenced across existing and pending ones to support policy alignment.

Response. We thank the commenters for their thoughtful input addressing both the entirety of the proposals and specific areas of concern. As noted in the HTI–1 Proposed Rule (see, for example, 88 FR 23821), we proposed requirements for Health IT Modules certified under the Program to support workflows and specifications that would enable an individual to exercise their right to request restriction of uses and disclosures under the HIPAA Privacy Rule. We expressed our concerns about feasibility, timelines, and the overall complexity of the workflows and the related capabilities associated with this right as well as our intent to propose several options for consideration by the healthcare and health IT communities. Based on the mixed input we received on the proposed new criterion in § 170.315(d)(14) and the inclusion of the criterion in the privacy and security framework in § 170.550(h), and the strong concerns regarding its implementation feasibility by interested parties opposing these proposals, we have concluded that we should not finalize the proposals at this time. Our decision to not finalize the criterion in § 170.315(d)(14) is informed by the range of comments expressing concern with successfully implementing the proposal. In particular, there was no clear consensus on whether and how to proceed either with immature and untested standards or without the required use of specific standards for the certification criterion at § 170.315(d)(14). We agree with the concerns on the high risk of allowing Health IT Modules to implement a wide variety of misaligned standards and implementation specifications, as well as increased burden on developers of certified health IT, care providers, health information exchange networks, and a high probability of confusion for patients.

We note that those supporting our proposals for § 170.315(d)(14) did so to varying degrees, often extending conditional support while raising the same broad technical and policy considerations and concerns as those opposed to the proposal. Outright support on § 170.315(d)(14) as proposed, or for the various alternate proposals, was not as common as conditional support or opposition. The specific suggestions for such conditional support were varied and would introduce substantial additional detailed specification well beyond the scope of our proposal and the standards in the alternate proposals. Based on this input, there is no clear and consistent approach at this time to effectively address all commenter concerns. Therefore, we have not finalized the specific proposal to adopt a new certification criterion in § 170.315(d)(14). We also have not finalized corresponding modifications related to this proposed criterion's in ONC's Privacy and Security Framework in § 170.550(h). We will continue to encourage and engage with industry and standards development community efforts to advance standards supporting privacy workflows and to monitor the continued evolution of the HL7 DS4P IGs to consider new criteria in future rulemaking.

In consideration of those commenters who articulated full support, we recognize the importance of empowering patients to take ownership of their data and continue to support efforts to develop the technical capability for patients to leverage certified health IT to take affirmative action regarding the collection, use, and disclosure of their EHI. We note that we have maintained the existing criteria in § 170.315(b)(7) and § 170.315(b)(8) which support the application and persistence of security labels for document-based exchange and reference the standards adopted in § 170.205(o)(1), the HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 (HL7 CDA DS4P IG) incorporated by reference in § 170.299. These two criteria require a Health IT Module to (1) enable a user to create a summary record that is tagged as restricted and subject to restrictions on re-disclosure and (2) enable a user to receive a summary record that is tagged as restricted and subject to restrictions on re-disclosure and to preserve privacy markings. The use of Health IT Modules certified to these two criteria can support privacy and security labels based on consent and with respect to sharing and re-disclosure restrictions. As noted, these existing criteria utilize the HL7 CDA DS4P IG, and include the use of the taxonomy of reference (HCS Security Label Vocabulary) for the purposes of applying and identifying standardized security labels on health information at the document, segment, or data element level. These existing certification criteria can be leveraged during transitions of care and sending/receiving summary of care records ( i.e., combined with Health IT Modules certified to § 170.315(b)(1)) and we encourage purchasers of certified health IT to explore the use and incorporation of these capabilities in their Health IT Modules.

We recognize the concerns of both commenters supporting the application of standards and those identifying a lack of readiness and gaps in the standards for the disposition of a disclosure request based on our proposed new criterion. We also recognize those commenters who advised a longer implementation timeline to refine and test standards. While we considered delaying the implementation of our proposal to 2030, or beyond, we believe that Health IT Modules certified to § 170.315(b)(7) and (b)(8) that use the HL7 CDA DS4P IG may serve as a balanced approach to address these disparate concerns by applying the standard where feasible, while allowing broad flexibility for health IT developers to implement functionalities where the standard is silent on core processes. We will continue to monitor uptake of the existing certification criteria at § 170.315(b)(7) and § 170.315(b)(8), as well as continue to work with the healthcare, health IT, and standards community to advance and evaluate the readiness and potential adoption in future rulemaking of the related HL7 FHIR DS4P IG, which is intended to support the same security label taxonomy (HCS Security Label Vocabulary) for health information exchange via standards-based APIs using the FHIR standard.

Comments. We received many comments in relation to our proposal to update the existing “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), to add § 170.315(e)(1)(iii) to support additional tools for implementing patient requested privacy restrictions (88 FR 23822 through 23824) through the inclusion of an “internet-based” method for patients to request a restriction. Commenters were overwhelmingly supportive of the proposal to provide a means for patients to make a restriction request via Health IT Module. However, commenters expressed a wide range of related concerns ranging from the documentation of the request to potential consequences to consider when processing a patient's requests for restriction.

One commenter expressed concern that the HIPAA Privacy Rule does not (with certain exceptions) require a covered entity to restrict disclosure of an individual's PHI if so requested. Instead, the covered entity is required to have a process for approving or denying the request, and that decision is not under the individual's control. One commenter recommended that the certification criterion respect the individual's request for privacy regardless of the covered entity's perspective. However, another commenter noted that requiring the covered entity's approval ensures that important health information is still available when medically necessary while balancing patient privacy and security concerns. One commenter stated that clinicians may have a better understanding than individuals regarding which health data is relevant for their care. Commenters also expressed concern regarding an obligation to accept an individual's request for restriction. One commenter questioned how the lack of restriction on timelines for the request—such as the lookback period for the data or the length of time for which the restriction would be applicable—could impact the clinician's ability to make a reasoned judgment. Another commenter expressed a number of legal concerns relating to concerns that clinicians may have to defend refusals to comply with a patient's request for restriction, or that compliance with the patient's request which could place them in legal jeopardy for fraud, professional misconduct, or criminal charges.

Response. We thank the commenters for their input and support of our proposal to include an internet-based method for an individual to request restriction of uses and disclosures consistent with their right under the HIPAA Privacy Rule. We have finalized this proposed revision to the existing “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) to support additional tools for implementing patient requested privacy restrictions (88 FR 23822 through 23824) through the inclusion of an “internet-based” method for patients to request restriction. Specifically, we have finalized in § 170.315(e)(1)(iii) a requirement that Health IT Modules support patients (and their authorized representatives) to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. We have also finalized that conformance with this paragraph is required by January 1, 2026.

In response to comments on whether a patient or health care provider may be best suited to determine if data should be private, or a covered entity's obligation to accept a patient's request, we reiterate our statement from the HTI–1 Proposed Rule that our intent is to advance technologies that support requirements already extant under the HIPAA Privacy Rule (88 FR 23821). In the HTI–1 Proposed Rule, we described that the HIPAA Privacy Rule provides individuals with several rights intended to empower them to be more active participants in managing their health information. These include the right to access certain health information maintained about the individual; the right to have certain health information amended; the right to receive an accounting of certain disclosures; the right to receive adequate notice of a covered entity's privacy practices; the right to agree or object to, or authorize, certain disclosures; the right to request restrictions of certain uses and disclosures; and provisions allowing a covered entity to obtain consent for certain uses and disclosures. Under the HIPAA Privacy Rule, covered entities as defined in 45 CFR 164.530(i) are required to allow individuals to request a restriction on the use or disclosure of their PHI for treatment, payment, or health care operations and to have policies in place by which to accept or deny such requests (See 45 CFR 164.522(a)(1)(i)(A) and (B)). The HIPAA Privacy Rule does not specify a particular process to be used by individuals to make such requests or for the entity to accept or deny the request. However, we believe that certified health IT should—to the extent feasible—support covered entities so they can execute these processes to protect individuals' privacy and to provide patients an opportunity to exercise this right (88 FR 23821).

We further stated that identifying which health data are defined as “sensitive” may vary across federal or state laws and may further vary based on an individual's perspective. Thus, the concept of “sensitive data” is dynamic and specific to the individual. Patient populations that have historically been subject to discrimination may identify a wide range of demographic information as sensitive, including race, ethnicity, preferred language, sex, sexual orientation, gender identity, and disability status—or patients may want to restrict health data that they view as sensitive, such as behavioral health or reproductive health-related data. These considerations from an individual's perspective may not always coincide with a health care provider's perspective. However, we believe that facilitating the ability of a patient to request such a restriction, in addition to addressing patient considerations, may also provide additional context for health care providers engaged in discussions with patients about their health information, sensitivities, and related concerns.

In response to commenters expressing concerns with timelines associated with requests, we decline to specify any limitations and note that a health care provider might include an option for an individual to specify such information as a part of the internet-based method for requests in § 170.315(e)(1).

For commenters expressing concerns related to legal liabilities, we reiterate that ONC certifies capabilities of Health IT Modules to perform specific functions, in many circumstances using specific standards. These are generally restricted to technical standards and capabilities. The user of the technology may also need to comply with certain requirements established by federal, state, territory, local or tribal law. Our intent for finalizing a technical means for individuals to request a restriction on their data is to advance tools that support privacy laws, including the HIPAA Privacy Rule right to request a restriction of certain uses and disclosures.

We note that the revision adding an internet-based method to make a request that we have finalized as part of § 170.315(e)(1) only supports one component of the HIPAA Privacy Rule. As noted in the HTI–1 Proposed Rule, we emphasize that use of a Health IT Module certified to revised criterion in § 170.315(e)(1) would not, by itself, fully discharge a covered entity's obligations under the HIPAA Privacy Rule to allow an individual to request restriction of the use or disclosure of their PHI for treatment, payment, or health care operations or to have policies in place to address such requests (88 FR 23826). Further, use of any such certified Health IT Module would not discharge the obligations of a covered entity to meet any other requirements under 45 CFR 164.522. In addition, there may be other applicable laws that affect the exchange of particular information, and those laws should be considered when developing policies that provide individuals with more granular control over the use or disclosure of their PHI.

Comments. Several commenters expressed support for a patient's ability to manage various aspects related to their restriction requests. Multiple commenters noted that patients should be able to allow data use/exchange with some parties but not others and be able to decide the timing to safeguard patient autonomy and mitigate criminalization risk. Commenters also suggested that the patient should be able to define when a treatment relationship exists with a provider and only allow exchange with those providers who qualify, without explicit consent from the patient. One commenter noted that patients should be able to group data by type or encounter/procedure date or any criteria the patient wishes to impose on data use and exchange. Another commenter recommended allowing patients to decide how long they would like to restrict sensitive data from being shared. Another commenter suggested that we introduce certification requirements focused on granting health care providers the option to segment entire discrete sensitive notes, which allow clinicians to limit access to notes that patients consider sensitive, in a fully self-contained way.

With regards to recording patient requests for restriction, we received comments related to the inclusion of additional, relevant information. One commenter sought clarification on whether the requirement includes providing a standard way for a patient to state the purpose for a particular restriction. One commenter highly recommended that we include a certification criterion for the “tracking of patient privacy and disclosure requests” and another suggested that the concepts “request for restriction was made” and “request for restriction was granted” be separated in the requirements, recorded, and permanently associated with the related data. They also recommended that if a request is denied, a rejection reason should be required, retained, and exchanged alongside the related data so the next recipient of the data could potentially decide how to respond to the patient request.

Response. We thank the commenters for their input and advocacy on behalf of patients. In the HTI–1 Proposed Rule, we did not include proposals for § 170.315(e)(1) to add specific requirements on the format of the “internet-based method” individuals to request restrictions. We also did not specify additional functionality beyond the capability for patients (and their authorized representatives) to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. For example, we did not propose that the function must enable individuals to specifically identify different access roles for individual care team members or that patients be enabled to group health information in different ways, such as by type or encounter/procedure, or that patients be provided the option to segment entire discrete sensitive notes. We proposed an approach that, at minimum, would support a method for patients to request restrictions on PHI uses and disclosures through means related to the function supporting their ability to view, download, or transmit to a 3rd party their health information using certified health IT. We also did not propose specific terminologies to be used for the recording, disposition or notification of acceptance or denial of such requests. We appreciate the insights into enhanced functionalities and the related recording of data associated with such request, but such additional requirements would constitute a significant deviation from the proposed functionality. We do not believe that our proposals represent sufficient notice of the intent to add such requirements in this final rule. However, we will continue to engage with the health IT, standards, health care provider, and patient advocacy communities and to encourage innovative approaches to implementation of the adopted criteria and standards, as well as advancement of additional interoperable privacy standards and functionality. We will also monitor and analyze approaches by health IT developers for real world implementation of the revised criterion, and will consider such information to inform further modifications in future rulemaking.

We further note that, while we have not finalized the inclusion of additional capabilities or the application of a specific standard, there are obligations imposed on covered entities under the HIPAA Privacy Rule, if they agree to the requested restrictions, which this functionality may partially support, that health IT developers may consider supporting in related capabilities. For example, the HIPAA Privacy Rule prohibits a covered entity that agrees to a restriction request to use or disclose PHI in violation of such restriction except in certain limited circumstances. We encourage developers of certified health IT certifying Health IT Modules to the revised criterion in § 170.315(e)(1) to consider if there are methods that additional health IT tools could integrate with such Health IT Modules to facilitate these processes. In addition, while we did not propose and have not finalized the use of a standard for the use of security labels, we note that the HL7 CDA DS4P IG adopted in § 170.205(o) and the HCS Security Label Vocabulary that is referenced as part of the HL7 CDA DS4P IG are valuable health IT implementation resources for these purposes. As described in the HTI–1 Proposed Rule (88 FR 23824), the HCS Security Label Vocabulary could serve as the basis for a format-agnostic and transport-mechanism-agnostic standard for the application of security labels and to define the general instructions for security labels for a wide range of use cases including patient requested restrictions. While we are not requiring the use of the HCS Security Label Vocabulary within the revised criterion in § 170.315(e)(1), we recommend health IT developers consider its applicability for this purpose. We further note that the existing criteria “security tags- summary of care send and receive” in § 170.315(b)(7) and (b)(8) for sending and receiving summary of care records with security labels applied at the document, segment, or data element level would potentially support the capabilities commenters describe, including, for example, the ability to label a clinical note in the C–CDA as sensitive.

Comments. ONC also received several comments related to health equity and the need for patient-specific education about privacy restrictions. Multiple commenters recommended explaining specific aspects of the proposed functionality to patients such as, how it facilitates individual rights under the HIPAA Privacy Rule, how data is used to improve individual and population outcomes, and the proper role of health IT in protecting the security and privacy of health information. Multiple commenters also recommended providing counseling to patients regarding benefits and risks of restricting data and the impact on their healthcare outcomes and safety. These comments focused on empowering patients with more granular privacy controls while noting that health literacy is an important part of such control in order to avoid disparities in privacy protection and on overall care quality. These commenters also identified that a person may not share sensitive health data if they do not understand the options for data sharing. One commenter suggested that we clarify if and how patients should be informed about functionality, specifically regarding the ability to request a restriction in multiple ways and with different levels of granularity (rather than just having the binary choice to either share or to not share data globally). Some commenters expressed concern that, if presented with complex data-element sharing options, patients may get confused and simply decide against sharing any data. Another commenter suggested that patients also need to be informed that their requests may be denied. Multiple commenters recommended that we add a requirement that patient-facing certified Health IT Modules include the capability to provide educational materials regarding the patient's options about disclosure and instructions regarding how to change disclosure limitations. Other commenters additionally highlighted the importance of patient education and health literacy, particularly for older-adult and disabled patients who may struggle with cognitive impairments or behavioral health issues. Finally, commenters sought clarification on whether the patient will be informed about who will be notified of restriction requests, as some may be concerned about negatively impacting their relationship with their providers and/or healthcare institutions.

In addition to patients, multiple commenters suggested that we provide education and guidance to providers, developers, and the industry as a whole. One commenter noted that provider organizations often do not have a clear mechanism for making patient restriction requests or know how to process/adjudicate/implement them if they do receive requests. Another commenter suggested that the industry will also need significant additional guidance and infrastructure. One commenter suggested that health IT developers should receive guidance regarding standards for developing a process for patient restriction requests. Another commenter noted that without a robust communication, education, and engagement effort, many entities essential to implementing the final rule at medical practices, hospitals, and health systems will be left out. Another commenter recommended that we consider the use of an implementation guide in future rulemaking, and one commenter requested that we provide full guidance on what different types of information should be flagged and how such flags would be addressed in FHIR resources.

Some commenters indicated ONC should provide education and work to clarify how this proposal is balanced with information blocking requirements. One commenter noted that confusion about information blocking often results in compliance officers, administrative personnel, in-house attorneys, and policy consultants misinterpreting regulations. They relayed feedback that some health IT developers refuse to provide patients or physicians granular controls over medical information. The commenter noted that compliance with the information blocking regulation is overriding compliance with other, more protective laws and rules, and they recommend that we adequately educate those involved in interpretating, implementing, and operationalizing our policies. Another commenter also requested that we address overlaps with information blocking, how and when to implement Notices of Privacy Practices by providers, and other healthcare workflow considerations that could allow this criterion to be misinterpreted and potentially abused. A commenter also stated that patients should be educated about information blocking and that patient facing tools should be held to similar requirements for access, privacy, and security as certified health IT products.

Response. We thank the commenters for the thoughtful consideration of the impacts of our proposals. As we noted in the HTI–1 Proposed Rule (see, for example, 88 FR 23748), health equity considerations are a driving force behind our proposals. We described the importance of expanding the interoperability of health data that is essential to identifying health disparities, measuring quality, addressing gaps in care access and outcomes, providing patient-specific preventative care and intervention, and supporting researchers in their ability to address the risk of unintended bias in clinical guidelines that may exacerbate disparities (88 FR 23821). We also described how important it is to ensure that with the expansion of exchange of granular health equity data comes expanded needs for thoughtful and deliberate privacy policies to support and protect patients (88 FR 23821). We discussed how ONC has specifically focused on how health IT can support efforts to reduce healthcare disparities and provide both insights and tools for the purposes of measuring and advancing health equity. This includes specific steps to expand the capabilities of health IT to capture and exchange data that is essential to supporting patient-centered clinical care that is targeted to supporting a patient's unique needs (88 FR 23821). We believe that patients should be empowered to make such decisions for themselves, and that support or education from clinicians might most appropriately be based on clinical impacts and considerations rather than a perceived lack of patient understanding or competency to make informed decisions.

We appreciate commenters suggestion that to fully implement the range of potential rights afforded by the HIPAA Privacy Rule, additional guidance, infrastructure, and standards development is needed to process for patient restriction requests. While we agree with the need for future work on technical specifications and implementation guides, we note that the behavior of covered entities and their role in patient education related to the HIPAA Privacy Rule or other privacy laws is outside the scope of ONC Certification Criteria for Health IT. We encourage covered entities using certified health IT to review and follow the obligations defined under the HIPAA Rules and other applicable laws and programs. We likewise encourage all actors who are required to comply with the HIPAA Rules, whether as HIPAA covered entities or business associates, to know and to comply with all of their obligations under the HIPAA Rules. In response to the comment indicating concern for ONC to extend adequate education on information blocking, we note our deliberate focus on developing accessible, user-friendly resources to help inform the effective implementation of these policies. This includes, but is not limited to, Frequently Asked Questions, recorded national webinars, and infographics all accessible on the ONC website. For discussion of the relationship of privacy laws, including the HIPAA Rules and other laws, to the information blocking regulations, please see section IV.A of this final rule.

Finally, we appreciate commenters' suggestions about ONC's role in educating patients about health IT capabilities and standards as they relate to the privacy and security of health information. We are committed to continued public engagement for that purpose.

Comments. We received mixed feedback on the implementation timeline proposed for health IT developers to comply with any new or revised criteria. In general, commenters (both those opposed to and those supportive of the implementation timelines proposed) address the proposed timelines for updates to the criterion in § 170.315(e)(1) within the context of the implementation burden for that proposed revision and the proposed new criterion in § 170.315(d)(14) together. Multiple commenters expressed concerns that the overall implementation timeline is too aggressive. One commenter noted that if the scope of the proposed new and revised criteria were not narrowed and a holistic effort to also address updates to consent policies is not pursued, a significantly longer implementation period will be required ( i.e., four years or longer). Commenters consistently noted that a development project for the revised criterion in § 170.315(e)(1) in addition to the proposed new criterion in § 170.315(d)(14) would likely require two to three years to code and test and another one to two years for healthcare organizations to implement.

Some commenters shared feedback regarding how to make the proposed implementation timeframe more feasible. Multiple commenters suggested that if we narrow the scope to a limited set of USCDI v3 data elements in § 170.315(e)(1) for which restrictions can be requested and clearly and narrowly define the set of restrictions that certified health IT must support ( e.g., restricting the specified data from being accessed by proxy users of the patient portal) in the proposed criterion in § 170.315(d)(14), two years from the publication of a final rule would be feasible. Another commenter requested that we take an incremental approach and start with a low risk, target use case for the effective date of January 1, 2026. This would allow developers and providers to test, learn from and build on this capability over time at both the developer and user levels to address potential issues and risks.

Conversely, some commenters felt the timeframe would be difficult to operationalize and expressed concerns regarding the implementation timeline as being too aggressive. Multiple commenters noted that the proposed criterion would not be finalized until after the development and finalization of the USCDI v3, which ONC released July 2022, so there would not be perfect alignment between the use of USCDI v3 and the applicability of our proposed new and revised criteria. Some commenters recommended that ONC should have a constrained scope of USCDI subject to the tagging and to start with a more focused set of the most relevant data elements in the USCDI thus excluding certain sensitive data from what is shareable from within the USCDI until the criterion is fully operationalized. Commenters encouraged “control” or “consent” as an over-arching principle to be timed along with USCDI's expansion to more person-centered information and concepts. Commenters noted this alignment is essential for EHR developers to have the incentive to give users control over their preferences and for physicians be able to honor patients' expressed preferences related to sensitive, life-changing, or abnormal results. In one instance, a commenter also indicated that if ONC were to finalize this proposal then it should reconsider implementation to an earlier requirement date of January 1, 2024, to ensure that operationalizing patient requested restrictions is an immediate priority for software developers if finalized.

Response. We thank the commenters for their input and consideration of implementation needs and challenges. As previously noted, we have not finalized the proposed new criterion at § 170.315(d)(14) nor the corresponding changes to § 170.550(h). We have only finalized the revisions to the criterion in § 170.315(e)(1). We believe that the reduced scope of the changes we have finalized—focusing on the revised criterion in § 170.315(e)(1) and outlining our commitment to encourage the further adoption, use, and advancement in support of numerous care settings and use cases of the existing criteria in § 170.315(b)(7) and (b)(8) for sending and receiving health information with security labels—should help mitigate the concerns over scale, implementation timeframes, and feasibility. We also believe this approach is appropriate to supporting the advancement of health IT for privacy workflows that place importance on the need to empower patients with agency and control of their data, while acknowledging real challenges, including but not limited to scale and feasibility, as described earlier including from those in support of our proposals. We also agree with commenters that the revisions to the criterion in § 170.315(e)(1) for use of the USCDI v3 are finalized to occur at the same time as the revisions to the criterion in § 170.315(e)(1) described in this section. We have finalized that these revisions to the criterion in § 170.315(e)(1) align with the updates made to USCDI, as discussed in section III.C.1 of this final rule, so that the functionality is synchronized with the USCDI v3 including any new or updated data elements.

We have finalized our proposal to revise the criterion in § 170.315(e)(1) as proposed, with the specific revision in § 170.315(e)(1)(iii). Pursuant to other policy decisions discussed elsewhere in this final rule on compliance timing, we have adopted our proposal that conformance with this new paragraph will be required for Health IT Modules certified to § 170.315(e)(1) by January 1, 2026.

11. Requirement for Health IT Developers To Update Their Previously Certified Health IT

In the HTI–1 Proposed Rule, we proposed to make explicit in the introductory text in § 170.315 that health IT developers voluntarily participating in the Program must update their certified Health IT Modules—including when new standards and capabilities are adopted—and provide that updated certified health IT to customers in accordance with the timelines defined for a specific criterion or standard where included, such as via cross-reference, in § 170.315 (88 FR 23827). We proposed that health IT developers with health IT certified to any of the certification criteria in § 170.315 would need to update their previously certified Health IT Modules to be compliant with any revised certification criterion adopted in § 170.315 (please see section III.A.2 of this final rule for discussion of the adopted definition of revised certification criterion (or criteria)), including any certification criteria to which their Health IT Modules are certified that reference new standards adopted in 45 CFR part 170 subpart B, and capabilities included in the revised certification criterion. Health IT developers would also need to provide the updated health IT to customers of the previously certified health IT according to the timelines established for that criterion and any applicable standards (88 FR 23827).

We noted that in addition to supporting the goals of the Program, we believe this approach will help to advance interoperability. We stated that requiring health IT developers who voluntarily participate in the Program to update Health IT Modules to revised certification criteria (including new and revised standards) can help to advance capabilities for access, exchange, and use of EHI for authorized use under applicable State or Federal law. In addition, we explained that ensuring health IT developers voluntarily participating in the Program provide such updates to customers will help to enable the secure exchange of EHI with, and use of EHI from, other health information technology without special effort on the part of the user. We also stated that the proposed timelines serve to support clear and transparent benchmarks for furthering interoperability throughout the health IT infrastructure (88 FR 23827).

We explained that the updates to criteria may include technical capabilities such as security enhancements or additional electronic transactions not previously supported for a criterion. These updates may also include an expansion of the data supported by content, vocabulary, and format standards to increase the scope of interoperable EHI (88 FR 23827). The adoption of USCDI v3 and its incorporation into certification criteria through updates to those criteria, as finalized in this rule, means that certified health IT systems will be able to support representation of this health information in a standardized computable format. Updating current systems to incorporate these data elements and providing updated certified health IT to customers would allow users of certified health IT to begin to access, exchange, and use such data without special effort. Over the long term, this advancement of interoperability for certified health IT systems may also have a positive impact on the availability of this essential data and the capability to access, exchange, and use this data across a nationwide health IT infrastructure—including for purposes not yet specifically supported by certified health IT such as clinical research (88 FR 23827).

Comments. Commenters outlined concerns regarding the definition of “provide” and, specifically, the preamble language that states, “[we] propose that to `provide' the product means the developer must do more than make the product available and there must be demonstrable progress towards implementation in real-world settings.” Commenters expressed confusion about what “demonstrable progress towards implementation in real-world settings” means and suggested ONC clearly define this phrasing. Commenters also mentioned concerns about how the responsibility of implementing or upgrading to health IT meeting the revised certification requirements ultimately lies with the provider and not the developer.

Response. We thank commenters for their input. We appreciate that the responsibility of implementing a Health IT Module is not solely on the developer. With this final rule, as discussed below, we recognize the potential for variation in how implementation of certified health IT proceeds, including implementation consistent with the agreements, contracts, and licenses that exist between health IT developers and their customers of certified health IT. Overall, our proposed approach is not new or exclusive to the proposed updates in the HTI–1 Proposed Rule, but rather is consistent with the approach ONC adopted for the ONC Cures Act Final Rule updates to the 2015 Edition certification criteria (85 FR 25664). From the effective date of the ONC Cures Act Final Rule through December of 2022, and based on the programmatic technical assistance, developers of certified health IT successfully updated their technology and provided it to customers. However, as discussed in the HTI–1 Proposed Rule, ONC used the terms “provide” and “make available” interchangeably in the ONC Cures Act Final Rule, and subsequent technical assistance (including through correspondence and via public forums) was required to support clarity and achieve that transition (88 FR 23828). We also noted in the HTI–1 Proposed Rule that “provide” does not imply that the Health IT Module must be in production use across all customers (88 FR 23828). Under this clarification for the term “provide,” we have finalized as proposed that “provide” does not mean that the Health IT Module must be in production use across all customers. We encourage developers of certified health IT to provide updated Health IT Modules to their customers—and support them in their implementation of such updated modules—in the manner most appropriate to support safety, security and interoperability across settings and systems.

It is beneficial or necessary to further define “demonstrable progress toward implementation in real world settings” as the phrasing or concept is not part of the finalized regulatory definition of “provide.” As noted by commenters, the phrasing/concept introduces additional confusion over what might constitute demonstrable progress and whether implementation includes production use.

We stated in the HTI–1 Proposed Rule, and continue to maintain, that we do not intend for “provide” to mean either that customers who no longer wish to use a certified Health IT Module must be provided the update or that customers who do choose to use an updated certified Health IT Module must have the updated Health IT Module in production use by the timelines established for the health IT developer (88 FR 23828). We note that there are a number of instances in which a health IT developer will have updated the Health IT Module, but the customer may have declined the update. This can occur when the customer is not yet ready to implement new functionalities, standards, and/or workflows, or when the customer decides that the functionalities, standards, and/or workflows are not relevant to their clinical practice.

With consideration of the above explanations, we have finalized the term “provide” with a further clarification that “provide” is binary. That is, the updated Health IT Module is either provided to customers (respective of customer choice) by the timeline established, or it is not. Further and accordingly, we have also finalized that a health IT developer must update a Health IT Module as described and provide customers with updated Health IT Modules in order to maintain certification of the Health IT Module. Consistent with the definition of interoperability and the Assurances Condition and Maintenance requirements discussed in section III.D, the certified Health IT Module must be able to support all the capabilities to which it is certified, and such capabilities must be provided to the customer for use without special effort by the end of the regulatory specified timelines.

We also note that we proposed to include the definition of “provide” in § 171.102, which stated that “ Provide is defined as it is in § 170.102.” We did not intend to define “provide” in part 171 of the HTI–1 Proposed Rule. Therefore, in this final rule, we have not finalized the revision to add the definition of “provide” in § 171.102.

We have finalized in § 170.315 for all revised certification criteria and in 45 CFR part 170 subpart B for each applicable standard, as proposed, that a Health IT Module may be certified to either the existing certification criterion or the revised certification criterion until the end of the transition period when the prior standard(s) and/or certification criterion no longer meet certification requirements. During this time period, existing customers may continue to use the certified health IT they have available to them and can work with their developers to implement updates in a manner that best meets their needs consistent with the established regulatory timeframes. Finally, as with the 2015 Edition Cures Update, in order to support effective communication of the updates, we will implement a practical approach to facilitate transparency using the Certified Health IT Product List (CHPL), which is the tool that health care providers and the general public may use to identify the specific certification status of a certified health IT product at any given time, to explore any certification actions for a product, and to obtain a CMS Certification ID for a product, which is used when participating in some CMS programs.

Comments. Commenters voiced concerns about how the HTI–1 Proposed Rule aligns with CMS's Promoting Interoperability Program—specifically, the impact on the timing of when hospitals and clinicians implement or upgrade an EHR in order to comply with CMS regulations.

Response. We thank commenters for their feedback. We have worked closely with CMS for more than a decade to ensure alignment between our Program and CMS programs, including the Medicare Promoting Interoperability Program and the Quality Payment Program (these programs incorporate the programs previously known as the EHR Incentive Payment Programs, or “Meaningful Use”) and we will continue to do so moving forward. For example, CMS finalized in the CY 2021 PFS final rule (85 FR 84815 through 84828) that health care providers participating in the Medicare Promoting Interoperability Program and eligible clinicians participating in the Quality Payment Program must use certified health IT that satisfies the definitions of CEHRT at 42 CFR 495.4 and 414.1305, respectively, and is certified under the Program, in accordance with the 2015 Edition Cures Update, as finalized in the ONC 21st Century Cures Act Final Rule (85 FR 25642).

As part of the CY 2024 PFS Final Rule, CMS finalized revisions to the definitions of CEHRT in §§ 495.4 and 414.1305 for the Medicare Promoting Interoperability Program and for the Quality Payment Program (88 FR 78308 through 79312) in a manner consistent with the “edition-less” approach to health IT certification that we proposed in the ONC HTI–1 Proposed Rule. This included removing references to the “2015 Edition” in the CEHRT definition, and that in order to meet the CEHRT definitions, technology must meet ONC's certification criteria in 45 CFR 170.315 “as adopted and updated by ONC.” CMS stated that these revisions would ensure that updates to the 2015 Base EHR or subsequent Base EHR definition at § 170.102, and updates to applicable health IT certification criteria in § 170.315, would be incorporated into CEHRT definitions, without requiring additional regulatory action by CMS. CMS noted in its final rule that it will continue to determine when new or revised versions of measures that require the use of certified health IT would be required for participation under the Medicare Promoting Interoperability Program and the Quality Payment Program. In determining requirements for any potential new or revised measures, CMS stated it will consider factors such as implementation timelines and provider readiness to inform when CMS proposes requiring participants to complete measures that rely on the use of certified health IT (88 FR 79310). We will continue to work with CMS as we finalize timeline requirements for developers of certified health IT to update and provide certified health IT to their customers so that their customers ( e.g., health care providers) can meet CMS requirements for the use of such certified health IT. We also note that, historically, CMS has included additional guidance for program participants within CMS proposed or final rules (see, for example, 85 FR 84818–84828).

Comments. Commenters in general agreed that if a Health IT Module is not updated to new or revised certification criteria, then the Health IT Module should be retired at the “expiration date” of the certification criterion and/or standard. One commenter expressed confusion about using the term “shall update” when it is up to the developer to determine if they want to update their health IT to comply with new or revised certification criteria.

Response. We thank commenters for their input. Participation in the Program is voluntary and, therefore, any “shall” statements within the Program only apply to a health IT developer that is participating and plans to continue to participate in the Program. If a developer participating in the Program intends to no longer support a specific certified Health IT Module, but intends to continue to participate in the Program, previously finalized policies relating to the withdrawal of a Health IT Module or modification of a certificate would remain applicable (88 FR 23828). Otherwise, if a health IT developer participates in the Program and intends to maintain certification of a Health IT Module, the developer will need to comply with the requirements of the Program, including the finalized requirement in the introductory text to § 170.315 stating “[f]or all criteria in this section, a health IT developer with a Health IT Module certified to any revised certification criterion, as defined in § 170.102, shall update the Health IT Module and shall provide such update to their customers in accordance with the dates identified for each revised certification criterion and for each applicable standard in 45 CFR part 170 subpart B.”

D. Assurances Condition and Maintenance of Certification Requirements

In the HTI–1 Proposed Rule, we proposed to establish a new Condition of Certification and accompanying Maintenance of Certification requirements under the Assurances Condition of Certification (88 FR 23828 through 23830). These new requirements would serve to provide the assurances to the Secretary that Congress sought in the Cures Act and further clarify Program requirements that are established under the authority Congress provided in section 3001(c)(5) of the PHSA, as amended by the Cures Act, and discussed in detail in the HTI–1 Proposed Rule (88 FR 23826).

1. Condition of Certification

We proposed in § 170.402(a)(5), that, as a Condition of Certification, a health IT developer must provide an assurance that it will not inhibit a customer's timely access to interoperable health IT certified under the Program (88 FR 23829). To support this assurance, we proposed accompanying Maintenance of Certification requirements, which are discussed below. The Maintenance of Certification requirements define the scope of this Condition of Certification and provide clarity in terms of what it would mean to take the action of “inhibiting,” what constitutes “timely access,” and what is “interoperable health IT certified under the Program” (88 FR 23829).

Comments. In general, commenters supported the establishment of a new Condition of Certification and the accompanying Maintenance of Certification requirements. Commenters identified multiple benefits of the proposed requirements such as ensuring timely access to interoperable health IT and promoting the adoption of advanced technologies and capabilities that can enhance patient care and workflow efficiency. One commenter noted how these requirements will positively impact the community of health centers by ensuring they have access to the latest capabilities and standards.

Response. We thank commenters for their support. As noted above and discussed in detail in the HTI–1 Proposed Rule (88 FR 23826), these new requirements will serve to provide the assurances to the Secretary that Congress sought and further clarify Program requirements. Interoperable health IT is an underpinning of the Program and particularly the conditions of certification found in the Cures Act and implemented in 45 CFR part 170 subpart D. Congress established support for health IT interoperability beginning with the authority provided in section 3001(c)(5) of the HITECH Act to adopt standards (including implementation specifications and certification criteria) and establish the Program.

For purposes of certification and the maintenance of such certification under the Program, a health IT developer will need to provide an assurance that its health IT is certified to the most recently adopted certification criteria and such certified health IT is made available to its customers in a timely manner. These actions are essential because certification criteria, and in particular revised certification criteria (as defined in this final rule), include standards, implementation specifications, and capabilities that support and improve interoperability as that term is defined by the Cures Act and incorporated in 45 CFR part 170. Since the inception of the Program, ONC has updated certification criteria to include the most recent versions of standards and implementation specifications that most appropriately support and improve interoperability at the time of adoption. We do this because as standards and implementation specifications evolve, they, by their very nature, improve interoperability by allowing for more complete access, exchange, and use of all electronically accessible health information. Further, the interoperability definition also focuses, in part, on the secure exchange and use of EHI from other health IT without special effort on the part of the user. The Assurances Condition of Certification is an important piece to supporting and achieving these goals because it seeks assurances from health IT developers that they will not take any actions to inhibit the appropriate access, exchange, and use of EHI. We, therefore, have finalized in § 170.402(a)(5), as proposed that, as a Condition of Certification, a health IT developer must provide an assurance that it will not inhibit a customer's timely access to interoperable health IT certified under the Program.

Comments. A handful of commenters expressed concern about how the Maintenance of Certification requirements may be interpreted as mandatory when the decision to participate in the Program is voluntary. One commenter identified the use of the term “shall update” as possibly being misunderstood as an obligation for developers to continue to participate in the Program when, in fact, it is up to the developer to determine if they want to pursue certification or to allow the module to be retired.

Response. We thank the commenters for their input. Participation in the Program is voluntary. Health IT developers do not have an obligation to continue to participate in the Program. However, as discussed under section III.C.11 “Requirement for Health IT Developers to Update their Previously Certified Health IT,” if a health IT developer does participate in the Program, it needs to comply with the requirements of the Program, including the finalized Assurances Condition and Maintenance of Certification requirements.

Comments. Two commenters identified difficulties in navigating between the different requirements for certified health IT for ONC and CMS. Both commenters recommended CMS delay the effective date of changes to the definition of CEHRT referenced within CMS programs until the next reporting period or performance year. The commenters stated that this proposed modification would eliminate confusion and promote cross-agency collaboration.

Response. We thank the commenters for their feedback. We recognize that certain CMS programs, including the Medicare Promoting Interoperability Program and the Quality Payment Program, require the use of technology meeting the CEHRT definitions in 42 CFR 495.4 and 42 CFR 414.1305. The CEHRT definitions cross-reference health IT certification criteria in 45 CFR 170.315, including relevant dates within the certification criteria which define the requirements of the certification criterion.

While changes to the definition of CEHRT maintained by CMS are outside the scope of this final rule, we note that, as part of the CY 2024 PFS Final Rule, CMS finalized revisions to the definitions of CEHRT in 42 CFR 495.4 and 414.1305 for the Medicare Promoting Interoperability Program and for the Quality Payment Program (88 FR 78308 through 79312), including specifying that in order to meet the CEHRT definitions, technology must meet the 2015 Base EHR or subsequent Base EHR definition (as defined at 45 CFR 170.102) and other certification criteria in 45 CFR 170.315 “as adopted and updated by ONC.” CMS stated that these revisions would ensure that updates to the 2015 Base EHR or subsequent Base EHR definition at § 170.102, and updates to applicable health IT certification criteria in § 170.315, would be incorporated into the CEHRT definitions, without requiring additional regulatory action by CMS. We also note that CMS stated that it did not agree with separate effective dates in the CEHRT definitions for the use of updated certified health IT products within the Medicare Promoting Interoperability Program or the Quality Payment Program, as recommended by commenters (88 FR 79311). CMS stated that emphasizing the timelines ONC adopts through notice and comment rulemaking for health IT developers to update and provide certified technology to their customers will reduce burden on participants in the Medicare Promoting Interoperability Program and the Quality Payment Program. CMS further stated that it will continue to determine when new or revised versions of measures that require the use of certified health IT would be required for participation under the Medicare Promoting Interoperability Program and the Quality Payment Program and will consider factors such as implementation time and provider readiness to determine when to require reporting on these measures. We agree with CMS' statements on these topics.

In order to support effective communication of the updates, we intend to implement a practical approach to supporting CMS program participants and other certified health IT users through the Certified Health IT Product List (CHPL) in the same manner as was implemented for the 2015 Edition Cures Update. As also discussed under section III.C.11 “Requirement for Health IT Developers to Update their Previously Certified Health IT,” the CHPL is the tool that health care providers and the general public may use to identify the specific certification status of a certified health IT product at any given time, to explore any certification actions for a product, and to obtain a CMS Certification ID for a product, which is used when participating in some CMS programs. We note that historically, CMS has included additional guidance for such program participants within CMS proposed or final rules (see, for example, 85 FR 84818–84828).

2. Maintenance of Certification Requirements

We proposed, in § 170.402(b)(3)(i), that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion (88 FR 23829).

We also proposed, in § 170.402(b)(3)(ii), that a health IT developer must provide all Health IT Modules certified to a revised certification criterion to its customers of such certified health IT. We clarified that a customer, for this purpose, would be any individual or entity that has an agreement to purchase or license the developer's certified health IT (88 FR 23829).

We proposed separate “timely access” or “timeliness” Maintenance of Certification requirements for each of the two proposed Maintenance of Certification requirements above that would dictate by when a Health IT Module must be updated to revised certification criteria, including the most recently adopted capabilities and standards; and by when a Health IT Module certified to a revised certification criterion, including the most recently adopted capabilities and standard, must be provided to the health IT developer's customers. We proposed, in § 170.402(b)(3)(iii), that unless expressly stated otherwise in 45 CFR part 170, a health IT developer must complete the proposed “update” and “provide” requirements according to the following proposals. First, we proposed, in § 170.402(b)(3)(iii)(A), that a health IT developer must update and provide a Health IT Module by no later than December 31 of the calendar year that falls 24 months after the effective date of the final rule adopting the revised certification criterion or criteria. Second, we proposed that the “provide” requirement would need to be completed within this same timeframe for customers of the previously certified health IT that must be updated under the “update” proposal. However, we proposed deviations to this timeframe because the “provide” requirement applies to all Health IT Modules that are certified to a criterion that meets the revised certification criterion definition ( i.e., not just health IT previously certified to a `prior version' of a revised certification criterion) and to new customers of health IT certified to revised certification criteria (88 FR 23829 through 23830).

In all the above circumstances, we proposed that health IT certified to revised certification criteria must be provided to all customers, including new customers ( i.e., new to the capabilities), of health IT developers under the Program within reasonable timeframes (88 FR 23830).

Comments. Multiple commenters supported the Assurances Condition and Maintenance of Certification requirements. One commenter suggested health IT developers be required to provide all current and new customers with the most current version of a certified Health IT Module. Additionally, the commenter recommended that all health IT developers who have chosen not to comply with new or revised certification standards send a communication to customers in order to better inform such customers.

Response. We thank commenters for their support. We have finalized in § 170.402(b)(3)(i), as proposed, that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion. For clarity, ` applicable revised certification criteria' includes those certification criteria to which the Health IT Module was previously certified that meet the definition of a revised certification criterion as finalized in this rule (please see section III.A.2 of the preamble, including Table 1, and “revised certification criterion (or criteria)” under § 170.102 of the regulation text for the definition of revised certification criterion (or criteria)). Equally important, and, as stated above, to meet the requirement, the Health IT Module will need to be updated to the most recently adopted capabilities and standards included in the revised certification criterion. Second, we have finalized, in § 170.402(b)(3)(ii), that a health IT developer must provide all Health IT Modules certified to a revised certification criterion to its customers of such certified health IT. As noted above, a customer, for this purpose, is any individual or entity that has an agreement to purchase or license the developer's certified health IT.

In response to the comment about sending a communication to customers by a health IT developer not complying with the “update and provide” requirements, we note that the developer would, under the commenter's described circumstances, violate these new Maintenance of Certification requirements and the Condition of Certification we have finalized at § 170.402(a)(5), by inhibiting a customer's timely access to interoperable health IT certified under the Program. As such, the developer will have committed non-conformities under the Program, unless the health IT developer did so for a permissible reason as described in section III.C.11 (for example, a developer of certified health IT would not be required to provide updated certified health IT to any customer that elected to decline the update for any reason; or a health IT developer's exercising its ability to reduce the scope of a certification while not under ONC–ACB surveillance or ONC direct review). Because we did not propose a requirement that health IT developers who have chosen not to comply with new or revised certification standards send a communication to customers in order to better inform providers and hospitals, we have not accepted this recommendation. However, if the developer committed a non-conformity, the Program process for correcting the non-conformity may involve notification to all customers.

Comments. Commenters requested additional information regarding when, as proposed, a regulatory exception (“unless expressly stated otherwise in 45 CFR part 170”) to the 24-month criteria might be applied by ONC in § 170.402(b)(3)(iii)(A). Commenters outlined how a possible exception creates additional timelines in an environment where competing priorities between meeting deadlines associated with ONC requirements and the requirements under CMS regulations already exist. A few commenters requested ONC provided explicit guidelines about when a regulatory exception to the “24 months plus X” requirement might be applied. One commenter expressed concern about how this proposed regulatory exception may negatively impact development roadmaps and the ability to fulfill requests falling outside of non-regulatory functionality. Further, multiple commenters expressed concerns about the proposed deadlines and the implications these timeframes have on developers and providers. Commenters stressed the importance of having 18–24 months to address any new or revised certification requirements and identified the December 31st date outlined in the HTI–1 Proposed Rule as a specific concern. One commenter specifically stated “[g]iven requirements on the implementation end of the cycle, vendors must have 24 months prior to general availability to properly develop and certify their solutions.”

Response. We appreciate commenters' feedback. For purposes of regulatory clarity, we have revised the proposed “timeliness” provision in § 170.402(b)(3)(iii)(A). We have modified the proposed timeliness requirement to state, “a health IT developer must complete the “update” and “provide” requirements consistent with the timeframes specified in part 170” (§ 170.402(b)(3)(iii)(A)). This means that the compliance dates included in the certification criteria in § 170.315 and standards in subpart B will establish when health IT developers need to comply with these Maintenance of Certification requirements. In § 170.402(b)(3)(iii)(B), we have finalized the provision that health IT developers will still have up to 12 months, at a minimum, to provide new customers with health IT certified to revised criteria. Specifically, we have finalized that for health IT developers that obtain new customers after the effective date of a final rule, the health IT developer must provide health IT certified to revised certification criteria either in the timeframe identified in part 170 or not later than 12 months after the purchasing or licensing relationship has been established between the health IT developer and the new customer for the health IT certified to the revised criterion.

The timeframe, as noted above, will offer health IT developers no less than 12 months to provide health IT certified to revised certification criteria to new customers ( i.e., customers new to the capability). Based on the timeframe, a health IT developer has the ability to plan both the certification to revised certification criteria and the execution of contracts and agreements with new customers to ensure that it can meet the above timeline for new customers. To note, we have also finalized a conforming revision to the Real World Testing Maintenance of Certification requirements in § 170.405(b), as proposed at 88 FR 23830, in that we removed most of the “update and provide” requirements currently found in § 170.405(b)(3) through (7) and (b)(10) because they will be moot based on the effective date of this final rule ( e.g., many timelines expired on December 31, 2022). Therefore, in § 170.405, we removed and reserved paragraphs (b)(3) through (7) and (b)(10).

E. Real World Testing—Inherited Certified Status

In the ONC Cures Act Final Rule, we finalized requirements in § 170.405(a) that a health IT developer with Health IT Module(s) certified to § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must: successfully test the real world use of the technology for interoperability in the type(s) of setting(s) in which such technology would be marketed. We established in § 170.405(b) that each developer's annual real world testing plan is required to be published by December 15 of a given year and would need to address all of the developer's Health IT Modules certified to criteria listed in § 170.405(a) as of August 31 of that year (85 FR 25769). We also finalized that the annual real world testing plan would pertain to real world testing activities to be conducted in the year following the December 15 plan publication due date, with an annual real world testing results report to be published by March 15 (§ 170.405(b)(2)(ii) of the year following the year in which the real world testing is conducted) (85 FR 25774).

Many health IT developers, however, update their Health IT Module(s) on a regular basis, leveraging the flexibility provided through the Program's Inherited Certified Status (ICS) option. Because of the way that ONC issues certification identifiers, this updating can cause an existing certified Health IT Module to be recognized as new within the Program. All updates to certified health IT must be tracked and recorded to support program integrity and transparency within the Program. When a certified health IT developer leverages ICS for Health IT Modules that have been updated, they receive a new certification date for the newer version of the certified Health IT Module. When an ICS certification is issued, a new certification date is issued by the ONC–ACB to reflect these updates. Regular updating, especially on a frequent basis such as quarterly or semi-annually, creates an anomaly that could result in existing certified Health IT Modules being inadvertently excluded from the real world testing reporting requirements because of those updates.

In order to ensure that all developers test the real world use of their certified health IT, as required, we proposed in the HTI–1 Proposed Rule to eliminate this anomaly by requiring health IT developers to include in their real world testing results report the most recent version of those certified Health IT Module(s) that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted (88 FR 23831). This approach would ensure that health IT developers fully test all applicable Health IT Modules as part of their real world testing requirements. This policy would also prevent a developer from avoiding, or delaying conducting or reporting, real world testing specifically on the updated versions of Health IT Modules certified through Inherited Certified Status after August 31 of a given year. This policy would not change the underlying requirement that a developer with one or more Health IT Modules certified to any criterion listed in § 170.405(a) must plan, conduct, and report on real world testing of each of those Health IT Modules on an annual basis.

Comments. A significant number of commenters supported our proposal to require developers of certified health IT to include in their real world testing results report newer versions of those certified Health IT Module(s) that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted. Many commenters reiterated the importance of real world testing and expressed appreciation for ONC's efforts to address the anomaly that could result in existing certified Health IT Modules being inadvertently excluded from the real world testing reporting requirements when updated using Inherited Certified Status before their real world testing results reports are due. Several commenters praised the requirement to demonstrate conformity in a production environment and the assurance gained from testing results that reflect the most recent version of the certified health IT used to meet real world testing requirements. A commenter in support of this proposal suggested that ONC make real world testing mandatory for all health IT developers. Overall, commenters in support of this proposal recognize real world testing as a critical component to verifying certified health IT, eligible for real world testing, works in real world scenarios and use cases, and appreciate ONC's efforts to advance real world testing requirements by requiring health IT updated using Inherited Certified Status to be included in health IT developers' real world testing results reports. One commenter requested that ONC clarify in rulemaking which versions of the certified Health IT Module, after updating using ICS, are required to be included in real world testing results report.

Response. We appreciate these comments and agree with the need to ensure newer versions of certified Health IT Modules updated after the August 31 deadline using Inherited Certified Status are accounted for in real world testing and results reporting. We have issued public resources that provide clarity on what versions of certified health IT should be included in real world testing results reports and believe that the guidance is sufficient for developers to determine, for their unique circumstances, which versions of their certified health IT should be included in their results reports. Currently, certification criteria identified in § 170.405(a) are required to adhere to the Real World Testing Condition and Maintenance of Certification requirements, and this final rule does not change the applicable criteria (§ 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h)). ONC will continue to collaborate with interested parties to ensure all required certified health IT continues to function in real-world scenarios and workflows as intended by certification requirements for interoperability and data exchange. We have finalized our requirements at § 170.405(b)(2)(ii) for health IT developers to include in their real world testing results report the newer version of those certified Health IT Module(s) that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted.

Comments. One commenter was not supportive of this proposal and the requirement for health IT developers to conduct real world testing on their certified health IT and expressed concerns that it adds no value to health IT certification. This commenter suggested that if available functionality is not being implemented in production environments it should not be required for real world testing.

Response. We did not propose any substantive changes or updates to the real world testing requirements in § 170.405. Congress required the real world testing of certified health IT for interoperability in the Cures Act (PHSA § 3001(c)(5)(D)(v)). We have implemented this requirement through the Real World Testing Condition and Maintenance of Certification requirements. The real world testing of certified health IT has value to the Program and users of certified health IT. Since December 2022, more than 500 real world testing plans and results have been submitted by developers of certified health IT with applicable certification criteria. The plans and reports have provided insight into how developers of certified health IT think about framing and measuring the interoperability of their certified Health IT Modules in production use. The plans and reports also provide interested parties with information they can use to understand how a specific certified Health IT Module is demonstrating real world interoperability. We are aware of the challenges faced by health IT developers when establishing approaches to meet their real world testing requirements. ONC has released several public resources to assist the developer community in developing real world testing plans and navigating unique circumstances such as low adoption of specific certified health IT capabilities. Among numerous points of guidance, the Real World Testing Resource Guide includes information on how developers of certified health IT should treat Health IT Modules that do not have functionality or that have not yet implemented functionality in production environments. We also reiterate that the Aug 31 deadline for eligible certified health IT supports developer preparation activities well before entering the applicable calendar year of real world testing.

Comments. Several commenters raised concerns that are out of scope for the proposal, including suggestions for additional certification and real world testing requirements to improve interoperability, none of which are addressed in this rulemaking. Some made recommendations for how ONC may enhance certification and real world testing requirements by further defining measures, data elements, and how health IT should be assessed for data augmentation solutions. A number of these commenters expressed the need for additional real world testing requirements, such as more rigorous testing of data segmentation, standards and implementation guides, and required standard code sets. Some commenters requested more focus on public health data and the use of standard code sets to improve data quality for real world testing, stating that clinical and laboratory partners require data inputs that are high quality, correctly coded, and not reliant on human readability or narrative text to provide critical information. Commenters asserted that these additions to real world testing requirements would diminish mapping burden, improve data entry, facilitate improvements to data quality, and lessen administrative burden on clinical staff. One commenter requested that ONC require real world testing of certified health IT before the sale and implementation of the certified health IT in clinical settings. Another commenter requested that ONC not consider standards mature until they have been real world tested with publicly available comprehensive testing reports. Lastly, one commenter raised issues related to human research protocols when conducting real world testing using real patient data and the need to protect this data from misuse.

Response. We thank commenters for the input. Because these recommendations for certification and real world testing requirements are out of scope for the HTI–1 Proposed Rule in that we did not propose to change any related real world testing conformance requirements, we decline to finalize any such changes. ONC previously finalized requirements, through the ONC Cures Act Final Rule, for real world testing plans and results reports, the required elements to be included, and developers' responsibilities for establishing measure(s) for their approach to assessing their health IT in real world settings (see 85 FR 3580). We reiterate that the proposal finalized in this final rule specifically addresses health IT developers who update their certified Health IT Modules using Inherited Certified Status after the August 31 deadline and before results reports are due for a particular year of real world testing. We also note that the Inherited Certified Status flexibility is specifically designed for updates to certified Health IT Modules that do not adversely impact certified capabilities.

F. Insights Condition and Maintenance of Certification

1. Background and Purpose

The Cures Act specified requirements in section 4002(c) to establish an EHR Reporting Program to provide reporting on certified health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. Data collected and reported would address information gaps in the health IT marketplace and provide insights on the use of certified health IT.

To develop the EHR Reporting Program, ONC contracted with the Urban Institute and its subcontractor, HealthTech Solutions, to engage the health IT community for the purpose of identifying measures that developers of certified health IT would be required to report on as a Condition and Maintenance of Certification under the Program. Detailed background and history on the overall process, and the Urban Institute's reports, can be found in the April 18, 2023 Proposed Rule titled, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (88 FR 23832). For clarity purposes, we refer to the Condition and Maintenance of Certification associated with the “EHR Reporting Program” as the “Insights Condition and Maintenance of Certification” (also referred to as the “Insights Condition”) throughout this final rule. We believe this descriptive name captures a primary policy outcome of this requirement.

2. Insights Condition and Maintenance of Certification—Final Measures

In the HTI–1 Proposed Rule (88 FR 23831), we stated that the proposed measures associated with the Insights Condition related to and reflected the interoperability category in section 3009A(a)(3)(A)(iii) of the PHSA. We further stated that these measures related to four aspects or areas of interoperability, which we referred to as measurement “areas:” individuals' access to EHI, public health information exchange, clinical care information exchange, and standards adoption and conformance, as discussed in further detail below (88 FR 23831). We explained that the majority of our proposed measures were data points derived from certified health IT. The measures generally consisted of numerators and denominators that would help generate metrics ( e.g., percent across a population), which were further detailed in each measure, but the measures could also serve as standalone values. We noted that in some cases we planned to generate multiple metrics by using different denominators for the same numerator or using different numerators with the same denominator. For each proposed measure, we included information on the rationale for the proposed measure, proposed numerators and denominators, and key topics for comment.

As stated in the HTI–1 Proposed Rule, we proposed to modify measures developed by the Urban Institute to reduce ambiguities and to address potential costs and burdens. Based upon public comment and interested party input consistent with section 3009A(a)(3)(C) and (D) of the PHSA, we proposed to modify the measures the Urban Institute developed, as well as the proposed minimum reporting qualifications, to ensure that small and startup developers are not unduly disadvantaged by the measures.

We also stated that in future rulemaking we anticipated proposing additional measures for future iterations of the Insights Conditions and Maintenance of Certification requirements under the Program and that through this first set of measures we intended to provide insights on the interoperability category specified in the Cures Act (as codified at section 3009A(a)(3)(A)(iii) of the PHSA). We also stated that we intended to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future requirements (88 FR 23832).

In the HTI–1 Proposed Rule (88 FR 23832), we stated that we explored various pathways on how to make it easier for the public to view and comment on the detailed technical specifications supporting the measures. We directed readers to consult our website healthIT.gov and provide comment on the technical specifications for measure calculation. We received numerous comments regarding the information described in the technical specifications for the measures, including the definitions of various measurement-related terms such as encounters and duplicate C–CDAs. We have included summaries of these comments within their respective measure sections in this final rule. While the substantive requirements for each measure are defined in this final rule, we determined that measure specification sheets are a logical and accessible method for the public to also view the technical specifications that support those requirements. The finalized specification sheets accompanying this final rule are available at www.healthit.gov/hti-1. This is consistent with the approach used by other HHS programs related to measure technical specifications ( e.g., CMS Electronic Clinical Quality Measures (CMS eCQMs)). This approach of publishing technical specification separately allows for more effective viewing of the technical details, including supporting public comment on those specifications in a transparent manner. We welcomed comments on the measure specifications sheets accompanying the HTI–1 Proposed Rule and noted in the HTI–1 Proposed Rule (88 FR 23832) that such public comment will be used to further refine the technical specifications. We also stated that we intended to keep these measure specification sheets up to date. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion.

Comments. Commenters, including health care provider specialty organizations, technology advocates, health information exchanges, healthcare quality organizations, and some health IT developers, were generally supportive of our proposals to implement the new Insights Condition, and of the measures and reporting processes described. A few commenters emphasized the potential of information gleaned from the Insights Condition to drive transparency in the health IT marketplace and, in particular, to highlight ways for patients to access and use their data. One commenter noted that ONC's development of the Insights Condition demonstrates commitment to improving interoperability, and encouraged ONC to envision a future state of health information exchange capabilities that include patient-requested restrictions, outcomes tracking, and integration of data from other sources such as Prescription Drug Monitoring Programs. Commenters also lauded the potential of the Insights Condition to clarify trends in current capabilities for interoperability services such as APIs that will allow the market to address gaps and improve interoperability. One commenter noted that they believe public health programs and safety net providers could particularly benefit from the Insights Condition and encouraged ONC to work with community health centers to ensure that its implementation supports the populations they serve.

Response. We thank commenters for the feedback and appreciate their support for the potential of the Insights Condition to address information gaps in the marketplace and improve interoperability. We also appreciate comments taking note of our efforts to improve interoperability and continue to explore avenues to increase efficient information exchange for use in improving health and healthcare. As stated in the HTI–1 Proposed Rule (88 FR 23831), data collected and reported under the Insights Condition will address information gaps in the health IT marketplace and provide insights on the use of certified health IT. We also agree that public health and safety net providers can benefit from increased market transparency that the Insights Condition can provide. We will continue to engage with public health professionals and safety net providers in our implementation of the Program.

Comments. Some commenters suggested that information gained from the Insights Condition will not benefit current users of certified health IT, and some commenters questioned the value of the data in furthering interoperability.

Response. We fundamentally disagree with this perspective offered by some commenters. In the Cures Act, Congress established the requirement to create an EHR Reporting Program and we believe that submission of specific measures pursuant to the Insights Condition under the Program will provide transparent reporting, address information gaps in the health IT marketplace, and provide insights on the use of certified health IT. The adopted metrics are specifically meant to provide insights on how certified health IT enables various aspects of interoperability, including individuals' access to EHI, public health information exchange, clinical care information exchange, and standards adoption and conformance. These metrics help address gaps in information in the health IT marketplace by providing data on key aspects of interoperability that are neither directly nor publicly available from other sources. As described in greater detail within this final rule, the metrics will be shared with the public in a transparent manner on ONC's website.

Comments. A few commenters expressed support and understanding of the use of numerators and denominators by ONC. One professional society expressed support of all proposed measures and numerator/denominator combinations. One commenter specifically voiced support for all the various numerator/denominator combinations proposed as a key opportunity to provide market transparency on various aspects of how information is being exchanged and used by patients and health care providers, and another commenter specifically supported requiring health IT developers to report on the measures. Further, the commenter highlighted the potential of the various combinations to help ONC provide market transparency on various aspects of how information is being exchanged and used by patients and health care providers.

On the other hand, a number of commenters expressed confusion related to the terms numerator and denominator. One commenter requested ONC establish more succinct separation and definition of numerators and denominators for the Insights Condition. Further, the commenter stated measure definitions for numerators and denominators are confusing and overlap. Another commenter found the terms numerator and denominator confusing and requested that ONC use different ones. One commenter encouraged ONC to maximize reuse of collected data, such as allowing a given measure to be submitted once and tagged to count for all relevant metrics where it can be reused. One commenter suggested that ONC state in the overview section for the Insights Condition that developers will be required to submit raw data, and metrics will be calculated after submission. Another commenter suggested removing expected metrics from the specification sheets and only focusing on counts or metrics to be collected by health IT developers.

Response. To reduce confusion, we have replaced the terms “numerator” and “denominator” with “metric” throughout the Insights Condition. Numerator and denominator were terms meant to identify how the metrics would be used to generate various statistics, but given the confusion expressed through public comments related to these terms, we have simplified and replaced these terms. Thus, instead of a list of numerators and denominators that would be submitted, health IT developers shall be responsible for submitting a list of metrics. This applies across all the finalized measures. This represents a change in terminology and does not represent a substantive change. Developers of certified health IT are responsible for reporting on the metrics, not calculating the derived statistics. We would like to reiterate that ONC will be responsible for calculating any derived statistics from the reported metrics using various combinations of the metrics (previously known as numerators and denominators). In other words, this final rule focuses on listing the metrics that developers of certified health IT would be collecting and reporting, rather than the derived statistics which ONC will calculate.

Comments. Some commenters requested clarification on the information that would be required for submission by health IT developers. One commenter requested ONC establish detailed, clear, and consistent specifications for reporting and attestation under the Insights Condition.

Response. As stated earlier in this preamble and in the HTI–1 Proposed Rule (88 FR 23832), we explored various pathways on how to make it easier for the public to view the detailed technical specifications supporting the measures. We determined that measure specification sheets were a logical and accessible method for the public to view the technical specifications supporting those requirements in a clear and consistent manner and that measure specification sheets have been used successfully by other agencies such as CMS for detailing their measures. The information in this preamble and in the measure specification sheets provides the list of metrics and specifications for reporting and attestation under the Insights Condition. We intend to provide up to date measure specification sheets to assist with the community's understanding of the finalized measures and metric calculations. The measure specifications provide granular definitions and other information needed to operationalize the metrics to ensure they are implemented in a consistent manner across health IT developers. The updated measure specification sheets that reflect the final set of metrics will be available for download and viewing on ONC's website at www.healthit.gov/hti-1. We believe that the measure specification sheets provide a more user-friendly format that is more easily accessible. For example, given that not all metrics may be applicable to all health IT developers, developers can select which metrics they wish to review and download. We also intend to publish educational materials on ONC's website that include graphics and other visual displays to help explain the metrics and the reporting process.

Measurement Area: Individual Access to Electronic Health Information

In the HTI–1 Proposed Rule, we proposed in § 170.407(a)(1) a measure within the individuals' access to their EHI measurement area to require that any developer of certified health IT with Health IT Modules certified to the criteria specified in the measure to report on the different methods individuals use to access their health information. We refer readers to the HTI–1 Proposed Rule (88 FR 23833) for detailed background associated with the “individuals' access to electronic health information supported by certified API technology” measure.

Comments. Many commenters expressed support for the proposed measure noting the importance of patients' engagement in their own healthcare and the need to further understand how individuals access their health data. Most commenters indicated support of the general intent and focal points of the proposed measure, while including recommendations to simplify the measure. Some commenters indicated this measure would pose a high level of burden, particularly related to encounter-based metrics. Another commenter stated the proposed measure should not present a significant regulatory burden as the data can be collected in real-time using established technologies.

Response. We have made revisions in response to public comment in an effort to reduce burden and simplify reporting as further described below. We note for readers that we have revised some of the measure names (including the name of this measure, which we updated to individuals' access to electronic health information through certified health IT) for additional clarity and consistency. The revisions to the measure names do not inherently reflect substantive changes to the measure. We have used the phrase “certified health IT” across our measures to provide clarity and consistency across the Program. We thank commenters for expressing support for the proposed measure and agree that it will contribute valuable insight into the methods that individuals use to obtain access to their EHI. This information can help ONC and others build an understanding of where EHI is available for usage so that individuals can make informed decisions about their healthcare.

Individuals' Access to Electronic Health Information Through Certified Health IT Measure

We proposed (88 FR 23833) to adopt the “individuals' access to electronic health information supported by certified API technology” measure within the “individuals' access to electronic health information” area in sect; 170.407(a)(1). We proposed (88 FR 23833 and 23834) to require that any developer of certified health IT with Health IT Modules certified to either the “view, download, and transmit to a 3rd party” certification criterion (§ 170.315(e)(1)), or the “standardized API for patient and population services” certification criterion (§ 170.315(g)(10)), report the numbers of unique patients that used each of the specified methods to access their EHI.

We proposed two distinct numerators and three denominators as part of the measure (88 FR 23834) in § 170.407(a)(1) and noted that we planned to generate multiple metrics from a combination of different numerators and denominators. We proposed (88 FR 23834) the first numerator to be the number of unique individuals who had an encounter and accessed their EHI at least once during the reporting period via at least one of three types of methods: (1) third-party app using technology certified to “standardized API for patient population services” certification criterion under § 170.315(g)(10); (2) patient portal using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1) only; or (3) app offered by the health IT developer or health care provider using technology certified to the API criterion under § 170.315(g)(10) (if applicable). We proposed (88 FR 23834) a second numerator to be the number of unique individuals who accessed their EHI regardless of an encounter during the reporting period using at least one of the same three types of methods identified above. We stated that each of these numerators would be stratified or reported by type of method. For detailed background on the proposed measure, we refer readers to the HTI–1 Proposed Rule (88 FR 23834).

We proposed (88 FR 23834) the first denominator for this measure to be the total number of unique individuals who had an encounter during the reporting period. We proposed (88 FR 23834) the second denominator to be the total number of unique individuals who used at least one of the types of methods referenced above to access their EHI who had an encounter during the reporting period. We proposed (88 FR 23834) the third denominator to be the total number of unique individuals who used at least one of the three types of methods referenced above to access their EHI during the reporting period (regardless of whether the individual had an encounter or not).

Comments. Commenters representing EHR developers stated that the proposed measure would result in medium to high qualitative ratings of burden, particularly for the encounter-based measures, and shared suggestions to modify its structure. Several commenters representing health IT developers recommended separating the measure into two measures: (1) a measure applicable to Health IT Modules certified to the § 170.315(g)(10) criterion; and (2) a measure applicable to Health IT Modules certified to the § 170.315(e)(1) criterion. These commenters also expressed concern that the structure of the measure did not align with product level reporting and could create issues and inconsistencies in reporting and interpreting its results. These commenters further stated that many Health IT Modules are certified either to § 170.315(g)(10) or 170.315(e)(1), but very few are certified to both. They suggested that ONC revise the measure to report on patient access (view, download, and transmit) via patient portal versus FHIR via apps and reported at the developer level.

Commenters also recommended removing the third access method that was proposed in the HTI–1 Proposed Rule (88 FR 23834) referred to as “App offered by the health IT developer or health care provider using technology certified to the API criterion under § 170.315(g)(10) (if applicable).” They explained that, per the API Condition and Maintenance of Certification requirements, developers of certified Health IT Modules shall treat all (similarly situated) app developers as the same. Therefore, they would be unable to distinguish whether an app is offered by a developer of certified health IT or by a health care provider. Two commenters stated that they would be able to distinguish between access via apps that they developed versus others, but they did not see the relevance of it.

Commenters also requested clarification on the measure structure for numerators and denominators.

Response. We appreciate the assessment from commenters on the level of effort to develop this measure. Considering the medium to high burden ratings from health IT developers that commented on the measure, we have made three modifications intended to simplify and reduce the burden of implementing the measure while establishing a starting place for initial reporting that can be expanded in the future.

First, given that commenters indicated that it would be difficult to distinguish whether an app is offered by a developer of certified health IT or by a health care provider, we have removed the third method of access to EHI from the measure that we had proposed in the HTI–1 Proposed Rule (88 FR 23843), referred to as, “App offered by the health IT developer or health care provider using technology certified to the API criterion under § 170.315(g)(10) (if applicable).” Second, we have simplified the metrics (formerly referred to as numerators and denominators) by removing the stratification related to methods of access, and instead incorporated the stratification in the metrics. This now aligns the metrics to each associated criterion and addresses the concern that very few Health IT Modules are certified to both criteria (§ 170.315(g)(10) or § 170.315(e)(1)). Third, as suggested by commenters, we have removed the metrics related to encounters from this measure. We acknowledge that health IT certified to one criterion only, particularly to § 170.315(g)(10), would not be able to report encounters. By removing the requirement around unique individuals with encounters, we expect that developers of products certified to only one criterion will be able to report access to EHI via the applicable method. We also finalized this measure without encounter-based metrics as we considered how an encounter-based measure would apply to health IT developers who offer and implement integrated systems across ambulatory and inpatient settings, as well as developers who offer and implement only ambulatory systems and only inpatient systems. For developers offering integrated systems, an individual might have an ambulatory visit and an inpatient visit within the reporting period and access their EHI. However, the proposed construction of the encounter-based metrics would have required developers to determine the unique individuals and reconcile their encounters and EHI access across ambulatory and inpatient value sets, which would be a complex endeavor. Therefore, this measure does not include encounter-based metrics in efforts to reduce both complexity and burden of implementing the measure.

We will use a third metric, which counts the number of unique individuals who access their EHI during the reporting period using any method, to assess trends in individuals' use of the two methods of access. This will allow ONC to evaluate as developers of certified health IT continue to make more APIs available under § 170.315(g)(10), and it will also provide insight into individuals' use of methods beyond those required for certification that are facilitating patient access to their electronic health information.

Comments. A commenter requested clarification on whether individuals were expected to have both an encounter during the reporting period and access their EHI during the reporting period, or whether the reporting period refers only to the encounter. The commenter also requested clarification on whether the individual has ever accessed their EHI should be counted. A couple of commenters expressed concern about whether deduplication is expected, noting that most denominators and numerators are feasible if developers of certified Health IT Modules are not expected to deduplicate individuals' access counts. They suggested ONC should either change counts to be transaction-based and avoid unique patient measurement, or clarify that unique patient count will be unique only within each instance of the EHR software and cannot be deduplicated across instances.

Response. We have revised the encounter-based approach for the measure so that encounters are no longer included. With regards to the concern related to deduplication, we require unique patient counts of access during the reporting period. However, we recognize that the counts would only be unique within each instance of the EHR software. To clarify, the measure should report on whether individuals accessed their data during the reporting period; this is not a measure of an individual ever accessing their EHI.

Comments. Several commenters requested that ONC clearly state whether the scope is for patients accessing their own records, exclusive of authorized representative access events. Most commenters requested that the measure not include access by authorized representatives. One commenter requested that ONC should include access by an individual's authorized representative in the measure count.

Response. We thank commenters for their feedback on whether patient-authorized representatives should count in the measure when they access EHI and note that there was no consensus. While we agree with the commenter suggesting that ONC should include access by an individual's authorized representative, we did not propose this distinction for our measure. As such, we may incorporate patient-authorized representatives in future rulemaking, noting that it would be beneficial to align this measure with the CMS Promoting Interoperability (PI) Measure for patient access, which similarly counts patients and their authorized representative in the numerator for providing access to patient-authorized representatives for view, download, and transmit (VDT), and apps of the patients' choice. The finalized measure only counts individuals.

Comments. We received comments indicating the need to clarify the definition for access to EHI. Some commenters sought further clarification on the proposed methods of portal and API access for this measure. One commenter asked, in cases where the patient portal may display several electronic health information elements on the log-in landing page, if such a scenario counts as a patient accessing their EHI via a patient portal. One commenter asked whether patient portal access should count any use of the patient portal or specifically a view, download, or transmit to a 3rd party activity. Regarding individual access via a developer's app, a commenter requested clarity on whether an app using different technology than what is included in § 170.315(g)(10) should be counted. For an API, one commenter requested clarity on whether the measure should record the submission of a request for information or the response to the request.

Response. We appreciate the opportunity to clarify how access to EHI is defined for the finalized measure. The definitions associated with this measure (as noted earlier) are described in detail in the measure specifications. Access to EHI via patient portal using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1) is counted as a patient log-in with the access credential belonging to the individual at least once during the reporting period. Access to EHI via technology certified to the “standardized API for patient population services” certification criterion under § 170.315(g)(10) is counted as the individual's authorization, as indicated by an access token, at least once during the reporting period. To summarize, access to EHI is based upon an individual logging into a system (whether that be a portal or third-party app or other system) within the reporting period and is not based on accessing any specific piece of information or performing any specific action within the system itself such as view, download and transmit activities.

Comments. We received some comments suggesting expanding the proposed measure. One commenter suggested that the data should report on whether individuals are accessing their health information more than once in the same reporting period. Another suggested that the data should report those individuals who tried to access their health information via the proposed methods and failed. Another commenter suggested reporting “percentage of use” similar to what was proposed for the “use of FHIR bulk data access through certified health IT” measure to measure the adoption of API-based means of access by single users in a developer's client base. One commenter noted that the most common method for authenticating users of third-party health apps is via their patient portal account and that some patients may only use their portal to access their app of choice. They suggested ONC provide an additional metric to determine whether the portal is being used to access health information directly or to access health information via a third-party app. Finally, one commenter suggested collecting additional data for this measure to support health equity, suggesting the measure include a patient's language.

Response. We appreciate comments suggesting expanding the measurement of individual access to EHI and agree that there are several important dimensions of access to EHI to explore. Given that we also received numerous comments related to the burden associated with reporting the current proposed measures, we have not added the suggested additional requirements at this time, though they may provide further insights. Our intent is to balance the value of the information we now require to be collected with the burden of doing so. We may consider these suggestions in future iterations of the measure through rulemaking.

Comments. One commenter expressed concern and requested clarification about how the measure may reflect on the quality of a developer of certified Health IT Modules' products. The commenter stated that health care providers have the relationships with patients and provide the instructions to access their health information, while developers have no influence on these activities.

Response. We acknowledge that there are many factors that influence how and to what degree individuals access their EHI, including those mentioned by commenters. While the results do not solely reflect on the performance of the health IT developers, the methods health IT developers provide to access EHI may vary in usability, implementation of functionality, and robustness of functionality, which may influence patient and provider use of EHI. The measure intends to shed light on the role that health IT plays in facilitating access to EHI through different methods.

Comments. One commenter asked about the entity that would be responsible for reporting on the measure in a situation where the health IT developer relies upon a different certified Health IT Module (owned by a separate entity) in order to meet the certification criteria associated with the Insights Condition (in this case § 170.315(e)(1). Specifically, the commenter sought clarity on whether the developer of the certified health IT module using the relied upon software would be responsible for reporting, or if the developer of that relied upon software would be responsible for reporting.

Response. We appreciate the request for clarification. In these instances, similar to how this is addressed through the Real World Testing requirements, we would expect a health IT developer using relied upon software in its Health IT Module to meet the certification requirement associated with § 170.315(e)(1) to report on this Insights Condition measure on its own accord. The health IT developer may work with its relied upon software vendor, if necessary, to report on the metrics.

Finalization of Measure

We have finalized the measure as “individuals' access to electronic health information through certified health IT ” in § 170.407(a)(3)(i). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described further in the accompanying measure specification sheets located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion. The reporting period for the measure and related metrics below consists of one calendar year. Data collection for the measures and associated metrics will begin during the first phase of reporting (which is described later in the preamble):

(1) Number of unique individuals who accessed their EHI during the reporting period using technology certified to the “standardized API for patient population services” certification criterion under § 170.315(g)(10).

(2) Number of unique individuals who accessed their EHI during the reporting period using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1).

(3) Number of unique individuals who accessed their EHI using any method. The methods are not limited to third-party apps using technology certified to “standardized API for patient population services” certification criterion under § 170.315(g)(10) or patient portals using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1) during the reporting period.

Measurement Area: Clinical Care Information Exchange

In HTI–1 Proposed Rule (88 FR 23834), we proposed two measures under the “clinical care information exchange” area in § 170.407(a)(2) and (3) titled, “C–CDA documents obtained using certified health IT by exchange mechanism” and “C–CDA medications, allergies, and problems reconciliation and incorporation using certified health IT.” These measures primarily focused on characterizing the state of information exchange between health care providers who are customers of health IT developers with certified health IT, in contrast to other measures that capture exchange with individuals, public health agencies, and other entities.

Comments. Numerous commenters indicated general support for both clinical care information exchange measures. Commenters representing health care providers valued the reconciliation and incorporation measure because effective reconciliation and incorporation of medication, allergy, and problem information through certified health IT benefits patient safety and care coordination. Some commenters suggested that examining volume alone would not be a good indicator of interoperability advancement or quality. Rather, measures that focus on the efficiency of reconciliation in combination with volume measures would provide better insights into the advancements in interoperability. One commenter suggested removal of both measures.

Response. We appreciate the support expressed for both clinical care exchange measures. We believe measuring volume is important as it provides the means to assess the extent that patient information is moving between providers to facilitate high value care. Furthermore, patient and encounter volume measures help contextualize and interpret other measures designed to assess progress related to interoperability. Current measures to understand the magnitude of information exchange and use are fundamentally limited. For example, as noted in the HTI–1 Proposed Rule (88 FR 23835), publicly available information from some health information networks can be difficult to interpret without also knowing the number of encounters occurring at sites using these methods, the number of patients being treated, and other measures of volume. Measures intended to provide insight into the volume of information exchanged across the nation are not feasible to collect from end users through clinical surveys, and the CMS PI Program measure is reported by a subset of providers that participate in that program.

We agree with commenters that measures of efficiency and effectiveness of health IT to support deduplication and reconciliation alongside measures of volume of clinical care documents received and incorporated will provide valuable insight on interoperability trends. Both measures are discussed more fully below.

Consolidated Clinical Document Architecture (C–CDA) Documents Obtained Using Certified Health IT by Exchange Mechanism Measure

We proposed (88 FR 23834 and 23835) to adopt the “C–CDA documents obtained using certified health IT by exchange mechanism” measure in § 170.407(a)(2). We stated that this measure would report on the volume of C–CDA documents obtained using certified health IT by exchange mechanism relative to patient volume, and that a developer of certified health IT with Health IT Modules certified to the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) would be required to report the proposed numerators and denominators for this measure. We refer readers to the HTI–1 Proposed Rule (88 FR 23834 through 23836) for detailed background on the proposed measure.

We proposed four numerators and four denominators for this measure (88 FR 23835). We noted in the HTI–1 Proposed Rule (88 FR 23835 and 23836) that we planned to generate multiple metrics from different combinations of these numerators and denominators. We proposed to adopt the following numerators for this measure: (1) number of unique C–CDA documents obtained (which we defined for the purpose of this proposal as either C–CDAs that are received—that is, C–CDAs that have been sent or `pushed' by others and received using certified health IT or C–CDAs that are queried—that is, C–CDAs that were found or `pulled' from a network or central repository using certified health IT) using certified health IT and Direct Messaging during the reporting period; (2) number of unique C–CDA documents obtained (received or queried) using certified health IT and a local/regional health information exchange (HIE) or national health information network (HIN) during the reporting period; (3) number of unique C–CDA documents obtained (received or queried) using certified health IT and a developer-specific HIN ( i.e., a network that facilitates exchange between entities using the same health IT developer's products) during the reporting period; and (4) number of unique C–CDA documents obtained (received or queried) using certified health IT and a method not listed above and not including electronic fax during the reporting period.

We proposed (88 FR 23835) to adopt the following denominators for this measure: (1) number of encounters during the reporting period; (2) number of unique patients with an encounter during the reporting period; (3) number of unique patients with an associated C–CDA document during the reporting period; and (4) number of unique C–CDA documents obtained (received or queried) using certified health IT during the reporting period. We proposed (88 FR 23835) to include denominators for the number of encounters during the reporting period and the number of unique patients seen ( i.e., with an encounter) during the reporting period to provide a sense of the volume of C–CDA documents exchanged relative to the number of instances when a C–CDA document might be useful.

Comments. While numerous commenters expressed general support for this measure, some commenters raised concerns. Their major concerns related to: (1) burden associated with the measure and the overall program; potentially including health care providers as they may need to map their exchange partners to different types of networks for reporting purposes; (2) rethinking the mechanisms which include a mix of methods and standards that are not mutually exclusive; (3) measuring beyond standards that reflect the current state such as FHIR, which may become dominant in the future; (4) better defining and specifying the selected exchange mechanisms; and (5) potentially including mechanisms that do not result in structured, interoperable data, such as e-fax, to more fully measure the totality of exchange, including exchange across the care continuum with providers who do not possess electronic exchange capabilities.

Response. We thank commenters for their feedback and agree with the concerns raised by commenters related to the potential burden of some metrics, including impacts on providers, the need to reduce overall burden associated with the Insights Condition, and the ability to meaningfully distinguish between the proposed exchange mechanisms given the overlap between the use of standards and methods of exchange. Therefore, we have not finalized the “C–CDA documents obtained using certified health IT by exchange mechanism” measure. Although we value measuring exchange mechanisms, the ecosystem for HIE methods is evolving, particularly with the launch of TEFCA. The evolving landscape for exchange calls for a measure that tracks trends related to the adoption and use of each mode of exchange to better inform ONC's policy making and health care providers' operational decisions. We may consider proposing a revised version of this measure in a future rulemaking with the intent of capturing trends in how clinical information is being exchanged, inclusive of FHIR-based exchange.

Consolidated Clinical Document Architecture (C–CDA) Problems, Medications, and Allergies Reconciliation and Incorporation Through Certified Health IT Measure

We proposed (88 FR 23836) to adopt the “C–CDA medications, allergies, and problems reconciliation and incorporation using certified health IT” measure in § 170.407(a)(3), which would capture the number of C–CDA documents that are reconciled and incorporated (as defined in § 170.315(b)(2)(iii)) as part of a patient's record by clinicians or their delegates. We proposed (88 FR 23836) that a developer of certified health IT with Health IT Modules certified to the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) would be required to provide information on how data in C–CDA documents are used, focusing on the reconciliation and incorporation of medications, allergies and intolerances, and problems.

We proposed (88 FR 23836) the numerator to be the total number of C–CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms supported by the certified health IT during the reporting period. The numerator would increment, or increase in number, upon completion of clinical information reconciliation of the C–CDA documents for medications, allergies and intolerances, and problems, as described in the certification criterion in § 170.315(b)(2).

We proposed (88 FR 23836) the denominators for this measure, using the definition of “encounter” described earlier in the preamble of the HTI–1 Proposed Rule (88 FR 23832), as the following: (1) number of encounters during the reporting period; (2) number of unique patients with an encounter during the reporting period; (3) number of unique patients with an associated C–CDA document during the reporting period; and (4) number of unique C–CDA documents obtained using certified health IT during the reporting period. For this fourth denominator, we indicated that we were aware that in the current landscape, some clinicians and hospitals are able to receive C–CDA documents through multiple methods and it is possible to receive multiple copies of the same C–CDA ( e.g., via Direct Messaging and an HIE). We sought to only include unique C–CDA documents in both the numerator and denominator because we believed that clinicians were unlikely to reconcile multiple copies of the same C–CDA and that by eliminating these duplicates, we would avoid undercounting reconciliation (88 FR 23837).

Comments. Several commenters who indicated general support for the measure also expressed concerns about the burden associated with the measure. These commenters noted that their reports for clients on a similar measure for the CMS PI Program do not necessarily create efficiencies in aggregating the data across their clients. One commenter indicated the value of the measure did not outweigh the burden because many of their clients do not regularly reconcile and incorporate documents they obtained.

Commenters representing EHR developers also provided qualitative ratings of burden associated with these measures. They indicated that the data points ( e.g., numerators/denominators) “number of encounters” and “number of unique patients with an encounter” would be low level of effort; whereas “number of unique patients with an associated C–CDA document” and “number of C–CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms” would be a high level of effort. The rest of the clinical care exchange numerators and denominators were rated as medium level of effort. The commenter expressed that the “number of unique patients with an associated C–CDA document” was rated as high in burden because greater clarification was needed related to what the term “associated” meant.

Response. We appreciate the feedback from commenters. In response to public comments, we have revised metrics to reduce burden associated with the measure as further discussed in this section below. We appreciate that aggregating data across clients at the product level requires additional effort even if the incorporation and reconciliation measure is similar to the CMS PI measure, but we maintain that the existence and use of the similar data structures to generate reports for clients creates efficiencies for developers relative to the counterfactual, in which no such data structures currently exist. We believe the measure will provide value commensurate with the burden described by commenters. As noted earlier, commenters representing health care providers expressed value in the proposed incorporation and reconciliation measure. If providers are not engaging in these activities, it would be useful to make that information more widely known to healthcare organizations, payers, and other interested parties involved with patient safety through this measure. Providers may find the measures useful to evaluate their workflows and health IT configuration to optimize functionality that supports incorporation and reconciliation.

The version of the metric included in the measure specification is described in more detail below and in the measure specification itself. We have included the following metrics described at 88 FR 23835 in the measure specification: number of encounters during the reporting period, number of unique patients with an encounter during the reporting period, and number of unique patients with an associated C–CDA document during the reporting period. These metrics are included as described at 88 FR 23835, except for a revision to the measure of encounters described further in this preamble.

We have revised the metrics, “number of unique C–CDA documents obtained (received or queried) using certified health IT during the reporting period” (88 FR 23835) and “the total number of C–CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms through the certified health IT during the reporting period” (88 FR 23836) to better capture how health IT functions and to reduce requirements specific to the Insights Condition. The revisions are further described later in this section.

Comments. Numerous commenters requested clarification on whether duplicate documents should be counted and asked how duplicates should be defined. Some commenters recommended that all documents be counted, whether duplicative or not, because all documents must be managed. Furthermore, one commenter recommended that ONC require that all documents are counted, whether considered duplicates or not, because whether documents are duplicates or not, all must be processed, deduplicated, and reconciled. Comments also indicated that deduplication may not be necessary if the intended purpose is to examine trends over time. Commenters noted that there is not necessarily industry consensus on what it means for information to be duplicative. Numerous commenters noted that examining the full content of documents to verify if documents are duplicates may not be feasible. Most commenters indicated that ONC should limit its definition to duplicates based upon document identifiers as that was the most feasible option, though these commenters acknowledged that relying on document identifiers alone to identify them may not fully capture all duplicative documents.

Response. We appreciate the input from commenters on how the measures should manage duplicate C–CDAs. In response to feedback, the approach to identifying duplicate C–CDAs to support metrics related to unique C–CDA documents, as included in the measure specifications accompanying the HTI–1 Proposed Rule, has been revised. We have removed the requirement for health IT developers to identify C–CDAs that “otherwise contain substantially identical data as identified by developers of certified health IT.” In the measure specification accompanying this final rule, we have provided a definition for “unique C–CDAs” so that duplicate C–CDAs shall be identified based upon document identifier only, and only one of multiple C–CDAs with the same document identifier will be included in a count of unique C–CDAs. For example, if an HIE receives a C–CDA from a health care provider and regenerates the C–CDA, the content of the document does not change, but the document may have a new document ID. In this instance, we will not require health IT developers to undertake the effort to analyze the content to determine if it is identical to the original C–CDA's content, and we recognize that C–CDAs containing identical information would not be counted as a duplicate if they have different document IDs.

We agree with the commenters who highlighted the work necessary to process, deduplicate, and reconcile both non-duplicative and duplicative C–CDAs, and the importance of capturing the totality of all C–CDAs processed. In response to this comment, we have added a metric as the number of total C–CDA documents obtained, inclusive of potential duplicate documents as described in the measure specification. This reflects the totality of documents measured by health IT developers, irrespective of document identifier. This metric relates directly to the proposed metric “number of unique C–CDA documents obtained using certified health IT during the reporting period” (88 FR 23835) and would represent the count of C–CDAs before deduplication processes were applied. Given the substantial comments we received on the deduplication process as described in the measure specification, we believe that this permutation on the underlying metric was both anticipated by and supported by public comment.

We have also retained the metric counting the unique number of C–CDAs and have made a revision by modifying the approach to identifying duplicate C–CDAs underlying this metric. The metric, as described in the measure specification accompanying the final rule, is the number of unique C–CDA documents obtained. We clarify that unique C–CDAs are identified by document ID and only one of multiple C–CDAs with the same document identifier counted. This metric relates directly to the proposed metric following revision of the deduplication process. The difference between these two metrics represents the volume of duplicate C–CDAs obtained, determined by document ID. This is critical to track as health care providers have identified the potential negative downstream impacts of duplicate documents exchanged on the complexity of exchange and usability of the data.

Comments. Numerous commenters indicated that the proposed metric did not explicitly include important automated aspect of the reconciliation process, which includes deduplication through automated means. Commenters pointed out that reconciliation by human users can be assisted by underlying automation and that there was variation in these practices. For instance, as noted above, commenters expressed concern that there was not industry consensus on how to deduplicate information contained within a C–CDA. The HITAC specifically noted that new tools and automated processes are advancing to reduce the human burden involved in reviewing exchanged information. Numerous commenters also noted that the measure is specifically based on reconciliation actions occurring at the C–CDA document level, whereas many developers aggregate data across individual documents for consolidated or “bundled” clinical reconciliation for a more user-friendly workflow to deduplicate C–CDAs. Commenters noted the measure should be modified to better account for bundled reconciliation, and that doing so would align this measure further with the CMS PI Program measures. Numerous commenters recommended that ONC include documents reconciled not only by human users, but those documents automatically reconciled via electronic tools that reduce the need for manual review and reconciliation of data. A commenter expressed that the metric was rated as high in burden because auto-reconciliation was not included in the proposed measure.

Response. We appreciate considerations from commenters on the range of evolving practices to automate and support reconciliation and incorporation of C–CDAs, which can reduce burden on end-users. As noted above, given this range of practices, we have specified in the measure specification accompanying this final rule that the identification of unique C–CDAs for the purpose of the Insights Condition depends only on document identifier.

In proposing within the measure specification to define duplicates based on the inclusion of substantially identical information as identified by health IT developers, we intended to reflect what we understood to be wide variation in developers' approaches to determining whether information was duplicative. However, public comments further highlighting variation in approaches to deduplication, particularly automated processes to do so, coupled with comments about similar automated processes that some developers use to reduce burden, indicate that it is essential to measure automated processes to meaningfully capture how information in C–CDAs is used. Without including metrics on these processes, we believe the metrics as proposed may have led to invalid inferences. For instance, the proposed metrics may have inappropriately conflated fully automated processes identifying no new information with processes involving clinician review and resulting in new information incorporated into the Health IT Module. This was confirmed by commenters indicating that it might be infeasible or of little value to implement the proposed metrics in cases where documents were bundled or otherwise pre-processed.

We further agree with commenters that changes in health IT systems that reduce provider burden are vital. The metrics described in the measure specification accompanying the final rule will facilitate insight into the extent to which health IT systems employ automated processes to streamline reconciliation and incorporation of clinical information and result in greater use of information in C–CDAs and reduced burden. As a result, the measure will properly reflect the success of developers with approaches that create efficiency for the healthcare delivery system.

To support the final measure and to capture the range of methods that support the reconciliation and incorporation process, we use several terms in the measure specification sheets accompanying the final rule. For purposes of clarity, we note the terms have the following meanings:

• “Pre-Processes for Reconciliation and incorporation” is any automated process that (1) deduplicates C–CDAs, for instance, based on document identifier, the information contained within multiple C–CDAs, or other means; (2) removes information for user review that is identical to information in the Health IT Module; (3) aggregates data across documents for bundled reconciliation; or (4) uses another means to process C–CDAs to facilitate manual (by a clinician or their delegate) or fully automated reconciliation and incorporation of information into the Health IT Module.

• “Reconciled and Incorporated via Any Method” is any approach to reconciling and incorporating information in the Health IT Module, including but not limited to manual processes performed by a clinician or their delegate only; a mix of manual and automated processes; or fully automated processes. This includes an affirmative action to (1) reconcile new information from the C–CDA into the Health IT Module, for instance, by comparison of medication information in the Health IT Module and information in the C–CDA; or (2) indicate that no new information needs to be incorporated into the Health IT Module.

• “Fully automated processes for reconciliation and incorporation” is any process by which problems, medications, or allergies and intolerances contained within C–CDAs are automatically reconciled with information within certified health IT and incorporated into health IT without an action by a clinician end-user or their delegate. These processes include (1) reconciling new information from the C–CDA into the Health IT Module, for instance, by comparison of medication information in the Health IT Module and information in the C–CDA; or (2) determining that no new information needs to be incorporated into the Health IT Module.
• “Determined to have no new problems, medications, or allergies and intolerances information” is any pre-process or fully automated process that determines that the C–CDA contains no new information.

In consideration of public comment received on the proposed measure, we have included more specific metrics in the measure specification accompanying the final rule. Three metrics account for pre-processes and fully automated processes related to reconciling and incorporating C–CDAs and two more clearly framed metrics related to C–CDAs for which automated processes were not applied. We made these adjustments to better reflect developers' existing practices related to deduplication and similar pre-processing, including the bundling of C–CDAs described in public comment on the HTI–1 Proposed Rule and accompanying measurement specification. In contrast to the original measure in the HTI–1 Proposed Rule, we have not finalized a requirement that any complex deduplication be performed specifically for the Insights Condition by those developers who do not currently deduplicate or otherwise automatically process C–CDAs, which will result in reduced burden on developers.

In so doing, we believe the updated metrics represent a direct evolution of the focus in the HTI–1 Proposed Rule on deduplication that is responsive to comments and reduces burden on developers. To that end, in the measure specification accompanying this final rule, we sub-divided the proposed metrics to more precisely capture rates of pre-processes and fully automated processes described by commenters.

• In addition to the metric, number of unique C–CDA documents obtained, we have also included two metrics to enable the proper and accurate capture of the use of pre-processing that may facilitate efficient and effective review of information contained within C–CDA documents: (1) number of total C–CDA documents obtained that were pre-processed, and (2) number of total C–CDA documents obtained that were not pre-processed. Following the change to what constitutes a duplicate C–CDA previously discussed, the number of unique C–CDAs will reflect elimination of an important subset of duplicate C–CDAs, but will not reflect more complex deduplication processes. The complementary metrics reflect the extent that developers performed pre-processes, inclusive of those deduplication processes, for obtained C–CDAs. This approach eliminates the need to perform specific, complex deduplication processes for the Insights Condition and the final metrics should decrease developer burden compared to what was proposed. We expect that some developers that do not have the capability to pre-process C–CDAs would report a zero for the first metric.
• We have divided the proposed metric “number of C–CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms supported by certified health IT during the reporting period” into two metrics to more clearly differentiate between reconciliation activities that were and were not supported by pre-processes: (1) number of total C–CDA documents obtained that were pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method; and (2) number of total C–CDA documents obtained that were not pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method. This division was made in response to public comment requesting that we specify how the proposed metrics accounted for pre-processing and requesting that we reduce the complexity of C–CDA processing necessary, specifically for the Insights Condition. We expect that some developers that do not have the capability to pre-process C–CDAs would report a zero for the first measure.

Finally, we have included a specific standalone metric to capture fully automated processes that did not result in new information. In the proposed measure specification, we stated, “if no update is necessary, the process of reconciliation may consist of simply verifying that fact or reviewing a record received and determining that such information is merely duplicative of existing information in the patient record.” We believe that this statement was ambiguous about whether automated processes for making this determination would count as reconciliation, and commenters indicated as much by comparison to the CMS PI measure. Given commenters' interest in highlighting various approaches to processing C–CDAs, we have included a metric focused directly on this process as the number of total C–CDA documents obtained that were determined to have no new problems, medications, or allergies and intolerances information by pre-processes or fully automated processes. This metric is intended to disambiguate how to capture pre-processes and fully automated processes for verifying that no new information was available relative to the measure specification accompanying the HTI–1 Proposed Rule.

We believe this approach will facilitate measurement of C–CDAs that are bundled together prior to end-user review. For instance, if the bundle is not reviewed by a clinician end user or their delegate and information is not automatically reconciled and incorporated, the metric related to reconciling information that has been pre-processed described above would not include C–CDAs that contained new information presented in a bundle. Prior to manual review, C–CDAs that contributed no new information to the bundle could either be counted as contributing to both the metric related to reconciling information that has been pre-processed and the metric related to determining that the C–CDA contained no new information, or to neither metric depending on the approach that most closely matched the product's logic. Once manual review of a bundled C–CDAs is completed, each C–CDA that comprised the bundled review would increment the metric related to reconciling information that has been pre-processed above, and those that contributed no new information to the bundle would increment the metric related to determining that the C–CDA contained no new information as well. We have adopted this approach to acknowledge the health IT systems that have functionality that streamlines the reconciliation process, with the interest of understanding how this functionality reduces burden for end users. We recognize that today many developers may apply no pre-processes or fully automated processes to obtained C–CDAs, and these developers would report a zero for these metrics.

C–CDA documents obtained via all mechanisms (including from national networks, such as the Carequality framework and CommonWell, Direct Trust, and eHealth Exchange; Health IT Developer networks; EHR to EHR exchange; regional, local, and community HIE; and Direct Secure Messaging) should be counted in the measure. However, we clarify that the measure does not require any stratification by exchange mechanism.

Comments. One commenter raised a concern that it would be difficult to deduplicate patients across EHR instances and thus ONC should clarify that deduplication across EHR instances is not expected.

Response. We appreciate the request for clarification. We recognize that this requirement represents a significant level of burden and do not expect deduplication of patients across EHR instances for this measure.

Comments. Many commenters recommended to include any valid C–CDA R2.1 IG document-level template for measurement, as opposed to only the CCD, Discharge Summary, and Referral Note templates described in the measure specifications sheets related to this measure. Some commenters also noted that including a broader set of document types would better capture the full scope of C–CDA document exchange that is active in healthcare today and aligns with CMS PI Program. Additionally, one commenter representing health IT developers noted it would be less burdensome to include all documents, rather than only the subset, as they did not have the capability to identify the subset. Relatedly, numerous commenters also suggested that we modify the definition for obtaining C–CDAs. Many commenters indicated that excluding C–CDA without any data would be problematic as that would involve reviewing the content of the C–CDA which would be burdensome. One commenter noted that a C–CDA without any data (such as a patient header) would be rejected and not counted. Some commenters suggested including any document received inbound that is in a valid file format with a header indicating that it is a C–CDA R2.1 document template.

Response. In an effort to align with the “automated measure calculation” (§ 170.315(g)(2)) criterion that health IT developers follow to support reporting the CMS measures, we have revised the measure specification so that the measure includes any valid C–CDA document-level template referred to in the standards adopted for certification to § 170.315(b)(2) for measurement, as opposed to only the CCD, Discharge Summary, and Referral Note templates. This brings the measure into alignment with the CMS PI Program measure (Support Electronic Referral Loops By Receiving and Reconciling Health Information), which states “Starting in 2019, for the Promoting Interoperability measure an EP may use any document template within the C–CDA standard for the purposes of the measure.” We note that this scope is substantially broader than the “clinical information and reconciliation and incorporation” (§ 170.315(b)(2)) criterion, which only requires that certified Health IT Modules be able to reconcile and incorporate Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary. We will not require developers to exclude documents without data, acknowledging that some developers do not parse or otherwise pre-process C–CDAs and, therefore, cannot readily evaluate whether the C–CDA contains data. We plan to collaborate with the community to determine if more nuanced levels of analysis are warranted for future measure updates to refine the measure.

Comments. Some commenters asked ONC for clarification on the proposed denominator, “number of unique patients with an associated C–CDA document during the reporting period.” One commenter indicated they were not sure how it differed from “documents obtained” in one of the other denominators and whether it was intended to only capture new associations that occurred during a reporting period or a snapshot of all patients at the end of the reporting period. One commenter also inquired about how to count a document received during one reporting period but matched in another reporting period.

Response. We clarify that the metric, number of unique patients with an associated C–CDA document during the reporting period, refers to the number of unique patients that have been matched to at least one C–CDA within the certified Health IT Module by automated or manual means in the reporting period and, therefore, have at least one associated C–CDA. The metric, number of total C–CDA documents obtained through certified health IT during the reporting period, refers to the total number of C–CDA documents obtained across all patients for the reporting period. For example, if two C–CDAs were received for a single patient during the reporting period, the first metric would count this as a single unique patient, while the second metric would count this as two C–CDAs. These counts would not depend on whether information had previously been received for a patient prior to the reporting period. As noted in the HTI–1 Proposed Rule, we believe these denominators support an understanding of the volume of C–CDA documents exchanged relative to the number of instances when external information could inform health care providers.

With regard to documents that may be obtained in one reporting period and reconciled in another reporting period, the measure's metrics call for counting C–CDAs obtained, reconciled, and incorporated in the same reporting period. We recognize that some C–CDAs obtained prior to the reporting period, but reconciled and incorporated during the reporting period, are not counted in the metrics. However, we expect these instances will not substantially impact the interpretation of the metrics' results. We also recognize that some C–CDAs obtained during the reporting period may be reconciled and incorporated following the reporting period, but similarly believe these instances will be uncommon. We expect that the shift to calendar year reporting will further minimize the exclusion of documents that are received before the start of a reporting period and reconciled during the start of the reporting period.

Comments. One commenter suggested the encounter-based metrics may not adequately measure one of the key areas of interest, which is to assess the extent to which exchange of outside information can potentially inform care. This commenter suggested that to identify the extent to which encounters benefited from information exchange would require a denominator of total number of encounters during the reporting period, and a numerator of encounters in which information from a C–CDA document was incorporated. Such a measure would provide the percentage of encounters in which outside information was potentially beneficial to the encounter was incorporated from received documents.

Response. We agree with the commenter that many variations on the required metrics could provide additional insight into how exchanged information is used and that measures related to the proportion of encounters in which obtained information was incorporated could be particularly insightful. However, we have sought to balance that consideration against the potential for additional burden associated with the measure. To that end, we decline to revise or extend measures to capture the proportion of encounters in which information was incorporated. We plan to continue to collaborate with the community to investigate the degree of development necessary to link C–CDAs incorporated to their use to inform care during an encounter.

Comments. Several commenters raised questions regarding what actions count as reconciliation. One commenter requested clarification on whether a document would be considered incorporated if any amount of data was incorporated or by specific data element. A couple of commenters requested ONC be more explicit about what types of data are included for reconciliation, asking whether a document should be included only if it had problems, allergies, or medications (PAM) for reconciliation, or if reconcilable laboratory results ( e.g., blood tests) or immunizations should also be included. A commenter requested that ONC limited it to reconciliation of PAM, given that it is a certification requirement, and that the numerator be explicitly defined in that manner. Relatedly, a couple of commenters recommended that if a document did not contain any new information to be reconciled that it should still increment the numerator to match the existing CMS PI measure. Another commenter requested that ONC clarify that viewing documents is not equivalent to reconciling documents.

Response. Our intent is to align the measure requirements with the “clinical information reconciliation and incorporation” (§ 170.315(b)(2)) certification criterion. As such, we describe in the measure specification accompanying the final rule that metrics related to reconciliation of C–CDAs would increment upon reconciliation of medications, allergies and intolerances, or problems. The two metrics are: (1) number of total C–CDA documents obtained that were pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method; and (2) number of total C–CDA documents obtained that were not pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method. We clarify that the increment occurs when reconciliation is completed for any one of the three types of data, that is, when at least one medication, allergy and intolerance, or problem is reconciled and incorporated or when it is determined that no new information should be incorporated. We agree with the recommendation from commenters that documents that do not contain any new information for reconciliation should still increment the metrics when an end-user or automated process verifies the fact that information in the C–CDA is duplicative of existing information in the patient record to match the existing CMS PI measure. The third metric, number of total C–CDA documents obtained that were determined to have no new problems, medications, or allergies and intolerances information by pre-processes or fully automated processes, would also increment when automated processes were used to make this determination. We believe that distinguishing between automated processes that identify no new information and other reconciliation is important for a valid understanding of the use of information and burden on end-users. We clarify that the act of simply viewing a C–CDA, without an affirmative action verifying that information is either absent or duplicative, would not increment these metrics.

Comments. One commenter suggested focusing measurement on transitions between outside organizations/systems, as patients within health systems are often referred, admitted, and discharged to providers within the same system which might make it difficult to interpret the results.

Response. The measure is intended to count C–CDAs that must be exchanged outside of a “one patient one chart” system, where multiple specialists within a system can access a single patient record and manage a single list for problems, medications, and medication allergies. We note that this measure applies to intra-system exchange, where specialists within the same provider organization do not have access to a “one patient one chart” health IT system, and inter-system exchange, where specialists across different provider organizations also do not have access to a “one patient one chart” health IT system. We also note that this measure is not limited to transitions of care. We may consider if the measure should be reported by transitions of care in future rulemaking.

Finalization of Measure

We have finalized the measure as “consolidated clinical document architecture (C–CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT” in § 170.407(a)(3)(ii). We have revised the proposed measure based on public comments received related to variation in industry practices, including approaches to deduplication and automation. Specific metrics to support this finalized measure are described in the related measure specification located on ONC's website and in the section above. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion:

1. Number of encounters

2. Number of unique patients with an encounter

3. Number of unique patients with an associated C–CDA document

4. Number of total C–CDA documents obtained

5. Number of unique C–CDA documents obtained

6. Number of total C–CDA documents obtained that were pre-processed

7. Number of total C–CDA documents obtained that were not pre-processed

8. Number of total C–CDA documents obtained that were pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method

9. Number of total C–CDA documents obtained that were not pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method

10. Number of total C–CDA documents obtained that were determined to have no new problems, medications, or allergies and intolerances information by pre-processes or fully automated processes

The reporting period for the measure and related metrics consists of one calendar year. Data collection for the measures and associated metrics will begin during the second and third phases of reporting (which is described later in the preamble).

Measurement Area: Standards Adoption and Conformance

We proposed (88 FR 23837) to adopt four measures in the “standards adoption and conformance” area in § 170.407(a)(4) through (7) to provide insight into the role that standards play in enabling the access, exchange, and use of EHI. We proposed to measure the following aspects within this area: (1) availability of apps to support access to EHI for a variety of purposes; (2) the usage of FHIR-based APIs to support apps; (3) the use of bulk FHIR to support the access to EHI for groups of individuals; and (4) the use of EHI export functionality (88 FR 23837). We stated that together, these measures will provide a foundation for understanding whether and to what extent ONC's policies to promote standards are supporting users of health IT, including patients, clinicians, researchers, and others to access, exchange, and use EHI via certified health IT for a variety of purposes. These measures would also provide visibility into industry adoption of standards required by the Program and provide data to inform future standards development work.

Comments. Many commenters supported the “standards adoption and conformance” measurement area. One commenter expressed support for interoperability measurement as a national priority. One commenter disagreed with ONC's statement that data on the volume of information exchanged would provide the means to assess the extent that patient information is moving between providers to facilitate high value care, stating that pure volume does not accurately reflect quality.

Response. We appreciate the support expressed by many commenters and agree that only collecting data on the volume of information exchanged will not strictly reflect the quality of care provided. However, we plan to use this data in conjunction with other collected data from the “Insights Condition and Maintenance of Certification” to create metrics that will assess the extent that patient information is exchanged between providers to facilitate high value care.

Comments. We received numerous comments with suggestions for new or revised measures in the “standards adoption and conformance” area. Throughout this measurement area we use the abbreviation “app” for the term application. Apps that may connect to ONC-certified health IT via the capabilities enabled by 170.315(g)(10), refer to third-party software or IT system not offered by the certified health IT developer including but not limited to: mobile apps, web portals, locally hosted software, enterprise software solutions, and custom software.

For the “applications supported through certified health IT” measure, the majority of comments received suggested metrics focused on the availability ( e.g., number of distinct apps) and accessibility ( e.g., number of accesses) of patient-facing and non-patient-facing apps. Two commenters suggested metrics focused on requesting additional qualitative context/information about the purpose for which apps were developed or use cases, especially for specialty care apps, and clinical decision support. One commenter requested for app developers to report the turnaround time for app developer authentication and authorization to production environments. One commenter requested for app attestation to be included in the Insights Condition requirements.

For the “use of FHIR in apps supported by certified API technology” measure, a majority of the comments suggested metrics focused on IG development, adoption, and conformance beyond the US Core IG. One commenter requested a metric that counts the number of queries made by either a patient or a clinician. One commenter suggested counting the total number of FHIR resources by individual resource.

For the “use of FHIR bulk data access through certified health IT” measure, most of the commenters suggested metrics focused on obtaining information related to the FHIR Bulk Data request metadata ( i.e., user-type of the FHIR Bulk Data requester, export time per resource (average), and group size for successful exports (average)). One commenter suggested a metric that counts the number of FHIR Bulk Data export requests. Another commenter suggested a metric that focuses on real-world performance of FHIR Bulk Data implementations.

Response. We thank all commenters for their thoughtful input. We appreciate the interest expressed in requiring additional reporting metrics for the “standards adoption and conformance” measurement area, and may explore the feasibility of these suggested reporting metrics in the future.

Applications Supported Through Certified Health IT Measure

In the HTI–1 Proposed Rule (88 FR 23837), we proposed to adopt the “applications supported through certified health IT” measure in § 170.407(a)(4), which would provide information on how certified health IT supports the health app ecosystem by asking certain health IT developers under the Program to report app names and app developer names, intended app purposes, intended app users, and whether a registered app is in “active” use across a developer's client base (as further detailed below). We stated in the HTI–1 Proposed Rule that this measure would result in a listing of apps that could be used to generate a variety of metrics. Only developers of certified health IT with Health IT Modules certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) criterion would be required to report data for this measure.

In the HTI–1 Proposed Rule (88 FR 23837 through 23840), we proposed that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) provide certain information about the apps that are connected to their certified technology. We proposed that the app name and the developer (company/organization or individual) responsible for the app would be reported for each app registered to a developer of certified health IT whose Health IT Module is certified to the § 170.315(g)(10) criterion. We noted that the app registration process required under § 170.315(g)(10)(iii) may provide an opportunity for developers of certified health IT to gather standard information for apps connecting to their certified API technology as part of existing workflows. There may be other mechanisms besides the app registration process by which developers of certified health IT wish to obtain this information.

We proposed that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain and report the intended purpose(s) for each app connected to their certified API technology using the following categories:

• Administrative Tasks ( e.g., scheduling & check-in, billing & payment)

• Clinical Tools ( e.g., clinical decision support, risk calculators, remote patient monitoring)

• Individuals' Access to their EHI ( e.g., enables patients to access their health information, medications, test results, vaccine records)

• Research ( e.g., used to perform clinical research)

• Population Data ( e.g., bulk transfer of data, population analytics & reporting)

• Public Health ( e.g., electronic case reporting)

• Patient-Provider Communication ( e.g., secure messaging, telehealth)

• Educational Resources ( e.g., patient and provider educational resources)

• Other Intended Purpose

• Unknown ( e.g., missing)

As stated in the HTI–1 Proposed Rule (88 FR 23838), developers of certified health IT to whom the measure applies would report the intended purpose(s) of the app for each app registered to their Health IT Module(s) certified to the § 170.315(g)(10) criterion. The categories we proposed under this measure were informed by app category taxonomies in published literature from Barker & Johnson (2021), Ritchie and Welch (2020), and Gordon and Rudin (2022). While we recognized this taxonomy may need to evolve over time, we conveyed in the HTI–1 Proposed Rule our belief that the proposed categories represented a large majority of the current market, and that the types of information, if reported on a complete set of apps, would provide insightful information to guide ONC's future efforts to support individuals' access to their EHI via apps, along with other priority uses, such as research and clinical care.

Additionally, we proposed (88 FR 23838) that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain the following intended user(s) categories for each app connected to their certified API technology:

• Individual/Caregiver
• Clinician
• Healthcare Organization
• Payer
• Researcher
• Other Intended User

• Unknown ( e.g., missing)

We also proposed (88 FR 23838) that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain the status for each app connected to their certified API technology using the following categories:

• Actively Used—An app is defined as “Actively Used” if EHI has been transferred to the app using certified API technology for 10 or more unique patients during the reporting period
• Not Actively Used—An app is defined as “Not Actively Used” if EHI has been transferred to the app using certified API technology for fewer than 10 unique patients during the reporting period

Comments. Most commenters, including EHR and app developers, as well as commenters representing health care providers, were generally supportive of this measure and provided specific requests for clarification and recommendations to constrain the measure. Several commenters indicated that the data collection burden is high for this measure. One commenter expressed concerns that the reporting of these data could lead the public to believe that health IT developers had a role in recruiting application developers to connect to § 170.315(g)(10). Another commenter recommended that this information be collected directly from application vendors to reduce burden on health IT developers.

Response. We thank commenters for their general support. We believe this measure provides greater transparency regarding apps that are connected to certified health IT. Specifically, this measure would enable ONC and the public to understand to what degree apps are connecting across different certified health IT products, which is important for enabling individuals' access to their EHI. The ONC Cures Act Final Rule (85 FR 25750) emphasized the importance of standardization, transparency, and pro-competitive business practices through the API Condition and Maintenance of Certification requirements that would make it easier for third-party apps to connect to certified health IT, and subsequently facilitate individuals' access to their EHI. This measure also provides insights into the types of apps that integrate with certified health IT. Collecting this information will be beneficial to developers as well, for it will provide them with insights about available technologies and uses for data that are in demand in the marketplace.

We acknowledge that collecting this information may require new or updates to existing data collection as part of the app developer registration processes. Although developers expressed concerns related to the burden associated with collecting this information, most commenters indicated that they have an existing app registration process, and thus we believe that developers of certified health IT are best positioned to collect and report this measure. The app registration process would provide an opportunity to gather standard information for apps connecting to their certified health IT as part of existing workflows. We currently do not have data regarding which apps are connected to their developers' health IT and thus cannot directly collect this information. We also recognize that health IT developers do not recruit application developers to connect to certified health IT, but rather are collecting this information among those application vendors that are connected to their systems and through the app registration processes.

Comments. Numerous commenters recommended that ONC directly acknowledge that mandatory collection of intended purposes and intended users via the health IT developer registration process would not violate the API Condition of Certification. One health IT developer expressed concern that some of the measures will require collection of new types of data, specifically app categories and audiences. Commenters representing app developers indicated they supported this measure and furthermore had suggestions for additional measures to include.

Response. We appreciate the comments, and note that the collection of app information required for this Insights Condition measure will not violate the API Condition and Maintenance of Certification (§ 170.404(b)). Specifically, the requirements in § 170.404(b) enable a Certified API Developer to institute its own process to register applications for production use, so long as it occurs within five days of completing its verification of an API User's authenticity. We do not believe requiring app developers to provide basic information such as the characteristics of their application, including intended users and purpose, to be creating undue burden on app developers. Given the support we received for this measure, including from app developers, we do not believe this will be a widespread concern or issue. However, we remind Certified API Developers that the registration process must still occur in the allotted five business days of completing its verification of an API User's authenticity, pursuant to paragraph § 170.404(b)(1)(i) and consistent with § 170.404(b)(1)(ii).

Comments. Several commenters had questions related to which apps would be subject for inclusion in this measure. Commenters representing EHR developers inquired whether applications relevant for this measure would be exclusively those registered for and using the scope of FHIR resources required under the scope of the relevant program criterion at § 170.315(g)(10). Another commenter indicated that some § 170.315(g)(10) certified health IT does not transfer patient EHI and requested clarification on whether this technology would be subject to reporting for this measure.

Response. We appreciate the feedback and offer the following clarifications. Any app that is registered via the app registration process for the § 170.315(g)(10) criterion is subject for inclusion in this measure. We note that the apps that are used by a variety of interested parties to interact with health IT certified to § 170.315(g)(10) are in scope and could include, but are not limited to, provider-, patient-, and payer-oriented apps. This variety is also reflected in the category of intended user types we plan to collect. We did not fully understand the comment regarding a § 170.315(g)(10) certified health IT that does not transfer patient EHI because that is the primary point of such technology. As a result, we are unable to provide further clarity in response to the comment aside to reiterate that all apps registered through the § 170.315(g)(10) app registration process is in scope for this measure.

Comments. Many commenters indicated that it would be difficult to collect additional information from app developers that are already registered with their certified health IT and that new information will not be collected until app developers need to re-register their app. Thus, ONC should expect a disproportionate number of “unknown” entries related to intended purpose of app and users during early years of reporting. Another commenter indicated that it would be unable to capture this information for applications that do not register with the developer of certified health IT. One commenter noted that with a dynamic client registration process, where the registration of applications with an authorization server would be done dynamically using a trust framework, might lead to attributes needing to be collected as part of the registration assertion process. They recommended that this may need to be reviewed, perhaps by a FHIR at Scale Taskforce (FAST) workgroup.

Response. We appreciate these comments, and recognize that the measure data may not be as comprehensive initially as it will be in future years since the year 2026 will be the first measure collection phase and some health care providers will still be implementing § 170.315(g)(10) upgrades. Thus, there may be many “unknown” entries in early years of reporting, and as apps re-register, this information would be provided. Many developers certified to § 170.315(g)(10) may require app developers to register via a process that allows for the collection of the data required for this measure. To the commenter who indicated app information may be missing for those apps that do not register, we recognize that apps not connected to the certified (§ 170.315(g)(10) API (and therefore not required to register) would not be included. We also note that while the app registration process required under § 170.315(g)(10)(iii) may provide an opportunity to collect this information, developers of certified health IT may wish to use other mechanisms such as surveys, forms, or health IT system-based methods to obtain this information. We are not limiting or specifying the methods by which developers of certified health IT collect this information. Developers should describe the method(s) they used to collect the data in the required documentation they submit to ONC. Further, we believe it will be possible to collect these data through the dynamic client registration process; however, we note that existing dynamic registration implementation guides may need additional specification. We appreciate the recommendation to consult with a FAST workgroup or other groups working on dynamic client registration to ensure that this step is included as part of that process.

Comments. One commenter supported the proposed collection of user type (intended user of app) for apps and encouraged collection of information that would identify the types of users that are the focus of the app ( e.g., patient, provider, system) to the dataset of information collected about apps. Another commenter requested clarification between “clinician” and “healthcare organization.” One commenter suggested that the value sets for metrics, intended purpose of app and intended user of app, be based upon a standardized value set referenced in other interoperability initiatives such as TEFCA and HL7 Role Class, respectively. One commenter also noted that some apps may have multiple intended purposes and intended users and wanted to confirm that reporting of multiples where relevant was acceptable.

Response. We appreciate the input provided by commenters on establishing or selecting an available value set for intended purpose and intended user. We agree that “clinician” and “healthcare organization” may seem duplicative and to avoid confusion we have revised the value set by removing both of these options and replacing “clinician” with “clinical team” and “healthcare organization” with “healthcare administrator/executive.” We appreciate the recommendation to consider standardized value sets and may consider identifying relevant value sets in future rulemaking. With regards to selection of metrics, intended purpose, and intended user, we understand that there may be multiple purposes and users so apps should select all that apply and not be limited to one response. Therefore, these are the following intended user(s) categories for each app connected to their certified health IT:

• Individual/Caregiver
• Clinical Team
• Healthcare Administrator/Executive
• Payer
• Researcher
• Other Intended User

• Unknown ( e.g., missing)

Comments. Several commenters requested clarification on whether an application is “actively used” or “not actively used,” noting applications that are “not actively used” are not a reflection of the certified health IT. One commenter recommended that an application should be designated as actively used based upon either a particular threshold of total API call volume, or total authorization events constituting a unique user session for the app. The commenter indicated that this approach would help ensure that apps used in high frequency for retrieving health information on a small number of patients are not erroneously classified as “not actively used.” The same commenter expressed concern about a threshold of 10 or more unique patients, indicating that an app that is used daily by fewer patients should still be considered “actively used,” especially for developers that may only serve a smaller scope of providers. Another commenter suggested an additional category of “evaluating” that represents an app is connected but used by fewer individuals (such as 3 or 5), along with a “superactive” designation for larger numbers of individuals, therefore creating four categories, rather than two.

Response. We thank commenters for their input. We realize that usage of apps is not necessarily a reflection on health IT developers. However, this information is critical to collect in order to distinguish between production apps that are registered and are in use ( e.g., 10 or more unique patients), production apps that are registered and are not in use ( e.g., less than 10 unique patients), and production apps that are registered but not enabled by the health IT developer. Without this information, the value of the overall data would be limited.

The definition of active use is described in our measure specification. The definition is based on whether EHI has been transferred to the app using certified health IT for ten (10) or more unique patients during the reporting period. By setting the threshold at ten or more unique patients, we expect that this threshold will represent active use. While mobile patient portal apps and well-known healthcare apps ( e.g., Apple Health) have large user bases, for lesser-known healthcare apps that filled specific healthcare segments ( e.g., rare or terminal diseases, chronic or hereditary diseases, age-related conditions, pediatrics, behavioral and mental health), ONC expects smaller user bases. An ONC internal analysis of the Google Play^TM store data found that the number of Android installs for apps that enable patients to access their data, ranged from 4 to over 400,000. There is little public data on number of users specifically, and thus, in setting the criteria of active use, we are relying upon the number of installs for these types of apps, even though it is not equivalent to the number of users. A mix of self-reported data show approximately 3.87 million people use health and fitness apps, and data from app stores list approximately 350,000 mobile health apps (many of which include apps that do not integrate with EHRs and are not applicable to this metric); on average, health apps have approximately 11 users each. However, none of these data sources provide data on actual use for the apps that connect with EHRs. We aim to be broad in determining active use and balance the need to define app use to include apps that have a smaller target audience. Thus, we have set a relatively low threshold of ten or more unique patients for defining active use. We appreciate the alternative suggestions for measuring whether an app is actively used. However, using total API call volume to measure usage would skew results and make it difficult to determine appropriate level of API calls to qualify for “active use,” as certain apps may make API calls multiple times per day. A lower threshold of less than ten users that would also take into account the use of apps on a daily or weekly basis may be more complex to implement, as this also involves measuring the frequency of use (as opposed to simply the number of users). Also, the call or requested data (which would be used to assess frequency of use) may be difficult to interpret as apps using APIs regularly request data from providers as part of their process to update the data within the app, and it may not reflect user driven behavior. The other suggested alternative, using authorization events, could be difficult to implement because it would be difficult to determine the number of authorization events that would define whether an app is actively used given the number of authorization events could vary by individual and app. However, we plan to continue collaborating with the community to assess level of usage using authorization events for future iterations of this measure.

With regards to expanding usage from two to four categories, we may consider expanding categories in the future.

Comments. A couple of commenters also had questions about the inclusion of apps as of the last day of the reporting period ( i.e., report only existing apps as of the last day of the reporting period) or whether apps should be included based upon whether they had registered at any point during the reporting period ( i.e., report all apps that had been registered during the reporting period, even if they are not registered on the last day of the reporting period). A commenter suggested counting the total number of apps active at any point in the reporting period to appropriately account for onboarding and offboarding activity, whereas a couple of commenters noted that reporting of the app status is not a metric that is measured over a reporting period and would be an indication at a point in time at the end of the reporting period.

Response. We clarify that the app status ( e.g., usage) should include apps based upon whether they had registered at any point in time during the reporting period. We seek to measure the unique number of individuals who used the app during the reporting period (a calendar year) and do not want to limit the inclusion to apps that are registered as of the last day of the reporting period. For apps that were registered during the reporting period and are not registered at the end of the reporting period, we would want their status to be calculated and included.

Comments. One commenter representing medical professionals recommended that as part of this measure, ONC include a metric requiring health app developers to attest to whether they adhere to (yes/no) any of the following: (1) Industry-recognized development guidance ( e.g., Xcertia's Privacy Guidelines/Privacy Is Good Business: a case for privacy by design in app development); (2) Transparency statements and best practices ( e.g., Mobile Health App Developers: FTC Best Practices/CARIN Alliance Code of Conduct/AMA Privacy Principles); and/or (3) A model notice to patients ( e.g., ONC's Model Privacy Notice). The commenter noted that almost all patients want transparency on how apps access, exchange, or use their medical information, and this would address that need.

Response. We thank the commenter for their recommendations to include a metric on an app developer's adherence to various privacy and security practices and frameworks. We may consider these recommendations in future rulemaking. We also refer readers to other federal regulations such as Section 5 of the FTC Act, Children's Online Privacy Protection Act (COPPA) and the COPPA Rule, and other industry initiatives supporting consumers in app privacy, security, and transparency.

Finalization of Measure

We have finalized the “applications supported through certified health IT” measure in § 170.407(a)(3)(iii). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described further in the accompanying measure specification located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion.

1. Application Name(s);

2. Application Developer Name(s);

3. Intended Purpose(s) of Application;

4. Intended Application User(s); and

5. Application Status.

The reporting period for the measure and related metrics above consists of one calendar year. Data collection for the measures and associated metrics will begin during the first phase of reporting (which is described later in the preamble).

Use of FHIR in Apps Through Certified Health IT Measure

In the HTI–1 Proposed Rule (88 FR 23839), we proposed the adoption of the “use of FHIR in apps supported by certified API technology” measure in § 170.407(a)(5), which would capture the volume of FHIR resources transferred in response to API calls from apps connected to certified API technology by FHIR resource type. We also proposed (88 FR 23839) that the FHIR resources transferred be reported by FHIR version used and by US Core Implementation Guide version deployed. This measure also proposed requiring developers to report FHIR resources transferred in response to calls from two different endpoint types: patient-facing and non-patient-facing, the latter of which would include endpoints that do not facilitate individuals' access ( e.g., clinician, payer, or public health endpoints). We explained that this measure proposed to require developers of certified health IT with Health IT Modules certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) certification criterion to report on the number of deployments they support across their customer base, and that together, these data points would provide insights into the usage of certified APIs by collecting data on the volume of FHIR resources transferred to apps in response to API calls by FHIR resource type, type of endpoint, and US Core Implementation Guide used.

We proposed (88 FR 23839) the first numerator to be the number of FHIR resources returned/transferred in response to a call to a certified API technology by resource type. We proposed the second numerator to be the number of distinct certified API technology deployments (across clients) associated with at least one FHIR resource returned/transferred in response to a call. We noted that each of the numerators would be stratified ( e.g., divide into subsets) by type of endpoint (patient-facing vs. non-patient-facing), by FHIR version, and by US Core Implementation Guide.

We proposed (88 FR 23839) the denominator to be the total number of distinct certified API technology deployments (across clients). In addition, we proposed this denominator to be stratified by type of endpoint (patient-facing vs. non-patient facing), FHIR version, and US Core Implementation Guide. We noted that non-FHIR APIs, such as those represented with proprietary standards, are excluded from this measure, including numerators and denominators. We refer readers to the HTI–1 Proposed Rule for a complete listing of the metrics this measure would enable us to calculate (88 FR 23839). As stated in the HTI–1 Proposed Rule, this measure would require that developers report the volume of FHIR resources transferred in response to calls by FHIR version and by US Core Implementation Guide. While Health IT Modules certified to § 170.315(g)(10) are required to respond to requests according to FHIR version Release 4, we are aware that there will be newer versions of FHIR supported by newer versions of the US Core Implementation Guide. Gaining insights into the frequency in use of US Core Implementation Guides will inform ONC of the variability in the implementation of FHIR across developers.

We requested feedback on whether information on both aspects of the measure, FHIR version and US Core Implementation Guide, are necessary as each provides unique insights, or whether focusing on one of these (either FHIR version or US Core Implementation Guide) would be sufficient to understand where the industry is in the implementation of FHIR. We also requested comment on the feasibility of reporting the use of different HL7 FHIR implementation guides and FHIR versions, versus being stratified by type of endpoint, type of FHIR resources, and by the number of certified API technology deployments (88 FR 23840).

We also proposed (88 FR 23840) to require developers of certified health IT to whom the measure would be applicable to report the number of certified API technology deployments (as a proxy for organizations that have installed certified API technology) where FHIR resources were transferred in response to a call (relative to the total number of certified API technology deployments). We stated that this information can shed light on whether usage is concentrated versus dispersed, indicating the breadth of usage across end users and organizations. However, given that API deployments may vary across developers, we sought feedback on whether this measure would be a good proxy for understanding usage across their client bases.

Comments. The majority of commenters expressed support for the proposed measure. Two commenters, one of which represents ONC's Health IT Advisory Committee, indicated the support for metrics that would help inform the future development of interoperability standards, including versions and variations. Commenters indicated these data would provide use of standards in the field that can shed light on industry-wide readiness for the adoption of standards, such as those adopted through Standards Version Advancement Process (SVAP). One commenter suggested to delay or eliminate the measure. Commenters representing community healthcare associations expressed support for this measure, stating that this measure benefits community health centers by measuring the interoperability and seamless data exchange between healthcare applications and exchange partners, which leads to better care coordination and improved population health outcomes.

Response. We thank commenters for their support and believe that these measures provide real-world usage data to help guide and inform the future development of interoperability standards, and therefore we do not plan to eliminate this measure as suggested by one commenter. While the data for this measure will be collected in the first year of the Insights Condition (CY 2026), the first response submission period has been delayed to July, 2027 to provide more time to implement the measure and reduce burden. More details on the compliance dates associated with all the measures can be found in section III.F.3.

Comments. A couple of commenters provided qualitative ratings of burden associated with the metrics. One commenter indicated that the first metric (number of FHIR resources returned/transferred in response to a call to a certified health IT by resource type) would be medium level of effort; whereas the other commenter indicated that first metric would be high level of effort. Both commenters indicated that the second metric (number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned/transferred in response to a call) would be low level of effort. A couple of other commenters requested additional clarity on whether the first metric intends for developers to report the number of total resources returned for each resource, or the number of requests that returned at least one (1) resource for each resource. For example, if a request returns 100 different Observations, would that be considered a count of 1 or 100 total resources. Two commenters recommended defining the first metric to be the total number of resources returned. Another commenter recommended simplifying the metric by measuring only the number of queries or requests made by patients and by clinicians to measure the actual usage of API functionality.

A few commenters requested clarifications on whether any FHIR resources supported by CEHRT need to be counted. Commenters also recommended for ONC to isolate USCDI v1 FHIR resources that are within scope of § 170.315(g)(10) for reporting consistency across health IT developers. Several commenters recommended that this measure should not require tracking of FHIR resources that developers may support beyond USCDI v1, as required by § 170.315(g)(10).

Response. We appreciate the feedback on the burden associated with the measure. As discussed earlier in the preamble, to address burden, we have phased the implementation of the measures starting with a simpler version in the first year and then added the additional complexity in the subsequent years. Additionally, we have revised the measure to address burden. We agree with commenters that for reporting consistency and certain, clear requirements that the FHIR resources reported should align with the criterion § 170.315(g)(10). FHIR resources supported by and within the scope of the § 170.315(g)(10) criterion include FHIR resources referenced in the US Core IG attributed to and that support USCDI data elements. In this case, as an HTI–1 regulatory baseline, would be version 6.1.0 and v3, respectively, because data collection for this measure will begin after the technical requirements for health IT developers to update their certified health IT to these newer standards would have occurred as of January 1, 2026. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion. Additionally, if a health IT developer chooses to use the SVAP to adopt a newer version of standards referenced in § 170.315(g)(10), they will need to report based on the newer versions.

We also appreciate the requests for clarification on the metrics. Our intent is to measure the adoption and use of FHIR by industry users ( e.g., third-party app developers, health IT developers, provider organizations). To clarify on whether the metric intends for developers to report the number of total resources returned for each resource, or the number of requests that returned at least one resource for each resource, we have revised the first metric to make it clear that we expect the latter. Additionally, we have removed the phrase, “in response to a call” across the metrics associated with the measure. For example, we have revised the metric from, number of FHIR resources returned/transferred in response to a call to certified API technology by FHIR resource type to the following, number of requests made to certified health IT that returned at least 1 FHIR resource by FHIR resource type. Both the proposed and revised metric assess the types of FHIR resources provided by certified health IT in response to a request. A request made to certified health IT can return a variety of different types and number of FHIR resources in response. The proposed metric focused on both the number of resources and types of resources returned; the revised metric focuses largely on the types of resources returned rather than the volume of resources returned. This simplified metric will still provide us with the necessary information on the types of resources provided. As noted by commenters, the total volume of FHIR resources returned is more difficult to interpret. The volume of resources could be related to a small number of apps returning a lot of data or many apps returning a little data. In contrast, the number of requests that returned at least 1 resource by resource type provides us insights into the “demand” for each resource and is easier to interpret. Measuring queries alone doesn't provide insight into whether data was shared in response to the query as there may not be data available to return. The goal in this metric is to understand the number of API requests that return various FHIR resources to gain insight on the resources most commonly exchanged.

Comments. A couple commenters requested specific clarification on whether the metric, number of distinct certified health IT deployments (across clients) is intended to be the total number of API deployments active at any time during the reporting period, or the total number active as of the end of the reporting period. The commenters recommended defining it to be the total number of API deployments active at any time during the reporting period. Another commenter noted a limited situation where an EHR user may have more than one production database of a certified solution and requested additional clarification for reporting on the measure, anticipating that they would count all deployments of the certified solution regardless of the number of clients that represents. A couple commenters provided qualitative ratings of burden associated with the metric, indicating that this would be low level of effort.

Response. We thank commenters for their feedback. Originally, we proposed reporting the number of distinct certified API technology deployments (across clients) during the reporting period. We clarify that this refers to counting the total number of certified health IT deployments active at any time during the reporting period, not the total number active as of the end of the reporting period. We had not intended, nor indicated, that we would be measuring this as of the end of the reporting period. We also acknowledge situations where an EHR user may have more than one production database of a certified solution and have revised the measure to count all deployments of the certified solution regardless of the number of clients that represents. The metric now measures the number of distinct certified health IT deployments (across clients) active at any time during the reporting period (overall) and by user type ( i.e., patient-facing and non-patient-facing).

Comments. Several commenters expressed support for patient-facing versus provider-facing stratification. One commenter expressed concern about reporting in this manner as endpoints can serve multiple and broad audiences. For example, the same endpoint could be used for both patients and providers. The same commenter recommended to report based on user type instead of endpoint types.

Response. We thank the commenter for their input and agree that FHIR endpoints are not necessarily specific to a user type and can serve multiple audiences. Given that endpoints can serve both patients and providers (for example) and thus would have to be double counted if that was the case, we have modified the metric to instead report the types of users the endpoint serves. We believe this will simplify reporting. Therefore, we have replaced the term endpoint type with user type. The user type categories are patient-facing and non-patient-facing. We believe the revision better represents our intention of understanding the user types that are using FHIR resources and FHIR APIs.

Comments. Commenters were generally split on the proposed stratification of reporting both the FHIR version and the US Core Implementation Guide (IG) version. Those in support of stratifications indicated that the stratifications provide important distinctions for understanding the use and development of FHIR and is appropriately scoped in alignment with how most health IT developers' certified APIs are deployed. One commenter noted that being able to track IG conformance beyond US Core is essential to understanding how the industry is using FHIR and the data being exchanged via FHIR. Additionally, one commenter who supported the stratification noted that given continued updating of the US Core IG, future FHIR versions and US Core IG versions may not be synonymous in describing the capabilities of a technology, making it necessary to stratify by both FHIR version and the US Core IG version. One commenter recommended requiring the reporting of each FHIR resource by IG conformance beyond the US Core IG at the installation level for all health IT developers, including smaller developers that certify to FHIR API criteria. Several commenters suggested that ONC remove the stratifications for FHIR version and US Core IG version, noting that FHIR R4 is currently the only relevant version of FHIR base specification version and that, in most cases, health IT developers are only conformant to one version of the US Core IG. However, one commenter was supportive of the inclusion of the proposed stratifications for future reporting, as long as ONC provides specific guidance to health IT developers. One commenter noted that stratifying the number of deployments by the proposed stratification attributes does not make sense unless ONC's objective is to measure FHIR APIs or resources transferred and recommended stratifying deployments by the version of the certified health IT product. Another commenter highlighted that the proposed stratifications for FHIR version and US Core IG version would be a high level of effort and recommended limiting the measure stratifications to only patient-facing and non-patient facing endpoints.

Response. We thank commenters for their feedback. We agree that the stratifications provide real-world data regarding the implementation and use of FHIR and US Core IG. This detailed reporting would help inform our goal of guiding future development of standards and insights on the current implementation and use of standards. We also acknowledge some support for restricting the measure specification to FHIR R4 and to one version of the US Core IG. In response to comments, we have made changes to metrics related to this measure so that the metrics are simplified and the stratification by FHIR version no longer needs to be reported. We also have developed a phased approach to implement the measure and related metrics over two years. Similar to the HTI–1 Proposed Rule metric, which called for reporting the number of FHIR resources returned/transferred in response to calls (also called requests) to a certified health IT by FHIR resource type, the first metric listed below also assesses the types of FHIR resources provided by certified health IT in response to a request. The revised metric no longer requires the number of FHIR resources, but instead requires counting the number of requests where at least one FHIR resource was provided. As described earlier, we sought to simplify this metric in response to comments and thus scaled back this metric to the number of requests made that returned at least 1 FHIR resource by resource type. For the second metric listed below, we have simply embedded the original stratification—by user type (which replaced type of endpoint)—within the metric; rather than listing the stratifications separately. The third metric differs from the second metric because it asks about the number of distinct certified health IT deployments (across clients) overall and by user type, and is not limited to those certified health IT deployments which were associated with at least one FHIR resource returned or transferred. We note that for the third metric, the word “total” was removed from the HTI–1 Proposed Rule measure as there is no substantive difference between “total number” of distinct certified health IT deployments (across clients) by user type ( i.e., patient-facing and non-patient-facing) and “number” of distinct certified health IT deployments (across clients) by user type ( i.e., patient-facing and non-patient-facing) and we seek to create consistency across the metrics.

As noted earlier, to reduce burden, we have dropped the stratification by FHIR version but have kept the US Core IG version stratification. Given that we are aligning the reporting of FHIR resources to those supported by the § 170.315(g)(10) criterion and health IT developers will also report on the US Core IG version which aligns with the specific version of FHIR, we do not also need to separately obtain information on FHIR version. The metrics indicate the number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned by US Core IG version(s). Together, the phasing of the reporting requirements and simplifying metrics (including removing the FHIR version stratification) will lower the initial reporting burden for health IT developers, as well as provide health IT developers additional time to develop the infrastructure necessary to report on the more advanced stratification (US Core IG versions) which would have valuable insights.

Finalization of Measure

We have finalized the measure as “use of FHIR in apps through certified health IT” in § 170.407(a)(3)(iv). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described further in the accompanying measure specification located on ONC's website. As noted earlier, if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion. The reporting period for the measure and related metrics below consists of one calendar year. Data collection for the measures and associated metrics will begin during the first and second phases of reporting (which is further described later in the preamble):

In the first year (where responses will be due July 2027, and annually thereafter), we require developers to report the:

• Number of requests made to distinct certified health IT deployments that returned at least 1 FHIR resource by FHIR resource type.

• Number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned, overall and by user type ( e.g., patient-facing and non-patient-facing).

• Number of distinct certified health IT deployments (across clients) active at any time during the reporting period, overall and by user type ( i.e., patient-facing and non-patient-facing).

In year 2, in addition to what is required in year 1, we require developers to report the metrics below. These metrics will be due July 2028 (and annually thereafter):

• Number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned by US Core Implementation Guide version.

Use of FHIR Bulk Data Access Through Certified Health IT Measure

We proposed (88 FR 23840) to adopt the “use of FHIR bulk data access through certified health IT” measure in § 170.407(a)(6), which would measure the number of bulk data downloads completed through certified health IT relative to the number of certified health IT deployments or installations. Specifically, we stated that this measure would provide information on how certified health IT is being used to perform “read” services for a specified patient population using the HL7 FHIR® Bulk Data Access (Flat FHIR) V1.0.1 standard. A developer of certified health IT with Health IT Modules certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) certification criterion would be required to report under this proposed measure.

We proposed (88 FR 23840) the first numerator to be the number of data/download requests completed during the reporting period using certified health IT certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) in response to a bulk data download request to export all data for patients within a specified group. We proposed (88 FR 23840) the second numerator to be the number of distinct certified health IT deployments or installations certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) (across clients) that successfully completed at least one bulk data download request during the reporting period.

We proposed the denominator (88 FR 23840) to be the total number of distinct certified health IT deployments or installations (across clients). We requested comment on whether additional stratifications would provide valuable insights, what additional data developers of certified health IT are collecting, and what effort developers of certified health IT are devoting to collecting additional data such as: (1) intended use case ( e.g., population analytics, reporting, research); (2) entity calling the API ( e.g., healthcare organization, payer, public health agency); and (3) automated queries (refreshing the data at certain intervals) versus ad hoc queries. For future measure development, we requested comment on whether it is possible to collect information on the number of authorized users calling a bulk FHIR API, the level of effort required to collect this information, and whether it would provide valuable insights.

We also noted and clarified that non-standard or proprietary resources ( e.g., non-FHIR based) transferred would be excluded from this measure, and that the proposed data for this measure would not include patient-facing applications, as individual patients only have the right to access their own records or records of patients to whom they are a personal representative.

Comments. The majority of commenters were supportive of the proposed measure. Two community healthcare associations supported this measure, expressing that this measure benefits community health centers by monitoring the ability to leverage comprehensive data for population health management and analytics, which will guide public health and population health initiatives. One commenter strongly recommended including at least one metric to track the real-world performance of current HL7/SMART FHIR bulk data implementations. One commenter expressed an opinion that the burdens of data capture for this reporting purpose outweighed the value of additional stratification and suggested starting with a “core” measure and layering on additional stratifications using a phased approach. The commenter noted that while reporting is feasible, it may require development to capture a specific countable event for reporting purposes. A couple of commenters also provided qualitative ratings of burden associated with the measure. One commenter indicated that the first numerator would be medium level of effort; whereas the other commenter indicated that the first numerator would be low level of effort. Both commenters indicated that the second numerator would be low level of effort, and that the denominator would be low level of effort.

Response. We appreciate the support expressed by commenters as well as the desire to phase in the measure, providing more time to implement the measure which, overall, has relatively lower burden. We also appreciate the suggestion to include at least one reporting metric to track the real-world performance of current bulk FHIR implementations. However, this will require additional research to determine whether the reporting metric should be included for future rulemaking.

Comments. Several commenters requested additional clarity on whether the specification of “operationalized as [FHIR ServerBase]/Group/[groupid]/$export” is used for both numerators in this measure. Additionally, commenters expressed confusion on whether the count for both measures is defined as the number of group export completed or the number of group export completed, accessed, and downloaded. The commenters recommended to count the number of completed requests, regardless of whether they are subsequently accessed and downloaded by the requestor. One commenter noted that their health IT solution cannot determine when a user has downloaded all queried and retrieved data files. One commenter requested additional clarity on the difference between “requests completed” in the first numerator and “successfully completed” in the second numerator for a bulk data download request. Another commenter suggested defining “complete” as when the Bulk Data Status Request reports a status of complete ( i.e., the timepoint when the user may begin downloading files). One commenter requested additional clarity on how “rate” will be measured under the second numerator. One commenter requested clarification regarding the requirement to include API-enable “read” services for multiple patients across all endpoints regardless of whether it is publicly available or not and specifically whether non-patient-facing endpoints are to be counted, since regulations only require patient-facing URL endpoints to be published. One commenter suggested for ONC to collect data on bulk FHIR data queries by cohort type ( e.g., research, financial operations, care management, public health, electronic case reporting).

Response. We thank commenters for their feedback. To clarify, the bulk data download request using certified health IT to export all data for patients within a specified group will be operationalized as “[FHIR ServerBase]/Group/[groupid]/$export” for the metrics associated with this measure. We agree with commenters that the measure should focus on the number of completed requests, regardless of whether they are subsequently accessed and downloaded by the requestor and have revised the wording of both metrics to reflect this change. Thus, “completed” is defined as when the Bulk Data Status Request reports a status of complete ( i.e., the timepoint when the user may begin downloading files). We believe there is not a substantive difference between “successfully completed” and “completed,” and to keep consistency between these metrics, we have removed the proposed term “successfully” from both metrics. We have also replaced the term “data/download” to “bulk data access” for consistency with the title of the measure.

We have removed “expected metrics” that we had originally listed in the measure specifications sheets accompanying the HTI–1 Proposed Rule, such as the rate of bulk data download requests. To clarify, it is ONC that will be responsible for calculating derived statistics based upon the metrics and data the developers report. We will also determine how calculated metrics will be aggregated and reported (whether at the national, developer, and/or product level) once we receive the data. How the data is presented will depend in part upon the completeness and quality of the data received.

These metrics apply to API-enabled “read” services for multiple patients where the number reported should reflect the “read” access queries that used the population services capabilities in § 170.315(g)(10) ( e.g., the FHIR Bulk Data Access IG). Given that bulk FHIR is likely primarily for non-patient facing use cases, it should not be limited to patient-facing endpoints; it needs to include “all” endpoints and use cases. Furthermore, these metrics are unrelated to the API Condition of Certification requirements for publishing patient-facing endpoints, which supports patient access to their data using 3rd party apps and not related to Bulk FHIR. To reiterate, the metrics should reflect activity across all endpoints regardless of whether publicly available or not and type of endpoint user. The endpoints included should not be limited to those only used by patients. This is important as we seek insight on bulk data usage volume independent of user type and have developed a measure in a manner that does not differentiate between public and private APIs. In addition, we note that the measure applies to FHIR Bulk Data requests for FHIR resources that within the scope of § 170.315(g)(10) as discussed in more detail in the responses to comments in the previous measure above.

We appreciate the interest expressed in a reporting metrics that measure the adoption and conformance of FHIR Bulk Data APIs by cohort type or use case and may explore the feasibility of this in the future.

Comments. One commenter recommended ONC to align the denominator to the “use of FHIR in apps supported by certified API technology” measure. Another commenter requested clarification on whether the denominator is intended to be the total number of API deployments active at any time during the reporting period, or the total number active as of the end of the reporting period and recommended to define the denominator to be the total number of API deployments active at any time during the reporting period. Another commenter noted a limited situation where an EHR user may have more than one production database of a certified solution and recommended to count all deployments of the certified solution regardless of the number of clients that represents.

Response. We thank commenters for their input. In response to comments, we have reviewed the metrics (previously referred to as denominators) for the two measures (“use of FHIR in apps supported by certified API technology” [finalized as “use of FHIR in apps through certified health IT”] and “use of FHIR bulk data access through certified health IT”). We concur that these metrics should be consistent with each other and measure the number of distinct health IT deployments (across clients) active at any time during the reporting period. Therefore, we will use the metric from the “use of FHIR in apps through certified health IT” measure for calculating any derived statistics.

We acknowledge situations where an EHR user may have more than one production database of a certified solution and clarify that this measure counts all deployments of the certified solution regardless of the number of clients that represents.

Finalization of Measure

We have finalized the “use of FHIR bulk data access through certified health IT” measure in § 170.407(a)(3)(v). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described further in the accompanying measure specification located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion:

1. Number of bulk data access requests completed (across clients) to export all data requested for patients within a specified group.

2. Number of distinct deployments of the certified health IT deployments (across clients) that completed at least one bulk data access request.

The reporting period for the measure and related metrics above consists of one calendar year. Data collection for the measures and associated metrics will begin during the second phase of reporting (which is described later in the preamble).

Electronic Health Information Export Through Certified Health IT Measure

We proposed (88 FR 23841) to adopt the “electronic health information export through certified health IT” measure in § 170.407(a)(7) which would capture the use of certified health IT to export single patient and patient population EHI. A developer of certified health IT with Health IT Modules certified to the “electronic health information (EHI) export” (§ 170.315(b)(10)) certification criterion will be required to report data under this proposed measure.

We proposed (88 FR 23841) a count for this measure (rather than a numerator and denominator) that includes the number of full data EHI exports requests processed during the reporting period and reported by the following subgroups: (1) by a single patient EHI export; and (2) by patient population EHI export. We also proposed (88 FR 23841) reports should include a “yes” or “no” attestation for enabling direct-to-individual EHI exports. We stated that the proposed measure would report on the number of EHI export requests processed by a health IT developer and provide insights on the implementation of the EHI export capability. We refer readers to the HTI–1 Proposed Rule for detailed background on the measure (88 FR 23841).

As stated in the HTI–1 Proposed Rule (88 FR 23841), we also noted in the ONC Cures Act Final Rule (85 FR 25695) that the EHI Export certification criterion in § 170.315(b)(10) does not require “direct-to-patient” functionality in order for a developer to demonstrate conformance to the criterion. However, we did not preclude this functionality, and we sought comment as part of the HTI–1 Proposed Rule on whether any products support direct-to-patient EHI Export functionality to inform future policy decisions. We also sought comment on whether it would be valuable for this measure to be reported by “use case” for why the data was exported ( e.g., moving to another certified health IT system, use for a population health tool), and how feasible would it be for impacted developers to report in this manner. Lastly, we sought comment on whether it would be valuable, and if so, how valuable, for this measure to include reports regarding the types of recipients ( e.g., patients, organizations) of the exported data, and how feasible would it be for impacted developers to report this data in this manner.

Comments. Most commenters expressed support of this measure with numerous commenters indicating that this measure is feasible as written and that the burden to report this measure is low. One commenter recommended delay or removal of this measure though did not provide a rationale. One commenter recommended ONC to consider how patient EHI can be best protected upon export, given concern regarding inappropriate use of information. Another commenter recommended creation of patient-facing and provider-facing educational materials in support of this measure. One commenter asked for clarity regarding the term “processed” and whether it intended to indicate started or completed. One commenter disagreed with an attestation reporting requirement for functionality that is not required. One commenter who supported attestation asked for clarification on “direct-to-individual,” specifying whether the capability should be performed by the patient without any health care provider involvement. One commenter indicated that capturing and reporting “use case” does not provide value and did not support this capability while requesting that the “use case” and “recipient” types be standardized across all health IT developers. One commenter requested clarification of the definition of a “full data export” and whether a subset of data in a timeframe or based upon patient request would constitute “full data” in the context of this measure.

Response. We appreciate the support expressed by numerous commenters, as well as the thoughtful feedback and suggestions for this measure. However, in our overall efforts to reduce burden, we have not adopted the “electronic health information export through certified health IT” measure. We plan to revisit the EHI export capability in § 170.315(b)(10) as a potential measure when this capability is more widely deployed and may propose measures that provide more valuable insights in future rulemaking.

Measurement Area: Public Health Information Exchange

In the HTI–1 Proposed Rule (88 FR 23841), we discussed how the COVID–19 pandemic exposed many gaps and challenges in the nation's public health infrastructure, including a need for more accurate and timely data, increased electronic exchange of patient health information between health care providers and public health agencies, and greater support for vulnerable individuals and communities disproportionally affected by the pandemic. Therefore, in § 170.407(a)(8) and (9), we proposed two measures within the “public health information exchange” area for reporting health care providers' use of certified health IT to exchange data with an immunization information system (IIS) (88 FR 23841). We stated that the insights from these measures could help ONC (and HHS more broadly) assess the public health capabilities of certified health IT, and that we believe that more detailed measurement of health care providers' ability to use certified health IT to successfully exchange health information with public health agencies would provide critical data for pandemic response and other public health emergencies.

Comments. We received broad support for the adoption of two measures within the “public health information exchange” area. These commenters also encouraged additional public health information exchange measures in future iterations of the Insights Conditions, such as for cancer reporting, electronic case reporting, syndromic surveillance, and electronic laboratory reporting, along with an estimated timeframe for the development and implementation of these measures. A couple of commenters recommended that ONC align future public health information exchange measures with CMS measures. One commenter expressed support and requested clarity on how the information will be used to evaluate performance, or inform policy or other decision making. Another commenter requested ONC to make aggregate responses available to the public.

Response. We thank commenters for their support and agree that the goal is to help measure progress related to certified health IT's ability to support public health information exchange. This data will provide “insights” into health care providers' use of certified health IT for public health information exchange that can guide policy efforts to improve these efforts through initiatives such as the CDC Data Modernization Initiative. In this iteration of the Insights Condition, we have focused on immunization related exchange. However, in future rounds, we plan to consider other areas of public health information exchange to include as part of the Program, working with CMS, CDC, and other federal partners as necessary to ensure alignment of measures. As noted in the HTI–1 Proposed Rule (88 FR 23847), we plan to make the measures and the required data documentation reported by health IT developers available to the public.

Comments. One commenter expressed concern on the level of burden required by health IT developers to obtain the necessary data for each measure and recommended requiring only overall administration submission numbers. Another commenter opined on whether engaging with public health agencies to generate some meaningful data might be less burdensome on vendors and their users and may paint a more complete picture of the situation.

Response. We understand the concerns expressed regarding burden and recognize that these measures may require discrete effort on the part of health IT developers. We appreciate the feedback from commenters and made revisions to reduce the burden associated with creating and reporting these measures which are further detailed below in this section of the preamble. This includes removing our proposal to report by age for the “immunization history and forecast” measure, providing additional time for implementation by phasing in the measures over two years, and phasing in complex aspects of the requirements ( e.g., reporting by age and/or IIS) over a span of three years.

Data from the measures we have finalized in this final rule will provide insights into the level of exchange between certified health IT systems and IISs, to identify opportunities to address gaps or lags discovered. With regards to public health entities having similar measures, the CDC's Immunization Integration Program (IIP) Testing and Recognition initiative, an ONC approved alternative testing method for the “transmission to immunization registries” (§ 170.315(f)(1)) criterion, share some similarities to the measures we had proposed and subsequently finalized. We seek to build upon the IIP by expanding the scope of their measures, which cover a sample of jurisdictions, to include all jurisdictions. This expansion would provide national level insights. In contrast to the IIP, ONC's electronic submission of immunization administrations to IISs shall be reported by age categories, which will help interpret the data as IISs are more likely to have mandates for reporting vaccinations given to children and adolescents compared to adults. We also have a unique measure in comparison to the IIP, which measures the total number of vaccine administrations. Developers that participate in the IIP should gain experience that will help them with reporting for the Insights Condition. Regarding the concern whether public health jurisdictions may serve as an alternative source for this data, while an IIS serves as a valuable source to understand vaccination coverage using unique patient records and vaccination histories, not all jurisdictions have access to or the ability to produce the measures that we proposed. Jurisdictions with high performing IISs and staff to support them are more likely to have these data and use them to improve data quality. However, not all jurisdictions have access to these data. Thus, the measures address an important gap in information that can help improve interoperability between health care providers and jurisdictional IISs.

Immunization Administrations Electronically Submitted to Immunization Information Systems Through Certified Health IT Measure

In the HTI–1 Proposed Rule (88 FR 23842), we proposed to adopt in § 170.407(a)(8) a public health exchange measure that would report on the volume of immunization administrations electronically submitted to an immunization information system through certified health IT. We stated that this measure would capture the use of certified health IT to send information on vaccination and immunization administrations to an IIS. Specifically, the proposed “immunization administrations electronically submitted to an immunization information system through certified health IT” measure would require developers of certified health IT with Health IT Modules certified to the “transmission to immunization registries” (§ 170.315(f)(1)) criterion to report on the number of records of immunizations administered that were sent electronically to an IIS during the reporting period. We proposed that developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) that do not have users that administered immunizations during the reporting period would attest that they are unable to report on this measure.

We stated that the intent of the measure is to ensure that ONC has the information necessary to assess whether Health IT Modules certified to § 170.315(f)(1) are being used to support electronically sending vaccination information data to IISs, which has proven to be critical to public health preparedness and response.

For the numerator, we proposed (88 FR 23842) developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) report the number of immunization administrations from which the information was electronically submitted to an IIS successfully during the reporting period by IIS and age group. We proposed (88 FR 23842) that the numerator and denominator counts would be reported overall (across IIS and age subgroups) and by the following subgroups: (1) number of administrations by IIS; and (2) number of administrations by IIS and age group (adults (18 years and over) and children/infants (17 years and under)). We defined a successful submission to an IIS would be the total number of messages submitted minus acknowledgments with errors (2.5.1, severity level of E). We stated that we believe this definition will avoid limitations from IIS jurisdictions that do not send HL7 Acknowledgment messages (ACKs) for this measure. Given that, we proposed that ACKs with an error (severity level of E) would not be counted, and we sought comment on whether ACKs with a warning (severity level W) should still be counted in the numerator. We also sought comment (88 FR 23842) on whether the number of immunizations administered can be linked to immunizations submitted to the IIS, effectively creating a subset of the numerator (immunizations administered). Additionally, we sought comment (88 FR 23842) on whether a successful submission should be counted if a health care provider is able to successfully submit to at least one registry, as opposed to all the registries they submitted to ( e.g., health care providers who operate in multiple states sending data for the same administration to multiple IISs). In the Proposed Rule (88 FR 23842), we also considered whether “replays,” which involve resubmitting administrations until they are successfully submitted, qualify as a successful submission. In other words, we sought comment on whether successful submissions should be limited to the first attempt to submit.

We proposed (88 FR 23842) the denominator for this measure to be the number of immunizations administered during the reporting period, and that the denominator be stratified by the following subgroups: (1) number of administrations reported to each IIS; and (2) number of administrations reported to each IIS, by age group (adults (18 years and over) and children/infants (17 years and under)). Given the variation in immunization reporting requirements and patient consent by state or jurisdiction, reporting of administrations by IIS is critical to interpreting the data correctly, therefore we proposed this measure to be stratified by IIS. In addition, given that immunization requirements are different for children and adults, we proposed stratifying by age group as well. To further inform public health exchange efforts, we also sought comment (88 FR 23842) on whether adolescents/infants should be further stratified by age, and by what age limits. For providers who operate in multiple states, and thus would be sending data for the same administration to multiple IIS, we sought comment (88 FR 23842) on whether a successful submission should be counted if a provider is able to successfully submit to at least one registry versus all the registries to which the provider submitted. As stated in the HTI–1 Proposed Rule (88 FR 23843), the data collected for this measure would enable ONC to calculate the percent of immunizations administered where the information was electronically submitted to an IIS.

Comments. The majority of commenters supported the proposed “immunization administrations electronically submitted to an immunization information system through certified health IT” measure, stating that these reporting metrics will encourage providers to institute proven best practices for obtaining consent and report vaccinations where consent is received. Commenters also stated that organizations using certified health IT would benefit, as it would provide aggregate numbers and user-friendly reports, and help detect connectivity interruptions, as well as help federal agencies, public health agencies, and health IT developers better understand the extent to which health IT is exchanging data with an IIS. A commenter also stated that this would provide real-time and comprehensive data on immunization coverage, facilitating targeted interventions, and contribute to overall population health protection. One commenter recommended that ONC and CMS continue collaborating to consider how their measures can be analyzed and interpreted in tandem to answer questions about data exchange, as well as to collaborate on additional future public health measures.

Response. We thank commenters for their support of the measure and agree with the potential benefits of a measure that assesses how Health IT Modules certified to the “transmission to immunization registries” (§ 170.315(f)(1)) criterion are being used to support electronically sending vaccination information data to an IIS. This criterion has proven to be critical to public health preparedness and response. We believe this measure can provide insights beyond current physician surveys limited by small sample size that do not provide information on actual usage of functionality that supports electronically sending vaccination data to an IIS.

Comments. Several commenters expressed concern regarding the burden related to this measure. Commenters representing health IT developers recommended we delay the patient age and IIS stratifications from the measure and proceed with the overall administration submission numbers, due to the high burden level rating for these stratifications. Other commenters expressed support on the age group stratifications as proposed and did not believe any additional age group stratifications were necessary, stating that it may add unnecessary complexity to the measure. One commenter suggested eliminating the measure. Another commenter stated that since API access can be measured at either endpoint of the transaction, ONC should request this information from the IIS rather than from providers. One commenter recommended to lessen the burden, ONC could provide standardized value sets for use by all vendors in the counting of mandatory immunization requirements across the nation, however, the commenter conveyed that the necessary work for this effort would outweigh the benefits.

Response. We appreciate the support expressed on the stratifications and have finalized the IIS and age stratifications as proposed. The IIS stratification is critical for assessing both the interoperability and exchange of information between certified health IT and immunization information systems as well as the extent to which health care providers are engaging in immunization reporting. Examining these data by IIS will allow us to monitor the evolving state of immunization data exchange as efforts are made to modernize public health information technology. Additionally, public health jurisdictions will obtain data which they currently don't have access to, and understand the extent to which certified health technology is used for immunization reporting. Therefore, we have kept the proposed IIS stratification. We also believe stratifying by age is important for the purpose of interpreting the results. Public health jurisdictions commonly mandate immunization reporting for children, but do so less for adults. Without the age stratification, it would be difficult to assess whether high or low rates of submission were due to differences in requirements related to adults versus children or another reason ( e.g., issues with exchange between certified health IT systems and IIS). Thus, we kept the proposed stratification for age to provide insights on trends related to reporting immunizations for adults and children.

However, we also understand and acknowledge the concerns expressed for the resources required to develop stratifications for this measure. In response to commenters, we have updated the implementation timelines to provide additional time for compliance by phasing in the stratifications (IIS and age) by an additional year and refer readers to the Insights Conditions and Maintenance of Certification section (III.F.3) for a detailed discussion of timelines and the phasing in of measures in this final rule.

We appreciate the comment inquiring about the potential role to leverage public health APIs to support measurement. The measure focuses on data submitted via certified health IT and note that the suggested use of public health APIs for measurement is currently outside the scope of the Program, and not all public health entities may have APIs to support this type of measurement.

We also clarify that the measure does not require logic customized to individual jurisdiction reporting mandates. As noted in the HTI–1 Proposed Rule (88 FR 23842) the number of immunizations transmitted to an IIS will reflect the provider organization's existing practices to transmit this data in accordance with jurisdictional requirements. Therefore, we do not see an immediate need to create a value set that would express those requirements. However, we may explore this suggestion in the future rulemaking to reduce burden.

Comments. One commenter requested clarification on whether the age to be used for counting purposes is the age at the time of immunization administration or at the time the information is transmitted to the IIS. Another commenter recommended that adolescent data extend through age 18, rather than to age 18, to align with the Vaccines for Children program age ranges, as well as requested expectations for jurisdictions that either have limited adult reporting or have an adult “opt-in” model, as these jurisdictions will likely have a low level of reporting.

Response. We thank commenters for their feedback. In response to comments, we have modified the age categories for clarity. In alignment with the CDC's Vaccines for Children program, we have modified the age stratifications to the following two categories: (1) immunizations administered for patients 18 years of age and younger (children and adolescents) and (2) immunizations administered for patients 19 years of age and older (adults). We are aware that age-related requirements vary by jurisdiction but for the purposes of standardization and ease of reporting, we have opted to align our requirements with the CDC's Vaccine for Children Program. Patients in the measure's metrics should be counted based on age at time of administration. We acknowledge that a relatively small number of patients may fall into separate counts if the date of immunization is close to the end of the reporting period, but we expect that these instances should not significantly impact the metrics calculated.

Comments. One commenter recommended that timeliness should be added to this measure's numerator and stratify the measure by the definition of “timely” to be less than or equal to 24 hours to provide health IT developers, providers, and public health agencies with insights into how rapidly immunization data is being shared with IIS registries and accessed by health agencies.

Response. We appreciate the recommendation to factor timeliness and agree this plays a critical role in data quality and utility. We may consider this aspect for future potential measure enhancements as we seek to appropriately factor variation in provider workflow and jurisdictional reporting requirements.

Comments. One commenter requested clarification on whether a message is a failure or success if the initial message for a vaccination administration is successful, but the administration is updated in the EHR, and the update message fails. One commenter suggested collecting how many submissions needed to be repeated. Several commenters stated that replays should qualify as a successful submission since there are scenarios that could create a submission failure at no fault of the developer, and immunization submitters should be recognized for successful error remediation. One commenter recommended that “replays” are considered successful submissions, but each replay of a single immunization administration should not be counted as a separate submission, as overcounting may result in inflating the numerator of the measure.

Response. We thank commenters for their feedback. The intent of the measure is to understand the process of submitting immunization to an IIS and efforts by health care providers to successfully submit immunization administrations to an IIS. While the process and effort can involve resolving message failures, the measure counts the number of immunizations administered that are submitted to the IIS, rather than the number of attempts to successfully transmit the immunization. With this in mind, we clarify that, in the instance where the initial message for an immunization administration is successful and a subsequent update in the EHR has an update message that fails, the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS should reflect the final status of the immunization submission to the IIS. There should not be two counts in these metrics for the successful initial message and the subsequent failure update message. We expect that the shift to calendar year reporting will minimize instances where the final status of successful vaccine submissions would not be available to count in the measure. Therefore, the measure will count the status of the final submission at the time the reporting period ends in these metrics, rather than counting each attempt separately. This applies to replays, which should not count as separate submission attempts in these metrics. Although this measure will not separately document the number of replays, we agree with commenters who supported counting replays and multiple messages as separate attempts to successfully submit an immunization and may consider future measures that would document the level of effort taken for successful error remediation. We encourage those reporting on this measure to include counts of replays in the supplemental documentation as this could shape future iterations of this measure.

Comments. Several commenters expressed support that those acknowledgements with a severity level of “E” be considered a failure for purposes of the measure's numerator. The commenters added that acknowledgements with the severity level “W” should not be considered a failure, given that they were likely successfully processed by the IIS and their data accepted by the immunization program. However, another commenter noted the possibility that including acknowledgements with the severity level “W” could inflate the measure and make interpretation challenging. One commenter requested confirmation that only “E” responses should be subtracted from the success acknowledgements and noted it would be helpful for ONC to define the concepts of error and warning responses in the context of this measure. One commenter stated that there is variation on how the error status of level “E” is used in practices, noting that this would likely make the aggregated data ONC proposes to report less than accurate, and requested clarification on whether the purpose of the use of error and warning messages in this context is to assess whether immunization registries are functioning effectively. One commenter recommended that the successful submission definition be revised to reflect that no negative acknowledgement is a successful submission, until an alternative mechanism is used to route acknowledgements from the registry back to the EHR.

Response. We thank commenters for their feedback. We appreciate the comment that acknowledgements from IIS with a severity level of “W” could potentially inflate the measure and acknowledges the variation on how “E” is used in practices. We intend to collaborate with the community to monitor how these instances may impact the interpretation of the measure and determine if it should be revised in the future. We also appreciate commenters requesting confirmation that the measure should consider acknowledgements with a severity level of “E” as a failed message. We confirm that this is the only severity level for messages that should be excluded from the measure's metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS. We thank commenters for their consideration of the implications for error status level “E.” We confirm that successful submissions are defined as the total number of messages submitted to an IIS, minus acknowledgements with errors (2.5.1, severity level “E”). For these metrics, we clarify that not all immunizations that are administered and submitted during the period may receive a status of the submission acknowledgement message from an IIS during the reporting period. In this situation (where an acknowledgement from an IIS is not received), the immunization submission should be counted as successful. We request that health IT developers report the number of submissions that did not receive acknowledgement in the supplemental documentation so these metrics can be refined in the future if needed.

Comments. A few commenters stated that a successful submission should be counted if a health care provider is able to successfully submit to all of the registries to which the provider submitted, including submissions to more than one IIS, stating that the inflation of the count would be minimal.

Response. In response to comments, the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS, indicate that each successful submission to an IIS to which a provider submits immunizations should be included and counted as a successful submission. Thus, an immunization that is successfully submitted to more than one IIS would be counted the number of times it was successfully submitted to each IIS. When the stratified metric is reported by IIS, the count inflation should not be an issue as the multiple submissions would be separated by IIS.

Comments. Several commenters requested clarification on the denominator counts. One commenter requested clarification on whether a patient who opts out of having certain administered immunizations submitted to the IIS should be included in the denominator, as well as if an immunization is ordered but refused by the patient. The same commenter also requested clarification on whether the denominator includes administered vaccines from provider organizations that do not yet have connectivity in place to an IIS for reporting administered vaccines. One commenter recommended that the denominator exclude the number of patients who have opted out of vaccination reporting to capture more accurately the proportion of immunization administrations electronically submitted.

Response. We thank commenters for their request for clarification. We clarify that the measure focuses on counting immunizations administered and submitted. Patients who have been administered an immunization and opt out of submitting their data to an IIS should count in the metrics for the number of immunizations administered overall, by age category and IIS, but not the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS. To ease burden and given the assumption that the number of opt-outs are relatively low, we believe it is sufficient to include them. However, there may be value in counting the number of opt-outs in the future to determine whether it is worth removing them (or separately report on these). Patients who decline an immunization will not appear in the metrics for the number of immunizations administered overall, by age category and IIS, and there will be no immunization submission to count in the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS. We also clarify that immunizations administered at health care provider organizations that have certified health IT eligible for reporting but do not have an existing, active connection to electronically submit immunizations to an IIS will count in the metrics for the number of immunizations administered overall, by age category and IIS, while there will be no count in the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS. This approach will contribute to insights on the number of immunizations that could be electronically submitted to reduce provider burden associated with manual submission.

Comments. One commenter stated that stratifying the denominator (number of immunizations administered within the reporting period) by IIS does not make sense since an IIS is not identified with an immunization administration. One commenter expressed concern stating that an EHR is unlikely to know of administrations reported to an IIS through a web portal or alternate mechanism and recommended that the measure should instead be out of the total number of doses administered how many doses were submitted electronically, and of those electronically submitted, how many were successful. A couple of commenters recommended that the number of administrations reported to each IIS should be revised to number of administrations valid for reporting to each IIS to ensure that the count of doses sent electronically only include those doses tagged as newly administered. Another commenter requested guidance on how doses should be counted in the metrics if two EHR systems merge, and another requested clarification on how data submitted from a non-traditional location should be counted.

Response. The metrics for the number of immunizations administered overall, age category and IIS, is stratified or reported by IIS because we seek to assess the extent to which an IIS is receiving data on immunizations administered. While the location of the patient typically determines the IIS to which vaccine administration information is sent, given that it is unclear as to which data sources may be easily accessible to make this determination, we provide two options regarding how best to select the IIS for those vaccines that are administered but not submitted: (1) based upon the primary IIS used by the client site; or (2) based upon the jurisdiction associated with the client site's location. Whatever approach is used should be documented in the required documentation for this measure. We note that the stratification by age in the total vaccines administered within the reporting period enables comparisons with the vaccines submitted electronically metric.

We clarify that the measure pertains to immunizations electronically submitted to IISs through certified health IT. Immunizations submitted via web portals or alternate mechanisms, such as manual submission of spreadsheets, would not be reported in the immunizations submitted electronically metrics, but, given that these were administered but not electronically submitted via certified health IT, they would be included in the metrics for the number of immunizations administered overall, age category and IIS. We do not believe it is feasible to remove these from the total vaccines administered metrics; however, if available, the volume of immunizations could be noted in the health IT developer's supplemental reporting to provide additional insight and context.

We also appreciate the requests for clarification on whether doses tagged as newly administered are included. We acknowledge that the “transmission to immunization registries” (§ 170.315(f)(1)) criterion includes historical vaccines and newly administered vaccines, giving health IT developers that certify to this criterion the capability to report both. We note this treatment of historical vaccines administered applies to data migrated from one EHR to another, and vaccines that were previously administered by another provider site. Because the proposed measure referred to administered immunizations (and not historical specifically), we clarify that the finalized measure will only count immunizations newly administered during the reporting period and will not count historical vaccines previously administered that were recorded during the reporting period. The inclusion of historical vaccines in addition to newly administered vaccines within one measure would be difficult to interpret; in the future we may consider the inclusion of historical vaccines based upon industry experience and the input we have received. The measure is not constrained to the type of health care provider who administered the vaccine or the location the vaccine was administered, provided the certified health IT is eligible for reporting.

Comments. One commenter requested clarification whether the immunization administration would have to be within the reporting period or the IIS submission in the reporting period (or both).

Response. For the metric, immunizations administered that were electronically submitted successfully to IISs, immunizations should be both administered and submitted during the reporting period. An immunization administered outside the reporting period but submitted during the reporting period would not count for these metrics. We note that if no acknowledgment is received for immunizations administered, and submitted during the reporting period, then the immunization would count as successfully submitted.

Comments. One commenter requested clarification on whether health IT vendors will be required to calculate a percentage and if so, requested ONC provide explicit guidance on the calculation components.

Response. We clarify that ONC will be responsible for calculating percentages based on the counts that health IT developers submit.

Finalization of Measure

We have finalized the measure as “immunization administrations electronically submitted to immunization information systems through certified health IT” in § 170.407(a)(3)(vi). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described in the accompanying measure specification located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion. The reporting period for the measure and related metrics below consists of one calendar year. Data collection for the measures and associated metrics will begin during the first and second phases of reporting (which is described later in the preamble):

1. Number of immunizations administered overall (year 1),

2. Number of immunizations administered overall by IIS and age category (year 2).

3. Number of immunizations administered that were electronically submitted successfully to IISs overall (year 1),

4. Number of immunizations administered that were electronically submitted successfully to IISs overall, by IIS and age category (year 2).

Immunization History and Forecasts Through Certified Health IT Measure

In the HTI–1 Proposed Rule, in § 170.407(a)(9), we proposed to adopt a public health information exchange measure to require reporting on the number and percentage of IIS queries made per individual with an encounter (88 FR 23843). The “immunization history and forecasts” measure would capture the use of certified health IT to query information from an IIS under the “transmission to immunization registries” (§ 170.315(f)(1)) criterion. Therefore, we proposed (88 FR 23843) that developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) would be required to report for this measure. We emphasized that understanding whether health care providers are engaging in electronically querying immunization information from IIS is critical to public health preparedness.

For the numerator, we proposed (88 FR 23843) developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) report the number of query responses received successfully from an IIS overall and by subgroup, by IIS and age group (adults (18 years and over) and children/infants (17 years and younger)) during the reporting period. The definition of a successful response from an IIS should be the total number of messages submitted minus acknowledgments with errors (2.5.1, severity level of E). However, since HL7 Z42 messages contain both immunization history and forecast, whereas Z32 messages exclusively contain history, we sought comment (88 FR 23843) on whether both message types should be included in the measure numerator.

As stated in the HTI–1 Proposed Rule (88 FR 23843), the first denominator we proposed for this measure would be the total number of immunization queries overall and by subgroup, by IIS and age group (adults (18 years and over) and children/infants (17 years and younger)) during the reporting period. We proposed to add this denominator to the measure proposed by the Urban Institute to provide data on the total number of query responses that are and are not successfully received from an IIS, as this will give further insights into any potential technical challenges that may be occurring during query exchange. The second denominator we proposed for this measure would be the total number of encounters overall and by subgroup during the reporting period. However, since it is unlikely that queries happen for every patient encounter, we sought comment (88 FR 23843) on whether the second denominator should capture to total number of applicable patient encounters during the reporting period regardless of whether a query was sent to an IIS. We proposed (88 FR 23843) that the numerator and denominator counts would be reported overall (across IIS and age subgroups) during the reporting period and by the number of IIS queries made by IIS and age group (adults (18 years and over) and children/infants (17 years and younger) during the reporting period. In the HTI–1 Proposed Rule (88 FR 23843), we conveyed our belief that reporting by these subgroups would be necessary to interpret the data and create public awareness that could inform IISs and other public health participants about the progress being made in immunization data exchange. We sought comment (88 FR 23843) on whether children/infants should be further divided and by what age limits.

We also proposed (88 FR 23843) developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) would attest that they are unable to report on this measure if they have no users that administered immunizations during the reporting period. There may also be providers who do not administer immunizations but would want to query an IIS to determine whether their patient has received a vaccination. We sought comments (88 FR 23843) on whether we should include this exclusion or suggestions on how we could better refine it.

Comments. A few commenters expressed support for the proposed measure, stating that comprehensive immunization history and forecasts through certified health IT enables health care providers to proactively manage immunization programs and promote preventative care. Also, by utilizing certified health IT to track history and generate forecasts, health care providers can identify immunization gaps, schedule timely vaccinations, and implement outreach initiatives to increase vaccination rates.

Response. We thank commenters for their support of the proposed measure and appreciate the examples of how the measure would support improvements in preventive care for patients. We agree that this measure, which provides insights on how certified health IT is used to support health care providers to electronically query immunization information from IIS, is critical to public health preparedness.

Comments. One commenter expressed concern with the second denominator, stating that the total number of visits will not accurately reflect the number of immunization query messages expected to be generated, as not all encounters can reasonably be expected to result in a query message, and suggested an alternate measure to include a numerator defined as the total number of unique individuals queried for during the reporting period and a denominator defined as the total number of unique individuals with encounters during the reporting period. Another commenter recommended that ONC develop a simpler definition of encounters that developers can apply to their own systems and encounter classification structures or establish a clear set of encounter type categories with fully defined mapping such as OMB/CDC Race categories/details. The same commenter suggested ONC coordinate with CMS to ensure that the value set references include all SNOMED and CPT codes in the proposal or identified alternatives. One commenter recommended modifying the second denominator to include encounters with immunizing provider sites rather than all encounters.

Response. We concur that not all encounters can be expected to generate a query to an IIS. Therefore, as one commenter noted, the number of visits may not reflect the number of immunization queries expected. We may collaborate with the community to consider the measure of unique patients for whom queries were made to the IIS for future rulemaking. The measure does not include encounter-based metric from the immunization measure domain to address the concern raised by commenters that not all encounters can be expected to result in a query message. We will still receive counts of the number of unique patients with an encounter during the reporting period, as proposed (and finalized) in the “consolidated clinical document architecture (C–CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT” measure. We refer readers to the definition of terms section immediately following this section for a more detailed discussion on defining encounters.

Comments. A few commenters expressed concern with the intent and interpretation of the proposed measure. One commenter stated that if the intent is to assess the overall functioning of bidirectional query, ONC should clarify this intent such that a low ratio does not reflect poorly on the developer of certified health IT or the querying organizations. One commenter commented that it was their experience that some IISs are not ready to return the data for response to the query and noted that this would impact the countable events for this measure and should be publicly disclosed if/when the data is published. One commenter recommended that these measures be considered exploratory and should not be used to penalize any certified health IT product or developer.

Response. We acknowledge that some IIS are not able to return data for a query response and as such, agree that the finalized measure should be seen as informative and reflects the role that the health IT developers, health care providers, and IIS systems play with the exchange of this information. We acknowledge that an IIS may have issues in returning the data for response to the query, thus impacting the value of this measure. We recognize this contextual information will be important to note with the publication of these data. Where health IT developers encounter instances where a complete bidirectional loop is not possible, we encourage health IT developers to document this information in the supplemental reporting to allow for more complete understanding of the metrics.

In this finalized measure, counts of queries sent to an IIS and responses received successfully are intended to provide insight on the functioning of bidirectional query to obtain immunization data. The metrics reported by health IT developers will provide new insights for ONC and the public health community that are currently unavailable at a national level. By understanding trends related to queries made and responses received over time, we will also gain feedback on the performance of queries and responses, which are part of the “transmission to immunization registries” (§ 170.315(f)(1)) criterion. As noted above, we will receive counts of the number of unique patients with an encounter during the reporting period, as proposed (and finalized) in the “consolidated clinical document architecture (C–CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT” measure, and expect to use this data to provide encounter context to the “public health information exchange” measures. Together, these metrics can inform efforts to increase the availability of IIS data for health care providers to have a more complete immunization background for individuals and groups of patients. We plan to collaborate with the community to consider the measure of unique patients for whom queries were made to the IIS for future rulemaking.

Comments. Several commenters requested clarification on the proposed numerator. One commenter noted that the proposed numerator reflects the interoperability of the IIS, not the certified health IT, and requested clarification on “received,” stating that the successful response definition is not clear in cases where the error can be detected by the certified health IT in the IIS response such as “received technically” versus “received into the chart.” A few commenters requested clarification on how “refines” are counted for measurement, when a query attempt must be refined before a successful attempt, and suggested the numerator should reflect total queries performed.

Response. We appreciate the concern expressed that the metric does not reflect the interoperability of certified health IT. Through our measures we seek to assess bidirectional exchange activity between IIS and certified health IT, which can help identify potential issues related to interoperability and track trends over time. We appreciate the comments and the opportunity to provider greater clarity. In this final rule, we clarify that the metrics for the number of query responses received successfully from IISs overall, and by IIS, should count an IIS response as “received technically,” in the form of a message or transaction. This clarification addresses that health care providers may not ingest all responses into the record. We agree that the initial query and each refined query should individually increment the total number of immunization queries sent to an IIS in order to acknowledge the effort to ensure a successful query.

Comments. A couple commenters expressed support that acknowledgement with a severity level of “E” be considered a failure for purposes of the measure. One commenter noted that an error with a severity level of “E” could be included in either an acknowledgment or a response (RSP) message. A couple commenters noted that a significant portion of messaging failures are communication failures where there will be no response received which should be excluded from the denominator or included in a separate metric. The commenter suggested that messages of “no patient found” or “too many patients” found, as well as messages with no response from the IIS (in the case of downtime, for example), would be considered successful. One commenter requested clarification on whether a query response message responding that a patient match was not possible should be counted in the numerator. The commenter also suggested that the submission of descriptive context should be required, stating that it may help with future evolution and fine tuning of the measures.

Response. We appreciate the comments received regarding that the measure should consider acknowledgements with a severity level of “E” as a failed message. We confirm that only severity level of “E” for messages are excluded from the metrics, the number of query responses received successfully from IISs overall and by IIS. We also appreciate the additional description of communication failure scenarios due to IIS downtime or other accessibility issues. We will collaborate with the community to monitor how these instances impact the measure's interpretation and determine if it should be revised in the future. At this time, we will not require health IT developers to provide separate counts for communication failures and counts of the descriptive context levels. We encourage health IT developers to capture information about communication failures as their functionality permits and include this explanation in the supplemental documentation.

Comments. In our request for public comment regarding whether both Z42 and Z32 messages should be included in the metrics, several commenters suggested that both Z42 and Z32 messages be included, stating that both are objectively relevant to patient care, contain significantly similar content, and have both been implemented in the real world.

Response. Given the support expressed in response to our specific question, the metrics, the number of query responses received successfully from IISs overall and by IIS will include Z42 and Z32 messages.

Comments. Commenters representing health IT developers expressed concern related to the proposed measure's stratification by IIS and age. These commenters suggested that the initial implementation of the measure should only require administration submission counts and that the development burden was high relative to the value of the stratifications. Other commenters supported the stratifications as defined, given that not all jurisdictions require comprehensive adult reporting. One commenter noted that additional age stratification was unnecessary and might add complexity. One commenter suggested delaying or eliminating the “immunization history and forecasts” measure.

Response. We appreciate the comments that indicated support for the measure's proposed stratifications, but that development burden would be high especially associated with the age stratification. We acknowledge that the age stratification is not as critical early on for this measure (compared to the submission of immunization data) as there are no state and jurisdiction level mandates for querying history and forecasts which vary by age. Therefore, we have delayed the implementation of this measure from “year 1” to “year 2” to provide health IT developers more time to produce the measure. Furthermore, the reporting by IIS will be delayed to “year 3.” We have not removed this measure as suggested by one commenter as there was a high level of support for this measure and we are providing additional time to implement the metric and related stratification.

Comments. One commenter requested clarification on how a query sent to multiple IIS should be counted. One commenter requested clarification on whether the first denominator should include only query response messages that support both the history and forecast. One commenter requested clarification on whether developers would be required to calculate a percentage and if so, ONC must provide explicit guidance on the calculation components.

Response. We clarify that the metrics related to the total number of immunization queries sent (overall and by IIS), should be incremented for each query sent to an IIS and the metrics related to number of query responses received successfully from an IIS (overall and by IIS), should increment for each successful message received. The measure should count queries and response messages so that the increment occurs for history, forecast, or history and forecast. This approach is supported by the “transmission to immunization registries” (§ 170.315(f)(1)) criterion that treats forecast and history separately. At this time, health IT developers are not required to report separate metrics for forecast and history. We clarify that ONC will calculate percentages based on the counts that the health IT developer submits.

Comments. One commenter stated that they did not agree with excluding queries performed by health care providers who do not administer immunizations, while another commenter recommended excluding these health care providers for simplicity.

Response. We acknowledge that the suggestion to constrain the measure to only include health care providers who immunize simplifies the interpretation of results. However, the National Vaccine Advisory Committee (NVAC) recommends that all healthcare professionals, regardless of whether they administer vaccines, routinely assess patients for vaccines due. Furthermore, there was no consensus across the comments to make this change. In this phase of reporting, it may add burden for health IT developers to segment the measure by whether the health care providers are immunizing providers. Therefore, the measure does not make distinctions for health care providers who do and do not administer immunizations and will collaborate with the community to understand the potential to incorporate this aspect in future rulemaking.

Finalization of Measure

We have finalized the measure as “immunization history and forecasts through certified health IT” in § 170.407(a)(3)(vii). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described in the accompanying measure specification located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion:

1. Number of immunization queries sent to IISs overall (year 2).

2. Number of immunization queries sent to IISs overall by IIS (year 3).

3. Number of query responses received successfully from IISs overall (year 2).

4. Number of query responses received successfully from IISs overall by IIS (year 3).

The reporting period for the measure and related metrics above consists of one calendar year. Data collection for these measures and associated metrics will begin during the second and third phase of reporting (which is described later in the preamble).

Encounters

For measures where patient encounters are relevant, we proposed the definition of an encounter should be based on the National Committee for Quality Assurance (NCQA) outpatient value set and SNOMED CT inpatient encounter codes. For outpatient codes, developers should use NCQA's Outpatient Value Set. For inpatient codes, developers should use SNOMED CT codes 4525004, 183452005, 32485007, 8715000, and 448951000124107. Listed below is a description of each SNOMED CT code:

• Emergency department patient visit (procedure)—4525004
• Emergency hospital admission (procedure)—183452005
• Hospital admission (procedure)—32485007
• Hospital admission, elective (procedure)—8715000
• Admission to observation unit (procedure)—448951000124107

Comments. Several commenters requested guidance for implementation of encounter value sets. Commenters representing health IT developers suggested adopting a broad definition of encounters for developers to apply and map to their own classification structures, while others suggested constraining the codes to a more limited and defined set. One commenter suggested limiting inpatient encounter codes to discharges only.

Several commenters supported the proposed approach (FR 23832) to align Insights Condition value sets for encounters with CMS programs. Commenters representing quality measure developers supported the proposed value sets that are used in electronic clinical quality measures (eCQMs). While calling for alignment with CMS programs, several commenters representing health IT developers recommended that the encounter value sets should follow industry standards, such as the FHIR Encounter.type field in the US Core Implementation Guide.

Response. We agree with commenters on the importance of aligning encounter value sets with industry approaches as well as re-using existing value sets that support CMS programs to reduce the burden of developing and reporting Insights Condition measures. In the HTI–1 Proposed Rule (88 FR 23832), we proposed to define encounters leveraging a code set defined by the National Committee for Quality Assurance and recommended by the HITAC, while requesting comment on alternative approaches. We proposed this approach in large part to align with existing measurement approaches used within CMS programs. As commenters described, not all codes included in the proposed approach are reflected in the US Core IG version 6.1.0, which is the version we believe commenters referenced. Based on public comment, we have revised the definition of encounters to maintain alignment with definitions of encounters within existing quality measurement approaches used by CMS while responding to industry concerns about burden and potential misalignment. Specifically, several CMS programs, including the Promoting Interoperability Program and the Quality Payment Program, require the counting of encounters using specific codes, and CMS maintains an CQM library that specifies specific encounter codes related to quality measurement. Developers of certified health IT have years of experience with those reporting efforts. Specifically, health IT certified to any criterion in § 170.315(c)(1) through (4) supports recording, importing, reporting or filtering CQMs, and health IT certified to § 170.315(g)(1) or (2), supports numerator recording and measure calculation for each Promoting Interoperability Program percentage-based measure. For the purpose of the Insights Condition, we define applicable encounters as all encounters that the developer includes in its calculation of encounters within the existing certification criteria in § 170.315(g)(1) or (2) and the CQMs that they have presented for certification as part of certification to § 170.315(c). For those developers that do not attest to any of the certification criteria at § 170.315(c), (g)(1) or (2), we specify that they include all encounters regardless of encounter code. Based upon analysis of the Certified Health IT Product List (CHPL), we note that of the 306 products currently certified to § 170.315(b)(2), 281 are certified to at least one of the included criteria, with 232 certified to criterion in § 170.315(c) and 260 certified to § 170.315(g)(1) or (g)(2).

In finalizing this approach, we have eliminated the prescriptive approach to defining value sets that delineate encounters taken in the HTI–1 Proposed Rule, which was based on a specific set of quality measures and their associated Value Sets. The finalized approach instead relies on existing developer competencies and experience as demonstrated by their existing certification to any criterion in § 170.315(c)(1) through (4), (g)(1) or (g)(2) while retaining a close link to existing quality measurement. Our goal in finalizing this approach is to build upon existing CMS program requirements, certification criteria, and developer of certified health IT's experience with these requirements. Rather than specify specific value sets, our intent is to allow the definition of an encounter to evolve as use of CQMs and approaches within this Program and the Quality Payment Program change. In finalizing this approach, we have also emphasized alignment with measurement within CMS programs ( i.e., eCQM and Promoting Interoperability percentage-based measures) rather than following industry standards, such as the FHIR Encounter.type field in the US Core Implementation Guide. As approaches within CMS' programs come into alignment with industry standards, the measure of encounters within the Insights Condition will also come into alignment. For developers that do not currently support the identification of specific types of encounters, our intent is to avoid creating a new requirement to implement specific terminologies or code sets.

Counts of Unique Patients

Comments. One commenter opposed the use of unique patient counts in the proposed measures under the Insights Condition. Further, the commenter stated unique patient counts when aggregating across many certified health IT instances would require significant burden and cost to deduplicate across customer databases. The commenter requested that ONC either change to transaction-based counts or clarify that unique patient counts will be unique only within each instance of the certified health IT and can be duplicated across instances.

Response. We thank the commenter for this input, and as noted in the individuals' access to EHI measurement area section in this preamble, we have revised our definition of unique patient counts so that counts would only be unique within each instance of the certified health IT. We recognize the potential difficulty of de-duplicating unique patients across more than one instance of a certified health IT and clarify that the patient counts should be unique within the instance and can be duplicative across instances.

3. Insights Condition and Maintenance of Certification—Requirements

As stated in the HTI–1 Proposed Rule (88 FR 23843), the Cures Act specifies that a health IT developer be required, as a Condition and Maintenance of Certification requirement under the Program, to submit responses to reporting criteria in accordance with the “Electronic Health Record Reporting Program” established under section 3009A of the PHSA, as added by the Cures Act, with respect to all certified technology offered by such developer. We proposed to implement the Cures Act “Electronic Health Reporting Program” Condition and Maintenance of Certification requirements as the “Insights Condition and Maintenance of Certification” (Insights Condition) requirements in § 170.407. As a Condition of Certification, we proposed that developers of certified health IT would submit responses to comply with the Insights Condition's requirements, described in this section of the preamble in relation to the Insights Condition's measures and associated certification criteria.

Comments. A number of health IT developers expressed concern about the burden that collecting and reporting measures for the Insights Condition will impose on health IT developers. A commenter stated that developing Insights Condition measures overlaps and competes with health IT developers' other priorities, including CMS' digital quality initiative and user requested analytics. One commenter expressed concern that the requirements would introduce barriers to market entry and reduce competition. However, one health IT developer commented that they do not believe that the Insights Condition presents a significant regulatory burden, as the measure data can be collected and reported using currently widespread technologies.

Relatedly, many commenters, including health IT developers, developer associations, and health systems, opposed the overall number and type of measures proposed in § 170.407 for the Insights Condition. Commenters suggested reducing the number and complexity of measures to reduce burden and improve feasibility for developers of certified health IT and their customers. Commenters stated the number of measures is higher than described due to the multiple numerators and denominators. Commenters recommended ONC remove the list of expected metrics or ratios and focus only on the individual data elements to be collected and reported. Some commenters suggested 10 or fewer counts as a starting point. One commenter indicated that there were duplicate measures in the set that should be combined or harmonized. One commenter recommended that ONC select measures that are well-defined and targeted, and designed not to heavily burden health IT system resources when collecting data. Commenters also suggested gradually increasing the number of measures over several years.

Response. We appreciate the concerns expressed for the potential burden imposed on health IT developers to report the Insight Condition measures. We emphasize the Insights Condition fulfills the Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (EHR) Reporting Program to provide transparent reporting on certified health IT.

We believe this final rule will address information gaps in the health IT marketplace and provide useful insights on certified health IT use while minimizing implementation burden on health IT developers. Our final rule includes multiple revisions to our proposals, described in greater detail throughout this section of the preamble under their respective sections, that are intended to minimize the burden on health IT developers in implementing the Insights Condition. In sum, for this final rule, we have:

• Delayed the submission of the first phase of measures and related metrics to July 2027 to allow health IT developers adequate time to develop and implement the measures.
• Established a more incremental approach for implementing the measures over a longer timeframe (three years), including phasing in more complex aspects of the measures. Extending the time frame will allow developers to work on other priorities, such as CMS' digital quality initiative and user requested analytics, and not have to exclusively focus on developing Insights Condition measures.
• Not finalized two proposed measures (“electronic health information export through certified health IT” and “C–CDA documents obtained using certified health IT by exchange mechanism”).
• Addressed potentially duplicate metrics to make it easier to understand the total number of unique metrics that are required. For example, the same encounter-related metrics were previously listed in the patient access, immunization, and clinical exchange measure specification. Those metrics are now only listed in the clinical exchange section and measure specification.
• Reduced the frequency of measure reporting from semiannual to annual, and changed the submission date for more convenience to health IT developers.
• Provided an alternative reporting approach for health IT developers who are not able to report on their entire customer base due to contractual reasons. This should limit the need to renegotiate contracts for the sole reason of complying with the Insights Condition requirements addressing a major source of burden. This approach is described below in section III.F.4 of this final rule.
• Supported health IT developers who choose to use their Insights Condition measurements and data as part of their Real World Testing plans and results, thus reducing the need to generate separate data for both Conditions of Certification.
• Replaced the terms numerators and denominators, which caused confusion from commenters, with lists of metrics within each measure that health IT developers will be required to report, and limited stratification of measures.
• Consolidated the required Insights Condition measures and related metrics into the table that is located later in this section of the preamble.

We do not believe that the Insights Condition introduces a barrier to market entry. The minimum reporting qualifications we proposed and have subsequently finalized further below in this preamble are designed to ensure that small and startup developers are not unduly disadvantaged by the Insights Condition requirements. Further, the availability of information on what capabilities are widely available or lacking in the marketplace may encourage new entrants to provide needed technologies.

Comments. Several commenters raised concerns that customers of health IT developers will perceive burden and lack incentives that would impact their willingness to allow access to data for health IT developers to report in order to comply with the Insights Condition requirements. A few commenters encouraged ONC to coordinate with CMS on ways to provide insights on EHI access, exchange, and use while reducing physician burden related to requirements for the Insights Condition and the CMS Promoting Interoperability Programs.

Several commenters suggested ONC collaborate with CMS to adopt regulatory requirements to promote customers of health IT developers to agree to allow data from their systems to be used for the Insights Condition. One medical professional society commenter suggested that ONC coordinate with CMS and use the Insights Condition data and metrics to augment CMS physician reporting requirements. Further, the commenter stated the goals of reducing physician reporting burden and providing CMS and ONC insight into EHI access, exchange, or use can be jointly achieved by allowing physicians to attest to meeting CMS reporting requirements, rather than reporting a numerator-denominator, supplemented by health IT developers reported data under the Insights Condition. One commenter stated that attestations exist for agreeing to cooperate with ONC–ACB surveillance activities as a precedent for such an attestation requirement.

Response. We appreciate the suggestion for ONC to collaborate with CMS. We recognize that health care providers in certain CMS programs were expected to attest to cooperate in “good faith” with both ONC–ACB surveillance activities and ONC Direct Reviews. We will explore potential opportunities with CMS to encourage support for the Insights Condition among hospitals, physicians and other healthcare professionals that participate in CMS programs. We will also explore potential opportunities with CMS on ways to reduce burden on physicians and other health care providers related to reporting requirements. We will continue to coordinate and work with CMS on points of intersection for potential future rulemaking.

Comments. Several commenters expressed concern that the Insights Condition reporting requirements will lead to increased burden or frustration for health care providers and health care provider organizations and encouraged ONC to consider the impacts of Insights Condition reporting by health IT developers on their customers. Commenters also expressed concerns that health IT developers will `pass on' the burden of reporting to end users ( i.e., health care providers), who will end up being required to assist their developers of certified health IT in collecting data or creating reports for the Insights Condition. Some commenters indicated that health care providers and health care provider organizations are already overburdened with reporting requirements. One commenter expressed concern about creating any additional direct or indirect reporting burden for rural and underserved health care providers. A few commenters suggested to reduce health care provider burden by making healthcare organization participation and data contribution optional and avoid selecting measures that will require mapping of data by the healthcare organization staff. One advocacy organization and a health system expressed support for ONC efforts to establish the Insights Condition and encouraged ONC to minimize its administrative burdens.

Response. We appreciate the concerns expressed by commenters and aims to minimize burden on customers of developers of certified health IT related to the Insights Condition. We emphasize that developers of certified health IT are responsible for reporting the Insights Condition measures, and that health care providers, including health care providers who provide care to rural and underserved populations, are not responsible for reporting under the Insights Condition.

We have sought to design the measures so they would not require providers to separately collect data outside of their normal activities as part of delivering care or create reports to assist developers of certified health IT for the Insights Condition measures. The measures are designed to come from system-generated data and not involve additional effort by health care providers. We believe that, using widely available database technology, health IT developers should be able to collect data required for reporting under the Insights Condition without significant end-user burden. As noted in the clinical care information exchange measurement area of the preamble, we did not adopt the “C–CDA documents obtained using certified health IT by exchange mechanism” measure, partly because it was identified as potentially requiring mapping of data at the healthcare organization level.

We describe earlier in this section of the preamble the multiple changes to our proposals that are intended to minimize the burden on health IT developers in implementing the Insights Condition. These changes to our proposals are also intended to minimize the burden on customers of health IT developers. We believe this final rule includes several changes to our proposals that significantly reduce potential indirect burden on users ( i.e., health care providers) of certified health IT. As noted earlier, we provide health IT developers with an alternative reporting option if they are unable to report on all their customers due to contractual reasons.

Comments. One health system expressed support for the Insights Condition and requested clarification on how health IT developers will have access to the information in locally installed systems to complete the reporting while maintaining appropriate confidentiality.

Response. We appreciate this comment. We expect that confidentiality would already be addressed in existing contracts or business agreements between the health IT developer and their customers. Health IT developers will not submit protected health information or personally identifiable information to ONC under the Insights Condition. The data that we are requiring health IT developer to report is aggregated at the product level and is not at the health care provider or patient level.

Comments. Several commenters were supportive of the measures in general, but recommended restructuring the measures as a single set, in table format identifying the associated certification criteria, with numerator/denominator pair as its own row. Some commenters provided a sample format for our consideration.

Response. We thank commenters for their feedback. We have taken a more streamlined approach to categorizing, describing, and displaying the measures under the Insights Condition. We also refer readers to the HTI–1 Proposed Rule (88 FR 23831) for detailed background and history of the proposed measures as each measure description includes statements on the intent of the measure. For example, in the HTI–1 Proposed Rule (88 FR 23834), we specified under the “individuals' access to electronic health information supported by certified API technology” (now finalized as the “individuals' access to electronic health information through certified health IT”) measure that we believe this measure would provide a national view into how individuals access their EHI and would inform ONC and health IT community efforts to empower individuals with access to their EHI.

We provide the table below to define the updated metrics that health IT developers are required to provide to ONC at the product level. The table identifies the metrics a health IT developer is required to report based on the certification criterion to which the health IT developer certifies. We reiterate that the health IT developer is responsible for providing and aggregating the data for each applicable “metric” at the product level. The table reflects the metrics that have been modified in some cases based on public comment and described in more detail below. We clarify that “year 1” refers to the first implementation year of the Insights Condition. Data collection during “year 1” starts in calendar year 2026 (January 1st, 2026–December 31st, 2026), with responses due in July 2027. Reporting is on an annual basis thereafter. The measures designated with “year 2” will begin data collection calendar year 2027, with responses due in July 2028 (and annually thereafter). The “year 3” measures start data collection in calendar year 2028, with responses due July 2029 (and annually thereafter). The reporting period for each of the measures below consists of one calendar year. Please refer to the measure specifications for details on the metrics, including definitions.

Comments. One commenter noted that ONC only proposed Insights Condition measures for the interoperability category. The commenter further noted that the Cures Act included other categories, including usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. The commenter encouraged ONC to focus on these additional areas for future measure development for the Insights Condition.

Response. We thank the commenter for their encouragement to consider other areas for future measure development. As described in our HTI–1 Proposed Rule (88 FR 23832), we intend for this first set of measures to provide insights on the interoperability category specified in the Cures Act. We intend to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future rulemaking.

Comments. One commenter stated that Conditions and Maintenance of Certification requirements including the Insights Condition should actively seek to identify bias and prevent use of algorithms that may cause discrimination against patients.

Response. We appreciate this suggestion and will consider ways that the Conditions and Maintenance of Certification requirements can help reduce bias and prevent harmful use of algorithms in patient care. We note that this final rule includes requirements that aim to introduce information transparency about Predictive DSIs supplied by health IT developers as part of their certified Health IT Modules, so that potential users have sufficient information about how a Predictive DSI was designed, developed, trained, and evaluated to determine whether it is trustworthy, including evaluation of fairness or bias. We refer readers to section III.C.5 (Decision Support Interventions and Predictive Models) of this final rule.

Comments. One commenter questioned whether ONC could get the information about some Insights Condition measures from existing sources.

Response. We appreciate this comment. As described in our HTI–1 Proposed Rule (88 FR 23831), our approach for identifying measures for the Insights Condition included several considerations, including measures reflecting information that ONC cannot obtain without regulation and efforts that are not duplicative of other data collection. We will continue to consider ways to reuse other data and reduce reporting burden while addressing information gaps in the health IT marketplace through the Insights Condition. Thus, the measures we finalized address an important gap in information that can help assess interoperability.

Cross-Cutting Requirements

In the HTI–1 Proposed Rule (88 FR 23832), we also proposed to apply certain requirements across multiple measures, including, but not limited to: (1) data submitted by health IT developers would be provided and aggregated at the product level (across versions); (2) health IT developers would provide documentation related to the data sources and methodology used to generate these measures; and (3) health IT developers may also submit descriptive or qualitative information to provide context as applicable.

We explained in the HTI–1 Proposed Rule (88 FR 23832) that overall, the documentation should help ensure the responses/data are interpreted correctly. Thus, the documentation related to the data sources and methodology would include the types of data sources used, how the measure was operationalized ( e.g., any specific definitions), any assumptions about the data collected, information on the providers or products that are included/excluded from the reported data, and a description about how the data was collected. As described earlier in the preamble, we would then use the measure data submitted by health IT developers to calculate the metrics ( e.g., percentages and other related statistics). Developers of certified health IT would submit this information to an independent entity, per statutory requirements in section 3009A(c) of the PHSA, as part of the implementation of the Insights Condition, which we discuss later in this section of the preamble.

Comments. Several commenters supported our proposal under the Insights Condition to require developers of certified health IT to report documentation used to generate each measure. Three commenters also supported the proposal for reporting optional documentation. One commenter favored requiring health IT developers to explicitly outline how they collect, aggregate, and analyze the data for the Insights Condition, including documentation on the assumptions made about the data and decisions made about the inclusion or exclusion of specific data and/or installations. Some commenters suggested that ONC establish consistent topics and categories for the required documentation submissions and requested having the option to keep the additional information submissions confidential. One commenter recommended that ONC prohibit developers from using trade secrets to prevent validation of reporting data. One commenter requested ONC define a clear and accessible pathway for public access to the Insights Condition data, as well as how identified issues will be mitigated by developers certified health IT. Further, the commenter noted that methodological transparency is essential to inform customers, regulators, and policymakers about what the Insights Condition was testing, how testing was performed, and what the reporting informs about achievement of interoperability objectives.

Response. We appreciate the feedback from commenters. We have finalized that developers of certified health IT are required under the Insights Condition to provide documentation related to the data sources and methodology used to generate these measures, and health IT developers may also submit descriptive or qualitative information to provide context as applicable. Later in this preamble, we also note that in accordance with the Cures Act, we intend to make responses (the metrics and required documentation) to the Insights Condition publicly available on our website. The metrics and required documentation will provide methodological transparency and enable assessing progress related to interoperability as requested by commenters.

We require that health IT developers, as part of their responses, will provide documentation used to generate the measures for more accurate and complete data calculation. As we stated in the HTI–1 Proposed Rule (88 FR 23832), the documentation should help ensure the data are interpreted correctly. Therefore, the documentation related to the data sources and methodology should include the types of data sources used, how the measure was operationalized ( e.g., any specific definitions), any assumptions about the data collected, information on the health care providers or products that are included/excluded from the metrics, and a description about how the data was collected. We intend to make the required documentation provided by health IT developers publicly available for the purposes of transparency and to allow interested parties to understand and interpret the data.

We do not anticipate that health IT developers will need to share any information they consider proprietary, trade secret, or confidential information for the required documentation related to the Insights Condition. The documentation identified above does not specifically require the disclosure of proprietary, trade secret, or confidential information. Health IT developers should be able to report without the sharing of any such information. If health IT developers wish to provide additional information as part of the optional documentation, we strongly encourage them to not include any proprietary, trade secret, or confidential information in their submission. Further, we intend to provide a method for health IT developers to first indicate whether they plan to share proprietary, trade secret, and/or confidential information for purposes of either required or optional documentation. If a health IT developer provides an affirmative indication, ONC will engage the developer in dialogue about potential alternative means of meeting either required documentation requirements or providing optional documentation ( e.g., in other generalized or descriptive ways that may achieve the same goal). As we noted in the Enhanced Oversight and Accountability (EOA) Final Rule (81 FR 72429), we will implement appropriate safeguards to ensure, to the extent permissible under federal law, that any proprietary business information or trade secrets that are disclosed by the health IT developer in its documentation would be kept confidential by ONC.

We also refer readers to section III.F.4 of this final rule where we describe how we intend for health IT developers to submit the metrics and related documentation electronically using a web-based form, which will provide templates that enable submitting the data to ONC in a structured, electronic format such as comma-separated values (CSV) or JavaScript Object Notation (JSON) for this purpose. For questions and comments that may arise in reviewing the results and supporting documentation, we encourage the public to follow the Certified Health IT Complaint Process described at: https://www.healthit.gov/topic/certified-health-it-complaint-process.

Comments. The majority of commenters opposed our proposal that developers of certified health IT report measures aggregated at the product level, across product versions. Several commenters recommended that ONC adopt a flexible approach where health IT developers can report either at the product or developer level with an attestation to indicate which level the health IT developer reported. Commenters noted that this level of flexibility is consistent with the Real World Testing Condition.

Some commenters stated that health IT developers with integrated products or platforms are not able to differentiate certain Insights Condition measures per product as proposed, making product level reporting impossible. In this circumstance, one action would be counted under multiple products. One commenter recommended reporting be permitted at the integrated database level instead of the product level to make reporting feasible. One commenter recommended reporting at the developer level to avoid duplicate counting. One commenter stated health IT developers with both cloud and non-cloud-based products would have problems aggregating data for reporting. Several commenters opposed any reporting at a level lower than a certified Health IT Module.

Three commenters requested reporting that is more granular, at the product version level. Commenters stated product version level reporting would better support health care provider and healthcare organization evaluation and comparison of health IT capabilities.

Response. We thank commenters for their feedback and acknowledge the variety of perspectives on this requirement. We have maintained and finalized in § 170.407(a)(1)(i)(A) that data submitted by health IT developers would need to be provided and aggregated at the product level (across versions). However, we recognize that integrated products, which serve multiple settings or support multiple CHPL ID products, will not be able to differentiate between the settings or CHPL IDs when reporting on the measures. This could result in either double-counting or only reporting for one product. To address this issue, we have revised our requirement, related to integrated products, so that integrated products will only have to report one response for two or more products that are integrated. The web-based form and templates will allow for health IT developers to identify as submitting on behalf of an integrated product and to provide the associated CHPL IDs with the response.

We believe that product level data would provide insights on how performance on the measures vary by market ( e.g., inpatient, outpatients, specialty) and by capabilities of products, whereas this type of insight would not be available at the developer level. A product level focus is also aligned with other Program reporting requirements that allow for product level reporting, such as the Real World Testing Condition and Maintenance of Certification (85 FR 25765).

In considering alternatives, such as proposing to require health IT developers to report measures at the health IT developer level or at the most granular level of product version/CHPL ID, we concluded that proposing to require data to be reported at the health IT developer level is unlikely to reduce burden given that data would still need to be obtained from each applicable product and then aggregated. We also concluded that proposing to require reporting at the product version/CHPL ID level could significantly increase burden because developers of certified health IT would need separate reports for each version of their products. A flexible approach with a mix of data at the developer and product levels does not allow for a consistent analysis and reporting across health IT developers.

Minimum Reporting Qualifications

As required by section 3009A(a)(3)(C) of the PHSA, ONC worked with an independent entity, the Urban Institute, to develop measure concepts for the Insights Condition that would not unduly disadvantage small and startup developers. For detailed background, we refer readers to the HTI–1 Proposed Rule (88 FR 23843). Additionally, we proposed (88 FR 23844) to implement the Insights Condition requirements in a way that does not unduly disadvantage small and startup developers of certified health IT. We proposed (88 FR 23844) to establish minimum reporting qualifications that a developer of certified health IT must meet to report on the measure. Developers of certified health IT who do not meet the minimum reporting qualifications (as specified under each measure), would submit a response to specify that they do not meet the minimum reporting qualifications under the Insights Condition measure. In this way, all developers of certified health IT would report on all measures, even if some report that they do not meet the minimum reporting qualifications.

In the HTI–1 Proposed Rule (88 FR 23844), we proposed that the minimum reporting qualifications include whether a health IT developer has any applicable Health IT Modules certified to criteria associated with the measure, and whether the developer has at least 50 hospital users or 500 clinician users across its certified health IT products, which serves as a proxy for its size or maturation status ( e.g., whether it is a startup) and refer readers to the HTI–1 Proposed Rule for details on how we determined the proposed thresholds for health IT developers (88 FR 23845).

We proposed (88 FR 23844) that if a developer of certified health IT does not meet these minimum reporting qualifications, it would be required to submit a response that it does not meet the minimum reporting qualifications on specific measures for a given Health IT Module(s) subject to the Insights Condition requirements. In addition, we proposed (88 FR 23844) that if a health IT developer does not have at least one product that meets the applicable certification criteria specified in the measure requirements, or a developer of certified health IT that is certified to the criterion or criteria specified in the applicable measure during the reporting period but does not have any users using the functionality, the developer would still be required to submit a response that it does not meet the applicable certification criteria or the number of users required to report on the measure.

Comments. Several commenters supported our proposal to establish minimum reporting qualifications that a developer of certified health IT must meet to report on each measure. However, commenters stated that minimum reporting qualification would be more appropriate at the product level instead of at the developer level. Commenters recommended ONC maintain the proposed minimum reporting qualifications and apply those qualifications to individual products. One commenter recommended applying the thresholds at the product version level.

Response. We appreciate the interest expressed in applying the minimum reporting qualifications at the product or product version levels. However, we believe applying minimum reporting qualifications at the developer level adequately addresses the Cures Act requirement for the Insights Condition to not unduly disadvantage small and startup health IT developers. Applying minimum reporting qualifications at the product or product version levels could result in missing valuable data related to the use of certain certified health IT products.

Comments. Commenters made a few requests for clarification on the minimum reporting qualifications. One commenter indicated that our minimum reporting qualifications are ambiguous and asked ONC to clarify if the minimum reporting qualification is “50 users in a hospital” or “50 hospital sites that have users.”

Response. We thank commenters for their input. We have finalized the minimum reporting qualification in § 170.407(a)(2) to be at least 50 hospital sites or 500 individual clinician users across the developer's certified health IT. We note that the 50 hospital sites threshold is applicable to health IT modules used in inpatient or emergency department settings, while the 500 individual clinician users threshold is applicable to health IT modules used in outpatient/ambulatory settings (non-inpatient).

Comments. One commenter expressed that requiring health IT developers attest to not having technology certified to a given criterion for purposes of not reporting data for a specific Insights Condition measure was redundant since ONC maintains the list of certified health IT products.

Response. The Cures Act requires that all developers of certified health IT report on all Insights Condition measures. We believe this attestation process provides for compliance with that requirement in the simplest way.

Comments. One commenter requested that the definition of “developer” be more specific to include the actual architects and engineers of the software itself. The commenter questioned if the current definition of “developer” could also be interpreted to include organizations that provide certified health IT access for practices/clinicians under MSSP agreements. Further, the commenter noted these healthcare organizations would not have resources to comply with the Insights Condition.

Response. The Conditions and Maintenance of Certification requirements in subpart D of 45 CFR part 170 apply to developers participating in the Program (see 45 CFR 170.400). Therefore, the finalized “Insights Condition and Maintenance of Certification” requirements (codified in § 170.407) apply to developers participating in the Program that meet minimum reporting qualifications. Although we discuss the finalized “offer health IT” and updated “health IT developer of certified health IT” definitions for purposes of the information blocking regulations (45 CFR part 171), as discussed in sections IV.B.1 and IV.B.2 of this preamble, this commenter's request is out of scope for this final rule since we did not propose a definition in the HTI–1 Proposed Rule, and there is no codified definition of “developer” specific to the Program regulations in 45 CFR part 170 at this time.

4. Insights Condition and Maintenance of Certification—Process for Reporting

We proposed (88 FR 23846) in § 170.407(b)(1) that, as a Maintenance of Certification requirement for the Insights Condition, developers of certified health IT would need to submit responses every six months ( i.e., two times per year) for any applicable certified Health IT Module(s) that have or have had an active certification at any time under the Program during the prior six months. We also proposed to provide developers of certified health IT with ample time to collect, assemble, and submit their data. We proposed (88 FR 23846) that developers of certified health IT would be able to provide their submissions within a designated 30-day window, twice a year. Developers of certified health IT would begin collecting their data twelve months prior to the first 30-day submission window. The first six months of this period would be the period that developers of certified health IT would report on for the first 30-day submission window. Developers of certified health IT would then have the next six months to assemble this data for reporting. During the second six months of this period, developers of certified health IT would begin collecting data for the next 30-day submission window and so on. We refer readers to the example we provided in the HTI–1 Proposed Rule (88 FR 23846).

We proposed (88 FR 23847) in § 170.407(b)(1)(i) that a developer of certified health IT must provide responses beginning April 2025 for the following measures: (1) individuals' access to electronic health information; (2) applications supported through certified health IT; (3) immunization administrations electronically submitted to an immunization information system through certified health IT; and (4) immunization history and forecasts. We proposed (88 FR 23847) in § 170.407(b)(1)(ii) that a developer of certified health IT must provide responses beginning April 2026 for the remaining measures: (1) C–CDA documents obtained using certified health IT by exchange mechanism; (2) C–CDA medications, allergies, and problems reconciliation and incorporation using certified health IT; (3) use of FHIR in apps supported by certified API technology; (4) use of FHIR bulk data access through certified health IT; and (5) electronic health information export through certified health IT. For further discussion regarding our rationale for these proposals, we refer readers to the HTI–1 Proposed Rule (88 FR 23847).

We welcomed comments on our proposed approach, as well as the proposed frequency of reporting, other frequencies of reporting such as more or less frequent, and any additional burdens that should be considered for developers of certified health IT to meet the proposed “Insights Condition and Maintenance of Certification” requirements.

We also noted in the HTI–1 Proposed Rule (88 FR 23847) that there may be other factors that could impact a developer of certified health IT's ability to easily collect data to comply with the Insights Condition's requirements. For example, a developer of certified health IT may have contracts or business agreements that inhibit the health IT developer's ability to collect data from its customers. We noted that in such scenarios, developers of certified health IT would need to renegotiate their contracts if we finalized our proposals. We explained that we expected developers of certified health IT would work to mitigate any issues and provisions affecting their ability to comply with this Condition and Maintenance of Certification requirement. Therefore, a developer of certified health IT that is required to meet the Insights Condition's requirements must submit responses or may be subject to ONC direct review of the Conditions and Maintenance of Certification requirements, corrective action, and enforcement procedures under the Program. We welcomed comments on our approach, as well as any specific hardships certified health IT may encounter with the Insights Condition of Certification.

We proposed (88 FR 23847) that responses to the Insights Condition would occur via web-based form and method, consistent with the requirements in § 3009A(c) of the PHSA. We noted that under the statute, developers of certified health IT must report to an “independent entit[y]” to “collect the information required to be reported in accordance with the criteria established.” We intend to award a grant, contract, or other agreement to an independent entity as part of the implementation of the Insights Condition and will provide additional details through subsequent information. We stated that we intend to make responses publicly available via an ONC website, and we intend to provide developers of certified health IT the opportunity to submit qualitative notes that would enable them to explain findings and provide additional context and feedback regarding their submissions.

Further, we proposed (88 FR 23847) a new Principle of Proper Conduct for ONC-Authorized Certification Bodies (ONC–ACBs) in § 170.523(u) that would require ONC–ACBs to confirm that applicable developers of certified health IT have submitted their responses for the Insights Condition of Certification requirements in accordance with our proposals. We stated an expectation that the ONC–ACBs would confirm whether or not the applicable health IT developers submitted responses for the Insights Condition of Certification requirements within the compliance schedule. The intent of this responsibility is not to duplicate the work of the independent entity in collecting and reviewing the response submissions. Rather, it is meant to support the ONC–ACBs' other responsibility in § 170.550(l) to ensure that developers of certified health IT are meeting their responsibilities under the Conditions and Maintenance of Certification requirements before issuing a certification.

Comments. Many commenters, including developers of certified health IT, opposed our expectation related to § 170.407(b)(1) in the HTI–1 Proposed Rule (88 FR 23847) that health IT developers would need to renegotiate their contracts or business agreements that inhibit their ability to collect data from their customers in order to comply with this requirement. Commenters stated that this expectation to renegotiate contracts or business agreements was unreasonable, not feasible, or overly burdensome.

Two commenters questioned the authority of ONC to require developers of certified health IT to renegotiate contracts or business agreements in order to gain access to customer data for the Insights Condition. Two developers of certified health IT commented that they experienced challenges in soliciting participation from customers in data collection for the Real World Testing Condition despite their efforts. One commenter noted that it is not feasible to require a renegotiation of client contracts specific to only one term without reopening renegotiation of all contract terms. One commenter stated the amount of time that finding, assessing, negotiating, and re-finalizing a contract is unreasonable in the proposed timeframe.

Several developers of certified health IT commented that ONC should require a good faith effort by developers to engage their customers to participate. Also, commenters suggested ONC include language in the Insights Condition that allows for exclusions or other flexibilities from reporting where health IT developers have been unable to obtain data for measures despite good faith efforts.

Several developers of certified health IT further commented that establishing a minimum threshold of customers is not a viable way to address their concerns. One developer of certified health IT commented that ONC should set the expectation that health IT developers request participation in data collection under the Insights Condition from all of their U.S.-based customers of certified health IT and report all of the data from participants who agree, as well as what percentage of their total customers this represents. One commenter sought clarification from ONC on whether there is an expectation that developers of certified health IT obtain numerator and denominator data from every U.S. customer using a product or only those customers agreeing to participate.

One commenter noted that time and cost estimates were not included in the Regulatory Impact Analysis for effort necessary from developers of certified health IT, or health systems, for contract renegotiation expectations related to § 170.407(b)(1). The commenter further noted that effort from both health IT developers and health systems would be necessary for each renegotiated contract.

Response. We appreciate the commenters' concerns regarding the feasibility of requiring developers of certified health IT to renegotiate contracts, when needed, with their customers to comply with the Insights Condition requirements. In response to public comment, we have removed this proposed requirement. In a scenario where a developer of certified health IT has contracts or business agreements with a customer that inhibit the health IT developer's ability to comply with the Insights Condition requirements, the health IT developer may exclude that customer's data for reporting under the Insights Condition.

In § 170.407(b)(1) in the HTI–1 Proposed Rule (88 FR 23847) we proposed that health IT developers provide us metrics based upon data from all their customers. In response to health IT developers expressing concerns regarding the difficulty in obtaining data from clients whose contracts would require updating to access the needed data, we have scaled back our requirement for health IT developers to provide complete data on all clients. In addition to the data on available clients that they report, health IT developers will provide ONC with information on the degree to which the data they are submitting is complete. We emphasize that the Insights Condition fulfills the Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (EHR) Reporting Program to provide transparent reporting on certified health IT with respect to all certified technology offered by a health IT developer, and therefore, health IT developers should be as inclusive as possible.

Based upon the suggestion we received via comments, we have finalized in § 170.407(a)(1)(i)(C) that health IT developers will report the percentage of their total customers, as represented by hospitals for inpatient products and clinician users for their outpatient products, that are included in their reported data for each metric for which they submit a response. The percentage of health care providers that are represented in the data provides transparency on the degree to which the data are complete. Specifically, we seek to determine whether the aggregated data that we receive from all health IT developers will produce nationally representative measures will be critical to generate and report the derived statistics and explain the results. For example, if the percentage of total customers represented is low across many health IT developers, then we would know that the data are incomplete. This in turn, would enable ONC to consider whether it would be valid to generate statistics at the national level. Overall, this information shall help ONC interpret the results and allow us to assess the degree to which the data are complete.

Comments. Many commenters opposed our proposal in § 170.407(b)(1)(i) for the first Insights Condition reporting period to begin in April 2024. Some commenters stated the timeline was unrealistic, not feasible, or impossible given timeframes to develop, deploy, test, and build the capability to compile the data. Commenters offered various alternative timelines for the first Insights Condition reporting period to begin. Several commenters requested delaying the first reporting period to begin in calendar year 2025, such as in January, April, or October of 2025. Several commenters requested delaying the first reporting period to begin in calendar year 2026. Some commenters requested delaying the first reporting period to begin 18 months after the final rule publication. One commenter requested ONC reconsider implementation over a four- or five-year timeframe. One commenter suggested longer timelines to ensure measures are validated before phasing in new measures.

Response. We thank commenters for the feedback and have revised the Insights Condition timelines. We have finalized in § 170.407(b)(1)(i) to delay the first reporting period to allow developers of certified health IT adequate time to develop and implement the Insights Condition measures and related metrics. We have finalized that the first data collection period will be January to December 2026, followed by the submission of the first phase of measures and related metrics due in July of 2027. This represents “year one” of the Insights Condition requirements. Reporting is on an annual basis thereafter. We have further extended our phased approach to measure requirements, including layering complexity associated with certain measures over the course of three years, so that certain measures (and related metrics) start in year one, while other measures or stratifications to existing measures begin in subsequent years. We have finalized “year 2” measures and related metrics start data collection in calendar year 2027, with responses due in July 2028, and annually thereafter. Finally, we have finalized “year 3” measures and related metrics start data collection in calendar year 2028, with responses due in July 2029 and annually thereafter. The phasing of the measures and related metrics are illustrated in the table in this section of the preamble.

We also appreciate the commenter's concern for needing additional time to assess measure validity. Our revised approach of phasing in more complex aspects of each of the measures enables reviewing baseline measures before adding complexity. Furthermore, our revised approach provides additional time for measure development and implementation and will allow us to apply lessons learned from the smaller set of measures to inform the implementation of next set.

Comments. Most commenters opposed our proposal in § 170.407(b)(1) to require the frequency of semiannual ( i.e., every six months) data collection and reporting under the Insights Condition. Most commenters suggested an annual frequency of data collection and reporting to reduce burden. Many of these commenters suggested using a calendar-year reporting period with reporting to occur mid-year to better align with the CMS Promoting Interoperability Programs and the Real World Testing Condition, and to avoid other April/October requirements for Attestations submissions. One health system commenter suggested an annual reporting period that does not overlap with clinical quality measure reporting schedules. One commenter stated that semiannual reporting would require two product upgrades within a one-year timeframe and that their customers would not be willing to comply. Three commenters supported our proposal to require semiannual ( i.e., every six months) data collection and reporting in April and October. One health IT developer commented the proposed six-month intervals are feasible with current technology and not overly burdensome to health IT developers. Commenters supported our proposal in § 170.407(b)(1) for six months to assemble and assess data collected prior to reporting under the Insights Condition.

Response. We appreciate the feedback on reporting frequency and the concerns expressed related to burden. To address these concerns, we have finalized to reduce the reporting frequency to annually (once per year) in § 170.407(b), on a calendar year cycle, with data collection to be completed from January to December. We have maintained the six-month data assembly period, such that reports for a given calendar year will be due to be submitted in July of the following calendar year.

Comments. Many commenters requested clarification on whether developers of certified health IT have the flexibility to reuse the Insights Condition reporting measurements and outputs for their Real World Testing plans and results.

Response. We appreciate the commenters request for clarity. We appreciate that the data collected related to the Insights Condition and Real World Testing could overlap. Therefore, developers of certified health IT can choose to repurpose the Insights Condition reporting measurements and/or data as part of their Real World Testing plans and results.

Comments. One health IT developer suggested that ONC apply its experience with Real World Testing to reduce measure ambiguity and provide Real World Testing reports as examples for health IT developers to use in planning for the Insights Condition.

Response. We agree with the commenter that the Real World Testing Condition provides relevant experience for health IT developers. We considered Real World Testing Condition reports in developing our proposals for the Insights Condition and intend to provide examples. We plan to leverage a system linked to the CHPL for reporting to make the process similar to other certification related processes. We will use web-based forms within that system for submission and plan to provide templates for health IT developers to use in their data submission for the Insights Condition. The templates will enable health IT developers to submit the data (as noted in the 88 FR 23847) in a machine-readable format, such as JavaScript Object Notation (JSON). We also intend to provide educational sessions and resources for health IT developers to support electronic reporting of the metrics and related documentation.

Comments. Some commenters recommended that ONC expand its governance structure to include patients and other clinicians in reviewing Insights Condition and Real World Testing results to identify new opportunities for action.

Response. We thank the commenters for the input. As described in our HTI–1 Proposed Rule, ONC, and our contractor, conducted various engagement efforts with a variety of groups having potential interests in the Insights Condition. This engagement process included a request for information by ONC, public forums, listening sessions, and discussions with experts and key groups, including health IT end users ( e.g., clinicians) and health IT developers. In addition to this engagement and public comments, the Health IT Advisory Committee (HITAC), which includes patient advocates and clinicians, provided recommendations to ONC that informed the Insights Condition. We will continue to look for opportunities to obtain input from a variety of perspectives, including patients and clinicians, on the Insights Condition.

Comments. One health care provider organization recommended that ONC make the Insights Condition metrics easily accessible to users of certified health IT and to the public. One health IT developer sought clarification from ONC if we intend to calculate and display percentages using the reported numerators and denominators across the universe of certified health IT that reported for a given measure, or if we intend to calculate and display metrics at the developer or product level. Another commenter encouraged ONC and developers of certified health IT under the Insights Condition to evaluate measure reliability and validity of the reported data before publicly reporting.

Response. We thank the commenter for the opportunity to clarify how ONC will calculate and display the Insights Condition metrics. In accordance with the Cures Act, we intend to make responses (the metrics and required documentation) to the Insights Condition publicly available on an ONC website. Prior to publicly releasing the data or publishing metrics, we will review and analyze the data to assess completeness and generalizability, which relate to the reliability and validity of the data. After this analysis, we will determine what level(s) the calculated metrics would be displayed, such as at the product, developer and/or national level. The aggregated data that is reported needs to have an adequate number of data points at any given level to make sure the metrics displayed are valid and reliable.

Comments. One commenter recommended that ONC create a public list of the certification status of health IT developers.

Response. We thank the commenter for this input, and note that ONC maintains the Certified Health IT Products List (CHPL) at https://chpl.healthit.gov/, which is a comprehensive and authoritative listing of all certified health information technology that have been successfully tested and certified by the Program and includes current certification statuses.

Comments. One commenter suggested requiring health IT developers to report on whether the certified health IT is hosted by the health IT developer or installed locally under the direct control of the user. Further, the commenter noted that this information may provide insight into usage patterns and adoption of cloud services and other technology that can inform HHS regulations.

Response. We thank the commenter for this suggestion, and we agree that this data element could be useful and informative in assessing the state of the certified health IT marketplace. We may consider this for future rulemaking.

Comments. A commenter stated that ONC–ACBs will need more detailed information on the degree of surveillance and validation that ONC–ACBs will need to provide in support of the Insights Condition reporting process in order to plan appropriately.

Response. Similar to other Conditions and Maintenance of Certification requirements, we will provide additional guidance to ONC–ACBs regarding their role and requirements related to oversight of the Insights Condition as the workflow and reporting systems for the Insights Condition are developed and finalized.

G. Requests for Information

1. Laboratory Data Interoperability Request for Information

We sought public feedback in the HTI–1 Proposed Rule (88 FR 23848) that may be used to inform a study and report required by Division FF, Title II, Subtitle B, Ch. 2, Section 2213(b) of the Consolidated Appropriations Act, 2023 (Pub. L. 117–328, Dec. 29, 2022), or future rulemaking regarding the adoption of standards and certification criteria to advance laboratory data interoperability and exchange.

We sought public comment generally on any topics identified in the Consolidated Appropriations Act, 2023, Section 2213(b) study on the use of standards for electronic ordering and reporting of laboratory test results, such as the use of health IT standards by clinical laboratories, use of such standards by laboratories and their effect on the interoperability of laboratory data with public health systems, including any challenges of the types identified above. We also sought comment on whether ONC should adopt additional standards and laboratory-related certification criteria as part of the Program. We received many valuable comments on this RFI. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.

2. Request for Information on Pharmacy Interoperability Functionality Within the ONC Health IT Certification Program Including Real-Time Prescription Benefit Capabilities

Section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, (Pub. L. 116–260) (CAA), requires PDP sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. The law specified that a qualifying RTBT must meet technical standards named by the Secretary, in consultation with ONC. Section 119(b)(3) also amended the definition of a “qualified electronic health record” in section 3000(13) of the PHSA to specify that a qualified electronic health record must include or be capable of including an RTBT. In the 2014 Edition Final Rule, ONC established the term “Base EHR,” based on the “Qualified EHR” definition, for use within the Program (77 FR 54262).

As stated in the HTI–1 Proposed Rule (88 FR 23848), we intend to propose in future rulemaking the establishment of a real-time prescription benefit health IT certification criterion within the Program and include this criterion in the Base EHR definition in § 170.102. We intend to propose a criterion that would certify health IT to enable a provider to view within the electronic prescribing workflow at the point of care patient-specific benefit, estimated cost information, and viable alternatives. We are also considering a proposal to adopt and reference the National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit (RTPB) standard version 12 as part of the potential certification criterion. This standard would enable the exchange of patient eligibility, product coverage, and benefit financials for a chosen product and pharmacy, and identify coverage restrictions and alternatives when they exist.

While we believe that implementing RTBT functionality required for inclusion in the Program under the CAA would be an important step towards improving prescribing experiences for providers and patients, we recognize that it is only one of a series of capabilities that are part of a comprehensive workflow for evaluating and prescribing medications (88 FR 23849).

Today, the Program addresses these additional capabilities in a limited manner. For instance, in the ONC Cures Act Final Rule, ONC adopted NCPDP SCRIPT standard version 2017071 and updated the “electronic prescribing” certification criterion in § 170.315(b)(3)(ii) to reflect this standard, including specifying electronic prior authorization transactions supported by the standard as optional transactions, which health IT developers can elect to have explicitly tested, or not, as part of certification of a product to § 170.315(b)(3) (85 FR 25680).

A “drug-formulary and preferred drug list checks” certification criterion had been established for the 2015 Edition in § 170.315(a)(10) but was later removed from the Program by the ONC Cures Act Final Rule (85 FR 25660). ONC removed the criterion due to the lack of associated interoperability standards and to reduce certification burden on developers as this functionality had been widely adopted across industry.

We requested comment in the HTI–1 Proposed Rule (88 FR 23849) from the public about specific issues related to establishing a certification criterion using NCPDP RTPB standard version 12 and other potential actions that could support complementary and interoperable workflows. Given the statutory definition in PHSA § 3000(13) of “qualified electronic health record” as an electronic record of health-related information on an individual that includes, or is capable of including, RTBT functionality, we sought to understand whether ONC should offer or require certification of other capabilities to optimize the value of real-time prescription benefit capabilities to clinicians and patients.

We requested input on how developers of certified health IT may be able to support drug price transparency, patient choice, and meet other market demands while ensuring reliable and trusted performance. We received many insightful comments on this RFI. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.

3. FHIR Standard

This request for information included in the HTI–1 Proposed Rule (88 FR 23855) focused on the FHIR standard for APIs (including FHIR Subscriptions, CDS Hooks, FHIR standards for scheduling, and SMART Health Links) and aligned with our aims of advancing interoperability through the use of APIs for treatment, payment and operations use cases. We welcomed technical and policy comments as we consider the potential applicability of these standards and specifications. We received many insightful comments on this RFI. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.

IV. Information Blocking Enhancements

In the HTI–1 Proposed Rule (88 FR 23746), we proposed enhancements to support information sharing under the information blocking regulations and to promote innovation and competition, as well as address market consolidation ( see Executive Summary discussion at 88 FR 23749 and 88 FR 23754 through 23755; see also preamble discussion in section IV of the HTI–1 Proposed Rule at 88 FR 23857 through 23873). We proposed new and revised definitions of terms for purposes of the information blocking regulations in 45 CFR part 171. The revisions to definitions included, as discussed in section IV.B.3, the removal of references to a period of time now passed in the information blocking definition (§ 171.103). We proposed (as discussed in IV.B.3 of this preamble) to remove reference to the period of time, now passed, from the exception in 45 CFR 171.301. We proposed, consequently, to rename the “Content and Manner Exception” to simply the “Manner Exception.” Each of these proposals is discussed, and public comments received on each proposal summarized, in section IV.B of this preamble.

We proposed enhancements to certain information blocking exceptions that had been established by the ONC Cures Act Final Rule (85 FR 25642). We proposed to clarify the uncontrollable events condition of the Infeasibility Exception (§ 171.204) to make it clear that an uncontrollable event must in fact have affected the actor's ability to fulfill requests for access, exchange, or use of EHI (for a more detailed summary, please see section IV.C.1.a of this preamble). We also proposed to create new conditions for (options through which to satisfy) the Infeasibility Exception when an actor has exhausted the § 171.301 Manner Exception and, separately, when a third party requests to modify EHI held by the actor. These conditions are discussed in sections IV.C.1.b and IV.C.1.c of this preamble. As discussed in section IV.C.2 of this preamble, we proposed to add a TEFCA manner condition to the proposed revised and renamed Manner Exception codified in 45 CFR 171.301 ( see88 FR 23872 through 23873).

The HTI–1 Proposed Rule included (at 88 FR 23873 through 88 FR 23876) three information blocking requests for information (RFIs). The first of these RFIs sought information on potential additional exclusions from the definition of “offer health IT.” The second sought information on possible additional TEFCA reasonable and necessary activities. The third sought information on health IT capabilities for data segmentation and user or patient access. We discuss these requests for information below, in section IV.D.1 through IV.D.3 of this preamble.

A. General Comments

Comments. In general, commenters expressed support for the proposed enhancements and for updating the regulations over time to improve clarity or reduce burdens for actors while continuing to encourage interoperable access, exchange, and use of EHI to the full extent permitted by applicable law and consistent with individual patients' privacy preferences. Some commenters made suggestions, recommendations, or requests for additional guidance, information and educational resources, or for other tools to help actors appropriately share information and avoid conduct that would be considered “information blocking” (as defined in 45 CFR 171.103).

Response. We appreciate the support expressed by many commenters. We include below additional explanation of provisions of this final rule. Requests, recommendations, or suggestions that we provide additional guidance, resources, or tools relevant to information blocking are appreciated. As part of our ongoing outreach and education efforts, all feedback and information we receive helps to inform our consideration and development of resources such as webinar presentations, fact sheets, and frequently asked questions (FAQs).

Comments. Several comments advocated for specific changes to the information blocking regulations, to other HHS regulations, or to state law. For example, a commenter advocated “aligning HIPAA rules, 42 CFR part 2 requirements, and other state and federal laws with information blocking regulations.” Another commenter stated that “ONC needs to clarify the national requirements for production of complete medical records, especially absolute transparency on corrections, deletions, delayed entries, and original content, upon ordinary request.” A commenter indicated health IT users may mis-apply the designated record set (DRS) definition to electronic records and stated that ONC “needs to consider discouraging inappropriate DRS definition-based information blocking of complete medical records through significant, powerful disincentives.” One commenter advocated for ONC to narrow the health information network definition “and clearly state in the regulatory text payers are not included in this definition and thus are not subject to the information blocking provision.” Another commenter expressed a view that specifying in the information blocking definition's regulatory text the persons whose records access can be affected by a practice would make the rule stronger.

Response. Comments related to the following are outside of the scope of the information blocking provisions of this rulemaking: establishment of health care provider disincentives for information blocking conduct; changes to HHS regulations outside 45 CFR part 171; adoption of requirements for creation or retention of specific metadata by all health care providers nationwide; and any change to any state or tribal law. However, comments recommending policy changes outside the scope of this rule are part of the rulemaking record, and we may refer to them as an information source when assessing potential future rulemaking or outreach and education activities.

Comments. A substantial number of comments expressed concerns about a perceived conflict between the goals of maximizing information sharing and appropriately protecting patients' privacy interests. These comments generally associated these concerns with specific policy recommendations, including the creation of new information blocking exception(s). Some commenters suggested that some § 171.102 actors may believe they have no option under information blocking regulations but to enable the access, exchange, or use of all EHI in all situations—including those where only some of the EHI can be used or disclosed consistent with privacy laws or the patient's individual privacy preferences. A few of these commenters specifically noted sensitive information or information associated with sensitive types of care, such as reproductive or behavioral health care.

Response. Some of the policy recommendations that commenters offered to address these concerns, such as to establish new exceptions or implement revisions beyond anything described in the HTI–1 Proposed Rule, were outside the scope of this rulemaking. Some provisions advocated by commenters appear to duplicate provisions already in place, such as provisions of the Privacy Exception (§ 171.202) and the Infeasibility Exception (§ 171.204). The expressed concerns and advocacy of duplicative policy provisions suggest it may be helpful to highlight here certain aspects of how the information blocking regulations currently operate.

Where applicable law prohibits a specific access, exchange, or use of information, the information blocking regulations consider the practice of complying with such laws to be “required by law.” Practices that are “required by law” are not considered “information blocking” ( see the statutory information blocking definition in section 3022(a)(1) of the PHSA and the discussion in the ONC Cures Act Final Rule at 85 FR 25794). For example, when the HIPAA Privacy Rule prohibits a covered entity or business associate from disclosing PHI, an actor who is also a covered entity or business associate can comply fully with the HIPAA Privacy Rule without implicating the information blocking regulations. For another example, a § 171.102 actor subject to a state or tribal law that expressly prohibits a certain access, exchange, or use of EHI can comply fully with that state or tribal law without implicating the information blocking regulations.

We recognize that even where federal, state, or tribal law does not expressly prohibit the actor from fulfilling a request to access, exchange, or use EHI, or require an actor to engage in particular privacy-protective practices, an actor may nevertheless wish to engage in practices likely to interfere with access, exchange, or use in order to honor their patients' privacy preferences. Actors covered by the information blocking regulations—health IT developers of certified health IT, health information networks or health information exchanges (HIN/HIEs), and health care providers—may seek certainty that the privacy-protective practices that are not required of them by law, but in which they choose to engage, will not meet the definition of information blocking.

In the ONC Cures Act Final Rule, we established the Privacy Exception (45 CFR 171.202) to ensure that actors can engage in reasonable and necessary practices that advance the privacy interests of individuals ( see85 FR 25845 through 25859) without committing “information blocking” as defined in section 3022(a)(1) of the PHSA and 45 CFR 171.103.

For example, the information blocking regulations in 45 CFR part 171 accommodate the fact that, in various circumstances, other applicable law (federal, state, or tribal) does not permit EHI to be used or disclosed unless certain preconditions are met. The Precondition Not Satisfied (45 CFR 171.202(b)) sub-exception of the Privacy Exception outlines a framework for actors to follow to be assured their practices of not fulfilling requests to access, exchange, or use EHI will not constitute information blocking when a precondition of applicable state, tribal, or federal law has not been satisfied.

In addition, for purposes of the Precondition Not Satisfied sub-exception, an actor operating under multiple state laws, or state and tribal laws, with inconsistent preconditions for EHI disclosures may choose to adopt uniform policies and procedures to address the more restrictive preconditions (45 CFR 171.202(b)(3)).

Examples that highlight the alignment between the HIPAA Privacy Rule and the information blocking regulations are included in the “HIPAA Privacy Rule and Disclosures of Information Relating to Reproductive Health Care” guidance issued by the Office for Civil Rights. As outlined in this guidance, there are certain preconditions that must be met before disclosures about reproductive health care can be made by health care provider workforce members, including to law enforcement officials. For instance, if a law enforcement official requests records of abortions from a reproductive health care clinic: “If the request is not accompanied by a court order or other mandate enforceable in a court of law, the Privacy Rule would not permit the clinic to disclose PHI in response to the request. Therefore, such a disclosure would be impermissible and constitute a breach of unsecured PHI requiring notification to HHS and the individual affected.” In this example, federal law does not permit the disclosure of EHI unless certain requirements are met, and therefore, the actor's practice not to disclose EHI would not be information blocking. We note that this is just one example of how the HIPAA Privacy Rule gives individuals confidence that their protected health information, including information relating to abortion and other sexual and reproductive health care, will be kept private. Please see the guidance from the Office for Civil Rights for additional information and examples.

We also note that information blocking regulations in 45 CFR part 171 accommodate an actor, if they so choose, agreeing to an individual's request for restrictions on sharing of the individual's EHI beyond the restrictions imposed by applicable law(s). Specifically, where the requirements specified in 45 CFR 171.202(e) are met, the Respecting an Individual's Request Not to Share Information (§ 171.202(e)) sub-exception of the Privacy Exception applies to an actor's practice of honoring an individual's request not to provide access, exchange, or use of the individual's EHI. This aligns with the individual's right to request a restriction on certain uses and disclosures of their PHI under the HIPAA Privacy Rule (45 CFR 164.522(a)(1)), to which an actor that is a covered entity may choose to agree but is not required by the HIPAA Privacy Rule to agree.

In scenarios where a § 171.102 actor that is also subject to the HIPAA Privacy Rule must agree to the request of an individual to restrict disclosure of PHI as provided in 45 CFR 164.522(a)(1)(vi), the actor's practice of agreeing to the request and complying with all requirements of 45 CFR 164.522 applicable to such requests and restrictions is, in our view, a practice that is “required by law.” We reiterate that practices that are required by law are excluded from the statutory (PHSA section 3022(a)(1)) as well as the regulatory (45 CFR 171.103) definition of information blocking without needing to also satisfy any of the 45 CFR part 171 exceptions. Therefore, when a § 171.102 actor that is also a HIPAA covered entity engages in a practice of complying with all requirements of 45 CFR 164.522 that are applicable to requests to which a covered entity must agree (as provided in 45 CFR 164.522(a)(1)(vi)) then that actor would not need to also satisfy the Respecting an Individual's Request Not to Share Information (45 CFR 171.202(e)) sub-exception of the Privacy Exception in order for that practice to not be considered information blocking. The practice would be excluded from the definition of information blocking because it would be “required by law” and, therefore, an information blocking exception for the practice would not be needed.

We refer commenters and other readers interested in learning more about the interaction of the information blocking regulations with the HIPAA Rules and other laws protecting individuals' privacy interests to the discussion of the Privacy Exception in the ONC Cures Act Final Rule (85 FR 25642, 85 FR 25845 through 25859). We also highlight the availability of additional resources through our website (start at: https://www.healthit.gov/topic/information-blocking ). Resources focused on how the information blocking rules work in harmony with privacy laws include, for example, an ONC Health IT buzz blog post titled “ Information Blocking Regulations Work in Concert with HIPAA Rules and Other Privacy Laws to Support Health Information Privacy ” and the following three frequently asked questions (FAQs) highlighting how information blocking regulations work in tandem with the HIPAA Privacy Rule and other privacy protective laws:

• Would it be information blocking if an actor does not fulfill a request to access, exchange, or use EHI in order to comply with federal privacy laws that require certain conditions to have been met prior to disclosure?

• If an actor, such as a health care provider, operates in more than one state, is it consistent with the information blocking regulations for the health care provider to implement practices to uniformly follow the state law that is the most privacy protective (more restrictive) across all the other states in which it operates?

• If an individual requests that their EHI not be disclosed, is it information blocking if an actor does not disclose the EHI based on the individual's request?

The Infeasibility Exception may also be applicable to matters of patient privacy preferences. Established by the ONC Cures Act Final Rule, the Infeasibility Exception (45 CFR 171.204) applies when an actor's practice meets one of the conditions set forth in § 171.204(a) and also meets the condition in § 171.204(b) ( see85 FR 25958, see also preamble discussion at 85 FR 25866 through 25870). The segmentation condition of the Infeasibility Exception (§ 171.204(a)(2)) can be met in conjunction with other exceptions to provide actors assurance that their practice does not constitute information blocking. The segmentation condition is applicable when the actor cannot fulfill the request for access, exchange, or use of EHI because the actor cannot unambiguously segment the requested EHI from EHI that:

• cannot be made available due to the individual's preference (such as where the individual has requested that the EHI not be shared with a specific person(s), for a specific purpose(s), or both);

• cannot be made available by law, for example, the HIPAA Privacy Rule, other federal law, or applicable state or tribal law does not permit the EHI to be made available to the person seeking it, for the purpose it is sought, or both; or
• may be withheld in accordance with the Preventing Harm Exception (45 CFR 171.201).

Applicable law may restrict providing certain types of EHI to a person or class of persons, for a specific purpose, or a combination of types of persons and specific purposes. For example, federal, state, or tribal law may require that certain information not be accessed, used, or exchanged by the person seeking it, for the purpose it is sought, or both. As we discuss above, an actor can, without engaging in “information blocking,” withhold information as required by law or withhold information by meeting the Pre-condition Not Satisfied sub-exception. Similarly, an individual ( see definition of “ individual ” in § 171.202(a)) may express a preference that some or all of the EHI for a particular patient not be shared with a specific person(s), for a specific purpose(s), or a specific combination of person(s) and purpose(s). Such a preference could be expressed, for example, by the individual making a request that a HIPAA covered entity restrict uses and disclosures of their PHI that § 164.522 requires covered entities to permit an individual to make. As we discuss above, and in accordance with the § 171.202(e) Respecting an Individual's Request Not to Share Information sub-exception, an actor may withhold information that a patient has requested the actor not share.

The example above illustrates a specific alignment between the information blocking regulations and HIPAA Privacy Rule. However, the § 171.202(e) sub-exception's alignment with the individual's right under the HIPAA Privacy Rule to request restrictions does not limit the sub-exception's availability to actors who are also subject to the HIPAA Privacy Rule's requirements. Nothing in the § 171.202(e) sub-exception limits its availability based on whether the actor is a HIPAA covered entity or business associate that must comply with the HIPAA Privacy Rule. Likewise, § 171.202(e) does not focus on whether the individual requested restrictions under any specific provision of the HIPAA Privacy Rule. Therefore, for purposes of the information blocking regulations, the § 171.202(e) Respecting an Individual's Request Not to Share Information sub-exception can be satisfied by any actor who chooses to meet the requirements of the sub-exception.

We recognize many actors may currently be unable to unambiguously segment reproductive health and behavioral health information indicated by some commenters on the information blocking provisions as sensitive information, as well as gender-affirming care information, from other EHI. These are also examples of types of information for which individuals may be likely to request restrictions on uses or disclosure. These are, however, not the only types of information to which the Infeasibility Exception's segmentation condition might apply. As we noted in the HTI–1 Proposed Rule, a health care provider might choose to honor a patient's request for restrictions on sharing of their EHI even if the provider did not know the patient's specific reasons for the request. The Respecting An Individual's Request Not To Share Information sub-exception (§ 171.202(e)) does not specify that the individual requesting restrictions should have particular reasons for requesting restrictions, or be required to share their reasoning with the health care provider or other actor of whom they make the request (88 FR 23874).

Where an actor engaging in a practice that is not (or practices that are not) fully covered by a single exception seeks certainty that such practices do not constitute information blocking, the actor could choose to satisfy several applicable exceptions that, in complement, do fully cover their practices. Applicable exceptions, and combinations of exceptions, will vary based on the actor's specific practice and particular facts and circumstances in which they engage and the practices for which the actor seeks the certainty offered by information blocking exceptions.

In various circumstances, an actor may wish to engage in one or more practice(s) that are covered in part, but not fully covered, by the Privacy Exception (§ 171.202) or the Preventing Harm Exception (§ 171.201). In some of these situations, such an actor may want to consider the potential certainty that could be available by satisfying a combination of the Infeasibility Exception (§ 171.204) with the Privacy Exception (§ 171.202) or with the Preventing Harm Exception (§ 171.201), or any combination of multiple exceptions applicable to the specific practice in which the actor engages. We provide the following example to illustrate how the use of a combination of exceptions might occur. We note that we have intentionally omitted from this example any consideration of why the individual may request, or why the actor may have chosen to agree to the individual's request. This is because the § 171.202(e) sub-exception's application is not limited based on what particular reasons an individual may have for requesting restrictions of any or all of their EHI, and does not specify that an actor must have specific reasons for choosing to grant rather than deny an individual's request for restrictions. However, as noted above, these exceptions could be exercised, separately or together, when an individual requests certain information ( e.g., reproductive health, behavioral health, or gender-affirming care information) not be shared or when such information cannot be unambiguously segmented from other EHI from the reasons noted above.

An individual makes a request of an actor not to share certain EHI. The actor agrees to the request, documents the request, implements the request, and does not otherwise terminate the request. After the actor agrees to the individual's request not to share information, the actor receives a request for the individual's EHI that encompasses information the individual requested that the actor not share. The actor determines that responding to the request is not prohibited by applicable law. The actor then determines that the actor has the technical ability to segment out some, but not all, of the requested EHI from the EHI subject to the individual's request not to share. The actor notifies the requestor in writing in 10 business days from the receipt of the request that the actor cannot unambiguously segment the EHI from the EHI that the actor cannot share for reasons consistent with the § 171.204(a)(2) segmentation condition. The actor provides the requestor with EHI the actor can unambiguously segment from the EHI that is subject to the individual's request, and the actor does not provide the requester with certain EHI that the actor cannot unambiguously segment from the EHI subject to the individual's request.

• For purposes of this example, the actor has two exceptions available. First, the actor has received an individual's request not to share information, elected to grant the individual's requested restriction on access, exchange, or use of EHI, and met the requirements of the § 171.202(e) Respecting an Individual's Request Not to Share Information sub-exception of the Privacy Exception. (Note: for purposes of the § 171.202(e) Respecting an Individual's Request Not to Share Information sub-exception, an actor (such as a health IT developer of certified health IT) who maintains or manages EHI on behalf of another entity (such as a health care provider) can rely on the other entity's practice that meets the sub-exception's requirements; the individual need not make a duplicative request for EHI sharing restrictions directly to the actor who is maintaining or managing EHI on behalf of the other entity.) Because the actor met the requirements of that sub-exception, the actor's practice of not providing the requested EHI that cannot be made available due to the individual's request would not constitute information blocking.

• Second, the actor cannot unambiguously segment certain EHI from the EHI that would not be made available due to the individual's request that the actor has agreed to honor. The Infeasibility Exception is satisfied by a practice that meets a condition in paragraph (a) of § 171.204, such as the segmentation condition (171.204(a)(2)) and the responding to requests condition in § 171.204(b). Meeting the § 171.204(b) condition does not require that an actor fulfill any EHI in response to any request but does require that the actor provide the requestor within 10 business days of receipt of the request, in writing, the reason(s) the request is infeasible. Thus, the actor in this example would satisfy the Infeasibility Exception for that portion of EHI that cannot be unambiguously segmented from EHI that cannot be made available due to the individual's request that the actor has agreed to honor. In this example, no other exceptions apply to the EHI that the actor can unambiguously segment from the EHI that cannot be shared because the actor has agreed to the individual's request not to share certain EHI. The actor, therefore, provides the EHI that can be unambiguously segmented and is not subject to the individual's request not to share information in response to the request. If the actor did not provide the EHI that can be unambiguously segmented, then the actor might be engaged in information blocking with respect to the EHI that can be unambiguously segmented.

We note that this is only one example to illustrate how the “stacking” of exceptions may occur. We have chosen to detail here an example scenario where an individual has requested restrictions to reinforce actors' and individuals' awareness of the § 171.202(e) sub-exception and to emphasize that the information blocking regulations accommodate actors' choosing to respect an individual's request for restrictions on EHI about the individual. We emphasize, however, that there may be a wide variety of scenarios where “stacking” other combinations of various exceptions with one another, or with restrictions on use or disclosure of EHI under applicable law, may occur.

Again, we refer actors and other persons interested in learning more about how the information blocking regulations, and particularly the exceptions, work in concert with the HIPAA Rules and other privacy laws to support health information privacy, to the blog post as well as the frequently asked questions referenced and linked above.

We will issue additional guidance as needed and intend to propose additional exceptions in future rulemaking to further support health information privacy, including for information that patients may view as particularly sensitive such as reproductive health-related information.

Comments. A commenter expressed concern about the applicability of information blocking regulations where there are data interoperability problems resulting from different implementations of standards by different EHR vendors.

Response. We thank the commenter for their input. However, we did not propose information blocking provisions specific to this topic in the HTI–1 Proposed Rule.

B. Defined Terms

1. Offer Health Information Technology or Offer Health IT

“Health IT developer of certified health IT” is defined for purposes of the information blocking regulations in 45 CFR 171.102. As we discussed in the ONC Cures Act Final Rule (85 FR 25798 through 25799), the definition finalized in that rule includes offerors of certified health IT who do not themselves develop certified health IT or take responsibility for the health IT's certification status under the Program. Specifically, we explained that “an individual or entity that offers certified health IT” would include “any individual or entity that under any arrangement makes certified health IT available for purchase or license” (85 FR 25798, quoted and cited in the HTI–1 Proposed Rule at 88 FR 23857). Both individuals or entities that otherwise fall into at least one category of actor as defined in 45 CFR 171.102—such as health care providers—and individuals or entities that otherwise would not fit the definition of any category of actor could offer certified health IT that they did not themselves develop or present for certification. As offerors of certified health IT, these individuals or entities could engage in conduct that constitutes information blocking as defined in § 171.103, such as through contractual terms or practices undertaken in operating and maintaining health IT deployed by or for another individual or entity.

As discussed in the HTI–1 Proposed Rule (88 FR 23858), we proposed to codify in § 171.102 a definition of what it means to offer certified health IT. As proposed, the definition would provide clarity about the implications under information blocking regulations of making available funding subsidies and certain features or uses of certified health IT as well as engaging in certain other conduct (as discussed in more detail below). Specifically, we proposed to define the term “offer health information technology” or “offer health IT.” For ease of reference, in this preamble, we will generally use the shorter version of the term, “offer health IT” when discussing or referencing the definition. In light of our proposal to establish the “offer health IT” definition, we also proposed ( see88 FR 23915 and 88 FR 23864) to update the wording of the “health IT developer of certified health IT” definition specific to the exclusion of certain self-developer health care providers. The proposal specific to the “health IT developer of certified health IT” definition is summarized and discussed in section IV.B.2 below.

As explained at 88 FR 23858 through 23859, the definition we proposed for offer health IT generally includes providing, supplying, or holding out for potential provision or supply, certified health IT under any arrangement or terms, but explicitly excludes arrangements and activities specified in paragraphs (1) and (2) of the offer health IT definition (which are discussed in detail in section IV.B.1.a and b, below). We proposed exclusions of certain arrangements and activities from the offer health IT definition to serve two primary purposes:

(1) to encourage certain beneficial arrangements under which providers in need can receive subsidies for the cost of obtaining, maintaining, or upgrading certified health IT; and

(2) to give health care providers (and others) who use certified health IT concrete certainty that implementing certain health IT features and functionalities, as well as engaging in certain practices that are common and beneficial in an EHR-enabled healthcare environment, will not be considered an offering of certified health IT (regardless of who developed that health IT).

We also proposed (in paragraph (3) of the offer health IT definition in § 171.102) to exclude from the offer health IT definition the furnishing of certain legal, health IT expert consulting, or management consulting services to health care providers or others who obtain and use health IT. The paragraph (3) consulting and legal services exclusion is discussed in detail in section IV.B.1.c, below.

The HTI–1 Proposed Rule included examples illustrating when certain arrangements or activities would or would not fall within a proposed exclusion (paragraphs (1), (2), and (3)), and clarified that if any individual or entity that engages in some conduct consistent with an exclusion from the offer health IT definition but also engages in other conduct that meets the definition of offer health IT, that individual or entity would be considered a health IT developer of certified health IT. We noted that once an entity meets the definition of health IT developer of certified health IT based on any of its conduct, that definition will apply to all practices of the entity. ( see88 FR 23860 through 23864).

Comments. More than thirty commenters' submissions included comments on the offer health IT definition, health IT developer of certified health IT definition, or both definitions. Of these, over a dozen expressed general support and none expressed general opposition to the proposals.

Response. We appreciate all commenters' feedback. We have finalized the proposed offer health IT definition with one revision to the wording to replace “for use by” with “for deployment by or for” other individual(s) and entity(ies). Our response to the comments summarized immediately below explains why we believe this finalized wording change improves clarity of the definition for actors and other interested parties.

Comments. With a reference to the exclusion proposed in paragraph (2) of the offer health IT definition in § 171.102, the Health Information Technology Advisory Committee (HITAC) recommended that we clarify that providing access to registries and similar data services provided by public health authorities is not considered providing health IT, regardless of the route used to request/access/receive data ( e.g., through direct logon to a public health information system, via an app or third-party tool, or via HIN/HIE). The recommendation's rationale was stated as: “This change is necessary to provide users the flexibility to connect to the data resource in the manner of the user's choosing.” Other comments requested that we explicitly exclude, or clarify whether the offer health IT definition excludes, an actor making EHI available through an API or enabling interaction with an API. Commenters also requested clarification on whether such an API-related exclusion would apply to specific types of individuals or entities, or to specific purposes.

Response. Although focused on the detail of the exclusion proposed in paragraph (2) of the offer health IT definition in § 171.102, HITAC's comment informed our review of the interaction between the wording of the proposed offer health IT definition and the distinction between the roles of API User and API Information Source, as we had already defined these roles in § 170.404(c) and (by cross-reference) § 171.102. Specifically, we believe that wording the offer health IT definition in § 171.102 to focus (as proposed, see88 FR 23915) on holding out or providing or supplying under any arrangement certified health IT “for use by” others may be a source of uncertainty for health care providers, and for others who deploy Certified API Technology in the role of an API Information Source. This uncertainty, we believe, relates to the implications for purposes of the offer health IT definition of a health care provider or other individual or entity in the role of an API Information Source making Certified API Technology available to individuals and entities (other than their own employees and contractors) in the role of API User.

At this point, a brief review of the distinction between our definitions of the API User and API Information Source roles, with reference to their establishment in the ONC Cures Act Final Rule (85 FR 25748 through 25749), may help to explain why we now believe clarity is improved by aligning the wording of the offer health IT definition with those two definitions. In the ONC Cures Act Final Rule, we finalized in § 170.404(c) definitions of API User and API Information Source for purposes of the ONC Health IT Certification Program, and by cross-reference to § 170.404(c) adopted those same definitions for purposes of the information blocking regulations in 45 CFR part 171. As discussed in the ONC Cures Act Final Rule at 85 FR 25748 through 25749, we received in response to the ONC Cures Act Proposed Rule ( see84 FR 7477 for preamble discussion, 84 FR 7588 for proposed definitions) comments requesting a definition of a “First-Order User” (to include patients, health care providers, and payers that use apps/services) and a definition of a “Third-Party Users” (to include third-party software developers, and developers of software applications used by “API Data Providers”). We decided, as explained in the ONC Cures Act Final Rule (85 FR 25748 through 25749), that such a distinction was unnecessary from a regulatory perspective, and we finalized the API User definition in § 170.404(c) (85 FR 25948) as “a person or entity that creates or uses software applications that interact with the `certified API technology' developed by a `Certified API Developer' and deployed by an `API Information Source.' ” We also defined an API Information Source as an organization that deploys certified API technology created by a Certified API Developer. We noted in the ONC Cures Act Final Rule that the definitions finalized in § 170.404(c) were created to describe relationships and to help describe the Condition and Maintenance of Certification requirements to which developers participating in the ONC Health IT Certification Program are subject (85 FR 25749).

A vast array of interoperable health IT items and services are designed and implemented specifically to achieve increasingly efficient access, exchange, and use of EHI for a wide range of permissible purposes. Thus, in an interoperable health IT ecosystem, one may see third-party apps adopted and used by patients, health care providers, health plans, public health authorities, researchers, and others to achieve access, exchange, or use of EHI by connecting to, interacting with, or otherwise making use of Health IT Module(s) deployed within, for example, a health care provider's EHR system or a public health authority's case reporting infrastructure. Our definition of API User in 45 CFR 170.404(c) illustrates this expectation: it includes both those who create and those who use software applications that interact with API technology deployed by anyone functioning in the role of an API Information Source.

We have revised the wording of the finalized offer health IT definition in order to improve certainty for individuals and entities who function in the role of an API Information Source (as defined in § 171.102 by cross-reference to § 170.404(c)) or function in an equivalent role where any APIs involved are not certified but may be part of health IT product(s) that also include one or more Health IT Modules certified under the Program. Specifically, we have replaced in the finalized offer health IT definition the phrase “for use” with the phrase “for deployment by or for.” We believe this wording is more consistent with the distinction between the act of connecting to, interacting with, or otherwise making use of a health IT item or service (for example, as an API User) and the act of allowing for such connections or interactions with the health IT that an individual or entity (for example, a health care provider) relies on in conducting its own business operations.

In addition, we believe this updated wording encompasses the full array of models through which individuals and entities obtain health IT for implementation or other deployment in their operations. We include “or for” in this finalized wording to ensure it is clear that the offer health IT definition is met regardless of whether the customer to whom the health IT is provided or supplied deploys the health IT by themselves or deploys the health IT by having the offeror or any third party(ies) do some or all such implementation and maintenance for them.

Providing or supplying health IT that includes one or more Health IT Modules certified under the Program meets the offer health IT definition finalized in § 171.102 regardless of whose employees, contractors, or consultants actually install, configure, manage, or maintain such health IT or other health IT with which such health IT may be integrated, interfaced, or otherwise interact. Likewise, holding out such health IT meets the offer health IT definition regardless of whose employees, contractors, or consultants would be needed, expected, or likely to set it up, manage, or maintain it in the event the holding out of the health IT resulted in the health IT being provided or supplied to one or more other individual(s) or entity(ies). To reinforce this clarity, we note that “deployment by or for” includes, without limitation, all of the following examples in which an individual's or entity's conduct would meet the offer health IT definition (and thus meet the health IT developer of certified health IT definition) in § 171.102:

• An individual or entity holds out, or provides or supplies, health IT for deployment by or for potential customer(s) under a software-as-a-service (SaaS) model, infrastructure-as-a-service (IaaS) model, or any combination of these and other model(s) under which the offeror would implement and maintain on behalf of the customer any instance of the health IT. For purposes of this example, it would not matter whether a single-tenant instance would be implemented for each customer or whether one or more customer(s) would share multiple-tenant instance(s) of the health IT with the offeror or other customer(s).
• An individual or entity holds out, or provides or supplies, health IT for the customer(s) to implement themselves, using any combination of their own employees and contractors, any single- or multiple-tenant instance(s) of the health IT.
• An individual or entity holds out or provides or supplies health IT that is implemented by a third party to customers. For purposes of this example, it would not matter whether a single-tenant instance would be implemented for each customer or whether one or more customer(s) would share multiple-tenant instance(s) of the health IT with the third party or other customer(s).

Comments. One commenter requested that we provide guidance or examples of how we define “beneficial” and “necessary” in the context of the exclusions from the offer health IT definition. A commenter requested guidance on our use of the verb “hold out” in the offer health IT definition. (Comments specific to particular exclusions are addressed in subsections IV.B.1.a through c, below.)

Response. In the HTI–1 Proposed Rule, we discussed our purposes for proposing the exclusions, including “to encourage beneficial arrangements under which providers in need can receive subsidies for the cost of obtaining, maintaining, or upgrading certified health IT.” Thus, “encourage[ing] beneficial arrangements” explains our intent and rationale for the exclusions (88 FR 23858) and the term “beneficial” does not appear in the text of any of the exclusions. The text of each exclusion defines and describes the arrangements that it excludes from the offer health IT definition.

The word “necessary” appeared in the proposed text describing excluded legal services furnished by outside counsel (subparagraph (3)(i) of the § 171.102, offer health IT definition). We did not propose to establish a purpose-specific meaning for the word “necessary” in this context. We intended it to have its widely understood and commonly used meaning of absolutely needed, required, or of an inevitable nature. Upon review of the comments, we have concluded that we can improve the clarity of subparagraph (3)(i) by deleting the word “necessary.” The updated language uses the phrase “as appropriate to legal discovery” to encompass the activity of facilitating the access or use of the client's health IT when it is necessary as well as when it may be only one of the practicable options through which the counsel's clients can fulfill their legal discovery obligations.

We use the term “hold out” in the text of the offer health IT definition as a transitive verb. As such, we believe “hold out” is generally understood in common usage to mean presenting an item or service as something realizable, attainable, or for acceptance. With his common usage in mind, we use “hold out” to ensure it is clear that an individual or entity's activities can meet the definition of offer health IT without anyone accepting the proffer of a sale (or resale) or of a license (or relicense), and without anyone otherwise obtaining or using any Health IT Module(s) from that individual or entity. This operates as a safeguard against, for example, the holding out for sale or license one or more ONC-certified Health IT Module(s) (or products containing such Module(s)) and ultimately only agreeing to provide non-certified health IT in an attempt to avoid meeting the offer health IT definition and to avoid being subject to information blocking regulations. For purposes of the information blocking regulations, if any individual or entity is holding out health IT that includes one or more ONC-certified Health IT Modules, that individual or entity will be considered to be offering health IT and thus would meet the definition of health IT developer of certified health IT.

We further note that whether such a scenario might implicate other federal or state laws does not affect whether an individual or entity's conduct meets the offer health IT definition.

Comments. A commenter requested we ensure adequate protection of the provision of open-source tools developed by open-source communities, irrespective of the terms on which they are made available, whether the tool is necessary for use of the product or the provision of care or whether the tool is integrated into a certified health IT product as part of the product. This comment appears to convey uncertainty on the commenter's part about whether a health care provider's (for example, a health system) integration of open-source modules with the certified health IT products it deploys (or has deployed by a third party on its behalf) to support its provision of patient care and other operational activities meets the offer health IT definition. The commenter also encouraged ONC to ensure that the provision of clinical decision support modules by a health system through an open-source community is protected. This comment also appears to convey uncertainty on the commenter's part as to if or when a participant in an open-source community might be considered to offer health IT and, therefore, would meet the health IT developer of certified health IT definition in § 171.102.

Response. We will discuss here how the finalized definition addresses these concerns, in the order in which they are summarized above.

First, specific to a health care provider deploying open-source health IT to support its provision of patient care and other operational activities, we do not believe that the fact that the health care provider is deploying open-source health IT impacts the analysis. As we discussed above, the offer health IT definition as finalized aligns with the API User and API Information Source role definitions previously established in § 171.102 and we believe the finalized definition of offer health IT provides clarity that deploying health IT that incorporates one or more Health IT Modules certified under the Program is not an activity that meets the offer health IT definition, regardless of whether, or how much of, the health IT in question was developed by an open-source community or any other source or developer of health IT. For purposes of the finalized offer health IT definition, we do not treat deploying a health IT product developed by an open-source community different from deploying a health IT product developed by a commercial developer.

Also of note, the finalized offer health IT definition focuses on the holding out or provision or supply of certified health IT products for deployment by or for other individual(s) or entity(ies). As cited in the HTI–1 Proposed Rule in connection to the proposed implementation and use activities exclusion (paragraph (2) of the offer health IT definition (88 FR 23860)), we noted in the ONC Cures Act Final Rule that “some use of a self-developer's health IT may be made accessible to individuals or entities other than the self-developer and its employees without that availability being interpreted as offering or supplying the health IT to other entities in a manner inconsistent with the concept of `self-developer' ” (85 FR 25799, emphasis added). We add emphasis here to “other than . . . its employees” and “to other entities” to highlight that the offer health IT definition is not met by an individual or entity deploying health IT for use or implementation in their own operations by their employees and contractors in the course of employment or scope of the contract. We further note that the offer health IT definition is not met when the action is deployment that makes the health IT available to individuals in certain non-employee roles other than the deploying entity's contractors. For these reasons, a health care provider deploying health IT in the health care provider's own operations would not meet the offer health IT definition—whether the health IT is open-source or not.

Turning to the question of participation in an open-source development effort, we believe the question of which participants in such communities fall within the definition of offer health IT is, necessarily, dependent on the specific facts and circumstances of any given case. For example, relevant facts would include which participants in an open-source community have undertaken what role(s) and responsibility(ies) in relation to the certification status of the Health IT Module(s) involved.

The question of whether or when a participant in an open-source community engages in conduct that constitutes holding out, or providing or supplying, health IT that includes at least one certified Health IT Module is similarly, and also necessarily, dependent on the specific facts and circumstances of the conduct. In any case, it is also important to recall that the offer health IT definition that we proposed, and have finalized, cannot be met unless the technology held out, or provided or supplied, for deployment by or for others includes one or more Health IT Module(s) certified under the Program. To the extent an open-source community produces only non-certified health IT items or services, the development or offering of that non-certified health IT would not, of itself, result in the community or its participants being considered health IT developers of certified health IT—regardless of whether the product is intended, designed, or fit for use only in conjunction with certified health IT in general or specific certified health IT product(s). The community's exclusively non-certified health IT items or services may be styled, branded, named by the community, or commonly referenced in the marketplace as products, apps, modules, or something else without affecting whether the community's conduct falls within the § 171.102 offer health IT definition. Neither the holding out nor the providing or supplying of entirely and exclusively non-certified health IT can meet the offer health IT definition.

We recognize that once integrated with any deployment of a compatible certified product (such as ONC-certified EHR software), a non-certified health IT item such as a macro or template might be difficult or impossible for the end user (such as a doctor using a health system's EHR system to document a diagnosis) to distinguish from the certified health IT product. For individuals or entities who deploy certified health IT product(s), we recognize that sharing such items with others may raise questions similar to the one posed by the comment specific to open-source health IT: does sharing with other individuals or entities a non-certified item that, as experienced by end users, may seem like part of a certified health IT product meet the offer health IT definition?

We note that whether an actor's conduct meets the offer health IT definition is not determined by the end user's perception of what is or is not part of a single certified health IT product. Likewise, whether an individual's or entity's conduct meets the offer health IT definition is not determined by whether a particular health IT item or service that is not certified health IT can or cannot be used independently of certified health IT. The individual's or entity's conduct can meet the offer health IT definition only when the health IT that the individual or entity holds out, or provides or supplies, includes at least one Health IT Module certified under the ONC Health IT Certification Program.

Even if a non-certified health IT item or service (for example, a macro or template) can only be used in conjunction with a specific certified health IT product, the offer health IT definition is not met by holding out, or by providing or supplying, for deployment by or for others only the non-certified health IT item or service. For example, a health care provider might choose to make available to other members of a developer's user group a macro that works only with one of the developer's Health IT Modules that is certified to § 171.315(b)(3). The hypothetical macro in this example is not a Health IT Module that is certified under the Program, and does not include any Health IT Module(s) certified under the Program when the health care provider makes it available to other members of the user group. In this example scenario, the act of supplying the non-certified macro to other individual(s) or entity(ies) does not meet the definition of offer health IT.

For a similar example, an open-source community or its participants could make available a “clinical decision support” (CDS) algorithm. In this example, the CDS algorithm is not a Health IT Module that is certified under the Program. The act of holding out the algorithm for deployment by or for others does not meet the offer health IT definition because the algorithm is not certified health IT. Likewise, the act of providing or supplying the algorithm for deployment by others does not meet the offer health IT definition. If, however, the algorithm was included as a part of a certified health IT product, and an individual or entity holds out, or provides or supplies, the certified health IT with the algorithm in it for deployment by other individual(s) or entity(ies), that conduct would meet the offer health IT definition.

Comments. Two comments on the offer health IT definition referenced reporting requirements in connection to the offer health IT definition. These comments did not identify specific reporting requirements they perceived entities would become subject to by engaging in conduct meeting the offer health IT definition.

Response. As established by the ONC Cures Act Final Rule and updated by the provisions finalized in this rule, the information blocking regulations (45 CFR part 171) do not include any requirements for any actor to proactively report to ONC.

Comments. Several commenters suggested that hosting, the provision of hosting services, or “extending their EHR” by health care providers for other health care providers should be excluded from the definition of offer health IT. One such commenter stated a view that such organizations should not be considered to offer health IT and should not be subject to “more stringent” information blocking requirements.

Response. In the HTI–1 Proposed Rule, we did not propose defining what conduct would meet or not meet the offer health IT definition based on whether it was done by an individual or entity that otherwise meets the definition of any type of actor (as the term actor is defined in § 171.102). These commenters' rationale for excluding hosting, the provision of hosting services, or “extending their EHR” by health care providers for other health care providers centered on preventing health care providers engaged in such conduct from also meeting the definition of health IT developer of certified health IT. Therefore, we discuss in context of our proposal to update the health IT developer of certified health IT definition ( see section IV.B.2 of this preamble, below) why we decline to establish at this time any regulatory provision with the effect these comments advocate.

Summary of finalized policy—offer health IT: we have finalized the proposed offer health information technology or offer health IT definition with a revision to its wording in response to comments received. The wording revision is from “for use by other individual(s) or entity(ies)” to “for deployment by or for other individual(s) or entity(ies).”

To increase clarity, we have further revised the definition by replacing the phrase “under any arrangement other than the following” with “under any arrangement except an arrangement consistent with subparagraph (3)(iii), below.” As discussed above, activities described in other paragraphs and subparagraphs we do not interpret as holding out or as providing or supplying health IT for deployment by or for other individuals or entities. Thus, only subparagraph (3)(iii) functions to exclude from the offer health IT definition arrangements under which someone obtains from an individual or entity any certified Health IT Module(s).

To improve readability, we also revised the opening phrases of the definition. This revision was from “. . . means to hold out for sale, resale, license, or relicense; or to sell, resell, license, relicense, or otherwise provide or supply health information technology (as that term is defined in 42 U.S.C. 300jj(5)) that includes one or more Health IT Modules certified under the ONC Health IT Certification Program, . . .” to “. . . means: to hold out for sale, resale, license, or relicense; or to sell, resell, license, relicense, or otherwise provide or supply health information technology (as that term is defined in 42 U.S.C. 300jj(5) and where such health information technology includes one or more Health IT Modules certified under the ONC Health IT Certification Program) . . .” as finalized.

For readability, we added a second sentence to the offer health IT definition that also enhances clarity as to the function of the definition's subparagraphs on the whole. That added sentence reads: “Activities and arrangements described in subparagraphs (1) through (3) are considered to be excluded from what it means to offer health IT.”

The finalized definition is shown in its entirety in the CFR amendatory instructions for § 171.102 (see “Regulation Text” section of this rule, below).

a. Exclusion of Certain Funding Subsidy Arrangements From Offer Health IT Definition

In the HTI–1 Proposed Rule, we included a provision to address concerns regarding the potential of some health care providers and other donors to stop making available funding subsidies that would go toward the cost of certified health IT in situations where the receiving health care provider is not able to afford the cost of the certified health IT. The proposal, in paragraph (1) of the offer health IT definition in § 171.102, explicitly excluded certain arrangements that focused on providing funding subsidies for providers to obtain, maintain, and/or upgrade certified health IT. We explained how this exclusion would operate in the HTI–1 Proposed Rule (88 FR 23859). We refer readers to the HTI–1 Proposed Rule for the full discussion of the donation and subsidized supply arrangements exclusion (paragraph (1)).

Comments. Of the comment submissions addressing this proposed exclusion, six supported exclusion of funding subsidy arrangements from the offer health IT definition. One comment submission did not express general opposition to the exclusion but expressed opposition to the definition of offer health IT excluding subsidies tied to a specific product, or excluding subsidies that would promote or prioritize imaging referrals of patients to the subsidizing entity or its partners. This comment, from two large clinical societies, recommended that if we finalize this exclusion, we state in preamble that promotion or prioritization of the subsidizing entity's services over those of unaffiliated, competing providers would not be exempted from the offer health IT definition.

Response. We appreciate commenters' feedback. We have finalized the exclusion of funding subsidy arrangements (paragraph (1) of the offer health IT in § 171.102) as proposed (88 FR 23915). The donation and subsidized supply arrangements exclusion as proposed and as finalized is conditional, as indicated by this language in paragraph (1) of the offer health IT definition: “provided such individual or entity offers and makes such subsidy without condition(s) limiting the interoperability or use of the technology to access, exchange, or use electronic health information for any lawful purpose.” Thus, the donation and subsidized supply arrangements exclusion (paragraph (1)) does not apply if the subsidy is conditioned on limiting the interoperability or use of the technology to access, exchange, or use EHI for any lawful purpose. Any agreement terms, statements (written or oral), patterns of conduct, or singular actions whereby the source of donation or funding subsidy conditions the donation on the recipient's limiting its use of health IT or its access, use, or exchange of EHI in ways specified or signaled by the funding source would be considered a condition limiting interoperability or use of the technology. Therefore, we do not believe that the purpose of this exclusion would be better served by limiting it at this time to arrangements under which recipients can choose to apply a funding subsidy to a minimum array of products or to any product on the market. However, we plan to remain alert for signals that funding subsidy sources may be misusing this exclusion. We note that we may consider amending this definition in future rulemaking in response to changing market conditions.

We appreciate commenters' concerns about donation or subsidy arrangements tied to specific technology where the donation or arrangement is for the purpose of promoting referrals to the source of the funding or its affiliates. We believe the proviso in the donation and subsidized supply arrangements exclusion (paragraph (1)), as proposed, is sufficient to ensure it does not apply to arrangements conditioned by the source(s), donor(s), or giver(s) on limiting interoperability or use of the technology. As stated in the HTI–1 Proposed Rule, we do not believe it is necessary to assess, for purposes of determining whether a funding subsidy should be considered an offer of certified health IT, whether the source(s) of the subsidy conditions the subsidy on the recipient referring patients to or away from the source. As we noted, there may be other laws implicated by solicitation or receipt of any remuneration in return for referral steering and similar conduct (88 FR 23859). For example, the Federal Anti-Kickback Statute (42 U.S.C. 1320a–7b(b), section 1128B(b) of the Social Security Act) could be implicated where remuneration is directly or indirectly offered, paid, solicited, or received for the referral of or arrangement of a referral of any item, service, or good for which payment may be made in whole or part under a “Federal health care program” (as defined in 42 U.S.C. 1320a–7b(f)). Nothing in this final rule should be construed as creating an exception to any fraud and abuse laws.

In light of the commenters' concern, we believe it may be useful to clarify how the donation and subsidized supply arrangements exclusion from the offer health IT definition operates for purposes of 45 CFR part 171 in the context of a donor or funding source that is using a subsidy to steer referrals or to distort the market for healthcare items or services through a condition(s) that limit the use of donation-supported or subsidized technology or the lawful access, exchange, or use of EHI. As noted in the HTI–1 Proposed Rule (at 88 FR 23859), we interpret “conditions limiting the interoperability or use of the technology to access, exchange, or use electronic health information” broadly. Specifically, we noted we would consider conditions to include not only the explicit terms of any written agreement but also oral statements and patterns of conduct on the part of the subsidy's source(s) toward, in the presence of, or made known by the source(s) to the subsidy's recipient. We further noted that we would consider a condition(s) to include a subsidy source limiting the use of the subsidy to particular technology that includes, or otherwise arranges for subsidy-supported technology to include, features, functions, coding, or other means that would limit recipients' options to lawfully use that technology to access, exchange, or use EHI. A recipient health care provider's access, exchange, and use of EHI for such purposes is not limited to but necessarily includes access, exchange, and use by care team members in the course of making diagnosis and treatment decisions within their scopes of practice and making referrals in accord with their professional judgement and understanding of their patient's preferences.

The limitation on the application of the offer health IT definition's donation and subsidized supply arrangements exclusion in paragraph (1) of the definition is, as noted in the HTI–1 Proposed Rule, a safeguard against inappropriate use of the exclusion by entities seeking to distort the health IT market. This would include efforts to limit recipients' options to use additional technology or to otherwise impede innovations and advancements in health information access, exchange, and use (88 FR 23859). The donation and subsidized supply arrangements exclusion (paragraph (1)) applies only where the individual or entity donates, gives, or otherwise makes available funding without condition(s) limiting the interoperability or use of the technology to access, exchange, or use EHI for any lawful purpose. We did not propose that the exclusion could apply to any arrangement conditioned in any way on limiting the interoperability or use of the subsidy-supported technology or the recipient's use of the technology to access, exchange, or use EHI for any lawful purpose. We have finalized the exclusion as proposed.

We further clarify in view of comments received that the limitation on application of the donation and subsidized supply arrangements exclusion in paragraph (1) of the definition does not consider what underlying intent or motive the funding source may have for any condition that limit the interoperability or use of the technology to access, exchange, or use electronic health information for any lawful purpose. Any condition that has such effect will mean the arrangement falls outside of the donation and subsidized supply arrangements exclusion (paragraph (1) of the offer health IT definition). Then, whether such non-excluded funding subsidy or donation arrangements would constitute the funding source offering health IT would have to be evaluated to determine whether the conduct constitutes holding out for sale, resale, license, relicense, or otherwise providing or supplying health information technology for deployment by other individual(s) or entity(ies).

To note, any third-party health IT developer of certified health IT or HIN/HIE that may be engaged in funding subsidy arrangements related to providing, configuring, or otherwise supporting health IT will want to bear in mind that their engagement in any practice they know or should know is likely to interfere with access, exchange, or use of EHI could constitute information blocking on the part of the actor (unless an applicable law requires or an exception set forth in 45 CFR part 171 is satisfied by such practice). This includes scenarios where the practice occurred at the direction of or on behalf of a funding subsidy source. This would be true for the health IT developer of certified health IT or an HIN/HIE regardless of whether the funding subsidy source or recipient is also an actor, and regardless of whether the funding subsidy source or recipient also engaged in conduct meeting the information blocking definition.

Comments. Several commenters recommended we adopt a policy under which a health care provider would not be considered to offer health IT, or be considered only a health care provider and excluded from the “health IT developer of certified health IT” definition, even if they “extend their EHRs” or otherwise donate or provide health IT on terms more affordable to a recipient than those available from other vendors of health IT items or services. Several commenters suggested such provision of health IT be excluded from the definition of offer health IT. A commenter that is a health system advocated for an explicit exclusion in situations where a health care provider hosts instances of a particular developer's EHR for other health care providers. A developer of certified health IT advocated to exclude from the definition of offer health IT any health IT resale or relicensing arrangements on non-discriminatory bases between health care providers or HIPAA covered entities. The developer's comment acknowledged the potential for organizations hosting or otherwise reselling health IT to make configurations or other implementation decisions potentially implicating the information blocking definition but asserted they had not observed this to have occurred among the providers reselling the developer's health IT.

Response. We appreciate commenters' sharing their experiences and perspectives. We did not propose that the donation and subsidized supply arrangements exclusion from the offer health IT definition would apply to a health care provider selling, licensing, or otherwise providing or supplying certified health IT (whether such health IT is self-developed by the provider offering it or obtained from a third-party developer) to other health care providers on a subsidized, discounted, or other basis. We decline to do so for reasons we discuss in this response and in Section IV.B.2 of this preamble below.

We cannot be certain whether commenters' reference to providers who “extend their EHRs” or similar wordings are meant to describe the donor health care provider entity selling, reselling, licensing, relicensing, or otherwise providing or supplying the health IT itself for deployment by the recipient providers. Therefore, to ensure clarity, we note that we perceive a clear distinction between two kinds of conduct. One distinct kind of conduct is donating, giving, or otherwise making available to a recipient funding to cover costs of an item or service (such as health IT that includes one or more Health IT Modules certified under the Program). A distinctly separate kind of conduct is the sale, resale, licensing, relicensing, or otherwise providing or supplying of the item or service itself to the recipient.

We proposed that the donation and subsidized supply arrangements exclusion (paragraph (1)) to encompass arrangements where “an individual or entity donates, gives, or otherwise makes available funding to subsidize or fully cover the costs of a health care provider's acquisition, augmentation, or upkeep of health IT” (88 FR 23915). We stated in the HTI–1 Proposed Rule that the proposed donation and subsidized supply arrangements exclusion “would remove from the definition of offer health information technology or offer health IT the provision of subsidies, in the form of funding or cost coverage subsidy arrangements for certified health IT” (88 FR 23859). We have finalized the donation and subsidized supply arrangements exclusion (paragraph (1)) of the offer health IT definition (§ 171.102) as proposed. Thus, the finalized first exclusion of the definition encompasses furnishing monetary resources (as described at 88 FR 23859, “subsidies, in the form of funding or cost coverage subsidy arrangements”) for an item or service.

We reiterate that the donation and subsidized supply arrangements exclusion as proposed and as finalized in paragraph (1) of the offer health IT definition does not encompass any arrangement where an individual or entity does any of the following to or with any health IT that includes one or more certified Health IT Module(s):

• holds out the health IT for sale, resale, license, or relicense for deployment by or for other individual(s) or entity(ies);
• sells, resells, licenses, relicenses the health IT for deployment by or for other individual(s) or entity(ies); or
• otherwise provides or supplies the health IT for deployment by or for other individual(s) or entity(ies).

To prevent any potential confusion or misunderstanding about the significance of our reference to “subsidized supply” arrangements in the text of the exclusion in (paragraph (1) of the offer health IT definition, we note that this is included to explicitly recognize a type of arrangement whereby a donor or other subsidy source subsidizes or fully covers costs by payment of such costs to the individual or entity that develops or offers the health IT item(s) or service(s) subsidized.

For an example of a scenario in which the donation and subsidized supply arrangements exclusion (paragraph 1) applies: a health system arranges with a health IT developer that the health system will pay eighty-five percent of the cost of any contract for use of a (developer hosted) EHR product suite by any health care provider that gives the developer a particular code that was supplied to the health care provider by the health system. Note that in this example the EHR product suite includes one or more Health IT Modules certified under the Program (because the offer health IT definition is not met if health IT that is held out or that is provided or supplied does not include any such Health IT Module(s).) The health system gives the code to independent safety net providers in its service area as a means of making funding available to the safety net providers to cover part of the safety net providers' cost to obtain and maintain use of an EHR product suite. A critical part of an analysis of the application of the exclusion in this example is whether money covering (part of) the contract costs for health IT is being supplied or whether the health IT itself is being supplied by the health system. Here the health system is only making a funding subsidy available. The health IT developer is supplying the health IT (EHR product suite).

In a different example, where a health system instead offers to host and support ONC-certified health IT for a safety net provider, the health system would be engaged in conduct to which the donation and subsidized supply arrangements exclusion (paragraph (1)) would not apply. Regardless of whether the entity doing the holding out or furnishing of health IT (or anyone else) would be subsidizing (in whole or in part) the costs of the health IT, the donation and subsidized supply arrangements exclusion (paragraph (1)) does not apply where an individual or entity holds out or, under any arrangement, provides or supplies for deployment by or for other individual(s) or entity(ies) any health IT product(s) that include one or more Health IT Modules certified under the Program.

We recognize that some health care providers, or other individuals or entities, may choose to engage, on a subsidized basis for the recipient or as a donation to the recipient, in conduct that is not encompassed by the exclusion in paragraph (1) but to which another exclusion to the offer health IT definition applies. In the interest of providing such individuals and entities certainty, we note that if any exclusion to the offer health IT definition applies to any particular conduct, it does not matter whether one or more other exclusion(s) do or do not also apply. If at least one exclusion applies to any particular conduct, that conduct is excluded from the offer health IT definition.

Finally, we note again that donation and subsidized supply arrangements can implicate other laws, including the Federal Anti-Kickback Statute and nothing in this final rule should be construed as creating an exception to any fraud and abuse laws.

We further discuss below, in the context of the health IT developer of certified health IT definition (section IV.B.2), our current position regarding health care providers who choose to engage in conduct that meets the offer health IT definition. However, it is important for providers and other individual(s) or entity(ies) interested in engaging in any conduct that meets the offer health IT definition to note that engaging in such conduct makes the individual or entity one that offers health IT. This means such an individual or entity will meet the health IT developer of certified health IT definition regardless of whether the individual or entity also happens to engage in any other conduct that is encompassed by an exclusion from the definition or that otherwise does not meet the offer health IT definition.

Comments. A commenter requested we confirm that subsidy arrangements where the funding source is not otherwise a § 171.102 actor are encompassed by the exclusion. The comment cited, as an example, subsidies from health plans to providers. Another comment recommended that we clarify the offer health IT definition excludes subsidy arrangements between healthcare entities, such as a health plan and community provider. Other comments suggested that we should reiterate that engaging in activities described in exclusion (1) is not a way for an individual or entity that is otherwise a § 171.102 actor to opt out of being subject to information blocking regulations.

Response. The finalized donation and subsidized supply arrangements exclusion (paragraph (1)) applies to the arrangements it describes. It does not specify characteristics that the source of the subsidy must have (or not have) for the arrangement to be excluded from the offer health IT definition. If any person engages in conduct described in paragraph (1), that means the excluded conduct does not fall within the definition of offer health IT. Thus, engaging in conduct described in paragraph (1) of the offer health IT definition will not turn an individual or entity who does not otherwise meet the § 171.102 actor definition into an “actor” for purposes of the information blocking regulations.

It is important to remember, however, that engaging in conduct described in the donation and subsidized supply arrangements exclusion (paragraph 1) simply has no effect on whether a person is not or is considered an actor as defined in § 171.102 for purposes of 45 CFR part 171. Even if an individual or entity that is otherwise an actor engages in conduct described in subparagraph (1) of the offer health IT definition, the person is still an actor. For example, if any entity meets the § 171.102 definition of health care provider then that entity is a health care provider regardless of whether it also happens to engage in conduct described in the donation and subsidized supply arrangements exclusion from the offer health IT definition. Also, any entity meeting the § 171.102 definition of health IT developer of certified health IT through any of its activities is a health IT developer of certified health IT regardless of whether it also happens to engage in conduct described in the donation and subsidized supply arrangements exclusion (paragraph 1).

A health care provider or health IT developer of certified health IT would remain subject to the information blocking regulations for any of their conduct that meets the definition of information blocking in § 171.103, including when that conduct occurs in the course of activities that fit the description of any exclusion from the offer health IT definition. Similarly, when and to the extent a health plan, health plan issuer, or any other entity engages in conduct meeting the functional definition of health information network or health information exchange (HIN/HIE), then that entity is a HIN/HIE regardless of whether the entity also happens to engage, at the same time, in conduct described in any exclusion from the offer health IT definition.

Comments. A commenter who referenced experience with donation of hospital equipment noted it is important for recipients of donated technology to have access to design documents, data schema, and other resources needed to facilitate the use of donated health IT systems through maintenance, process improvement, and interoperability concerns. This commenter encouraged ONC to provide a broad dissemination of publicly available user manuals, access to spare parts, and consumable resources to facilitate the use of donated equipment. A commenter suggested we consider adjusting conditions of the donation and subsidized supply arrangements exclusion to address the impact of discontinued subsidies on the recipient's ability to maintain the health IT over time.

Response. We appreciate the concerns raised by these comments. Specific to Health IT Modules certified under the ONC Health IT Certification Program, our Program regulations in 45 CFR part 170 provide for public availability of certain information and documentation about the technology. ( See45 CFR 170.523 disclosures applicable to certified Health IT Modules, 45 CFR 170.404(a)(2) transparency conditions for Certified API Technology.) To the extent documentation needed to effectively use health IT products that include non-certified items and services in complement to one or more Health IT Module(s) certified under the Program, such documentation would fall outside the scope of the Program's disclosures and transparency requirements. However, we believe the information blocking regulations discourage an actor from inappropriately withholding access to such documentation from recipients of their health IT. If an actor's practice of denying the recipients of health IT such information is likely to interfere with access, exchange, or use of EHI, that practice could implicate the information blocking definition. It is not clear what consumable supplies or spare parts relevant to health IT were referenced by the comment advocating ONC provide broad access to them. It is also not clear what is meant by the commenter advocating ONC “provide access” to spare parts and consumables. We note that the information blocking regulations maintain policies supportive of the access, exchange, and use of EHI and include policies under which the individuals and entities who actually supply health IT (donated or otherwise) for deployment by or for other individuals or entities generally continue to be subject to enforcement under the information blocking regulations as health IT developers of certified health IT.

Concerns specific to a supplier of technology withholding access to documentation and resources needed to use systems represents one example of conduct likely to interfere with a recipient's access, exchange, or use of EHI. This concern illustrates just one of many possible practices any individual or entity that engages in conduct meeting the finalized offer health IT definition would have opportunity to engage in that would be likely to interfere with customers' and others' ability to access, exchange, or use EHI in or through the health IT “offered.” Such opportunities to interfere with customers' access, exchange, or use of EHI are among the reasons we believe it would be inappropriate to exclude from the offer health IT definition the sale, resale, licensing, or relicensing of any Health IT Module based on such offering being subsidized by the offeror or a third party. Therefore, such conduct will generally continue to fall within the offer health IT definition. By engaging in any conduct falling within the offer health IT definition, the individual or entity engaged in the conduct meets the health IT developer of certified health IT definition and is subject to information blocking regulations accordingly.

We further note that this comment highlights the importance of prospective recipients of technology donations carefully considering the full terms of both the donation or subsidy arrangement and any contracts or other agreements with a developer, seller, reseller, licenser, or relicenser of the technology involved. For example, and for practical reasons entirely independent of the information blocking regulations, it is important for a recipient to know what items and services are included in the subsidy or donation and the level, extent, and duration of support for those items or services that the donation commits the funding source to cover. The information blocking regulations do not eliminate the need for anyone contemplating adopting health IT items or services pursuant to a donation or subsidy arrangement to consider and plan for their ability to maintain the health IT in good working order, or successfully transition away from it, at the end of a one-time donation or subsidy arrangement or in the event an arrangement providing an ongoing subsidy were to be discontinued (or not renewed). This would be true for adoption of initial, additional, upgraded, or replacement health IT items or services.

We also note that whether, as potential recipients of subsidized health IT or as a customer paying the full cost or market price themselves, all prospective recipients of any health IT will likely find it important to know and understand the terms of all agreements with the developer or offeror of health IT items or services they obtain. For example, a customer contemplating adoption of any health IT item or service would want to consider the potential that they may want to replace that particular product with another product in the future. Such a customer would want to look closely at how any data the product stores will be returned to the customer at the end of the agreement with the developer or other offeror of the health IT, and what support may be available, and on what terms, to help the customer (or a health IT developer or support contractor of the customer) import the data into the next product the customer will use to access, exchange, or use that data.

Recipients of donated health IT, like all customers of health IT, will also find it important to know whether technology they are considering for adoption includes any Health IT Module(s), or if the developer or offeror that would provide the technology has any Health IT Module(s), certified under the Program. An individual or entity that develops or offers health IT, but who does not develop or offer any certified Health IT, might not be subject to information blocking regulations unless the individual or entity is a health care provider or a HIN/HIE as defined in § 171.102.

Summary of finalized policy—donation and subsidized supply arrangements exclusion (paragraph 1): After consideration of the comments received that are relevant to, and within the scope of, this proposal, we finalized the policy, as proposed. Provision of funding to a recipient who will use it to cover some or all of the recipient's health IT acquisition, augmentation, or upkeep cost is explicitly excluded from the offer health IT definition. Likewise, arrangements whereby a funding source (whether or not referenced or styled as a “donor”) pays, remits, or otherwise transfers to a third-party funds covering the cost (in whole or part) of a health care provider's acquisition, augmentation, or upkeep of health IT are explicitly excluded from the offer health IT definition to the extent they are consistent with paragraph (1). However, the text of paragraph (1) explicitly and intentionally limits application of the donation and subsidized supply arrangements exclusion to those arrangements whereby the source of the subsidy makes available funding to cover costs of acquisition, augmentation, or upkeep of health IT. The finalized paragraph (1), donation and subsidized supply arrangements exclusion from the offer health IT definition, does not apply to sale, licensing, resale, relicensing, or provision or supply of the health IT itself—regardless of whether such provision or supply is on subsidized or other terms.

We reiterate that no individual or entity that otherwise meets the definition of any type of actor in § 171.102 can opt out of being subject to information blocking regulations by engaging in any activity excluded from the offer health IT definition.

b. Implementation and Use Activities That Are Not an Offering of Health IT

In the ONC Cures Act Final Rule, we noted that there are certain actions taken by health care providers who self-develop health IT for their own use that we do not interpret as them offering or supplying certified health IT to others (85 FR 25799). Specifically, we noted that “some use of a self-developer's health IT may be made accessible to individuals or entities other than the self-developer and its employees without that availability being interpreted as offering or supplying the health IT to other entities in a manner inconsistent with the concept of `self-developer,' and we provided examples of activities that we do not consider offers (85 FR 25799). Some of the examples we noted (85 FR 25799) were discussed in the context of practices amongst hospitals that purchase commercially marketed health IT as well as self-developer hospitals.

While the examples focus on self-developers, these examples would not be considered “offering” health IT regardless of who developed the certified health IT. We also believe there are examples of activities we did not discuss that should not be considered offers of health IT. We, therefore, proposed in paragraph (2) of the offer health IT definition ( see88 FR 23860 and 88 FR 23915) to explicitly exclude from the definition of offer health IT certain implementation and use activities of a health care provider or other entity (such as a HIN/HIE, health plan, or public health authority). We refer readers to the HTI–1 Proposed Rule (88 FR 23860) discussions of the activities explicitly listed within the implementation and use activities exclusion from (paragraph (2) of) the definition of offer health IT we have now finalized within § 171.102.

We sought comment on this proposal, including whether we should consider revising or refining any of the descriptions or wordings of the functionalities, features, actions, or activities listed in the draft regulation text or whether we should consider explicitly excluding additional activities, actions, or health IT functionalities from what it means to offer health IT.

Comments. Comments referencing this exclusion supported the provision. Several commenters recommended specific refinements to the wording or clarifications to the intended scope of the exclusion. Comments were received that recommended the implementation and use activities exclusion encompass each of the following as implementation and use activities:

• a health care provider organization or other entity uses pre-production staging or test environments for certified health IT;
• use of health IT for purposes of clinical education and improvement activities, including in simulation environments where no care is furnished to actual patients;
• a health care provider providing a public health authority's employees or contractors with access to its health IT systems;

• providing access to registries and similar data services that are provided by public health authorities, regardless of the route used to request/access/receive data ( e.g., through direct logon to a public health information system, via an app or third-party tool, or via HIN/HIE).

Response. We appreciate the comments received on the proposed implementation and use exclusion. In response to comments received, we have revised the wording of the finalized regulation text in the offer health IT definition (as discussed in section IV.B.1 of this rule, above) and have also revised the wording of subparagraphs within paragraph (2) (discussed in the summary of finalized policy—implementation and use exclusion (paragraph (2)) at the end of this section, IV.B.1.b, of this rule).

As discussed in section IV.B.1 of this final rule, we reviewed the wording of the offer health IT definition in light of a HITAC comment about providing access to registries and similar data services provided by public health authorities, regardless of the route used to request/access/receive data. We believe the change in the offer health IT definition's wording from “for use by” to “for deployment by or for” better aligns the wording of this definition with the definitions of “API User” and “API Information Source” previously established in § 171.102 by cross-reference to § 170.404(c) (as discussed in section IV.B.1 of this rule, above). We also believe this wording change removed a need to catalog within paragraph (2) all of the various manners in which access, exchange, or use of EHI with public health entities and with others might be accomplished without the individual or entity in the API Information Source role (or equivalent role for non-certified API technology or other manners of access, exchange, or use) meeting the offer health IT definition.

The excluded activity descriptions in subparagraphs (2)(ii), (iii), and (iv) are intended to accommodate current heterogeneity in how individuals and entities who deploy health IT (such as health care providers) make EHI available for access, exchange, or use by their information sharing partners. With the minor changes in wording that we mention above, we believe it is clear that subparagraphs (ii) through (iv) of paragraph (2) in conjunction with the revision to the offer health IT definition's wording accomplish this intent. Although subparagraph (2)(ii) discusses APIs and (2)(iii) discusses online portals, we believe that they, when taken together with subparagraph (2)(iv), provide for extensive heterogeneity in the manners of information sharing available now or in the future to those who access, exchange, or use EHI. Moreover, we believe the wording change that we discuss above from “for use by” to “for deployment by or for” also addresses commenters' concerns about whether the offer health IT definition does or does not include interactions with or use of pre-production or other non-production instance(s) of API technology.

We also reiterate that, as we stated in the HTI–1 Proposed Rule (88 FR 23860), we do not believe it is necessary to define a production instance because we observe health IT developers, resellers, and customers generally using and understanding a production instance as a particular implementation of a given health IT product that has “gone live” in a production environment (without needing to specify, for this purpose, whether such instance is single- or multi-tenant). Production environments, in turn, we observe are generally understood as being the setting where health IT is implemented, run, and relied on by end users in day-to-day conduct of their profession (such as medicine, nursing, or pharmacy) or other business (such as a payer processing healthcare reimbursement claims or a patient managing their health and care).

Summary of finalized policy—implementation and use activities exclusion (paragraph 2): After consideration of comments, we have finalized the proposed implementation and use activities exclusion (paragraph (2)) with revisions. As described in more detail below, we have refined how we describe several types of activities within the exclusion.

We have struck from subparagraph (2)(i), (ii), (iii), and (iv) the parenthetical “as defined in this section” following the terms “electronic health information” and “health information network or health information exchange.” The § 171.102 definitions of these terms apply throughout 45 CFR part 171 unless otherwise specified in a particular subpart or section. Thus, the presence or absence of this parenthetical has no effect on the meaning of the subparagraphs noted above and has been removed from the final text.

The wording of the activity description in subparagraph (2)(i) has been revised to remove reference to employees or contractors using the individual's or entity's health IT to access, exchange, or use EHI in the course of their employment. Instead, the exclusion lists a variety of types of activities that an individual's or entity's employees or contractors might do within the scope of their employment or contract duties specific to, or otherwise requiring use of, access to the health IT. The finalized wording of subparagraph (2)(i) explicitly includes use, operation, configuration, testing, maintenance, update, and upgrade activities for an individual's or entity's health IT system(s) or specific application(s) within such systems. It also includes explicit reference to the individual's or entity's employees or contractors giving or receiving training on the health IT.

We believe this explicit list of purposes for which employees or contractors might need to use an individual's or entity's deployed health IT provides the clarity some commenters sought regarding a health care provider maintaining non-production instances of health IT for various purposes other than supporting care delivery, documentation, or billing of healthcare. We believe this clarity is achieved by the rewording of subparagraph (2)(i) in complement to the change from “for use by” to “for deployment by or for” others in the offer health IT definition.

We have finalized subparagraph (2)(ii) with one revision to its wording: we have removed the parenthetical statement “(whether certified or not)” to improve readability. The deletion of “(whether certified or not)” has no effect on the substance of subparagraph (2)(ii) because the description references API technology in general. As used in subparagraph (ii) of the implementation and use activities exclusion, “application programming interface (API) technology” encompasses “Certified API Technology” as defined in 45 CFR 170.404(c) as well as any other API technology.

As proposed, subparagraph (2)(ii) referenced production instances and did not reference pre-production instances. We have retained reference to “production instances” of API technology in the excluded activity description in the finalized definition as the finalized offer health IT definition's wording change from “for use by” to “for deployment by or for” makes it unnecessary to explicitly encompass pre-production instances within subparagraph (2)(ii) of exclusion (2). Specifically, the revised wording of the offer health IT definition makes it clear that deploying any instance(s) of API technology with which independent, outside persons participating in testing activities might interact (in the course of testing or QI activities, or in the role of API User as defined in § 171.404(c) or an analogous role for health IT other than “Certified API Technology” as defined in § 171.404(c)) does not, in and of itself, meet the offer health IT definition. By contrast, the holding out, or the providing or supplying, for deployment by or for other individuals or entities under any arrangement not described in exclusion (3)(iii) of health IT that includes one or more Health IT Module(s) would meet the offer health IT definition, regardless of whether such other individual(s) or entity(ies) were to deploy (or have deployed on their behalf) production instance(s), pre-production instance(s), or any combination of production and pre-production instances of the offered health IT.

We have removed from the finalized text of subparagraph (2)(iii) a comma that immediately followed the word “clinicians.” This comma was a typographical error that has been corrected so that the finalized text describes making portals available to any or all of the following: patients, clinicians or other health care providers, or public health entities. We use “public health entities” here to encompass public health authorities, their employees, and their contractor(s) acting in the scope of the contract to the public health authority.

Specific to implementation and use activities of entities that need to share information with public health authorities, the revised wording of the offer health IT definition (from “for use by” to “for deployment by or for,” as discussed in section IV.B.1 of this preamble) renders the presence or absence of specific reference in subparagraph (2)(iii) or (iv) to public health authorities' contractors largely moot, because the activities subparagraphs (iii) and (iv) describe (as proposed and finalized) do not involve or include supplying health IT for deployment. However, we proposed the implementation and use activities exclusion (paragraph (2)) for the purpose of giving health care providers (and others) who use certified health IT certainty that implementing certain health IT features and functionalities, as well as engaging in certain practices that are beneficial in an EHR-enabled healthcare environment, will not be considered “offering” certified health IT (regardless of who developed that health IT) (88 FR 23858). Therefore, we have finalized subparagraph (2)(iv) with addition of explicit reference to public health authorities' contractors to better serve subparagraph (2)(iv)'s purpose.

By contrast, the activity described in subparagraph (2)(iv) was not proposed to, and as finalized does not, encompass supplying health IT for deployment by or for public health authorities or any other individual(s) or entity(ies). Holding out, providing, or supplying health IT that includes one or more certified Health IT Module(s) for deployment by or for a public health authority will meet the offer health IT definition. ( see also the discussion of deployment versus use of health IT in section IV.B.1 of this preamble.)

We have modified the wording of subparagraph (v) of exclusion (2) in response to comments seeking explicit clarity regarding the implications of a healthcare facility potentially allowing independent healthcare professionals who furnish services in a healthcare facility to use the facility's health IT for clinical education and improvement activities or to receive training in the use of the healthcare facility's health IT systems. Specifically, following “furnishing, documenting, and accurately billing for that care,” we have added: “participating in clinical education or improvement activities conducted by or in the healthcare facility; or receiving training in use of the healthcare facility's health IT system(s).” With the clarification of the wording of the offer health IT definition (as discussed above in section IV.B.1 of this final rule) from “for use by” to “for deployment by or for” other individuals, we believe the distinction is clear between supplying independent healthcare professionals with health IT to deploy in their outside practice(s) or other endeavors and merely enabling independent healthcare professionals to use a healthcare facility's health IT systems in the course of the professional's engagement in patient care and other activities conducted by or in the healthcare facility.

As is the case for subparagraph (2)(iv), we have nevertheless decided to finalize subparagraph (2)(v) to serve the purpose for which we proposed it: giving health care providers (and others) who use certified health IT certainty that implementing certain health IT features and functionalities, as well as engaging in certain practices that are beneficial in an EHR-enabled healthcare environment, will not be considered “offering” certified health IT (regardless of who developed that health IT) ( see88 FR 23858 and 88 FR 23860).

We believe that patients generally benefit when independent healthcare professionals who practice in a particular facility participate in such activities as training for use of the facility's health IT and other equipment. We believe patients also generally benefit when independent healthcare professionals are able to participate in a facility's clinical education activities, and we note that this includes the independent clinician conducting or leading clinical education or quality improvement activities in a facility for or with other professionals. Quality improvement and clinical education activities conducted in, but not necessarily by, the healthcare facility could include activities that occur in the facility that are partly or largely conducted by third parties (such as a professional specialty society, Patient Safety Organization (PSO), Medicare's Quality Innovation Network—Quality Improvement Organization (QIN–QIO), public health authorities (federal, state, or tribal), or similar entities). Prior to issuing the HTI–1 proposed rule, we had not had indications that healthcare facilities were experiencing uncertainty specific to allowing independent healthcare professionals to use the facility's systems in the course of clinical education or quality improvement activities in the facility—which could, from a health IT perspective, potentially make use of pre-production, production, or a mix of production and pre-production instance(s) of one or more system(s) or application(s).

Based on comments received in response to our proposing subparagraph (2)(v), we are concerned that codifying subparagraph (2)(v) with wording that explicitly references only furnishing, documenting, and billing for care in the facility would risk creating new uncertainty specific to independent professionals' use of a facility's health IT in the course of quality improvement and clinical education activities in the facility. By explicitly referencing clinical education and quality improvement activities conducted by or in a facility in addition to explicitly referencing furnishing, documenting, and accurately billing for care an independent healthcare professional furnishes to patients in a facility, we believe the finalized wording of subparagraph (v) is beneficial.

We reiterate, however, that the holding out, provision, or supply of health IT for deployment by or for other individual(s) or entity(ies) is not encompassed by any subparagraph of the implementation and use activities exclusion (paragraph (2)). (Again, we refer readers to the discussion of deployment versus use of health IT in section IV.B.1 of this preamble.)

c. Consulting and Legal Services Exclusion From the Offer Health IT Definition

In defining what it means to offer health information technology or offer health IT, we also considered whether it would be beneficial to explicitly establish an exclusion of certain management consulting services that play important roles in some providers' approaches to operational management of their practice, clinic, or facility. The bundled exclusions we proposed in paragraph (3) of the offer health IT definition address “consulting and legal services,” including:

• legal services furnished by attorneys that are not in-house counsel of the provider (commonly referred to as “outside counsel”);

• health IT expert consultants' services engaged to help a health IT customer/user (such as a health care provider) define their business needs and/or evaluate, select, negotiate for or oversee configuration, implementation, and/or operation of a health IT product that the consultant does not sell/resell, license/relicense, or otherwise supply to the customer; and
• clinician practice or other health care provider administrative or operational management consultant services where the clinician practice or other health care provider's administrative or operational management consulting firm effectively stands in the shoes of the provider in dealings with the health IT developer or commercial vendor, and manages the day-to-day operations and administrative duties for health IT and its use alongside other administrative and operational functions that would otherwise fall on the clinician practice or other health care provider's partners, owner(s), or staff.

We refer readers to the HTI–1 Proposed Rule (88 FR 23860 through 23864) for discussion and examples of services that would be excluded under each of subparagraphs (3)(i) through (3)(iii) of the proposed offer health IT definition.

Comments. Six commenters referenced this exclusion and expressed general support for the proposal. Some, however, recommended specific modifications or clarifications to the described activities. (Comments specific to each particular subparagraph of paragraph (3), the consulting and legal services exclusion, are summarized below.)

Response. We appreciate commenters' sharing their perspectives on this proposal through the public comment process. We have finalized the consulting and legal services exclusion (paragraph 3) with minor clarifications and revisions to each subparagraph, as discussed in detail below under sub-headings specific to each of these subparagraphs.

Legal Services Furnished by Outside Counsel

At subparagraph (3)(i) in the proposed offer health IT definition, we proposed to explicitly exclude legal services furnished by outside counsel (88 FR 23861). As we explained, this proposed exclusion would: codify how we already view, in the context of the definitions currently codified in § 171.102, legal services furnished by outside counsel in certain matters and remove an ambiguity that could, at least in theory, otherwise have unintended effects on how parties may in the future assess the best available options and mechanisms for efficient, cooperative discovery. The proposed exclusion for legal services furnished by outside counsel, like the proposed exclusion of health IT expert consulting services, would focus on the services provided and not on the type of organization providing them (88 FR 23861).

Comments. Several comments expressing support for the consulting and legal services exclusion (subparagraph (3)(i)) acknowledged the explicit exclusion of legal services furnished by outside counsel. No comments expressed opposition or concern and no comments recommended particular revisions or clarifications to the legal services description in subparagraph (3)(i).

Response. After considering comments received on the offer health IT definition and the consulting and legal services exclusion, we have finalized subparagraph (3)(i) of legal services furnished by outside counsel arrangements. We have, however, revised the text of subparagraph (3)(i) to remove unnecessary words and improve readability. These revisions are detailed below, under the summary of finalized policy—consulting and legal services exclusion (paragraph (3)) heading.

Health IT Consultant Assistance With Selection, Implementation, and Use of Health IT

At subparagraph (3)(ii) in the proposed offer health information technology or offer health IT definition, we proposed to explicitly exclude the work of health IT expert consultants engaged to help a health IT customer/user (such as a health care provider, health plan, or HIN/HIE) do any or all of the following with respect to any health IT product that the consultant does not sell or resell, license or relicense, or otherwise supply to the customer under any arrangement on a commercial basis or otherwise: define their business needs; evaluate or select health IT product(s); negotiate for the purchase, lease, license, or other arrangement under which the health IT product(s) will be used; or oversee configuration, implementation, or operation of a health IT product(s) (88 FR 23862).

Comments. Comments regarding the arrangements described in subparagraph (ii) of the consulting and legal services exclusion (paragraph 3) were generally supportive. Several comments recommended clarification as to whether the description encompassed the full scope of informatics consulting practice. One of these comments requested additional detail as to specific domains and tasks within the practice of clinical informatics. Several comments requested clarification as to whether the exclusion applied to a consultant configuring, implementing, or operating health IT on the customer's behalf, or whether it was limited to a consultant overseeing such activities conducted by others.

Response. After consideration of comments received, we have finalized the description of health IT consultant assistance arrangements in subparagraph (3)(ii) with revised wording to provide additional clarity. Specifically, we have:

• clarified the wording of the subparagraph's heading to read “health IT consultant assistance with selection, implementation, and use of health IT” (in the HTI–1 Proposed Rule (88 FR 23915) the omission of the word “with” was a typographical error, which we believe made the heading less readable); and
• modified the wording of subparagraph (3)(ii)(C) from “oversee” to “oversee or carry out” so that the exclusion's wording explicitly includes carrying out as well as overseeing configuration, implementation, or operation of health IT products.

We believe the revised wording (“oversee or carry out”) in subparagraph (3)(ii)(C) provides certainty and clarity to clinical or biomedical informaticists and other consultants that they can take an active role in configuring, implementing, or operating health IT on the customer's behalf, as well as or instead of overseeing such activities conducted by others, without the consultant's activities meeting the definition of offer health IT.

As proposed and now finalized, subparagraph (3)(ii) is agnostic to what specific domains of expertise, or what specific knowledge, skills, or abilities, the consultant might apply to any of the activities described in subparagraphs (3)(ii)(A) through (C) with respect to any health IT product(s) that the consultant does not hold out or supply to the customer under any arrangement. We do not at this time believe it is necessary to limit the applicability of subparagraph (3)(ii) by adding to it a catalog of specific domains in which a health informaticist might be practicing when, or in order to be considered to be, engaged in activities described in any of subparagraphs (3)(ii)(A) through (C) under arrangements consistent with subparagraph (3)(ii).

A definition of “health informatics” that is often attributed to the National Library of Medicine indicates that “health informatics” is “the interdisciplinary study of the design, development, adoption and application of IT-based innovations in healthcare services delivery, management and planning.” In our observation, there is today considerable heterogeneity in what health informaticists do, how they do it, and under what arrangements they engage with employers, customers, or clients. Therefore, we believe it would be more cumbersome than helpful to attempt to catalog all, and difficult to identify an appropriately representative sampling, of the tasks that a practitioner of health informatics might oversee or conduct without themselves selling, reselling, licensing, relicensing, or otherwise supplying the customer with health IT that includes one or more Health IT Modules certified under the Program. Such a catalog of tasks or domains of health informatics practice would risk rapidly becoming more limiting than we intend the exclusion to be. Therefore, we decline to do so. Instead, we emphasize that whether any activity or conduct in the course of practicing clinical, biomedical, public health, or any other variation of health informatics (or any other profession) is encompassed by the consulting and legal services exclusion under subparagraph (3)(ii) depends on whether the activity or conduct is consistent with subparagraph (3)(ii).

We reiterate that if an individual or entity who engages in an activity or arrangement encompassed by an exclusion from the offer health IT definition happens to otherwise be an § 171.102 actor, that individual or entity is an actor subject to the information blocking provision in section 3022 of the PHSA. If such actor engages in conduct that meets the definition of information blocking in § 171.103, that actor could be subject to enforcement action under the information blocking provision in section 3022 of the PHSA even if they engaged in the practice(s) meeting the information blocking definition in the course of an activity that would not, itself, meet the offer health IT definition.

For example, a clinical informaticist who is a doctor of medicine (MD) or osteopathy (DO) might provide consulting services consistent with subparagraph (3)(ii) of the offer health IT definition. The services in this example do not meet the offer health IT definition. Therefore, these services do not cause the informaticist to meet the health IT developer of certified health IT definition. But the clinical informaticist, as an MD or DO, meets the § 171.102 definition of a health care provider. Thus, the physician in this example is a § 171.102 actor and, were this physician to be determined by OIG to have committed information blocking, the physician would be subject to appropriate disincentives consistent with section 3022(b)(2)(B) of the PHSA.

If, however, an individual or entity who practices “health informatics” is not otherwise a § 171.102 health care provider, health IT developer of certified health IT, or HIN/HIE, and would only meet the § 171.102 actor definition by offering health IT chooses to only engage in conduct that does not meet the offer health IT definition, then the individual or entity would not be considered an actor.

Comprehensive and Predominantly Non-Health IT Administrative or Operations Management Services

In subparagraph (3)(iii), we proposed to exclude from the offer health IT definition comprehensive clinician practice or other health care provider administrative or operational management consultant services where the administrative or operational management consulting firm effectively stands in the shoes of the provider in dealings with the health IT developer or commercial vendor, and manages the day-to-day operations and administrative duties for health IT and its use alongside a comprehensive array of other administrative and operational functions that would otherwise fall on the clinician practice or other health care provider's partners, owner(s), or staff (88 FR 23862).

Alone among the three proposed exclusions of consulting and legal services arrangements, the exclusion of clinician practice or other health care provider administrative or operational management consulting services would be likely to include arrangements where the health IT deployed by or for the health care provider is supplied to them by the consultant—for example, as part of a comprehensive (“turn key”) package of practice management or other provider administrative or operations management services. In proposing the exclusion from the offer health IT definition of the activities specified in subparagraph(3)(iii), we noted its implication for health care providers' accountability for acts or omissions of their consultants operating under the exception—particularly health care providers' administrative or operational management services consultants—that implicate the definition of information blocking in § 171.103 (88 FR 23862). We refer readers to the HTI–1 Proposed Rule for the rationale for the comprehensive and predominantly non-health IT management services exclusion and explanation of how it operates (88 FR 23862 through 23864). The explanation includes the key factors that differentiate excluded clinician practice or other health care provider administrative or operational management consultant services from IT managed service provider (MSP) services and arrangements (88 FR 23863).

The HTI–1 Proposed Rule preamble discussion may include one or more instances of a typographical error in how subparagraph (iii) of exclusion (3) is referenced. This typographical error results in citing the paragraph as (3)(c) instead of (3)(iii). These typographical errors in how the paragraph is cited in the HTI–1 Proposed Rule preamble have no bearing on the substance of the proposal.

We solicited comment on this proposal, including specifically whether:

• this exclusion is more beneficial than harmful or confusing to the public, including the regulated community (health care providers, other information blocking “actors,” and those who may be more likely to be considered a “health IT developer of certified health IT” in the absence of this exclusion); and
• different or additional criteria should factor into differentiating whether a particular arrangement is a practice/operational management services arrangement that happens to include health IT as one of many necessities to operate as a health care provider rather than an arrangement for the supply of health IT that happens to include additional services (88 FR 23864).

Comments. We received comments discussing or referencing the proposal to exclude arrangements for comprehensive and predominantly non-health IT clinician practice or other health care provider administrative or operations management services from four commenters. No comments expressed opposition to excluding these activities from the offer health IT definition. One comment expressed appreciation for the clarity the proposal provides. Two comments recommended revising the exclusion to encompass additional types of arrangements. One comment advocated changing the effect of an activity's exclusion so that an individual or entity that meets the actor definition through other activities (such as by participating as a developer in the Program) would not be considered an actor while engaging in the excluded activity. One commenter shared thoughts specifically in response to the HTI–1 Proposed Rule's prompt for comments on potential benefits and harms of the proposal and potential additional criteria for differentiating between a practice/operational management services arrangement that happens to include health IT and an arrangement for the supply of health IT that happens to include additional services.

Response. Upon consideration of comments received, we have finalized the exclusion of comprehensive and predominantly non-health IT clinician practice or other health care provider administrative or operations management services (subparagraph (iii) of paragraph (3)). We have revised the wording of subparagraph (3)(iii) to improve its readability and clarity. We summarize and respond to specific, detailed comments below.

Comments. A commenter advocated that we expand the exclusion to explicitly encompass reselling and hosting certified health IT under a particular vendor-specific model.

Response. A health care provider who wishes to stand in the shoes of another provider in dealings with the health IT developer or commercial vendor, in managing the day-to-day operations and administrative duties for the health IT, or both, as part of a comprehensive array of predominantly non-health IT administrative and operational functions, can do so without meeting the offer health IT definition. Such conduct would be excluded from the offer health IT definition to the extent the arrangement is consistent with the comprehensive and predominantly non-health IT management services exclusion (subparagraph (3)(iii)). We refer readers to the HTI–1 Proposed Rule explanation of the key factors that differentiate excluded clinician practice or other health care provider administrative or operational management consultant services from IT managed service provider (MSP) services and arrangements (88 FR 23863). Although this discussion of key factors includes an instance of the typographical error whereby subparagraph (3)(iii) is cited as “(3)(c)”, the key factors discussed (88 FR 23863) apply to the arrangements described by subparagraph (3)(iii), as proposed and as now finalized.

We discuss in context of the health IT developer of certified health IT definition preamble below (section IV.B.2) additional concerns we would have for a potential policy under which health care providers who choose to sell or resell certified health IT under additional types of arrangements would not be considered health IT developers of certified health IT. Because of these concerns (discussed in IV.B.2, below) we do not believe it would be appropriate to expand the exclusions from the offer health IT definition to include the vendor-specific resale model cited by this commenter.

Comments. Some comments cited potential risks, such as of anti-competitive effects or conflicts of interest arising as a result of exclusions potentially encouraging entities in the health sector or beyond to develop consulting operations to supply health IT to customers without the consulting operation being subject to the information blocking regulations, as compared to entities that offer similar services but also meet the health IT developer of certified health IT definition. A comment recommended we ensure sufficient protections are in place but did not suggest specific additional criteria or considerations for determining which arrangements are or should be encompassed by the comprehensive and predominantly non-health IT management services exclusion (subparagraph (3)(iii) and which should instead meet the offer health IT definition.

Response. We appreciate receiving a response to our request for comment on these points. Subparagraph (3)(iii) explicitly indicates that the consultant providing these services acts as the agent of the health care provider or otherwise on behalf of the health care provider in dealings with the health IT developer or vendor, day-to-day operations and administration of the health IT, or both. This means that for any (individual or entity) consultant's services to be consistent with subparagraph (3)(iii), the consultant cannot also be the developer of any included health IT items or services. For subparagraph (3)(iii) to apply, the consultant also must explicitly provide comprehensive and predominantly non-health IT administrative or operations management services. Thus, the exclusion cannot apply if the consultant is simply furnishing health IT managed service provider (MSP) services and arrangements or any bundle of exclusively or predominantly health IT items and services to the health care provider.

We believe excluded bundles of predominantly non-health IT services are distinguishable from health IT MSP services and arrangements and bundles of predominantly health IT items and services based on their characteristics. For an arrangement to be consistent with the comprehensive and predominantly non-health IT management services exclusion (subparagraph (3)(iii)), the bundle of business administrative and operational management services must demonstrate all of the differentiating factors described at 88 FR 23863:

• The individual or entity furnishing the administrative or operational management consulting services acts as the agent of the provider or otherwise on behalf of the provider in dealings with the health IT developer(s) or commercial vendor(s) from which the health IT the client health care providers ultimately use is obtained;

• The administrative or operational management consulting services must be a package or bundle of services provided by the same individual or entity and under the same contract or other binding instrument, and the package or bundle of services must include a comprehensive array of business administration functions, operations management functions, or a combination of these functions that would otherwise be executed by the health care provider;

• The bundle of business administrative and operational management consulting services must include multiple items and services that are not health information technology as defined in 42 U.S.C. 300jj(5); and

• The non-health IT services must represent more than half of each of—

○ the person hours per year the consultant (individual or entity) bills or otherwise applies to the services bundle (including cost allocations consistent with Generally Accepted Accounting Principles), and

○ the total cost to the client for, or billing from, the consultant per year (including pass-through costs for the health IT items and services).

These factors that differentiate comprehensive and predominantly non-health IT management services tailor subparagraph (3)(iii) so that it cannot be satisfied by a simple rebranding of health IT resale models or managed service provider (MSP) services or by tacking a few non-health IT service(s) onto a bundle of predominantly (half or more) health IT items and services. Thus, we believe subparagraph (3)(iii) as finalized is appropriately tailored to guard against misuse of the exclusion in the market today.

We recognize, however, the potential for the market to evolve in ways that would increase risk of unintended consequences or abuse of this exclusion from the offer health IT definition. Although we have finalized the exclusion of arrangements consistent with subparagraph (3)(iii) without limiting its applicability based on characteristics, features, or factors beyond those we proposed, we note that we may consider amending the offer health IT definition (including any or all of its exclusions) in future rulemaking in response to experience with the definition in practice or other appropriate factors such as changing market conditions.

Comments. A commenter that is a commercial developer of certified health IT advocated that entities otherwise meeting the health IT developer of certified health IT definition should be able to operate a consulting entity that would engage in conduct excluded from the offer health IT definition without the consulting entity's conduct in the course of those activities implicating the developer as an actor. The commenter suggested that a developer could otherwise be at a competitive disadvantage specific to these consulting services compared to consulting entities that engage only in activities excluded from the offer health IT definition and do not otherwise meet the health IT developer of certified health IT definition.

Response. Achieving the effect recommended by this comment would require altering the structure and nature of the health IT developer of certified health IT definition rather than the offer health IT definition. Such modification of the health IT developer of certified health IT definition would be beyond the scope of the wording update we proposed in the HTI–1 Proposed Rule ( see88 FR 23864 and 23915). Therefore, we interpret the comment primarily as a response to our Request for Information on whether we should consider proposing in future rulemaking any additional exclusions from the offer health IT definition (section IV.C.1 of the HTI–1 Proposed Rule, starting at 88 FR 23873). We summarize and respond to this specific comment here because we believe, in light of comments received from the health IT customer community (including one addressed immediately below), it may be helpful to both health IT developers of certified health IT and their customers for us to provide an overview of certain features and implications of the information blocking regulations within which the finalized subparagraph (3)(iii) of the offer health IT definition appears.

A baseline feature of information blocking regulations in place since the ONC Cures Act Final Rule (85 FR 25642) is that the health information network or health information exchange (HIN/HIE) definition is currently the only § 171.102 actor type definition that is functional. As we stated in the ONC Cures Act Final Rule, “the individual or entity would be considered a HIN/HIE under the information blocking regulations for any practice they conducted while functioning as a HIN/HIE” (85 FR 25802). In contrast, both the health care provider and health IT developer of certified health IT definitions in § 171.102 are categorical, in the sense that an individual or entity either meets one of these definitions or they do not. For example, an individual or entity that meets the health IT developer of certified health IT definition in any of its activities is considered to be a health IT developer of certified health IT for any of its practices that otherwise meet the information blocking definition in 45 CFR 171.103—regardless of whether health IT involved in a specific practice is certified. To read more about the health IT developer of certified health IT definition's scope, including applicability of the Cures Act's information blocking provision to a developer's non-certified health IT, please see the ONC Cures Act Final Rule preamble starting at 85 FR 25795.

We recognize that in a variety of circumstances developers and offerors of certified health IT have business lines or other entities that market various services also marketed by competitor entities that do not develop or offer any certified health IT. We also recognize, and would encourage customers to be aware, that any individual or entity that (1) offers health IT products or consulting services in a way that satisfies the exclusion, (2) does not engage in any other conduct within the offer health IT definition, and (3) does not otherwise meet the § 171.102 actor definition would not be subject to the information blocking regulations.

We believe any perceived competitive disadvantage a “health IT developer of certified health IT” may experience as a result of meeting the definition in § 171.102 is offset by customers' potential preferences to receive services from consultants who are § 171.102 actors. For example, in choosing among otherwise competitive bids from a non-actor and a health IT developer of certified health IT to serve in a specific consulting role, a customer might weigh as favorable to a vendor or consultant that is a § 171.102 actor the fact that the actor could be subject to enforcement action under section 3022 of the PHSA if (except as required by law or covered by an exception) the actor engages in conduct they know or should know is likely to interfere with the access, exchange, or use of EHI. We also refer readers to the discussion in the ONC Cures Act Final Rule (85 FR 25795 through 25796) of a related concern about the potential impact of the Cures Act's information blocking provision (42 U.S.C. 300jj–52) on health IT developers' decisions to participate in the Program.

Comments. A commenter expressed concern about the risk of customers being uncertain as to which entities offering consulting services excluded from the offer health IT definition are subject to information blocking regulations and which are not, and about other entities' ability to support needs for data sharing within the healthcare space.

Response. We appreciate the commenter sharing this concern. We recognize that whether a consultant has the skills and expertise to deliver what the customer needs and expects for data sharing and other activities involving or relying on data, is a foundational question. Answering it, we believe, will continue to be something customers do by assessing prospective consultants' qualifications against their specific needs and priorities. Knowing that a consultant is an actor subject to information blocking regulations is a useful piece of information for customers to have, but a consultant meeting the § 171.102 actor definition does not guarantee the consultant has the level of particular knowledge, skills, abilities, or other capacity that the customer wants or needs from a consultant or other vendor.

We also recognize that customers who prefer to obtain services that are excluded from the definition of offer health IT from an entity that is subject to the information blocking regulations may need to engage in fact-finding to ascertain the status of entities that provide these services. We note that it may be somewhat easier to identify the actor status of a consultant where the consultant is also a developer participating in the Program, or a health care provider, than where they are not. This is because, for example, both individual and organizational health care providers must typically be licensed in jurisdiction(s) where they furnish healthcare. Most health care providers in the United States will also have a National Provider Identifier (NPI). Online directories of licensed health care providers are available from or for U.S. states, and CMS supports an online search utility for the NPI registry (available to the public free of charge at https://npiregistry.cms.hhs.gov/search ). Similarly, a search of ONC's Certified Health IT Products List (CHPL) ( https://chpl.healthit.gov/#/search ) will indicate whether an entity has listed under its name one or more Health IT Module(s) certified under the Program. By contrast, an entity that only resells Health IT Module(s) without having responsibility for the certification status of any such Health IT Module(s) will not be listed on the CHPL. It is also important to remember that entities' choices to engage in different lines of business under different names may mean that the name under which consulting services are furnished differs from the name(s) under which: a developer of certified health IT is associated with any CHPL-listed product(s); or an individual or entity that meets the § 171.102 health care provider definition may be listed in any registry, listing, or database of individual and organizational health care providers. Therefore, a customer may need to refer to additional sources of information, including those provided by the prospective consultant, and may want to consider addressing the consultant's § 171.102 actor status in the process of selecting the consultant or contracting with the consultant for their services (such as through representations and warranties).

One expectation we have for the improved clarity provided by the offer health IT definition is that it will help customers to differentiate between consultants who clearly are § 171.102 actors and those who might not be actors. With this clarity, we believe customers will be in a better position to assess what additional information, representations, or warranties they will require from a consultant before making or finalizing a decision to engage the consultant.

Summary of finalized policy—consulting and legal services exclusion (paragraph (3)): After considering comments received, we have finalized the substance of the consulting and legal services exclusion. The finalized text of paragraph (3) includes minor revisions to subparagraphs (i), (ii), and (iii) to improve clarity, address a typographical error, and improve readability (as discussed above):

• Revised the second sentence of subparagraph (i) to remove unnecessary words, increase precision, and improve readability, as follows:

○ Removed unnecessary words from “if or when facilitating limited access or use of the client's health IT or the EHI within it,” resulting in the revised phrase reading “when facilitating limited access or use of the client's health IT.”

○ Revised the phrase “to independent expert witnesses engaged by counsel” for readability and precision to read, as revised: “by independent expert witnesses engaged by the outside counsel.”

○ Revised the final phrase of the sentence from “as necessary or appropriate to legal discovery” to “as appropriate to legal discovery.”

• Revised the wording of the subparagraph (3)(ii) heading to read “health IT consultant assistance with selection, implementation, and use of health IT,” correcting the typographical error that had omitted “with” from the text as published in the HTI–1 Proposed Rule (88 FR 23915).
• Revised the wording of subparagraph (3)(ii) to improve readability by removing unnecessary reference to services being potentially provided by an individual or a firm, and to “expert.” As discussed in response to comments, subparagraph (3)(ii) applies to the activities it describes. Application of subparagraph (3)(ii) does not depend on the consultant having or applying specific type(s) or level(s) of expertise, knowledge, or skills in furnishing expert services to help the customer do (or do for the customer) the activities described in subparagraph (3)(ii)(A) through (C). The revision is from the HTI–1 Proposed Rule's wording “. . . provided by an individual or firm when furnishing expert advice and consulting services to a health IT customer or user that help the customer or user, or on the customer's behalf, do . . .” to “. . . advice and consulting services furnished to a health IT customer or user to do (or on behalf of a customer or user does).”
• Revised wording of subparagraph (3)(ii)(A) to improve readability, from “define the customer or user business needs; evaluate or select health IT product(s),” as presented in the HTI–1 Proposed Rule, to the finalized wording of: “define the business needs of the customer or user or evaluate health IT product(s) against such business needs, or both.”
• In response to public comments, modified the wording of subparagraph (3)(ii)(C) from “oversee” to “oversee or carry out” so that, on its face, the wording provides immediate and explicit clarity that the exclusion encompasses carrying out as well as overseeing configuration, implementation, or operation of health IT products.
• To improve readability of subparagraph (3)(iii), we have revised its wording in the following ways:

○ Split the paragraph into two sentences instead of one. The second sentence, as finalized, opens with “To be consistent with this subparagraph, such services must be furnished” to connect this to the preceding paragraph and ensure it remains clear that services are not consistent with subparagraph (3)(iii) unless they are furnished as part of a comprehensive array of predominantly non-health IT services (as discussed above, in responses to comments).

○ From the first revised sentence, removed unnecessary reference to clinician practice and other unnecessary words to improve readability. This change is from “provided by an individual or entity when furnishing a clinician practice or other health care provider administrative or operational management consultant services where the management consultant acts as the agent of the provider or otherwise” to the finalized wording: “when an individual or entity furnishes a health care provider with administrative or operational management consultant services and the management consultant acts as the agent of the provider or otherwise.”

○ Replaced in the first finalized sentence of the subparagraph the phrase “stands in the shoes of the provider” with less colloquial phrase “acts on behalf of the provider.”

○ Revised description of dealings with health IT developers and vendors to strike unnecessary adjective (“commercial”) and improve facial clarity that the dealings could be with one or more developers or vendors. This change in text is from “in dealings with the health IT developer or commercial vendor” to “in dealings with one or more health IT developer(s) or vendor(s).”

○ At the end of what is, as finalized, the first sentence of the subparagraph, we replaced “and/or in managing the day-to-day operations and administrative duties for the health IT,” with “or managing the day-to-day operations and administrative duties for the health IT, or both.”

○ Replaced in the second clause of the finalized second sentence of the subparagraph the phrase “fall on” with less colloquial phrase “be executed by” and struck unnecessary reference to a specific type of health care provider entity, and unnecessary reference to different roles within provider organizations. The affected portion of the subparagraph as presented in the HTI–1 Proposed Rule read: “as part of a comprehensive array of predominantly non-health IT administrative and operational functions that would otherwise fall on the clinician practice or other health care provider's partners, owner(s), or staff.” As a result of the revisions described here, the second sentence of the subparagraph reads as a whole: “To be consistent with this subparagraph, such services must be furnished as part of a comprehensive array of predominantly non-health IT administrative and operational functions that would otherwise be executed by the health care provider.”

We reiterate here, because we believe it is worth amplifying, a point we noted in the HTI–1 Proposed Rule (88 FR 23862) specific to the comprehensive and predominantly non-health IT management services arrangements (subparagraph (3)(iii)). That point is its implication for health care providers' accountability for acts or omissions of health care providers' administrative or operational management services consultants operating under the exception that implicate the definition of information blocking in § 171.103: where an administrative or operations management services firm would not be considered to offer health IT for which they contract on behalf of one or more practices (or facilities or sites of care) because they are acting as the provider's agent or otherwise standing in the shoes of the provider in selecting and contracting for a variety of services and supplies—including, but not limited to, the health IT that includes at least one certified Health IT Module—we would view the provider as retaining accountability for any information blocking conduct that the management services company perpetrates while thus acting on the provider's behalf. We recognize this may have implications for how providers may wish to structure administrative and operational services contracts in the future, potentially including a provider seeking representations and warranties giving the provider assurance that the administrative or operations management services company will not, without the provider's direction, knowledge, or approval, engage in any practice not required by law or covered by an information blocking exception that is likely to interfere with access, exchange, or use of EHI and could be unreasonable. However, subparagraph (3)(iii) of the consulting and legal services exclusion from the offer health IT definition is not intended to have the effect of regulating or otherwise interfering with contracting relationships between health care providers and entities that do, or might, furnish them with practice, facility, location, or site management consulting and operational services packages.

We also remind, again, any individual or entity otherwise meeting the § 171.102 actor definition that engaging in activities that are explicitly excluded from the offer health IT definition under paragraph (1), (2), or (3), will not change the fact that they are a § 171.102 actor. Where an individual or entity meets the actor definition, that actor's having also engaged in any one or more activities that satisfies an exclusion from the offer health IT definition does not mean the individual or entity is no longer an actor. The fact that an actor may engage in some conduct that is consistent with an explicit exclusion from the offer health IT definition does not mean that conduct on the actor's part is not subject to the information blocking definition. The fact that particular conduct of an individual or entity meets any exclusion from the offer health IT definition only means that specific conduct does not meet the definition of offer health IT.

2. Health IT Developer of Certified Health IT: Self-Developer Health Care Providers

For reasons discussed in the ONC Cures Act Final Rule (85 FR 25799 through 25800), health care providers who self-develop certified health IT “for their own use” were excluded from the health IT developer of certified health IT definition. However, under that definition, if a health care provider responsible for the certification status of any Health IT Module(s) were to offer or supply those Health IT Module(s) on any terms to other entities for those entities' use in their own independent operations, that would be inconsistent with the concept of the health care provider self-developing health IT “for its own use.” As we explained in the ONC Cures Act Final Rule (at 85 FR 25799), we use the term “self-developer” in this context as the term has been used in the ONC Health IT Certification Program (Program) and as described in section VII.D.7 of the Cures Act Proposed Rule (at 84 FR 7507).

In the HTI–1 Proposed Rule, informed by our proposal to define “offer health IT,” we proposed to modify the health IT developer of certified health IT definition in § 171.102. To ensure it would be immediately clear from the face of the regulations' text that we had put all health care providers that engage in activities consistent with the exclusions in paragraphs (1) through (3) of the offer health IT definition on the same footing regardless of who develops the health IT involved in these activities, we proposed to replace in the health IT developer of certified health IT definition the phrase “other than a health care provider that self-develops health IT for its own use” with the phrase “other than a health care provider that self-develops health IT not offered to others” ( See88 FR 23864).

Comments. A majority of comments specific to this proposal supported the proposal. Several comments stated that self-developer health care providers should not be considered health IT developers of certified health IT. Several comments stated that self-developer health care providers who offer health IT should be included health IT developers of certified health IT definition alongside other individuals and entities that offer certified health IT.

Response. We appreciate all comments received. Having considered the comments, we have finalized our proposal to align the self-developer health care provider exclusion from the health IT developer of certified health IT definition with our finalized definition of “offer health IT.” Stated another way, health care providers who self-develop certified health IT that is not offered to others are excluded from the health IT developer of certified health IT definition unless they “offer health IT” as now defined in § 171.102. We have made one revision to the wording of the finalized updated text of the definition for readability, specifically from “other than a health care provider that self-develops health IT not offered to others” to “other than a health care provider that self-develops health IT that is not offered to others.” We summarize and respond to additional comments related to the health IT developer of certified health IT definition below.

Comments. We received several comments advocating that we exclude all providers who host EHRs for other providers (sometimes characterizing it as extending the host provider's EHR) from the health IT developer of certified health IT definition. These comments have been discussed in section IV.B.1 because several of them discussed this recommendation as an extension, clarification, or addition to the proposed exclusions from the offer health IT definition. Some commenters, however, connected the suggestion to the health IT developer of certified health IT definition. Commenters' rationales for excluding from the health IT developer of certified health IT definition health care providers who “extend their EHRs” or otherwise provide certified health IT to other providers included: health care providers are already actors under the information blocking regulations (§ 171.102); recipient providers would be unable to afford interoperable health IT obtained from other sources; and the developer should be held accountable for design defects in health IT. Several other commenters, representing the health care provider as well as the ONC Health IT Certification Program-participating developer perspectives, explicitly supported our proposal to have all entities that offer health IT (as we have defined such action) continue to meet the definition of health IT developers of certified health IT regardless of whether such health IT was self-developed or obtained from a third-party developer.

Response. Whether done by a health care provider or anyone else, hosting EHR systems, otherwise providing or supplying health IT items and services, or holding out any certified health IT to health care providers generally meets the offer health IT definition. Such actions are excluded from the offer health IT definition only when and to the extent it is consistent with subparagraph (3)(iii) of the offer health IT definition. Any individual or entity, regardless of whether they also meet the § 171.102 definition of health care provider, who engage in conduct meeting the offer health IT definition meet the health IT developer of certified health IT definition on the basis of that conduct.

We had not proposed, and we have not made, revisions to “carve out” health care providers who offer health IT from the health IT developer of certified health IT definition. We included in section IV.C.1 of the HTI–1 Proposed Rule (88 FR 23873) a request for information on additional exclusions from the offer health IT definition but did not propose to exclude supply of health IT for deployment by or for others from the offer health IT definition based on the supplier being a health care provider. Further, as noted above, we received comments supporting the health IT developer of certified health IT approach we proposed. Therefore, any further exclusions from the offer health IT definition are deferred for future consideration.

Regarding concerns about design flaws in the software created by the developer of certified health IT, as a § 171.102 actor, the developer would be subject to information blocking penalties for software design flaws to the extent such flaws constitute information blocking. As we did in the ONC Cures Act Final Rule ( see 85 FR 25798 through 25799), we again refer commenters concerned about holding offerors that do not develop health IT accountable for the conduct of the developer (or others) to section 3022(a)(6) of the PHSA, which states that the term “information blocking,” with respect to an individual or entity, shall not include an act or practice other than an act or practice committed by such individual or entity. Where the individual or entity that develops health IT is different from the individual or entity that offers certified health IT, each such individual or entity is only liable for the acts and practices that it commits.

In the ONC Cures Act Final Rule (85 FR 25798–25800), we explained that any that any individual or entity that develops health IT, except for health care providers that self-developed certified health IT for their own use, meet the definition of health IT developer of certified health IT while they have one or more Health IT Modules certified under the ONC Health IT Certification Program. We also explained that individuals or entities meet the health IT developer of certified health IT definition if they offer certified health IT. This remains true with the conclusion of this rulemaking. Under the policies finalized in this rule, any individual or entity, including a self-developer health care provider or any other health care provider, that offers health IT (as defined in § 171.102) meets the definition of health IT developer of certified health IT.

Comments. A commenter requested that we clarify what the term health care provider means as used within the health IT developer of certified health IT definition.

Response. The term health care provider is defined for purposes of the information blocking regulations in 45 CFR 171.102. To help interested parties better understand the definition, we make information blocking resources available through our website, HealthIT.gov . These resources include a fact sheet titled “Health Care Provider Definition” that provides, in a single document, a copy of the full text of the health care provider statutory definition (PHSA section 3000) cited in § 171.102 and the text of statutory cross-references within the PHSA section 3000 definition of health care provider.

Summary of finalized policy—health IT developer of certified health IT definition: After consideration of comments received, we have finalized the revision to the definition substantively as proposed. We have made a non-substantive change to the wording of the finalized revised definition of health IT developer of certified health IT in comparison to the HTI–1 Proposed Rule; specifically, in the clause excluding self-developer health care providers to the extent their self-developed health IT is not offered to others. In the HTI–1 Proposed Rule, that clause read: “other than a health care provider that self-develops health IT not offered to others.” As finalized, we added “that is” immediately before “not offered to others” to improve readability of the finalized text.

We emphasize that any individual or entity that chooses to offer health IT (as defined in § 171.102) will meet the finalized revised § 171.102 health IT developer of certified health IT definition regardless of who developed the certified health IT that the individual or entity offers to others, and regardless of whether the health IT is offered at or below cost, market rate, or other benchmark price for the same or similar health IT items or services. This includes individuals and entities that offer health IT while also meeting the definition of health care provider, as both terms are defined in § 171.102, regardless of whether such individuals or entities also self-develop any health IT (certified or otherwise) deployed only within their own organization or operations. Regarding health care providers who might engage in activities consistent with one or more exclusion(s) from the offer health IT definition without also engaging in activities or arrangements that meet the offer health IT definition, we note that all such health care providers will stand on the same footing regardless of whether they also self-develop health IT that is not offered to others.

3. Information Blocking Definition

As finalized in the ONC Cures Act Final Rule (85 FR 25642) and the Cures Act Interim Final Rule (85 FR 70085), the information blocking definition (§ 171.103) and the Content and Manner Exception (§ 171.301(a)) were limited for a period of time to a subset of EHI that was narrower than the EHI definition finalized in the ONC Cures Act Final Rule in § 171.102. The narrower subset included only the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) for the first 18 months (until May 2, 2022) after the applicability date for 45 CFR part 171 (November 2, 2020) (85 FR 25792). The Cures Act Interim Final Rule extended the applicability date of 45 CFR part 171 to April 5, 2021 (85 FR 70069). This extended the end of the first 18 months of applicability of 45 CFR part 171 until October 6, 2022 (85 FR 70069).

Because October 6, 2022, has passed, we proposed to revise the information blocking definition (§ 171.103) to remove the paragraph designating the period of time for which the information blocking definition was limited to EHI that consists of the data elements represented in the USCDI (88 FR 23864 and 88 FR 23916). This time period designation was codified in § 171.103(b), as finalized in 2020, and removal of this paragraph allows for redesignation of remaining paragraphs within § 171.103 as shown in the HTI–1 Proposed Rule (at 88 FR 23916).

Similarly, because we included the same date in two paragraphs of the Content and Manner Exception (§ 171.301(a)(1) and (2)), we proposed to revise § 171.301 to remove the existing § 171.301(a)(1) and (2) as no longer necessary (88 FR 23864 through 23865 and 88 FR 23916). The proposed revised version of § 171.301 refers simply to EHI. We further proposed to renumber several of the existing provisions in § 171.301 accordingly and rename the exception as the “Manner” exception.

Comments. Comments received on our proposal to remove obsolete text from the information blocking definition (§ 171.103) generally supported this proposal. Comments noted that the information blocking definition prevents practices that hinder access to EHI, supports improved access to EHI for patients and health care providers, facilitates interoperability and encourages actors to prioritize interoperability, and promotes transparency and accountability in the healthcare ecosystem. A commenter stated the information blocking regulations are beneficial to underserved, underrepresented patient populations and the health care providers who serve them. This commenter advocated for collaborative efforts among various parties interested in information sharing, characterizing such efforts as crucial to ensuring that the information blocking regulations effectively support the goal of equitable access to high-quality healthcare for underserved populations. No commenters opposed this proposal. However, some commenters did note general concerns about the importance of balancing information sharing goals with patient privacy and data security.

Response. We appreciate commenters' feedback and have finalized the update to the information blocking definition (§ 171.103), as proposed. The topic of balancing information sharing goals with patient privacy and security of patients' health information is out of scope for this proposal, but it was also raised in comments on other proposals. We discuss, at the beginning of section IV of this final rule (above), comments raising general concerns about a perceived conflict between the goals of maximizing information sharing and appropriately protecting patients' privacy interests. We agree that information sharing can help improve many aspects of health care for all patients throughout the United States. We look forward to continued engagement with actors, patients, and others who support information sharing that contributes to improved care and health for individuals, families, and communities.

Comments. We received one comment that expressed concern about requirements to share mental health notes that were historically blocked from the rest of the record. The comment identified as an issue having all health care providers being able to access all mental health notes when they may not be immediately relevant to the patient at the point of care.

Response. In the HTI–1 Proposed Rule, we did not propose to modify existing exclusions from the § 171.102 definition of EHI for purposes of the information blocking regulations. Psychotherapy notes as defined in the HIPAA Privacy Rule at 45 CFR 164.501 are explicitly excluded from the 45 CFR 171.102 definition of electronic health information (EHI) for purposes of the information blocking regulations. We have posted on our website information resources to help actors understand the EHI definition and consider whether particular data is EHI for purposes of 45 CFR part 171 (see https://www.healthit.gov/topic/information-blocking ).

We note, and remind actors, that persons who engage in inappropriate uses and disclosures of individuals' health information may be violating other laws, including, but not limited to, the HIPAA Privacy Rule, 42 CFR part 2, or state or tribal laws. Persons using or disclosing individuals' health information in violation of one or more such law(s) would be subject to the consequences for violating those laws.

Comments. A commenter advocated for further revision of the information blocking definition to specify who must be affected by a practice that is otherwise consistent with the definition in order for the practice to be considered information blocking. The comment suggested as an example adding to paragraph (2)(b) of § 171.103 an explicit statement that the action can affect EHI access by physicians as well as by patients.

Response. We did not propose such a revision in § 171.103 and decline to adopt it here. We reiterate that an actor's practice meeting the information blocking definition is considered to be information blocking regardless of whether it affects access, exchange, or use of EHI by a patient, health care provider, health plan, or other person (as defined in § 171.102) that seeks access, exchange, or use of EHI for any permissible purpose (as defined in § 171.102).

Comments. A commenter requested we retain “Content and Manner” as the title of the exception codified in § 171.301 and retain wording specific to limiting the content fulfilled for a request to recognize the potential for an actor to be able to fulfill access, exchange, or use of some, but not all, EHI in a particular requested manner. Another commenter characterized our proposal to remove reference to the period of time and limited EHI in § 171.301 as removing a safe harbor protection for limiting the content of a response. This commenter stated that an actor may be able to satisfy § 171.301 for only some of the EHI requested. This commenter also stated that the proposed revision to § 171.301 creates uncertainty as to whether the Manner Exception can be satisfied where an actor can fulfill access, exchange, or use of only some EHI in the manner requested or in an alternative manner consistent with § 171.301.

Response. We decline to retain the prior title of the Manner Exception. We note that the “content” condition we have removed from regulatory text through this final rule has been moot since October 6, 2022, and we did not propose to re-instate it in the HTI–1 Proposed Rule. In section IV.A, we discuss an example situation where multiple exceptions could be used to provide an actor with certainty that their practices in responding to a request for access, exchange, or use of EHI will not be considered to be information blocking. Similarly, an actor might be able to satisfy the Manner Exception for only some of the EHI requested in a particular situation. In such instances, an actor may want to consider whether another exception is applicable to any other requested EHI.

Summary of finalized policy: After consideration of comments, we have finalized the proposed removal of references to the USCDI, as well as the time period designation, from §§ 171.103 and 171.301. We have also finalized corresponding redesignations of paragraphs, as proposed.

C. Exceptions

1. Infeasibility

a. Infeasibility Exception—Uncontrollable Events Condition

We established the Infeasibility Exception in the ONC Cures Act Final Rule (85 FR 25865 through 25870, 85 FR 25958; 45 CFR 171.204). The Infeasibility Exception includes conditions under which an actor's practice of not fulfilling requests for EHI access, exchange, or use due to infeasibility will not be considered information blocking. One of the conditions of the Infeasibility Exception, finalized by the ONC Cures Act Final Rule in § 171.204(a)(1), is the uncontrollable events condition. Under the uncontrollable events condition, an actor's practice of not fulfilling a request to access, exchange, or use EHI that is infeasible for the actor to fulfill as a result of events beyond the actor's control (listed in § 171.204(a)(1)) will not be considered information blocking provided such practice also meets the condition in § 171.204(b). In the HTI–1 Proposed Rule, we proposed to revise § 171.204(a)(1) to add clarity to the uncontrollable events condition (88 FR 23865).

In the HTI–1 Proposed Rule (88 FR 23865), we reminded readers that under the uncontrollable events condition, an actor's practice of not fulfilling a request to access, exchange, or use EHI as a result of a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority (§ 171.204(a)(1); 85 FR 25874) will not be considered information blocking provided such practice also meets the condition in § 171.204(b). We explained that the fact that an uncontrollable event specified in § 171.204(a)(1) occurred is not a sufficient basis alone for an actor to meet the uncontrollable events condition of the Infeasibility Exception. Rather, the use of the words “due to” in the uncontrollable events condition (paragraph (a)(1) of § 171.204) was intended to convey, consistent with the Cures Act Proposed Rule, that the actor must demonstrate a causal connection between the actor's inability to fulfill access, exchange, or use of EHI and the uncontrollable event. As we illustrated in the HTI–1 Proposed Rule (88 FR 23865), a public health emergency is listed as an uncontrollable event under § 171.204(a)(1). If the federal government or a state government were to declare a public health emergency, the mere fact of that declaration would not suffice for an actor to meet the condition. To meet the condition, the actor would need to demonstrate that the public health emergency actually caused the actor to be unable to provide access, exchange, or use of EHI for the facts and circumstances in question. The emergency need not be the only cause of a particular incapacity, but the actor needs to demonstrate that the public health emergency did in fact negatively impact the feasibility of that actor fulfilling access, exchange, or use in the specific circumstances where the actor is claiming infeasibility.

While the uncontrollable events condition (§ 171.204(a)(1)) has always required causal connection between the actor's inability to fulfill the request and the natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority, we proposed to revise the condition by replacing the words “due to” with “because of” (88 FR 23865). We welcomed comments on this proposal, including whether alternative or additional refinements to the wording of the condition may make the causal connection requirement more immediately obvious from the face of the text in § 171.204(a)(1) (88 FR 23865).

Comments. In general, commenters expressed support for clarifying the uncontrollable events condition by stating that the actor's inability to fulfill the request is “because of” one of the events listed. Commenters noted that the extra clarity adds certainty for actors and demonstrates a clear causation requirement. Some commenters supported the change but noted that “due to” and “because of” mean the same thing and the change would not have any resulting implications for actors. Another commenter agreed with the intent but did not believe that the change of wording from “due to” to “because of” provides any more clarity. This commenter asked what change in impact or obligation stemmed from the change, recommending a clear statement of the causal connection between the uncontrollable event and the impact on the actor. A commenter requested clarification as to how ONC believes the “due to” and “because of” differ in terms of implications for—or obligations now expected of— actors. A commenter recommended we make a clear statement about the causal connection between the uncontrollable event and the impact on the actor but did not suggest where, or in what words, we should consider making the statement.

Response. We appreciate the support expressed by many commenters and as discussed more fully below; we have finalized a revision of § 171.204(a)(1) with modifications to the regulation text to provide additional clarity. As noted in the preamble to the HTI–1 Proposed Rule, the words “due to” convey that the actor must demonstrate a causal connection between not providing access, exchange, or use of EHI and the uncontrollable event (88 FR 23865). We proposed to change the term to “because of” to provide further clarity. The revised language was not intended to change the substance of the condition, its implications, or what would be required of an actor for purposes of meeting the condition.

We did not receive comments suggesting specific additional refinements to the condition's text, or recommending specific alternative wording for “because of,” to make the causal connection requirement more immediately obvious from the text of the uncontrollable events condition (§ 171.204(a)(1)). However, having considered commenters' feedback, adding text to the finalized revision to § 171.204 will help actors and other interested persons immediately recognize that a causal connection is required between the uncontrollable event and the infeasibility of the actor's fulfilling a request for EHI access, exchange, or use. We have, therefore, finalized the proposed revision to § 171.204(a)(1) with the additional clause “that in fact negatively impacts the actor's ability to fulfill the request” at the end of the condition. This additional text is consistent with our statement in the preamble of the HTI–1 Proposed Rule that “the actor must demonstrate a causal connection between not providing access, exchange, or use of EHI and the uncontrollable event” (88 FR 23865). We intend for this additional clause to reinforce clarity that the actor must demonstrate an actual negative impact of the uncontrollable event on their ability to fulfill the requested access, exchange, or use of EHI for the uncontrollable events condition to be met. To reiterate, the finalized change to the wording of § 171.204 is only intended to improve clarity for actors and other interested parties in comparison to the previous wording rather than to make any change to the substance of the policy that it codifies.

Comments. A commenter recommended that ONC expand the definitions within the uncontrollable events condition to include impediments of data access, exchange, or use because of any disaster or emergency declared by an authorized governmental entity, noting that in addition to declared emergencies, this would include response and recovery periods associated with natural disasters that impacted the availability of providers' information systems or data.

Response. We did not propose to change the list of uncontrollable events or further define them, nor do we believe it is necessary to revise the references to disasters and emergencies to refer to a governmental declaration of that status or recovery or restoration periods. The events listed in the condition include acts of “military, civil, or regulatory authority” as well as natural or human-made disasters and other types of events or emergencies that might prompt a governmental authority to issue a declaration of disaster or emergency. However, consistent with the scope of the proposal, we emphasize that a key component of this condition is that an actor must demonstrate that a request for access, exchange, or use is infeasible because the uncontrollable event negatively impacts the actor's ability to fulfill the request.

Comment. A commenter recommended that we consider reporting flexibilities for this condition similar to those that other HHS programs put in place for declared emergencies, citing waivers issued in the context of public health emergencies for requirements of programs administered by the Centers for Medicare & Medicaid Services (CMS).

Response. We did not propose to create such a reporting system as suggested by the commenter nor is there currently a requirement for actors to routinely report to ONC which of their practices they believe they have structured to satisfy any information blocking exception(s). We thank the commenter for the suggestion.

Comment. A commenter noted the importance of minimizing administrative burden on health care providers, and specifically physicians delivering care in context of an emergency or disaster.

Response. The commenter did not specify the types of administrative burden it was concerned about, but we suspect the concern is related to documenting compliance with the conditions of the Infeasibility Exception, including § 171.204(b). We emphasize that the uncontrollable events condition does not require specific documentation to be satisfied, and we did not propose specific documentation requirements for an actor to satisfy the uncontrollable events condition in paragraph (a)(2). We also did not propose to change the requirements of the responding to requests condition (§ 171.204(b)). Both conditions remain the same in this regard. The responding to requests condition (§ 171.204(b)) does not include specific documentation requirements, but does require the actor to provide the requestor, in writing, the reason(s) why the request is infeasible within ten business days of receipt of the request. An actor has flexibility in demonstrating how they met the uncontrollable events and the responding to requests conditions of the Infeasibility Exception.

Comments. A commenter asked about an actor's burden of proof with respect to this exception.

Response. As noted in the response to the comment above, we did not propose in the HTI–1 Proposed Rule specific documentation requirements for an actor to satisfy the uncontrollable events condition or the responding to requests condition of the Infeasibility Exception. In the ONC Cures Act Final Rule (85 FR 25821), we stated that an actor seeking an exception needs to meet all relevant conditions of the exception at all relevant times. For the Infeasibility Exception, an actor seeking to satisfy the exception would need to demonstrate it satisfied one of the conditions in § 171.204(a) and the condition in § 171.204(b). Further, as we noted in the HTI–1 Proposed Rule, the actor would need to produce evidence and ultimately prove that complying with the request for access, exchange, or use of EHI in the manner requested would have imposed a clearly unreasonable burden on the actor under the circumstances (88 FR 23865, citing 85 FR 25866). We also refer readers to the ONC Cures Act Final Rule (85 FR 25819) for additional discussion on establishing that an actor's practice(s) meet the conditions of an exception.

Comments. Some comments we received discussed the responding to requests condition (§ 171.204(b)) as new or pending or in other ways that suggested some commenters may not have reviewed the full text of the existing Infeasibility Exception (§ 171.204) prior to commenting on the HTI–1 Proposed Rule.

Response. We thank all commenters for their feedback. We appreciate the opportunity to remind actors, and any persons who may seek EHI access from actors, where and how to find all the information blocking exceptions, and to discuss a bit further here the Infeasibility Exception's structure and its requirements.

First, we note that actors seeking to satisfy an exception, or other persons interested in when an exception applies, should review the exception's full regulatory text (found in the exception's section of 45 CFR part 171). In addition, the requirements and conditions of each exception set forth in subparts B, C, and D of 45 CFR part 171 should be read in context with the subpart's “availability and effect of exceptions” section (45 CFR 171.200, 45 CFR 171.300, and 45 CFR 171.400, respectively), as well as the general provisions in subpart A of 45 CFR part 171. The conditions under which each exception can be satisfied are specified in 45 CFR part 171. Where the conditions include any requirements the actor's practice must satisfy for an exception to apply, these requirements are included in that exception's section of 45 CFR part 171. For example, all of the conditions and requirements for the Infeasibility Exception to apply to an actor's practice of not fulfilling requested EHI access, exchange, or use due to the infeasibility of the request are specified in § 171.204. The general provisions in subpart A indicate the statutory basis and purpose of the information blocking regulations, the applicability of the regulations, and definitions of certain terms used in 45 CFR part 171.

Specific to the Infeasibility Exception, the requirement that, for this exception to apply, the actor's practice must satisfy at least one condition in paragraph (a) and also satisfy the condition in paragraph (b) of § 171. 204 has been in place since the Infeasibility Exception (§ 171.204) was established in the ONC Cures Act Final Rule (85 FR 25869 and 85 FR 25958; see also85 FR 25867). Thus, as is the case for a practice meeting any of the conditions codified in § 171.204(a), an actor's practice consistent with the § 171.204(a)(1) uncontrollable events condition would also need to meet the requirements of § 171.204(b), the responding to requests condition, for that practice to fully satisfy the Infeasibility Exception.

Comments. A few commenters suggested that 10 business days may not be enough time for an actor severely impacted by a disaster to become aware of and respond to requests received around the time the disaster occurred, or that actors may need time to recover from an event before they are able to respond to requests for EHI. One of these commenters cited the potential for some events to be sufficiently disruptive and that the actor would lose the ability to access requests received before and during the disruption. The commenter noted that a 10-day response time may be unreasonable in the middle of a major hurricane involving power outage, facilities damage, and displacement of staff members key to processing requests. A comment suggested specific changes to the responding to requests condition so that an automated notice a system is down be considered as sufficient “notice” to satisfy the exception.

Response. We did not propose in the HTI–1 Proposed Rule to change any aspect of the responding to requests condition (§ 171.204(b)) and decline to do so in this final rule. However, as it applies to actors' practices of not fulfilling requests that are infeasible because an uncontrollable event has, in fact, negatively impacted the actor's ability to fulfill access, exchange, or use of EHI, we welcome the opportunity to clarify that the responding to requests condition (§ 171.204(b)) does not focus on when the requestor sends or attempts to make the request. Rather, the responding to requests condition (§ 171.204(b)) specifies the “receipt of the request.” Satisfying the responding to requests condition, therefore, requires providing the reason for infeasibility in writing within ten business days of the actor receiving the request rather than counting ten business days from when a requestor may have sent or attempted to send the request.

Comments. A commenter supported the Infeasibility Exception and asked that ONC consider further examples and definitions of extreme and uncontrollable circumstances to prevent abuse of the condition.

Response. We appreciate the support. We note that the finalized revision to § 171.204(a)(1) includes the following additional clause at its end: “. . . that in fact negatively impacts the actor's ability to fulfill the request.” This new additional clause makes it clear that in order for the actor's not fulfilling a request to satisfy the § 171.204(a)(1) uncontrollable events condition, the uncontrollable event must, in fact, have had an adverse impact on the actor's ability to fulfill a request for EHI access, exchange, or use. We believe the clarifying modification will help prevent abuse of the condition because it will enable actors to more confidently and accurately assess when and how the uncontrollable events condition could be satisfied, thus deterring actors from asserting they cannot fulfill a request merely because an uncontrollable event that did not negatively impact the actor's ability to fulfill the request had occurred.

Summary of finalized policy—uncontrollable events condition of the Infeasibility Exception (§ 171.204(a)(1)): After consideration of comments received, we have finalized the revised uncontrollable events condition to the Infeasibility Exception with modifications to the proposed regulatory text. We have finalized our proposal to replace “due to” with “because of” in § 171.204(a). As discussed in response to comments, we have also added to the end of the text of § 171.204(a) the following: “that in fact negatively impacts the actor's ability to fulfill the request.” This addition is intended to improve the clarity with which the text conveys that to meet this specific condition of the Infeasibility Exception with respect to any request, an actor cannot simply assert that they cannot fulfill a request because an event consistent with § 171.204(a) occurred. To meet the condition, the actor must demonstrate that the uncontrollable event, in fact, negatively impacted the actor's inability to fulfill a request.

b. Infeasibility Exception—Third Party Seeking Modification Use

In the HTI–1 Proposed Rule (88 FR 23865 through 23867), we proposed to renumber the Infeasibility Exception's (45 CFR 171.204) infeasible under the circumstances condition from paragraph (a)(3) to paragraph (a)(5) and to codify at (a)(3) a new condition third party seeking modification use. We proposed, as discussed in section IV.B.1.c below, another new condition that would be codified as paragraph (a)(4) of § 171.204. We received no comments expressing a particular view on the redesignation of infeasible under the circumstances condition as subparagraph (a)(5) and have, based on finalization of proposed new conditions in (a)(3) and (a)(4), finalized the redesignation of the infeasible under the circumstances condition as (a)(5).

We proposed that the § 171.204(a)(3) third party seeking modification use condition would apply in certain situations where the actor is asked to provide the ability for a third party (or its technology, such as an application) to modify EHI that is maintained by or for an entity that has deployed health information technology as defined in § 170.102 and maintains within or through use of that technology any instance(s) of any electronic health information as defined in § 171.102. As a reminder, to fully satisfy the exception in § 171.204, an actor's practice must meet one of the conditions in paragraph (a) of § 171.204 and the requirements in paragraph (b) of § 171.204 (“. . . the actor must, within ten business days of receipt of [a] request, provide to the requestor in writing the reason(s) why the request is infeasible”).

We proposed (88 FR 23865 through 23867) that the third party seeking modification use condition of the Infeasibility Exception would be limited to situations when “[t]he request is to enable use of EHI in order to modify EHI (including, but not limited to, creation and deletion functionality), provided the request is not from a health care provider requesting such use from an actor that is its business associate” (88 FR 23916, emphasis added).

In § 171.102, we define “use” for purposes of the information blocking definition to mean “the ability for electronic health information, once accessed or exchanged, to be understood and acted upon.” We stated in the ONC Cures Act Final Rule that “acted upon” within the final “use” definition “encompasses the ability to read, write, modify, manipulate, or apply the information. . . .” (85 FR 25806). Therefore, in § 171.204(a)(3), we proposed to use “ third party seeking modification use ” as a descriptive title for the new proposed condition of the Infeasibility Exception applicable to an actor's denial of requests from a third party for “modification use” of EHI. In particular, this new condition focuses on requests to modify EHI held by or for a health care provider and is not applicable to third-party requests for other activities that would fall within the § 171.102 definition of the broader term “use.” For example, the new third party seeking modification use condition would not apply to any request involving only the ability to read or apply the information, which are other activities in the broader definition of use we used in the ONC Cures Act Final Rule. The third party seeking modification use condition is also not applicable to any request for “access” or “exchange” (as these terms are defined in § 171.102) of EHI.

The information blocking definition (§ 171.103) refers to the “access, exchange, or use” of electronic health information, and each of these terms is defined for purposes of 45 CFR part 171 in § 171.102. In this portion of the preamble, as in the HTI–1 Proposed Rule (88 FR 23865), we use the term “modify” or “modification use” to describe the particular type of “use” covered by this new condition. We do so to avoid confusion between this “modification use” and the definition of the broader term use in § 171.102. It is important to note that the term “modification use” in the proposed and finalized § 171.204(a)(3) refers to a specific type of use within the § 171.102 definition of the term use . Modification use focuses on actions on the EHI that change it in some way. Specifically, the condition focuses on requests to modify EHI held by or for a health care provider, but not to other types of “use,” such as the ability for EHI to be understood by a third party. The third party seeking modification use condition does not implicate, indicate, or imply any change to the definition of use in § 171.102 for any other purpose under 45 CFR part 171, or to any definition or other provision of the HIPAA Rules in 45 CFR parts 160 and 164. We recognize that HIPAA covered entities and business associates have an obligation under the HIPAA Privacy Rule to only disclose or use, in the sense of “use” as defined in 45 CFR 160.103, PHI as and when permitted or required under subpart E of 45 CFR part 164 or subpart C of 54 CFR part 1600 (see 45 CFR 164.502(a)). We have structured the information blocking regulations, including this finalized revision to the Infeasibility Exception, to accommodate that obligation. We note that the third party seeking modification use condition does not imply or indicate any change to the HIPAA Rules ( see88 FR 23865).

We proposed to add a definition of business associate to § 171.102 because we use the term in the third party seeking modification use condition. We proposed that the definition of business associate in § 171.102 would, by cross-reference to 45 CFR 160.103, be the same as the HIPAA Rules' definition of “business associate.” We emphasize that the § 171.204(a)(3) third party seeking modification use condition does not operate to change a business associate's rights or responsibilities under their business associate agreement (BAA) with any HIPAA covered entity. We also reiterate that the information blocking regulations do not require actors to violate BAAs or associated service level agreements. However, as we also previously explained in the ONC Cures Act Final Rule (85 FR 25812) and in information blocking FAQ28 (available at HealthIT.gov ), terms or provisions of BAAs could constitute an interference (and thus could be information blocking) if used in a discriminatory manner by an actor to forbid or limit access, exchange, or use of EHI that otherwise would be a permitted disclosure under the HIPAA Privacy Rule. To determine whether there is information blocking, the actions and processes ( e.g., negotiations) of the actors in reaching the BAA and associated service level agreements would likely need to be reviewed to determine whether there was any action taken by an actor that was likely to interfere with (“prevent, materially discourage, or otherwise inhibit”; § 171.102) the access, exchange, or use of EHI, and whether the actor had the requisite intent (85 FR 25812).

Comments. Comments received on the proposed § 171.204(a)(3) third party seeking modification use condition were generally supportive. Comments supporting this proposal commended the proposal's alignment with the policy goals expressed in the HTI–1 Proposed Rule, including reducing the burden on actors to document each modification use request in the same way that an actor would need to document its actions for the infeasible under the circumstances condition of the Infeasibility Exception. Some commenters supportive of this proposal also expressed appreciation for the proposal's applicability to situations where an actor may be concerned about the accuracy or reliability of data that a third party would like to add to an individual's designated record set maintained by the actor. A few commenters also noted that the proposed condition would simplify the handling of certain requests for EHI. A few commenters expressed support for the proposal's exclusion of requests that come from health care providers to their business associates.

Response. We appreciate the support expressed by many commenters. We have finalized the § 171.204(a)(3) third party seeking modification use condition with the minor modification of deleting the parenthetical “(including but not limited to creation and deletion functionality)” from the regulatory text in § 171.204(a)(3). This is done solely for readability purposes. The requests covered by this condition, as finalized, are to enable a third party EHI modification use functionality, including, but not limited to, creation and deletion functionality.

Comments. A few of the commenters did not support the proposal. Some of these commenters expressed concern that the proposal could potentially inhibit care coordination by making it too easy for an actor holding EHI to simply refuse modification use requests from third parties who also furnish services to the same patient(s). Some of these commenters expressed concern that certain actors, such as health IT developers of certified health IT, may seek to misuse the proposal to restrict access to EHI in an overly broad manner.

Response. We thank commenters for bringing to our attention their concerns about access, exchange, and use of EHI in support of care coordination. In developing our discrete proposal to provide further certainty to actors and now in finalizing this proposal, we have considered these concerns. In the HTI–1 Proposed Rule discussion of the reasons why this condition is not available to an actor when the actor is a business associate of a health care provider who is making the modification use request, we noted that there is often a level of trust and contractual protections between covered entities and business associates that removes certain concerns, such as security and data provenance, that led us to propose this new condition as structured (88 FR 23866). Many of these matters are addressed in business associate agreements, including security, as well as the permitted uses of the EHI (ePHI) that the covered entity grants the business associate. Further, the HIPAA Privacy and Security Rules place certain obligations on covered entities and their business associates that protect the privacy and security of EHI (and other PHI). For these reasons, we finalized this condition, as proposed, which permits actors to deny requests to modify EHI provided the request is not from a health care provider for which the actor is the business associate.

This condition was not proposed to apply, and as finalized does not apply, to an actor's practice of refusing to receive or process EHI via health information exchange or refusing to make EHI available for access, exchange, or use for permissible purposes. Where the manner or means of EHI use sought by a third party would not involve enabling a third party to modify (such as by adding to, creating, overwriting, editing, or deleting) EHI, then the condition does not apply even if the request is from someone other than a health care provider to whom the actor is a business associate. We also clarify that the third party seeking modification use condition applies only where a third party seeks modification use functionality for EHI within the records or systems maintained by the actor. This condition cannot be satisfied where a third party seeks access or exchange of EHI, even if the actor is certain that the requestor will or may make “modification use” of the EHI once it (or a copy of it) is in the requestor's possession, custody, or control. For example, the condition does not apply to situations where a health care provider, or their health IT developer chooses not to accept and process (such as through an EHR's receive and incorporate functions) EHI from a patient's health plan or prior health care provider or another of the patient's current health care providers. The condition also does not apply to read-only access (such as through API technology certified to any of the criteria in § 170.315(g)(7) through (10)), or to an actor's practice of refusing to make a patient's EHI available for access, exchange, or use by care coordination partners for permissible purposes. “Permissible purposes” is defined for purposes of the information blocking regulations in § 171.102.

Regarding commenters' concerns about entities potentially abusing the third party seeking modification use condition to restrict access, exchange, or use of EHI, the limited circumstances for which this condition applies, as described above and below, will mitigate any potential for abuse. This condition does not pose a problem for care coordination because it is very narrowly focused only on a particular manner of modification use of EHI (88 FR 23866) that the health care provider or the business associate would not have to enable, and it does not apply to a wide variety of manners by which health care providers routinely access, exchange, and use EHI for care coordination purposes. However, any abuse of this condition or any component of the information blocking regulations would be of concern to ONC, and we encourage anyone who believes they may have experienced or observed information blocking by any health care provider, health IT developer of certified health IT, or health information network or health information exchange to share their concerns with us through the Information Blocking Portal on ONC's website, HealthIT.gov. Information received by ONC through the Information Blocking Portal as well as the Health IT Feedback and Inquiry Portal also helps inform the development of resources we make publicly available on ONC's website, HealthIT.gov.

Comments. A few commenters requested that ONC provide further guidance on specific use cases where the third party seeking modification use condition could apply, including materials such as FAQs, scenario-based guidance, and examples of documenting use of the condition, including for behavioral health providers. One commenter recommended that documentation requirements for the condition be minimal.

Response. We thank commenters for their feedback. We release educational resources on an ongoing basis. ONC-published resources can be found on HealthIT.gov and to date include for the HTI–1 rulemaking: recorded webinars (both general and tailored for particular topics and audiences), fact sheets, measurement spec sheets, blog posts, and a new website hub for links to various materials and educational resources. In addition to the examples we provided in the HTI–1 Proposed Rule and provide in this final rule describing the applicability of this condition, we will continue to provide resources such as infographics, fact sheets, webinars, and other forms of educational materials and outreach. Resources specific to the information blocking regulations in 45 CFR part 171, across this and other ONC rules, are available on HealthIT.gov. The short URL that redirects to the information blocking landing page is: healthit.gov/informationblocking.

Regarding documentation requirements, we have not proposed or finalized a specific documentation requirement for the third party seeking modification use condition. In general, actors have flexibility to determine what documentation to create or keep in the event that they seek to claim an exception. However, as also discussed under the uncontrollable events condition above, an actor would need to demonstrate for each practice for which the Infeasibility Exception is sought on the basis of the third party seeking modification use condition (§ 171.204(a)(3)) that the condition was met at all relevant times and that the condition in § 171.204(b) was also met.

Comments. One commenter stated that the exceptions in subparts B and C of 45 CFR 171 are too complex for small health care providers, do not provide additional clarity, and that ONC should provide separate, simplified exceptions for health care providers.

Response. As we noted in the ONC Cures Act Final Rule, (85 FR 25819), we tailor information blocking exceptions and provide significant detail within each exception to clearly explain what an actor must do to meet each exception. For each exception, we typically propose and finalize conditions that can be consistently applied across all actors. However, there are conditions within certain exceptions that apply to one or a subset of actors, as applicable (85 FR 25819). As we stated in the ONC Cures Act Final Rule, the clearest and most equitable approach to the exceptions is to make all of the exceptions apply to all actors (85 FR 25819). Therefore, we decline the commenter's recommendation to provide “separate, simplified exceptions for health care providers.”

We believe that our explanations of the exceptions, as included in the ONC Cures Act rulemaking and in the HTI–1 Proposed Rule and this final rule provide the necessary clarity for health care providers, including small health care providers, to understand and apply the exceptions. As discussed throughout this final rule, we also invest in educational outreach to interested parties, including small health care providers and associations that represent them, in an effort to further explain the exceptions through presentations and written resources such as fact sheets.

We also note that the exceptions are voluntary and offer an actor certainty that a practice that satisfies all of the relevant conditions of an exception will not be considered information blocking. Further, we reiterate that failure to meet an exception does not necessarily mean a practice meets the definition of information blocking. By satisfying an exception, an actor gains the assurance that the actor's practice does not constitute information blocking. An actor's practice that does not meet the conditions of an exception does not automatically constitute information blocking, as the practice must still meet all the elements of the information blocking definition to be considered information blocking, including that the practice is likely to interfere with the access, exchange, or use of EHI, and that the actor acted with the requisite intent (85 FR 25820).

Comments. A few commenters responded to our request for comment on whether the condition should be of limited duration, and specifically, whether we should consider proposing to eliminate the condition if, at some point in the future, health information technology is capable of supporting lawful third-party modification use of EHI by any party with no or minimal infeasibility or other concerns. The majority of comments on this subject stated either that the proposal should not have a sunset date, or that it would be premature to establish a sunset date at this time. Two commenters stated that the condition should or could be eliminated in the future if the future technology is capable of supporting the aforementioned modification use of EHI, with no or minimal infeasibility or other concerns.

Response. We thank the commenters for their feedback. We agree that it would be premature to establish a sunset date for the condition because the appropriateness of eliminating the condition depends on the continued development of health IT's capability to support lawful third-party modification use of EHI by any party and with no or minimal infeasibility or other concerns. Because the pace of that continued health IT development is difficult to predict, we are not establishing a sunset date for § 171.204(a)(3) at this time. If advances in health IT capabilities or other changes in the interoperability and information sharing environment indicate to us that this condition should be modified or sunset, we would anticipate proposing such a change in a future rulemaking.

Comments. Three commenters expressed a concern that, as written, the condition would not apply to requests to “exchange” EHI by adding new EHI to a system through exchange from a third party. The commenters stated that ONC should add “exchange” of EHI to the condition.

Response. We thank the commenters for their feedback. The third party seeking modification use condition of the Infeasibility Exception is available to most actors to address situations where a third party's request is to modify EHI stored or maintained by an actor (88 FR 23866). The condition focuses on requests for a third party to have functionality to make modification use of EHI while, and as, it is held in the records or systems of the actor. We did not propose the condition to apply, and it cannot be met, where a third party is seeking to exchange EHI with the actor or to access a copy of EHI, even if the actor may know or reasonably suspect that the third party may modify (or have modified) EHI that is in records, applications, or systems maintained by the third party.

In situations where an actor receives EHI via exchange from a third party, whether that EHI is reconciled and incorporated into the record (“added” to the record) is a determination for the health care provider and potentially its business associates. Any such exchange of EHI and subsequent determinations to reconcile and incorporate EHI into the record (or not) is not within the scope of the proposed condition. Such practices and scenarios may implicate the information blocking definition, but there may also be other conditions or exception that apply depending on the specific facts and circumstances.

Comments. Commenters stated that the limitation to this condition is not broad enough, and that ONC should expand the limitation of this condition to also apply when the actor's customers are not HIPAA covered entities, or are not health care providers, but are maintaining EHI in systems licensed by an actor. Two commenters stated that the § 171.204(a)(3) third party seeking modification use condition should not apply in circumstances where the actor is a business associate or contractor of the organization that has licensed the interoperability elements or systems responsible for maintaining EHI. Along these lines, two other commenters expressed a concern that an actor, such as a health IT developer of certified health IT, that maintains EHI on behalf of an HIN/HIE could use this condition to deny an HIN/HIE's request, using third-party technology, for modification use of EHI maintained by the HIN/HIE. The commenters suggested that ONC clarify that the condition does not apply where a HIN/HIE requested modification use of EHI held by a health care provider or their health IT developer.

Response. We thank the commenters for their feedback. We finalized the limitation to this condition to apply when the actor is a business associate of a health care provider making the modification use request, and we are not at this time expanding the limitation of the condition as some commenters suggested. As we noted in proposing this condition, there is often a level of trust and contractual protections between covered entities and business associates that removes certain concerns, such as security and data provenance, that led us to propose this new condition (88 FR 23866). We explained in the HTI–1 Proposed Rule discussion of the limitation of this condition that covered entities (health care providers) and their business associates (as permitted by their BAA) need to access and modify relevant EHI held by other business associates of those covered entities on a regular basis (88 FR 23866). Because our proposal focused on the obligations that the HIPAA Privacy and Security Rules place on covered entities and their business associates to protect the privacy and security of EHI (and other PHI), we decline to expand the limitation of the condition at this time.

Regarding the commenters' concern about the application of the condition, we note that if the request for modification use is from the health care provider requesting such use from an actor that is the health care provider's business associate, the condition would not apply. Even if the actor who is a business associate of a health care provider could provide, or currently provides, items or services or engages in activities similar or identical to those the health care provider wants the third party to have modification use of EHI to accomplish, the condition does not apply when the actor is the business associate of the health care provider requesting modification use of EHI. Likewise, the finalized condition does not apply to an actor's denial of modification use by a third party where the actor is a subcontractor of any business associate to a health care provider, and the health care provider requests such use of EHI maintained by or on behalf of the health care provider. A “business associate” is a person or entity, other than a member of the workforce of a covered entity, who performs functions or activities on behalf of, or provides certain services to, a covered entity that involve access by the business associate to PHI (§ 171.102). A “business associate” is also a subcontractor that creates, receives, maintains, or transmits PHI on behalf of another business associate.

For purposes of the provision “carving out” requests from a health care provider to an actor that is its business associate from application of § 171.204(a)(3), it does not matter whether the health care provider merely licenses or otherwise obtains from the actor use of interoperability elements that would be necessary to enable a third party's modification use of EHI that the health care provider maintains, or the health care provider contracts with the actor to maintain and manage on the health care provider's behalf. If the actor is a business associate of the health care provider and the provider requests modification use by a third party of EHI, then the condition does not apply to the actor's denial of that request.

For these reasons, and in consideration of these and all comments received on our discrete proposal, we finalized, as proposed, a condition that permits actors to deny requests to modify EHI provided the request is not from a health care provider for which it is the business associate. We have not at this time expanded the limitation to the condition as the commenters requested. However, we note that we may consider amending the third party seeking modification use condition or taking other appropriate steps in future rulemaking in response to changing market conditions, experience with the condition in practice, or other signals that suggest amending the condition may be appropriate.

As a reminder, the third party seeking modification use condition does not operate to change an actor's contractual obligations to their customers. When an actor engages in a practice to deny modification use of EHI under the third party seeking modification use condition, they may also wish to consider whether the practice violates any of their existing contractual obligations.

Comments. Several commenters raised issues that are out of scope for this proposal, including:

• asking ONC to reiterate that actors cannot claim this exception to prevent requests from an individual or their personal representatives to amend the individual's PHI or record as permitted by the HIPAA Privacy Rule;
• a request for ONC to study what entities have access to health care providers' EHRs, why those entities may request to access or change authenticated documents or clinical notes, how health care providers evaluate the accuracy of data a third party wants to add to an individual's EHI, the potential benefits and harms of incorporating such data, and whether this condition would be possible in a future environment in which the Trusted Exchange Framework and Common Agreement (TEFCA) is actively exchanging data;

• asking ONC to consider whether patients should be consulted before data from another health care provider is incorporated into their EHI;

• asking ONC to consider what annotation mechanisms are or should be in place to create an audit trail for modifications to EHI;
• asking ONC to establish incentives for third-party applications to utilize best practices regarding maintaining the integrity and security of electronic health information;
• a request that the ten-business day timeline established in § 171.204(b) should be revised to be longer;
• a request to include in the certification criteria for health IT the functionality to alert an actor when a third party seeks modifications to EHI in the actor's system(s);
• recommending that ONC update certification criteria to better support health care providers' ability to use third-party apps maintained in certified health IT, utilizing existing APIs and support for user-created fields, while minimizing risks to data security and EHR performance;
• requesting examples of how providers should store information from a third party separate from the medical record, and requesting ONC work with health IT developers to implement a mechanism for providers to maintain data that has not been integrated into the medical record.

Response. We thank commenters for their input and reiterate our continued commitment to supporting EHI sharing consistent with patient preferences and applicable law. Whether received as out-of-scope comments on a proposed rule or through informal channels, the feedback, and questions we receive, are appreciated and help to inform our development of information resources that we make publicly available on HealthIT.gov. Informal channels include, for example, the Health IT Feedback and Inquiry Portal that is available year-round and not tied to the comment period for a proposed rule.

Regarding the relationship between the finalized § 171.204(a)(3) third party seeking modification use condition and the HIPAA Rules, we note again, as we did in the HTI–1 Proposed Rule, that the third party seeking modification use condition does not imply or indicate any change to the HIPAA Rules ( see88 FR 23865). Actors should note and should operate with awareness that a practice satisfying any information blocking exception in 45 CFR part 171 simply means that practice is not considered to be “information blocking” as defined in § 171.103. Any actor (as defined in 45 CFR 171.102) that is also subject to any provision(s) in 45 CFR parts 160, 162, or 164 must continue to comply with such provision(s) when and to the extent such provisions of the HIPAA Rules are applicable to the actor's conduct.

Summary of Finalized Policy: Third Party Seeking Modification Use Condition

As noted above and for the reasons stated above and in the HTI–1 Proposed Rule, we have finalized the condition as proposed with a non-substantive edit to simplify the regulation text by removing the parenthetical “(including, but not limited to, creation and deletion functionality).”

We note that for purposes of this condition, an actor may choose to verify that the modification use request came from the health care provider themselves or accept the third party's representation of a request as coming from a health care provider. Any actor considering whether to potentially avail themselves of the certainty offered by this exception will have flexibility to structure their communications approaches and operating procedures for communicating with the health care provider of which the actor is a business associate, or with third parties representing themselves as business associates of such health care provider. This flexibility enables actors to operate and communicate efficiently while complying with the actor's obligations under the HIPAA Privacy Rule, other applicable law, and its binding agreements (including its BAAs) with the health care providers who choose to request modification use for a third party functionality either directly from the actor or through one of the health care provider's business associates. As discussed above under comments on documentation, an actor would need to demonstrate for each practice for which the Infeasibility Exception is sought on the basis of the third party seeking modification use condition (§ 171.204(a)(3)), that it met the third party seeking modification condition and also met the § 171.204(b) responding to requests condition at all relevant times.

As with every other condition in § 171.204(a), we note that the § 171.204(a)(3) third party seeking modification use condition stands alone. This means an actor's practice could meet it without needing to meet any other § 171.204(a) condition. It also means an actor's practice that fails to meet the § 171.204(a)(3) third party seeking modification use condition could nevertheless satisfy another of the conditions, such as the infeasible under the circumstances condition in § 171.204(a)(5).

We emphasize that other conditions within § 171.204(a) and all of the other exceptions would remain available for consideration by the actor as to their applicability to the situation and request where the finalized § 171.204(a)(3) third party seeking modification use condition of the Infeasibility Exception would not be available.

c. Infeasibility Exception—Manner Exception Exhausted

In the HTI–1 Proposed Rule, we proposed to renumber the Infeasibility Exception's (45 CFR 171.204) “ infeasible under the circumstances” condition from paragraph (a)(3) to paragraph (a)(5) and to codify at (a)(4) a new “ manner exception exhausted” condition (88 FR 23867). We stated that the proposed manner exception exhausted condition would apply where an actor is still unable to fulfill a request for access, exchange, or use of EHI after having exhausted the exception in § 171.301 (which we have in this rule renamed Manner Exception, see Section IV.A.1), including offering all alternative manners in accordance with § 171.301(b), so long as the actor does not currently provide to a substantial number of individuals or entities similarly situated to the requestor the same requested access, exchange, or use of the requested EHI (88 FR 23867).

In the ONC Cures Act Final Rule (85 FR 25642), we finalized the Infeasibility Exception with modifications from the proposal (84 FR 7542 and 7603) to address concerns raised by commenters ( see85 FR 25866 through 25870). We finalized (85 FR 25858) three conditions that more specifically address situations where the Infeasibility Exception would be appropriately used. One of the conditions we finalized, infeasible under the circumstances, requires the actor to demonstrate, through a contemporaneous written record or other documentation, its consideration, in a consistent and non-discriminatory manner, of certain factors that led to its determination that complying with the request would be infeasible under the circumstances. The Infeasibility Exception (§ 171.204), as finalized in the ONC Cures Act Final Rule, provides assurance to an actor that if it meets applicable conditions of the exception at all relevant times, its practice will not be considered information blocking.

Also, in the ONC Cures Act Final Rule, we finalized the “Content and Manner Exception” (now the Manner Exception) (45 CFR 171.301). Under § 171.301, for the Manner Exception to apply, an actor must fulfill a request for access, exchange, or use of EHI in any manner requested, unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request (45 CFR 171.301(b)(1)(i), as originally codified). If an actor and requestor reach agreeable terms and the actor fulfills a request described in the manner condition in any manner requested: (1) Any fees charged by the actor in relation to its response are not required to satisfy the Fees Exception in § 171.302; and (2) any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the Licensing Exception in § 171.303 (45 CFR 171.301(b)(1)(ii), as originally codified) (85 FR 25877).

Section 171.301(b)(2) (original codification, redesignated in this final rule as § 171.301(b)) provides for fulfilling a request to access, exchange, or use EHI in a manner other than the manner requested. If an actor does not fulfill a request in any manner requested because it is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request, the actor must fulfill the request in an alternative manner agreed upon with the requestor consistent with § 171.301(b)(2) (original codification, now redesignated § 171.301(b)) in order to satisfy the exception (85 FR 25877). The Manner Exception offers certainty that an actor's practices that fully satisfy the Manner Exception's conditions will not be considered information blocking and is meant to incentivize offering an alternative manner (with priority to interoperable manners based on HHS-adopted and available open standards) when the actor is unable to fulfill access, exchange, or use of the requested EHI in the manner initially requested.

As discussed in the HTI–1 Proposed Rule, actors expressed uncertainty to ONC as to whether they have satisfied the infeasible under the circumstances condition in instances where they contended that fulfilling a request for access, exchange, or use of EHI would be infeasible (85 FR 23867). Under the Infeasibility Exception, the infeasible under the circumstances condition requires the actor to demonstrate that complying with the request is infeasible when considering, among other things, the financial and technical resources available to the actor and why the actor was unable to provide access, exchange, or use of EHI consistent with the Manner Exception. Specifically, actors have expressed concern about circumstances where the actor's inability to satisfy the Manner Exception's conditions rests solely on the requestor refusing to accept access, exchange, or use in any manner consistent with § 171.301, and fulfilling the request in the manner requested would require substantial technical or financial resources (or both) in the view of the actor, including significant opportunity costs. We have observed this being more of a concern for actors with significant skills and other resources for developing unique technical solutions or new technological capabilities ( e.g., EHR developers or HIN/HIEs) than for actors with few to no such resources ( e.g., small clinician office practices or safety net clinics), because, as noted, the infeasible under the circumstances condition of the Infeasibility Exception (§ 171.204(a)(5); previously § 171.204(a)(3)) requires actors to demonstrate their consideration of the financial and technical resources available to them, as well as why the actor was unable to provide access, exchange, or use of EHI consistent with § 171.301.

Among those actors with substantial skills and other resources to develop new, unique or unusual manners of supporting access, exchange, or use of EHI, we see actors who appear to be experiencing a problematic level of uncertainty about whether they will be engaging in information blocking if they decline demands from requestors for non-standard or non-scalable solutions that they do not currently support even after they have offered to provide access, exchange, or use of EHI in the same manner(s) the actor makes generally available to its customers or affiliates, and through standards-based manners, consistent with § 171.301—including offering terms for such manners that are consistent with the Fees (§ 171.302) and Licensing (§ 171.303) Exceptions. We anticipate that this uncertainty will lead actors who, again, have already exhausted the Manner Exception (§ 171.301), to divert their development capacity to fulfilling requested manners of access, exchange, or use of EHI that they could invent to meet the demands of a requestor determined to accept only the original manner they specified and who are unwilling or unable to agree to terms consistent with the Fees (§ 171.302) and Licensing (§ 171.303) Exceptions for their requested manner or any alternative manner consistent with the Manner Exception (§ 171.301) (88 FR 23868).

We stated in the HTI–1 Proposed Rule (88 FR 23868) that this new condition is necessary to ensure actors reasonably allocate resources toward interoperable, standards-based manners rather than allowing requestors, who, for whatever reason, do not build their products for compatibility with open consensus standards or other industry standards to attempt to force use of non-standard or non-scalable solutions by simply refusing to accept access, exchange, or use of EHI in any other manner. This diversion of resources away from standards-based and scalable manners of exchange detracts from, instead of supporting, achievement of key policy goals such as increased interoperability and innovation in use of open consensus standards to achieve secure, seamless exchange. Where novel approaches to system interfaces or other aspects of access, exchange, or use of EHI represent improvements over other available approaches, we anticipate these approaches will not need to be forced upon the industry but will instead find a natural foothold and diffuse according to a normal innovation curve.

Therefore, to reduce confusion and provide more certainty to actors, we proposed and have finalized at § 171.204(a)(4) a new condition in the Infeasibility Exception, the manner exception exhausted condition. Actors will be able to satisfy this exception when they have “exhausted” the manner requested condition and alternative manner condition of the Manner Exception and meet the other requirements of the new condition. If an actor either technically cannot provide the access, exchange, or use of EHI in the manner requested, or the actor and requestor cannot reach agreeable terms on the manner requested, then the actor must attempt to fulfill the request using the alternative manners in § 171.301(b) (85 FR 25877) (previously § 171.301(b)(2)(i)). Under the Manner Exception, for any alternative manner, the requestor must either specify the manner they would accept (§ 171.301(b)(2)(i)(A) and (B)) or specifically agree with the machine-readable format that they would accept (§ 171.301(b)(2)(i)(C)). In situations where an actor offers the alternative manners and the requestor does not specify or agree to receive the EHI via the offered alternative manners (as may be the case if the requestor does not want to receive the EHI in such a manner or cannot receive the EHI in such a manner), an actor may now seek to satisfy the new finalized manner exception exhausted condition of the Infeasibility Exception.

Previously, an actor who offered all the alternative manners would likely look to the infeasible under the circumstances condition of the Infeasibility Exception, which requires actors to demonstrate that complying with the request is infeasible when considering many factors, including the cost to the actor of complying with the request in the manner requested and the financial and technical resources available to the actor. The newly finalized manner exception exhausted provides actors the option of satisfying the Infeasibility Exception without needing to assess whether they could meet the requestor's particularized demands regarding the manner and/or terms in which they want to obtain access, exchange, or use of the requested EHI.

Comments. Most commenters were supportive of ONC's proposal to add the manner exception exhausted condition to the Infeasibility Exception. Commenters stated that it would reduce burden and allow actors to focus on innovation. Many commenters appreciated that the condition encourages use of standards-based mechanisms, and that it removes the uncertainty that could come about if it is technically infeasible for an actor to fulfill a request or when the actor has offered the alternative manners, but the requestor has not specified or agreed, as applicable, to access, exchange, or use of the EHI in any of those manners. Many commenters also appreciated ONC's acknowledgment that interoperable, standards-based exchange should be favored over expensive, resource-intensive, one-off solutions. Other commenters expressed appreciation that the condition allows health IT developers of certified health IT and other actors the opportunity to reach agreement on market-based terms and pricing to protect investments, while still promoting interoperability. A few commenters also expressed appreciation that the condition can be met without the actor needing to demonstrate they considered the resources available to the actor, and that exchanging entities will be protected from costly technical changes or solutions made solely to avoid claims of information blocking.

Alternately, a few commenters expressed general disagreement with the proposed condition. One commenter expressed concerns that the condition could be interpreted to allow actors to remain in exchange patterns that do not expand interoperability across a range of requestors and use cases. Another commenter noted that atypical requests may be necessary to achieve a particular use of EHI that is not adequately supported by existing standards.

Response. We thank commenters for their thoughtful feedback. Upon consideration of all comments received related to this proposal, we have finalized the condition as proposed with two modifications discussed below. We agree that the manner exception exhausted condition prioritizes interoperability and encourages efficiency by applying the Infeasibility Exception under circumstances where the actor cannot meet, or cannot be certain that they have met, the infeasible under the circumstances condition. We recognize that custom, one-off solutions can be costly and inhibit investment in innovative, scalable approaches to interoperability and exchange. We also recognize that atypical requests may be necessary to achieve a particular use of EHI and note that nothing in the information blocking regulations would prevent a requestor and actor from coming to an agreement to achieve innovative solutions to interoperability challenges or atypical use cases. To this point, we previously established the manner requested condition of the Manner Exception, now codified in § 171.301(a), which permits actors and requestors to come to terms on access, exchange, and use of EHI without such terms necessarily satisfying the § 171.302 Fees Exception or § 171.303 Licensing Exception.

In response to concerns that this may allow actors to remain in exchange patterns that do not expand interoperability, we note that satisfying the finalized manner exception exhausted condition of the Infeasibility Exception requires the actor to offer a standards-based method of exchange, either through certified health IT or using technology and transport standards published by the federal government or a standards developing organization accredited by the American National Standards Institute (ANSI). Both methods would support interoperability, and the use of certified health IT incrementally expands interoperability through certification to new and revised certification criteria that include new and updated standards and capabilities.

How many alternative manners are required to satisfy the condition?

In the HTI–1 Proposed Rule, we stated that it is important that the Manner Exception not be considered exhausted if the actor offers only one alternative manner, or only the least-interoperable “alternative machine-readable format” now codified in § 171.301(b)(1)(iii) (88 FR 23869). Therefore, we proposed a second factor requiring actors to have offered all three alternative manners in accordance with § 171.301(b) (88 FR 23869). We requested comments on how many of the alternative manners an actor should be required to offer in order to satisfy the proposed manner exception exhausted condition of the Infeasibility Exception: one, two, or all three alternative manners.

As explained below, we have finalized the manner exception exhausted condition of the Infeasibility Exception with a requirement that an actor offer two alternative manners, at least one of which must be either the alternative manner in § 171.301(b)(1)(i) or (b)(1)(ii). These alternative manners are, respectively, “[u]sing technology certified to standard(s) adopted in part 170 that is specified by the requestor” (in other words, via health IT certified under the ONC Health IT Certification Program, 45 CFR part 170) or, “[u]sing content and transport standards specified by the requestor and published by: (A) the Federal Government; or (B) a standards development organization accredited by the American National Standards Institute” (45 CFR 171.301(b)(1)). An actor may offer both of these alternative manners to satisfy this particular factor of the manner exception exhausted condition, or only one of these two and the manner specified in § 171.301(b)(1)(iii), which is “[u]sing an alternative machine-readable format, including the means to interpret the electronic health information, agreed upon with the requestor.” If the actor offers the EHI in at least two manners including one of either (b)(1)(i) or (b)(1)(ii), then this factor of the finalized manner exception exhausted condition is satisfied.

Comments. Responses to our request for comment on how many alternative manners an actor should be required to offer before this condition would be available reflected a broad range of perspectives. Many commenters said two alternative manners should be enough. Other commenters said just one, and a couple of commenters suggested requiring actors to exhaust all of the actor's own manners of exchange prior to making use of the condition. Another commenter requested that an actor be required to demonstrate that they have inventoried all of the information sharing tools available that could be offered as an alternative manner and require the actor to have made those available to the requestor before they can satisfy the condition. One commenter asked for a specific carve-out for health care providers that would only require them to offer access, exchange, or use in the manners supported by their certified health IT or any other manner that requires minimal effort. Another commenter suggested a specific carve-out for health care providers who do not use certified health IT, stating that it should be enough for such actors to offer access, exchange, and use only in a machine-readable manner. One commenter suggested that ONC require actors to offer a minimum of two manners for USCDI data elements, and only one alternative manner for any EHI beyond USCDI.

Response. After reviewing all comments, in § 171.204(a)(4)(ii), we have finalized the regulatory text so that the manner exception exhausted condition can be satisfied when an actor (who was unable to fulfill a request for access, exchange, or use of EHI because they could not reach an agreement with a requestor or were technically unable to fulfill the request in the manner requested) offered the requestor at least two alternative manners, one of which must use either technology certified to standard(s) adopted in part 170 that is specified by the requestor (§ 171.301(b)(1)(i)) or published content and transport standards consistent with § 171.301(b)(1)(ii).

By requiring actors to offer at least one of the first two alternative manners (as listed in § 171.301(b)(1)(i)–(iii)), we are balancing the interest of the actor in achieving certainty that the practice will fulfill the new condition, while also ensuring that interoperable, standards-based exchange remains favored over other methods of exchange. We believe that requiring all three alternative manners, as originally proposed, would place an unequal burden on actors who are not required by other government regulations or incentivized by any public or private program to use certified health IT. We believe that requiring two alternative manners, one of which must be more interoperable than is typically the case with a machine-readable format ( i.e., § 171.301(b)(1)(iii)), ensures that the condition will not have the undesirable effect of dampening actors' or requestors' enthusiasm for adopting and advancing standards-based interoperability.

The finalized requirement for the actor to have offered at least two alternative manners also balances the interests of those commenters who requested the condition be satisfied with just one alternative manner and those who wanted all three alternative manners. While nothing would stop an actor from offering a requestor all available manners at its disposal, we believe making that a requirement to satisfy the manner exception exhausted condition would render the condition impractical for many actors to satisfy and defeat at least a portion of our purpose in proposing it: to offer actors a simpler option for certainty than was already available in the infeasible under the circumstances condition. We also note that an actor could respond to a request by providing as much of the EHI as possible via any manner requested or an alternative manner, and still make use of the infeasible under the circumstances condition for any other EHI that they are technically unable to offer via an alternative manner, so long as the practice satisfies all the requirements of that condition (now § 171.204(a)(5)). As a reminder, to meet the Infeasibility Exception as a whole, actors will still, regardless of the condition(s) satisfied in paragraph (a) in § 171.204, also need to satisfy the condition in paragraph (b): responding to requests.

Comments. Some commenters expressed confusion over what exactly is an “alternative manner.” One commenter stated that, taken literally, “all alternative manners” would force an actor to offer tens or hundreds of possible technical solutions.

Response. We appreciate the comments and the opportunity to address the confusion. When referring to “alternative manners” we do not mean all possible manners of exchange other than the manner requested. Rather, we specifically mean only manners that would be consistent with subparagraph (i), (ii), or (iii) of § 171.301(b)(1). Offering as few as one option per category is sufficient to satisfy either paragraph (b)(1) of the alternative manner condition of the Manner Exception (§ 171.301) or the “at least two alternative manners” requirement finalized as part of this manner exception exhausted condition (subparagraph (a)(4)) of the Infeasibility Exception (§ 171.204).

Comments. A commenter asked that ONC clarify that responding actors are responsible to exchange EHI for the purpose and in the manner requested, if they are able to do so, even if they are not accustomed to utilizing the requested transaction pattern.

Response. We appreciate the opportunity to clarify. The commenter is incorrect. An actor may satisfy any of the exceptions to the information blocking definition in order to have certainty that their practice is not information blocking. Under the manner requested condition (now § 171. 301(a)) of the Manner Exception, an actor responding to a request to exchange EHI for a certain purpose and in a certain manner must only do so if they are technically able to and reach an agreement with the requestor. If they are not technically able to do so, or cannot reach agreement with the requestor, then an actor seeking certainty that their practice would not be information blocking would need to either satisfy the other conditions of the Manner Exception or satisfy a different exception to the information blocking definition. The exceptions to the information blocking definition are voluntary and offer an actor certainty that a practice that satisfies all of the applicable requirements and conditions of an exception at all relevant times will not be considered information blocking.

The manner exception exhausted condition is not available when exchange is technically feasible and can be accomplished consistent with the Manner Exception, whether because the parties have agreed to terms for fulfillment in the manner requested ( manner requested condition) or because the requestor has specified and/or agreed to accept access, exchange or use consistent with the Manner Exception's alternative manner condition—even if the actor is not accustomed to utilizing the requested manner to support access, exchange, or use of the EHI the requestor seeks, in general or for the same or similar permissible purpose a particular requestor seeks EHI access, exchange, or use. In other words, this condition would not be available if a responding actor is able to exchange EHI in the manner requested, and the parties have either reached agreeable terms for such access, exchange, or use; or the requestor has specified and/or agreed to accept such access, exchange or use in an alternative manner consistent with the Manner Exception. We emphasize that nothing about the manner exception exhausted condition prevents an actor from providing a requestor with a custom build for access, exchange, or use of EHI. Rather, this condition has been adopted to alleviate actor uncertainty as to whether they must provide the custom build or otherwise be considered to have engaged in information blocking.

We note that in cases where a requestor seeks a specific alternative manner of access, exchange, or use consistent with § 171.301(b)(1), and the actor declines to offer that manner (even if the actor is able to accommodate the requested alternative manner) and instead offers a different alternative manner, the OIG may consider this as a factor in determining whether information blocking has occurred, particularly if the requestor is unable to access, exchange or use the EHI in the offered alternative manner. For example, if a requestor specifies a FHIR-based API as its preferred alternative manner of access, exchange, or use, and the actor is capable of doing so, then the actor should prioritize fulfilling the request via FHIR, even if the actor is also capable of fulfilling the request via another alternative manner, such as C–CDA document exchange. ONC has consistently maintained this policy approach because it best ensures that EHI is made available where and when it is needed (for further discussion, see the ONC Cures Act Final Rule at 85 FR 25877).

Comments. A commenter stated that if an actor is unable to reach agreeable terms with a requestor for access, exchange, or use of EHI, or is technically unable to fulfill a request in the manner requested, and then proceeds to offer one or more alternative manners and the requestor is still not satisfied, then the burden should shift to the requestor to demonstrate and justify why the alternatives proposed by the actor are infeasible or otherwise insufficient to meet their needs. Further, the commenter stated that the actor who received the request should have a duty to respond to the requestor only after receiving a written statement setting forth such justification.

Response. We appreciate the comment. We decline to adopt this suggestion, however, because we find it inappropriate to entirely shift the burden to the requestor. Our information blocking regulatory scheme, consistent with the statutory information blocking definition, supports policy goals of discouraging interference with EHI access, exchange, or use, and encouraging routine, interoperable EHI sharing for permissible purposes consistent with patients' privacy preferences. Although we recognize there is substantial variation in actors' and requestors' circumstances, we do not believe our policy goals would be well served by identifying as “reasonable and necessary” any actor's practice of demanding a requestor to justify to the actor their need or preference for a different manner of EHI access, exchange, or use than the actor prefers to offer (42 U.S.C. 300jj–52). A key aim of our information blocking regulatory scheme is to discourage information blocking by actors and make it easier for requestors to obtain, for any permissible purpose, EHI access, exchange, or use in a manner that meets the requestor's needs. The condition, as finalized, requires the actor to offer only two alternative manners, at least one of which is standards-based. It, therefore, allows the actor enough flexibility to avoid developing one-off, unique, custom solutions unless the actor wants to do so. The actor who satisfies the § 171.301 Manner Exception by meeting the manner requested condition would not need to also satisfy any condition in the § 171.204 Infeasibility Exception, assuming all requested EHI was provided consistent with the Manner Exception. The § 171.301(a) manner requested condition also, we reiterate, allows the actor and requestor to come to any mutually agreeable terms, thereby allowing for those requestors, able and willing to do so, to satisfy any financial incentive the actor would require to develop any requested manner, however unique or one-off, the requestor might want developed.

Comment. At least one commenter stated that this condition should still be available in circumstances where the only applicable option is a “machine-readable format,” in other words, § 171.301(b)(1)(iii).

Response. We appreciate the comment. As stated above, we have finalized this condition with a requirement that the actor offer at least two “alternative manners” from § 171.301(b)(1)(i)–(iii), one of which must be either the alternative manner in § 171.301(b)(1)(i) or (b)(1)(ii). Because a machine-readable format is the option of last resort, and the least-interoperable of all the alternative manners, we believe that allowing a requestor to offer only a machine-readable format would be at odds with the purpose of the new condition. We note that an actor who is able only to offer access, exchange, or use of EHI in a manner consistent with § 171.301(b)(1)(iii) would not be able to make use of this condition but could still conform its practice to another applicable condition (for example, the infeasible under the circumstances condition of the Infeasibility Exception) in order to have certainty that the practice would not constitute information blocking. Moreover, even a practice that does not satisfy any exception does not automatically constitute information blocking. The facts and circumstances of any situation or allegation would need to be evaluated, and whether the practice constitutes information blocking depends on the unique facts and circumstances of the practice.

What counts as a “substantial number”?

We proposed, as the third factor of the manner exception exhausted condition, that the condition would be available only if “the actor does not provide the same access, exchange, or use of the requested electronic health information to a substantial number of individuals or entities that are similarly situated to the requestor.” In the HTI–1 Proposed Rule, we stated that “this factor as a whole serves a similar function to the § 171.204(a)(5) (originally codified in § 171.204(a)(3)) infeasible under the circumstances condition's factor considering whether the actor's practice is non-discriminatory, and the actor provides the same access, exchange, or use of electronic health information to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship” (88 FR 23870). We noted that the intent of the third factor is to provide a basic assurance that actors would not be able to misuse the § 171.204(a)(4) manner exception exhausted condition to avoid supplying some particular requestor(s) with manner(s) of access, exchange, or use of the requested EHI that would be more accurately characterized as generally available than as new, unique, or unusual (88 FR 23870). Given that intent, we stated that the proposed regulatory language of subparagraph (iii) of the condition “while on its face may seem indefinite and is designed to address any potential request, is intended to ensure that the actor offers any requestor . . . the same access the actor provides to a substantial number of its customers . . .” (88 FR 23870). We requested comment on whether we should further define “substantial number” for purposes of this condition.

Comments. A few commenters responded to this proposed provision of the manner exception exhausted condition. Some suggested we keep the “substantial number” flexible and not further define it. One commenter suggested that we set a certain percentage such that an actor providing the same access, exchange, or use to a percentage of its customers would not be able to deny the requestor the same access, exchange, or use and still make use of this condition. Another commenter suggested that even one customer should be enough, because just one customer can constitute the bulk of an actor's business, or one customer can request a more innovative manner that should be made available to all requestors without the use of the condition to cover an actor's practice of denying such access, exchange, or use. One requestor stated that “substantial number” was an inappropriate metric for the factor, because “generally available” or other terms indicating the state of a product or service are not typically dependent on the number of users but rather the actor's ability to service any requests for such functionality. The same commenter noted that lack of adoption of a given feature may occur for many reasons that have no bearing on the usefulness of the feature, and therefore any functionality that is considered usable by customers should be considered normal and customary practice, even if only one customer uses it. The commenter expressed concerns that the adoption level could be kept artificially low by telling initial requestors “no,” thereby preventing the particular feature from being considered “generally available” or similar. Another commenter said that if a functionality is considered usable by customers, then having any customer use it should be considered normal and customary practice, and it shouldn't matter if, for a time, they are the only customer using that feature.

Other commenters supported keeping the term “substantial number” without further specifying a specific number. These commenters stated that such an approach allows the right level of flexibility, with one commenter remarking that it permits actors to consider the specific means of access, exchange, or use of EHI contemplated by each request and the specific use case for which the request is made. Another commenter supported ONC's reasoning for not using a fixed number to define “substantial number,” referring to the reasoning laid out in the HTI–1 Proposed Rule (which is also discussed below).

Response. We thank the commenters for their feedback and input. We have finalized in § 171.204(a)(4)(iii) the term “substantial number” without further specificity. We believe this allows the appropriate amount of flexibility for all actor types, who may have very different numbers of requestors, to satisfy this condition based on what number of requestors is substantial for that actor. As we stated in the HTI–1 Proposed Rule, using “substantial number” rather than a specific number is important to recognize variation in actors' operational contexts, including their organizational sizes. What may be a trivial number to a large health IT developer of certified health IT might be an important or consequential (“substantial”) number for a small HIN/HIE (88 FR 23870). In addition, while we believe that calculating a percentage may be helpful to an actor in determining whether it provides a substantial number of customers the requested access, we do not believe establishing a specific percentage would be helpful given the wide variation in the number of customers an actor may have. For example, an actor with a large number of customers who provides the access to dozens of customers might only be providing such access to ten percent of its customers. Further, we did not propose such an approach for consideration.

In response to commenters who suggested we use a specific number, such as one, we note that in some cases, even one customer could be a substantial number, if, for example, it represents a large portion of the actor's deployments or is considered “generally available” as part of an actor's line of business ( see below and 88 FR 23870 for a discussion of “generally available/general availability”). Simply stating one, or more than one, could be overly broad and end up capturing one-off manners, custom builds, or highly customized deployments that are not easily replicable for another requestor without abandoning open consensus standards or interoperable manners. In other words, we believe that “substantial number” is flexible enough to include as few as one customer, when appropriate, and as many as all of a given actor's customers. Further, providing a fixed number could be considered arbitrary.

In response to commenters who noted that if a functionality is used by even one customer, it should be offered even if, for a time, there is only one customer using it. We agree that there may be instances where just one customer is using a particular functionality that is suitable and scalable for use by requestors beyond that one customer. However, in other instances, a functionality may be in use by only one customer because it is a custom build that would be difficult to replicate or scale, or because it is an obsolete product that this one customer continues to find sufficient for their needs. We, therefore, believe setting the standard that an actor cannot meet the manner exception exhausted condition if any one customer is using a requested build could too often prevent the condition from applying when a requestor seeks a manner that is not generally available or interoperable. Moreover, in the free market, especially useful features would be expected to attract the notice of developers and their customers, with the best features eventually being adopted by more than one customer.

Finally, in the HTI–1 Proposed Rule preamble, we stated that we chose to structure the § 171.204(a)(4)(iii) factor to align with the concept of whether the manner requested, including involved interoperability elements, is in a stage of development or overall lifecycle that would roughly approximate the “general availability” phase of the software release lifecycle, or a conceptually analogous phase for non-software interoperability elements (88 FR 23870). However, we recognize that not all actors are developers, and we intend this condition of the Infeasibility Exception to be available for all types of § 171.102 actors. As we stated in the HTI–1 Proposed Rule, health care providers, for example, do not typically develop software for the market and, in our observation, are likely to characterize components of their health IT systems in more operational terms—such as what has “gone live” in their particular implementation—than in software release lifecycle terms. We believe avoiding the specific lifecycle term also avoids potential for misunderstandings among actors and requestors, or for gamesmanship on the part of actors, around when different actors consider a particular interoperability element to enter or to be withdrawn from “general availability” as the term is widely used in the software sector. We finalize “substantial number” with the same analysis and guidance found in the HTI–1 Proposed Rule (see 88 FR 23870 through 23871).

What does “provide” mean in this context?

Comments. We received three comments requesting clarification of the term “provides” as used in the manner exception exhausted condition. A couple of commenters asked ONC to clarify that this condition includes only current methods of sharing data, and not former, replaced, or outdated methods of exchange. Another commenter noted that clarification of the term “provide” in this context is even more important, given other proposals related to information blocking that also include concepts like “making available” or “providing.” One comment speculated the definition of provide included in the HTI–1 Proposed Rule at § 171.102 (information blocking definitions) was included for purposes of this condition, indicating that it was unclear why the definition was proposed and that if finalized in the proposed form, it may add confusion to the provisions of the conditions of information blocking exceptions in general.

Response. We thank commenters for their feedback. We use the word “provide” in § 171.204(a)(4)(iii) without further definition. We unintentionally included a definition of provide in § 171.102 (information blocking definitions) in the HTI–1 Proposed Rule. We have not finalized any definition of the word “provide” in § 171.102. Further, we emphasize that the definition of provide finalized in § 170.102 (health information technology certification program definitions) is not applicable for 45 CFR part 171.

We offer the following points of clarification specific, and limited in effect, to our use of the word “provide” in § 171.204(a)(4)(iii). First, as we stated in the preamble of the HTI–1 Proposed Rule, our use of “provide” in the present tense is both precise and deliberative. This factor tests for whether the actor currently provides the same manner to a substantial number of individuals or entities who are similarly situated to any given requestor. Looking only at what the actor currently provides excludes manners that are nearing or have exceeded the end of their supported life cycles (88 FR 23870). We recommend reviewing the examples in the HTI–1 Proposed Rule related to “provide” in context of § 171.204(a)(4)(iii) and note that they remain appropriate as further explanation of our finalized policy (88 FR 23870).

How should “similarly situated” be determined?

In the HTI–1 Proposed Rule, we discussed that the concept of “similarly situated” is familiar because we also use the phrase in the Fees Exception (§ 171.302) and Licensing Exception (§ 171.303). We noted that it would serve here, as it does there, to indicate that different specific individuals or entities within a class of such individuals or entities who are similarly situated to one another should be treated in a consistent and non-discriminatory manner (88 FR 23871). We also stated that it is not our intent for the “individuals or entities that are similarly situated to the requester” criteria of this new proposed condition to be used in a way that differentiates the same access to EHI simply based on the requestor's status, such as individual ( e.g., a patient) or entity ( e.g., a healthcare system) (88 FR 23871).

Comments. A few commenters requested that ONC provide more specific information on the types of characteristics that would designate entities as similarly situated and provide examples or guidance on ways for actors to easily group and document that entities are similarly situated. One commenter expressed concern about the lack of clarity related to the “similarly situated” clause. Another commenter argued that the term was inappropriate and what should matter is not the requesting entity's circumstances but its intended purpose of use for the requested interoperability functionality, whether the use aligns with what the functionality was designed to support, and whether the use requires any substantially new development work.

Response. We appreciate the comments and have adjusted the finalized policy to address commenters' concerns. As we noted in the preamble to the HTI–1 Proposed Rule, “similarly situated” in the manner exception exhausted condition's third factor was meant to function in a fashion similar to the non-discrimination provisions in the Fees and Licensing Exceptions (88 FR 23871). However, with the use of the term “similarly situated,” we were proposing to permit certain discrimination of requestors based on the similarity of their situations to those already being provided access, exchange, or use. As a comparison, we did not permit any discrimination under a parallel construction of one of the factors used for the analysis under the infeasibility under the circumstances condition of the Infeasibility Exception ( compare “Whether the actor's practice is non-discriminatory and the actor provides the same access, exchange, or use of electronic health information to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship;” 45 CFR 171.204(a)(5)(i)(D)).

We provided guidance in the HTI–1 Proposed Rule on our thinking of how a determination of similarly situated would work. We first provided an example of categorizing requestors into “similarly situated” categories based on the size of the healthcare entity. We then specified that even within these different categories, requestors would not be treated differently based on extraneous factors, such as whether any of them may be competitors of the responding actor or may obtain more of their health IT from the actor's competitors than from the actor (88 FR 23871). Finally, we noted that it was not our intent for the “individuals or entities that are similarly situated to the requester” criteria to be used in a way that differentiates the same access to EHI simply based on the requestor's status, such as individual ( e.g., a patient) or entity ( e.g., a healthcare system).

Based on comments received and further consideration of our proposal and examples, we have revised the condition to exclude certain factors from a similarly situated determination and are providing additional clarification and guidance. Consistent with the HTI–1 Proposed Rule, we clarify that “similarly situated” cannot be used to discriminate against requestors based on whether the requestor is a competitor of the actor or whether the requestor will or might use the requested access, exchange, or use in a way that facilitates competition with the actor. Similarly, as we noted above and in the HTI–1 Proposed Rule (88 FR 23871), an actor cannot discriminate in providing a form of access, exchange, or use of EHI that it currently provides to a substantial number of individuals or entities solely based on the requestor's status. In this regard, we are specifically clarifying in regulation text (§ 171.204(a)(4)(iv)) that such statuses include requests by individuals, as we define that term in § 171.202(a), and the health care provider type and size. Regarding health care provider type ( e.g., radiology specialty practice or long-term post-acute care facility) and size, we believe further clarity is necessary based on comments and the example we provided in the HTI–1 Proposed Rule and recited above. While the example in the HTI–1 Proposed Rule may have suggested that size groupings are acceptable, we clarify that such groupings as “similarly situated” would be appropriate in terms of administering costs and licensing agreements under the respective Fees and Licensing Exceptions but would not be appropriate for discriminating in actually providing access, exchange, or use of EHI that the actor provides to a substantial number of individuals or entities. Costs associated with providing access, exchange, or use of EHI or costs associated with licensing interoperability elements, can logically vary based on the size of the entity, so it makes sense to use this category for the Fees and Licensing Exceptions. However, we don't see a similar reason to discriminate based on the entity's size when an actor seeks to satisfy this condition of the Infeasibility Exception because if an actor already provides such access to a substantial number of entities, there is not a parallel correlation that would make it infeasible to provide such access to a “differently” sized requestor.

As an example, if a solo practitioner requests access, exchange, or use of certain EHI in the same manner that an actor provides such access, exchange, or use of the same EHI to a large hospital system, then the actor would not be able to discriminate based on the difference between the requestors (large hospital system versus solo practitioner) and still use this condition to cover the practice.

Overall, these adjustments are responsive to comments and provide further clarity for the concept of “similarly situated” as it applies to this condition under the Infeasibility Exception.

Other Comments

Comment. One commenter asked that actors be required to report any requests that they have rejected.

Response. We appreciate the comment but decline to finalize such a policy at this time as we did not propose such an approach.

Comment. A few commenters asked ONC to explain why the first requirement of this new condition restates “technical inability” as the reason for the infeasibility under the Manner Exception when the Manner Exception itself provides that an actor must fulfill the EHI request in the manner requested “unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request in the manner requested.” A commenter asked ONC to explain how this alternative requirement in the manner exception exhausted condition is materially different from the options for meeting the first requirement.

Response. There is no substantive difference between the “technical inability” under the Manner Exception and this new condition. However, this requirement has been restated as it falls under a new condition and under a different exception. ONC's intent in including the technical infeasibility requirement is to ensure that an actor who cannot, for technical reasons, fulfill a request for any access, exchange, or use of EHI in any manner requested is able to use this condition (provided all other relevant provisions are also met) and an actor who does have the technical capability to provide access, exchange, or use of EHI in the manner requested but cannot reach agreeable terms with the requestor may also make use of this new condition (provided all other relevant provisions are also met). In other words, an actor who can technically fulfill the request but cannot reach agreeable terms can still make use of this condition, so long as all other relevant provisions are met.

Comments. We received many comments in response to this new condition (and in response to other proposals in the HTI–1 Proposed Rule) advocating we review or revise paragraph (b) of the Infeasibility Exception, which requires an actor that does not fulfill a request for access, exchange, or use of EHI consistent with any of the conditions in paragraph (a) of § 171.204 “provide to the requestor in writing the reason(s) why the request is infeasible” within ten business days of receipt of the request. One commenter noted that requests often come in without the needed level of detail, meaning the developer must ask questions and wait for answers from the requestor before determining whether the request is feasible. In such instances, the commenter stated, the timeliness rests on the requestor and not the responding actor, and therefore a ten-day time frame is insufficient. The commenter further contends that the ten-day clock should “toll” until sufficient information about the request has been received. Other commenters expressed agreement that ten days was too short, too inflexible, and unrealistic. Another commenter asked ONC to clarify that where an actor intends to apply the manner exception exhausted condition of the Infeasibility Exception that the ten-day time frame begins only after the actor and requestor have not been able to agree on an acceptable alternative manner under the Manner Exception. Another commenter noted that the ten-day time frame was so unrealistic as to preclude the use of the exception in situations where it would otherwise be relevant.

Response. While we appreciate the comments, we did not propose any changes to the ten-day time frame in the HTI–1 Proposed Rule and are not finalizing any changes to paragraph (b) of § 171.204 in this final rule. We may consider these comments in relation to future regulatory action and guidance.

2. TEFCA Manner Exception

In the HTI–1 Proposed Rule, we proposed to add in § 171.301(c) a TEFCA manner condition to the proposed revised and renamed Manner Exception codified in 45 CFR 171.301. The proposed condition was stated as follows: “If an actor who is a QHIN, Participant, or Subparticipant offers to fulfill a request for EHI access, exchange, or use for any purpose permitted under the Common Agreement and Framework Agreement(s) from any other QHIN, Participant, or Subparticipant using Connectivity Services, QHIN Services, or the specified technical services in the applicable Framework Agreement, then: (i) The actor is not required to offer the EHI in any alternative manner; (ii) Any fees charged by the actor in relation to fulfilling the request are not required to satisfy the exception in § 171.302; and (iii) Any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the exception in § 171.303” (88 FR 23872).

In proposing this condition, we sought to offer actors certainty that fulfilling, or even attempting to fulfill, requests for EHI using Connectivity Services, QHIN Services, or the specified technical services in the applicable Framework Agreement (“TEFCA means”) would satisfy the Manner Exception when an actor and requestors are parties to the Common Agreement or a Framework Agreement under the Common Agreement. As proposed, this would have been the case even when the EHI may have exceeded the minimum data classes and elements required by the Common Agreement as of the date a particular request is fulfilled, assuming the TEFCA means could support the requested access, exchange, or use of the EHI. We stated that the proposed condition could be satisfied regardless of whether the requestor initially requested access, exchange, or use via TEFCA means or some other manner (88 FR 23872). We noted that another important feature of the proposal was that it could be satisfied by the actor either fulfilling or offering to fulfill the requestor's request for EHI, again, assuming the TEFCA means could support the requested access, and exchange, or use of the EHI. We stated that the approach aligns with the Cures Act's goals for interoperability and the establishment of TEFCA by acknowledging the value of TEFCA in promoting access, exchange, and use of EHI in a secure and interoperable way.

We stated that the proposed condition would identify as “reasonable and necessary” an actor's practice of prioritizing use of TEFCA means, in lieu of other feasible manners, for all EHI for which access, exchange, or use can be supported by TEFCA means for both the actor and requestor, so long as the requestor is a TEFCA entity (QHIN, Participant, or Subparticipant) and the purpose is permitted under the TEFCA governing agreements. This would be true regardless of whether the request is initially made through TEFCA means or otherwise; and regardless of whether all of the particular data classes or exchange purposes are yet required by TEFCA's governing agreements to be returned in response to a TEFCA request (88 FR 23873). The condition was designed to provide a clear, efficient regulatory path to prioritize exchange amongst QHINs, Participants, and Subparticipants in TEFCA using TEFCA means of sharing any and all EHI that TEFCA means can support.

We requested comment on this proposal and received a substantial number of responses from commenters. These comments are summarized and addressed below.

Summary of Finalized Policy

For the reasons explained below, rather than include this condition as part of the Manner Exception, we have finalized a new subpart to the information blocking exceptions—Subpart D, “Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA).” The new subpart consists of three sections, § 171.400 “availability and effect of exceptions,” which mirrors §§ 171.200 and 171.300, stating that a practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in this subpart D by meeting all applicable requirements and conditions of the exception at all relevant times. We have reserved § 171.401 for definitions in future rulemaking and reserved § 171.402 for future use as well. At § 171.403, we finalized a TEFCA Manner Exception that is based on the TEFCA manner condition proposed in the HTI–1 Proposed Rule.

Similar to the proposed condition, the new TEFCA Manner Exception (§ 171.403) provides that an actor's practice of limiting the manner in which it fulfills a request for access, exchange, or use of EHI to providing such access, exchange or use only via TEFCA will not be considered information blocking when the practice follows these conditions:

(a) The actor and requestor are both part of TEFCA;

(b) The requestor is capable of such access, exchange, or use of the requested EHI from the actor via TEFCA;

(c) The request for access, exchange, or use of EHI is not via the standards adopted in 45 CFR 170.215 or version approved pursuant to 45 CFR 170.405(b)(8); and

(d) Any fees charged by the actor and the terms for any license of interoperability elements granted by the actor in relation to fulfilling the request are required to satisfy, respectively, the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303).

The first condition, in § 171.403(a), that the actor and requestor are both part of TEFCA, simply means that both the actor and the requestor must be either a QHIN, Participant, or Subparticipant, as those terms are defined in the Common Agreement as published at 88 FR 76773. For brevity, in the preamble, we will refer to these three terms collectively as “TEFCA entities” or a “TEFCA entity.” This exception will not be available in any situation where the actor, or the requestor, is not a part of TEFCA.

The second condition, in § 171.403(b), requires that the requestor must be capable of receiving (accessing, exchanging, or using, depending on the requestor's request) the EHI from the actor, via TEFCA. In the Proposed Rule, we used the term “TEFCA means” to describe fulfilling requests for EHI using Connectivity Services, QHIN Services, or the specified technical services in the applicable Framework Agreement (88 FR 23872, as those terms are defined at 88 FR 76773). In this final rule and in the regulation text, we describe an actor's practice of responding to a request to access, exchange, or use EHI “via TEFCA” to indicate that an actor may use any of the services described by “TEFCA means” consistent with the terms that both the actor and requestor separately agreed to for access to such TEFCA means, and consistent with the other conditions of the exception.

As finalized in § 171.403(b), the exception's condition for responding to requests for EHI that the requestor can obtain from the actor via TEFCA uses “via TEFCA” to communicate that the actor makes the EHI available, and the requestor is able to obtain the requested access, exchange, or use of the requested EHI using—what we referenced in the HTI–1 Proposed Rule as making EHI available through “TEFCA means” (88 FR 23872). This includes where Participants and Subparticipants may be exchanging EHI within the same QHIN or across different QHINs. In cases where the requestor is not capable of accessing, exchanging, or using the EHI via TEFCA, for example because the requestor does not support such exchange methods or its QHIN does not, an actor would not be able to make use of this exception.

The third condition, in § 171.403(c), excludes requests from the exception where the requestor seeks to access, exchange, or use EHI via the “Application Programming Interface Standards,” (or API standards) (45 CFR 170.215) adopted by ONC on behalf of the Secretary or another version of those standards approved pursuant to the “Standards Version Advancement Process” (45 CFR 170.405(b)(8)) under the ONC Health IT Certification Program. When a requestor seeks to access EHI via those API standards (essentially FHIR-based standards), an actor cannot use this exception. In other words, the third condition functions as a carve-out in that the exception is not available if the requestor requested access, exchange, or use of EHI via the API standards.

The fourth and final requirement for this condition, in § 171.403(d), states that any fees an actor charges, and any licensing terms an actor sets, must comply with the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303). This exception in § 171.403 would not be available in any situations where all four of these conditions are not satisfied.

Rather than finalize the proposed definitions, in order to maintain consistency between the most current version of the Common Agreement and this regulation, we have decided to refer to the definitions used in the Common Agreement (88 FR 76773) for the terms used in this exception. The relevant definitions are similar to, or the same as, the terms we proposed to define in the proposed TEFCA manner condition. For example, when we refer to Framework Agreement(s), we mean any one or combination of the Common Agreement, a Participant-QHIN Agreement, a Participant-Subparticipant Agreement, or a Downstream Subparticipant Agreement, as applicable. A Qualified Health Information Network (QHIN) is, as defined in the most recent version of the Common Agreement, a health information network (as defined in § 171.102) that is a U.S. entity that has been designated by the Recognized Coordinating Entity (RCE) and is a party to the Common Agreement countersigned by the RCE. Both Participant and Subparticipant are defined as they are in the Common Agreement (88 FR 76773). In some cases, such as with the term Connectivity Services, the definition proposed is different from the most recent version of the Common Agreement, where it is defined as the technical services provided by a QHIN consistent with the requirements of the then-applicable QHIN Technical Framework and pursuant to the Common Agreement with respect to all Exchange purposes. The Common Agreement also defines Individual Access Services (IAS) as the services provided to an Individual by a QHIN, Participant, or Subparticipant that has a direct contractual relationship with such Individual in which the QHIN, Participant or Subparticipant, as applicable, agrees to satisfy that Individual's ability to access, inspect, or obtain a copy of that Individual's Required Information using TEFCA Exchange. We decided to reserve 171.401 for possible future use to incorporate these definitions into the regulatory framework.

Timeliness of Exception

Comments. Some commenters stated that it would be premature to adopt this proposal. Commenters noted that TEFCA is in its early stages and has not yet launched. Others suggested ONC take a “wait and see” approach, monitor TEFCA deployments for utility, completeness, timeliness, ease of access, security, privacy, transparency, and consumer participation, and then finalize an exception only if real world experience demonstrates a need. A commenter noted that TEFCA is a voluntary program that does not support the full breadth of use cases for EHI, and that such an exception will designate other pathways as “less interoperable” even if they have equal or greater utility compared to exchange through TEFCA. Another commenter appreciated ONC's support for greater interoperability, but also stated it was too soon to establish this condition because it could result in less sharing of information in the early stages of TEFCA's development. The commenter suggested, as an alternative, that TEFCA-based exchange should be included as a preferred approach to sharing EHI, but not in a way that enables an actor to deny a request if the requestor cannot receive it via TEFCA-based exchange.

Response. We appreciate the feedback. The policy as proposed (88 FR 23873) and as finalized in the new TEFCA Manner Exception is only available when both the actor and the requestor are in TEFCA, which we believe eliminates the concerns about the timeliness of identifying as reasonable and necessary the practices that satisfy the exception. Entities will join TEFCA with the expectation that they will exchange EHI using TEFCA when possible. This exception reinforces that practice. No actor is required to join TEFCA, so those that do so will do so with the knowledge that this exception is available in certain circumstances. As a voluntary exception, no actor is required to make use of the exception—which we believe further negates the timeliness concerns. In addition, an actor will not be able to use this exception if, for whatever reason, the requestor is not capable of accessing, exchanging, or using the requested EHI via TEFCA. In such cases, an actor would need to provide the EHI in the manner requested, or in an alternative manner agreed upon with the requestor or use another exception to cover the practice to attain certainty that the actor's practice will not be considered information blocking.

Fees and Licensing Terms Concerns

Comments. Many commenters expressed concern that we did not propose to apply the restrictions found in the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303) to this condition. These commenters contended that, without such application, actors would be able to charge outrageous fees or set unreasonable licensing terms for interoperability elements. Other commenters noted that such fees could interfere with an individual's right to access their EHI. A couple of commenters asserted that, as proposed, the condition could result in applications that charge patients for their services as the only realistic way for patients to get their EHI. Some commenters further asserted that because the only fees that are prohibited in the Common Agreement are fees charged between QHINs, Participants and Sub-participants would be able to charge fees for exchange of EHI that would not need to satisfy the Fees Exception.

Response. We appreciate the comments and believe the commenters raised valid concerns. In fact, when proposing the TEFCA manner condition, we mistakenly assumed that all actors participating in TEFCA would have already reached overarching agreements on fees and licensing such that there would be no need for application of the Fees and Licensing Exceptions. ( See88 FR 23872, “[the proposal] facilitates an actor reaching agreeable terms with a requestor to fulfill an EHI request and acknowledges that certain agreements have been reached for the access, exchange, and use of EHI (for example, by using standards consistent with the Common Agreement or applicable flow-down Framework agreements that the actor and requestor have agreed to abide by)” (emphasis added)). In fact, the Common Agreement is silent on fees except to forbid QHINs from charging fees to other QHINs. Therefore, to correct our misunderstanding and in consideration of comments, we have finalized the exception to include that any fees charged by the actor, and any licensing of interoperability elements, must satisfy the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303). It was never our intent to permit fees or licensing agreements that would not satisfy the information blocking regulations, either by being agreed to ahead of time, as we presumed, or by satisfying the Fees and Licensing Exceptions.

Concerns Regarding EHI Accessibility and Fees for Individuals

Comments. Many requestors expressed concerns that the proposed TEFCA condition would interfere with an individual's access to their own EHI. One commenter stated that the condition could be used to elect out of participating in Individual Access Services in a national network capacity. The commenter stated that while responding to individual requests via TEFCA is required (by the Common Agreement), QHINs are not required to initiate support for Individual Access Services. One commenter expressed concerns that the exception will make it more difficult for patients to get provider and payer data, and that patients who do not understand how networks function will be disadvantaged compared to others. A few commenters expressed concern about patient matching within the TEFCA network. One commenter expressed concerns about sensitive data, citing reproductive health care as an example, and how a patient could control access to such EHI. Some commenters indicated they were especially concerned with patient privacy and the ability for applications to charge for access to patient data or possibly “traffic” EHI through “dark data” exchanges. A commenter encouraged ONC to focus on FHIR-based interoperability. A few commenters expressed concerns that the proposal would allow actors to charge individuals for access to their own data. Another commenter expressed significant concerns that the exception would permit charging fees to Individual Access Services (IAS) providers who are looking to access healthcare data on behalf of individuals.

Response. We appreciate the comments. Consistent with our proposal, the policy, as finalized, is applicable only when both the actor and the requestor are part of TEFCA (88 FR 23873, see also88 FR 23917–23918). We would like to assure commenters that this exception cannot be used in any case when an individual is requesting EHI, because an individual cannot be a QHIN, Participant, or Subparticipant under TEFCA. If the individual is using TEFCA's Individual Access Services to query for or retrieve EHI via TEFCA instead of seeking to access, exchange, or use EHI directly from their health care provider's portal or FHIR APIs, then the QHIN, Participant, or Subparticipant, in its role as an IAS provider, would be querying via TEFCA, not the individual. Furthermore, as described previously, the finalized exception includes the requirement that any fees charged for the access, exchange, or use of the EHI must satisfy the Fees Exception (§ 171.302), which specifically prohibits charging a patient (including a third-party app on the patient's behalf) for API or other electronic access to the patient's EHI (§ 171.302(b)(1) and (2)). Regarding patient privacy, all § 171.102 actors are required to protect patients' privacy and restrict the access, exchange, and use of EHI as required by all applicable law, including, but not limited to, the HIPAA Privacy Rule for actors to whom the HIPAA Privacy Rule applies.

Patient matching within TEFCA is addressed by applicable policy and technical procedures as well as associated agreements under TEFCA. For purposes of information blocking, any actor who receives a request for access, exchange, or use of EHI that the actor knows, or reasonably suspects, is misidentified or mismatched and who seeks certainty as to the conditions under which they can withhold such EHI without engaging in information blocking will want to consult the Preventing Harm Exception in 45 CFR 171.201, which recognizes this type of risk in § 171.201(c)(2).

Concerns Regarding Interoperability and FHIR APIs

Comments. Many commenters expressed concerns with the limited manner of exchange initially available in TEFCA and noted that when TEFCA officially launches, the Common Agreement will require only IHE document-based exchange. Commenters stated that restricting TEFCA entities to IHE document-based exchange would limit the use of EHI exchanged in that manner, would limit interoperability by not requiring the use of modernized exchange protocols like FHIR, and could even disincentivize joining TEFCA. Others noted that our proposal would push actors to one exchange mechanism over another, which would remove choice and optionality and could potentially eliminate or discourage use of other exchange options, such as FHIR APIs, that may be preferable for some use cases. A few commenters noted that many health IT developers of certified health IT plan to connect their customers to TEFCA such that their customers will have to actively choose to opt out. Commenters expressed concerns that most actors will likely be Participants or Sub-participants and, therefore, “subject to this exception.” As a result, one of these commenters stated that most of the information blocking regulations would be folded into the TEFCA framework, which lags behind today's use of FHIR APIs.

Other commenters noted that requestors may have practical reasons to ask for EHI in ways other than what TEFCA supports. Commenters encouraged ONC to advance support for HL7 FHIR within TEFCA as quickly as possible to allow third-party applications to access data more easily on behalf of individuals. A few commenters noted that section 4003(a) of the Cures Act defined interoperability as health information technology that enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user. The commenters claimed that the proposed TEFCA condition would require special effort on the part of the user, particularly with the use of IHE document protocol. Other commenters stated that entities should be able to choose the best interoperability mechanisms and request data in any format the current source can reasonably support using an exchange mechanism both can support. A commenter stated that, because there may be a delay before TEFCA widely implements the use of FHIR for all of the stated “exchange purposes,” organizations should be able to negotiate for the manner of access that best suits their requirements. In particular, the commenter stated that organizations should be allowed to prioritize using EHR systems' SMART on FHIR patient API endpoints, and for population-level use cases, bulk FHIR export, even if TEFCA supports access to such EHI in another manner.

Response. We thank the commenters for their feedback. Currently, TEFCA includes IHE document-based exchange, but publicly available documents note that FHIR exchange is a TEFCA priority and is planned for availability in 2024. IHE document-based exchange is a longstanding standard for exchanging EHI. For example, organizations supporting health information exchange nationally ( e.g., CommonWell Health Alliance, eHealth Exchange, Carequality) generally use IHE profiles such as Cross-Community Patient Discovery (XCPD) and Cross-Community Access (XCA) to enable clinical document exchange between disparate communities. However, as many commenters pointed out, FHIR-based exchange has certain advantages over IHE document-based exchange. Over time, QHINs, Participants, and Subparticipants may well be required to support broader uses of FHIR-based exchange, but it is also likely that many Participants and Subparticipants will continue to use document-based exchange instead of FHIR-based exchange for several transition years. In addition, the information blocking exceptions are all voluntary and are not “required” of any actor. The exceptions serve to offer certainty to actors that by conforming a practice to the conditions of an exception, such practice will not constitute information blocking. A Participant or Subparticipant in TEFCA is not “subject to” any exceptions, but if such entity is an actor (as defined in § 171.102), the new finalized exception would be available along with all the other exceptions.

In consideration of both our stated goal to incentivize TEFCA participation and comments suggesting that ONC should be promoting the use of FHIR-based APIs (for example, the standards codified in 45 CFR 170.215, “Application Programming Interface Standards”), we have limited the finalized exception's availability. Specifically, in instances where an actor that is part of TEFCA receives a request to access, exchange, or use EHI via the API standards adopted in 45 CFR 170.215, including updated versions of such standards as may be approved for voluntary use in the ONC Health IT Certification Program pursuant to 45 CFR 170.405(b)(8), the Standards Version Advancement Process, the actor cannot meet the finalized TEFCA Manner Exception. We finalized this policy in § 171.403(c), providing a limitation on the use of the exception in that it does not apply to a request for access, exchange, or use of EHI via the standards adopted in 45 CFR 170.215, including version(s) of those standards approved pursuant to 45 CFR 170.405(b)(8). This approach ensures that requestors seeking to access, exchange, or use EHI via FHIR-based APIs can request such access and be assured that an actor cannot use the TEFCA Manner Exception to limit the manner in which it fulfills the request to only via TEFCA. As many commenters noted, FHIR APIs advance interoperability to a greater degree than IHE document-based exchange, which is a currently permitted exchange mechanism under TEFCA. With the goals of the proposed condition to acknowledge agreements reached by parties and to promote both interoperability and TEFCA adoption (88 FR 23872–23873), the FHIR-based API limitation in § 171.403(c) is necessary to achieve these goals.

It is crucial to note that an actor ( e.g., a health IT developer of certified health IT) that participates in the ONC Health IT Certification Program cannot simply “turn off” API capabilities, outside of TEFCA, to avoid offering such access, exchange, or use to a requestor. Any developer that has chosen to participate in the Program is subject to the Conditions of Maintenance and Certification requirements in subpart D of 45 CFR part 170. The API Condition and Maintenance of Certification requirements in § 170.404 apply to health IT developers that certify health IT to FHIR-based API certification criteria. Such developers would not be compliant with the API Condition and Maintenance of Certification requirements if they do not, among other requirements, publish APIs and allow EHI access, exchange, and use through the APIs. Any actor with certified health IT who has deployed “certified API technology” (as defined in § 170.404(c)) or other API technology using the standards and implementation specifications adopted in § 170.215, who disables, disconnects, or otherwise “turns off” such API technology or requestors' connections in order to avoid offering such access, exchange, or use after joining TEFCA would do so explicitly outside the applicability of the TEFCA Manner Exception finalized in § 171.403 and such practices could constitute information blocking.

The TEFCA Manner Exception, as finalized, is not in conflict with the PHSA section 3000(9) definition of “interoperability” or with other ONC regulations. The exception only applies to entities that choose to voluntarily participate in TEFCA and agree to the interoperability means available under TEFCA, while also preserving the availability of interoperable FHIR APIs to requestors for the access, exchange, and use of EHI.

In sum, we believe that the proposed approach would not have led to most of the negative consequences for FHIR API adoption theorized by commenters. However, to address such confusion and concern and continue to incentivize TEFCA participation, in § 171.403(c), we have finalized the explicit limitation condition within the exception to remove any doubt about perceived conflicts between TEFCA and FHIR API adoption. ONC has been and will continue to be at the forefront of driving both TEFCA and FHIR API adoption across the industry and the Federal Government.

Comments. Many commenters noted that some EHI requestors who will likely be part of TEFCA may not have the technical capability to make requests or receive responses for certain permitted but optional exchange purposes.

Response. In situations where a requestor does not support the capability to make or receive requests or perform other transmissions for certain Exchange Purposes (including those that do not require a response), the TEFCA Manner Exception would not be available because the requestor would not have such access, exchange, or use of the EHI consistent with the requestor capability condition in paragraph (b) of § 171.403.

Comments. Some commenters stated that the proposed TEFCA manner condition could interfere with state reporting requirements, because, for example, some states require payers to exchange data within a specified network based on existing federal rules. One commenter stated that the condition risked discriminating against mechanisms of exchange and interoperability that are feasible and even required to be used by regional or local authorities. Another commenter stated that the inclusion of this exception demonstrates that there may be conflicting or confusing mandates under different federal programs, making compliance with information blocking regulations more difficult. The commenter urged ONC to continue to review how all federal and state laws, regulations, and programs interact to relieve the unnecessary burden of varying requirements that may not align. A commenter stated that the proposed condition risks discriminating against exchange mechanisms and interoperability pathways that are otherwise commercially and technically feasible, and in some cases, required under law. The commenter noted that a diversion of such exchanges to TEFCA would result in the loss of useful information that should be added to the patient's record to provide additional context for clinical care.

Response. We appreciate the comments. We remind commenters that the exceptions exist as a voluntary means for actors to gain assurance that their practice(s) does not constitute information blocking; and similarly, participating in TEFCA is voluntary. Compliance with an exception set forth in subpart B, C, or newly finalized D of 45 CFR part 171, would mean that an actor's practice does not meet the definition of information blocking in § 171.103. However, this would not, in or of itself, immunize the actor from any other consequences to which they are subject to for violating, ignoring, or otherwise failing to comply with other applicable laws.

In response to concerns that the exception risks discriminating against exchange mechanisms and interoperability pathways that are otherwise commercially and technically feasible, we note that a requestor can request EHI in any manner, and an actor may seek to satisfy the manner requested condition of the Manner Exception (§ 171.301(a)) and respond in that manner, if the actor and requestor can come to agreeable terms for the access, exchange, and/or use of the particular EHI. In such instances, the terms of the agreement need not satisfy the Fees Exception (§ 171.302) or the Licensing Exception (§ 171.303), and would meet the manner requested condition of the Manner Exception (§ 171.301). Using the TEFCA Manner Exception is voluntary, and in cases where a requestor would be unable to use its preferred exchange method it could negotiate with the actor under the manner requested condition (§ 171.301).

The TEFCA Manner Exception does not require actors to use TEFCA to meet public health reporting requirements under other applicable laws. Similarly, the TEFCA Manner Exception does prohibit the use of other exchange methods. Rather, it acknowledges an exchange method (manner) that both the actor and requestor have voluntarily chosen to use, and are capable of using, as a method that would be reasonable and necessary for purposes of not being considered information blocking. As noted above, actors are still responsible for their other legal obligations, such as under state law.

Regarding the concern about exchanging requested EHI only via TEFCA when doing so would result in the loss of some of the responsive EHI that the actor has and can (consistent with applicable law and patient privacy preferences) make available to the requestor for the purpose(s) applicable to the request, then this exception is not available to the actor. The finalized TEFCA Manner Exception applies only to the EHI that the actor is actually able to make available for access, exchange, or use via TEFCA and that the requestor is capable of accessing, exchanging, or using, as applicable, via TEFCA (§ 171.403(b)).

Incentivizing TEFCA Participation

Comments. Some commenters encouraged ONC to consider that while this condition will be useful for those already in TEFCA, it will not meaningfully incentivize participation in TEFCA. As an example, some state agencies that do not have the technological resources to adopt TEFCA technical services will contract with a third-party entity and end up passing the cost of the contracts on to others, including health care providers. Some commenters asked for a “safe harbor” period to allow participants to fully embrace TEFCA. A commenter expressed concern that the condition will discourage third-party apps from joining TEFCA because they will have more flexibility to request data outside of TEFCA.

Many other commenters, however, agreed that the proposal will incentivize and accelerate use of the available, interoperable, and secure TEFCA technical services by TEFCA entities. Commenters noted that the proposal would reinforce the transition to standards-based exchange and prevent actors from unnecessarily devoting limited time and resources to fulfilling burdensome, customized solutions. A commenter appreciated strong regulatory incentives to join TEFCA.

A commenter expressed concern that the proposed condition could be used to coerce use of TEFCA or be used as a defense to evade fulfilling a request for access, exchange, or use of EHI when the requestor does not use TEFCA for a permitted purpose for data beyond USCDI v1. Another commenter suggested ONC use the policy exactly that way and require only the actor be a part of TEFCA. The commenter contended that if the requestor can receive the access, exchange, or use of EHI via TEFCA and is eligible to join TEFCA, the actor should only be required to offer EHI via TEFCA in order to satisfy the exception (in other words, make the requestor join TEFCA to get the requested access, exchange, or use of EHI).

Response. We appreciate the comments. We recognize that this condition incentivizes, to differing degrees for different actors, joining TEFCA, and that not all entities will be ready, willing, or able to join TEFCA as soon as the first technical services under TEFCA go “live.” However, we do not agree that a safe harbor period is needed, as both joining TEFCA and using the exceptions are voluntary and function only to offer actors certainty that their practices that meet all relevant conditions of an exception, at all relevant times, will not constitute information blocking.

At this time, we decline to use this exception as a means to propel requestors into joining TEFCA or to justify, to us or to actors, why they are not yet TEFCA entities. Such an approach is beyond what our proposal or finalized exception is intended to achieve and may actually undermine and frustrate the intent of the information blocking statute and implementing regulations. We also recognize the concern that some actors may wish to use the exception to evade fulfilling a request for access, exchange, or use of EHI when the requestor does not use TEFCA for a permitted purpose beyond USCDI v1. Attempts to misuse the exception in that way would not be successful because, for the exception to apply to an actor's practice of making EHI available only via TEFCA, the requestor must be capable via TEFCA of, as applicable, accessing, exchanging, or using the requested EHI from the actor. The condition in § 171.403(b), as finalized, addresses concerns about limits to what EHI requestors can access via TEFCA by ensuring the condition is only available when the EHI the requestor seeks can, in practice, be accessed, exchanged, or used by the requestor via TEFCA.

Structuring the Exception Within the Existing Regulatory Framework

In creating a new subpart and finalizing a separate exception, we have made it easier for actors and requestors to understand when an actor's fulfillment of EHI access, exchange, or use only via TEFCA would not constitute information blocking. By creating a new subpart, we are clearly delineating that the exception is available only to TEFCA participants. Also, by removing it from the Manner Exception, we avoid introducing confusion about when an actor must offer alternative manners and in what order they must do so. Further, in creating this new subpart, we leave room for identifying other reasonable and necessary activities related to TEFCA that do not constitute information blocking, should we propose them in future rulemakings.

EHI That Can Be Made Available Versus EHI That Must Be Made Available via TEFCA

Comments. Some commenters stated that because TEFCA only requires the exchange of the USCDI, the exception will be of limited utility. Another commenter asked for clarity that EHI can exceed the base set of EHI required by TEFCA. Other commenters appreciated that the condition would not be limited to a subset of EHI, so long as the EHI could be accessed, exchanged, or used by the requestor, as applicable.

Response. We appreciate the feedback. As finalized, the exception can be satisfied when any EHI requested by the requestor can be made available to the requestor via TEFCA for the requested access, exchange, or use of the EHI, including where the EHI requested is beyond what is represented by the data elements within any USCDI version. Nothing in this exception restricts how much or which EHI can be shared via TEFCA or limits the exception's application to the minimum data elements that TEFCA's terms require TEFCA entities to make available in response to TEFCA queries. If an actor is capable of sharing all the requested EHI via TEFCA, and, importantly, the requestor is capable of accessing, exchanging, or using all of the EHI via TEFCA, as applicable, then the exception could apply to the practice (if all other conditions are also satisfied). Similarly, if an actor is capable of providing access, exchange, or use of some, but not all, of the requested EHI via TEFCA, the exception can cover the practice for the EHI that the actor is capable of providing via TEFCA and the requestor is capable of accessing, exchanging, or using (as applicable). The actor could then provide the remaining EHI in a different manner, for example, by using any of the methods in the Manner Exception (§ 171.301), or resolve the request through other means or applicable information blocking exceptions.

Other Concerns and Observations From Commenters

Comments. A couple of commenters stated that, in some cases, one business unit may sign up for TEFCA, in which case the entire organization would also become part of TEFCA. The commenters stated that in such cases, a requestor may be unaware that they are considered a part of TEFCA, may not have the technical capability to connect their IT systems to the TEFCA network, and will want to receive EHI in another manner.

Response. We thank the commenters for the feedback. The § 171.403(b) requestor capability condition of the finalized TEFCA Manner Exception ensures that the exception is only available when the requestor is capable via TEFCA of accessing, exchanging, or using, as applicable, the requested EHI from the actor at the time the request is made. We cannot anticipate every corporate arrangement; however, if a requester's organization is a party to the Common Agreement or a Framework Agreement, it is the requester's responsibility to resolve its approach to EHI access, exchange, and use within the organization.

Agreed Upon by the Requestor

Comments. Several commenters noted that, under the Manner Exception, a requestor must agree to access, exchange, or use of EHI if the actor offers to fulfill the request in any alternative manner. The commenters stated that, in the proposed TEFCA manner condition, requestors would not be required to agree to receive the EHI via TEFCA. They noted that this shifts the balance of power towards actors and away from requestors. Commenters expressed concerns that the requestor cannot counter with an alternative manner and are forced to accept via TEFCA. Other commenters appreciated that the condition would simplify responses for many actors who participate in TEFCA and allow requestors and actors to exchange EHI more efficiently.

Response. In the Manner Exception, one policy objective is to ensure the requestor receives the EHI in either the manner requested or in an alternative manner to which the requestor agrees. This policy assumes that the requestor would not agree to an alternative manner unless that manner allowed them the access, exchange, or use of EHI which they sought in the first place. In finalizing the TEFCA Manner Exception, this policy objective is fulfilled by two conditions. The requestor has agreed to be part of TEFCA and the requester capability condition, which states that the requestor is capable, via TEFCA, of accessing, exchanging, or using, as applicable, the EHI requested from the actor. Although the requestor does not have to agree to receive the EHI via TEFCA, the requestor did voluntarily join TEFCA, and assuming the requestor has the necessary capabilities, the requestor will still be able to access, exchange, and/or use the EHI, as applicable. In other words, even if the requestor does not agree to a specific instances of access, exchange, or use of EHI via TEFCA, the TEFCA Manner Exception is still available to the actor for providing such access via TEFCA, so long as an actor has satisfied all of the conditions of the exception at all relevant times. We believe this approach balances the policy interest of promoting interoperability and TEFCA participation with the interest in ensuring EHI moves in a manner that is usable by the requestor.

We also note that the comment and similar comments assume that TEFCA participation will not streamline information exchange. Those who join TEFCA are voluntarily seeking to get the benefits of scalable nationwide trust and infrastructure services for IHE-based and, as the transition to FHIR takes place, FHIR API exchange. Thus, those who join TEFCA would be motivated to fulfill as much of their information sharing obligations and practices as they are able to in order to reduce the overhead associated with achieving interoperability outside of TEFCA. In short, rather than hampering information sharing, we believe that encouraging exchange via TEFCA will make it easier for both actors and requestors to achieve access, exchange, and use of the EHI.

Finally, to clarify the distinction between the Manner Exception (§ 171.301) and its conditions (a) manner requested and (b) alternative manner, we have finalized a new subpart D, “Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA)” and finalized the TEFCA Manner Exception within that subpart at § 171.403.

Concerns About TEFCA Policies

Comments. A commenter asked for clarification about how to distinguish exchange that occurs pursuant to a Framework Agreement versus an intra-QHIN agreement. The same commenter also asked how actors will be able to ascertain whether a request made for a certain purpose ( e.g., health care operations) outside the TEFCA network aligns with the same purpose that they (the actors) would be offering to respond to under TEFCA; and how to handle situations where a requestor does not support the capability to make or receive requests or perform other transmissions for certain Exchange Purposes that do not require a response ( e.g., Payment, Public Health, or health care operations). Another commenter asked ONC to clarify which purposes are permitted under TEFCA as applied to this exception. One commenter asked that ONC clarify that if the EHI being requested or the exchange purpose for which it was requested are not part of the current required parameters of TEFCA, the condition will still be available.

Response. QHIN-to-QHIN exchange would be covered by this exception because both parties, the QHINs, are “part of TEFCA,” having signed the Common Agreement to become a QHIN. Exchange within QHINs (in other words, exchange between Participants or Subparticipants who have joined the same QHIN) would also qualify for this exception. In addition, the purpose of the request is not relevant for the information blocking definition, nor is the status of the parties beyond their being “part of TEFCA.” So long as the actor can respond to the request via TEFCA, and the requestor participates in TEFCA and is capable of access, exchange, or use of the EHI, as applicable, then the condition can be satisfied, assuming all the other conditions of the exception are also met. In situations where a requestor does not support the capability to make or receive requests or perform other transmissions for certain Exchange Purposes that do not require a response, then the TEFCA Manner Exception would not be available because the requestor would not be able to access, exchange, or use the EHI if transmitted via TEFCA, and thus the second condition of the exception, requestor capability (§ 171.403(b)) would not be met.

TEFCA Directory

ONC requested comment on whether an actor should be required to search a directory prior to responding via TEFCA (88 FR 23873).

Comment. One commenter expressed concerns that the directory would be unreliable, or that actors may not be recognized due to naming issues. Another commenter asked if QHINs would be permitted to leverage their own provider directories.

Response. We thank the commenters for their feedback. At this time, for reasons such as those mentioned by the commenter as well as due to the logistical complexities of providing real-time access to an easily usable directory for purposes of identifying requestors of EHI, we have not finalized a requirement that an actor search the TEFCA directory as a condition of the exception. Actors should be able to determine whether requestors are part of TEFCA through customary business interactions, such as those that occur when parties engage in exchanging EHI. Actors may also choose to use their own resources, such as provider directories, to make affirmative determinations of whether a requestor is part of TEFCA. However, it ultimately remains the actor's responsibility in making a positive determination as to whether a requestor is part of TEFCA for the purposes of satisfying this exception.

General Comments

Comments. A few commenters recommended that ONC restrict the scope of the proposed exception such that it covers only those reasonable activities that are necessary to comply with and implement the Common Agreement, and not to extend it to other practices. Commenters noted this would still incentivize TEFCA participation without inadvertently inhibiting innovation and competition.

Response. While we appreciate the commenter's position and agree that such an exception may incentivize TEFCA participation, the finalized TEFCA Manner Exception will provide certainty to actors that the practice of making EHI available for access, exchange, and use via TEFCA to other TEFCA participants, and consistent with the relevant outlined conditions, will not be information blocking. We may consider proposing additional TEFCA exceptions in future rulemakings.

Comments. One commenter expressed support for the exception, stating that it would reduce burden on physicians who connect to a QHIN by allowing physicians to rely on that connection as a substitute for fulfillment of tailored requests for EHI by redirecting the requestor to the QHIN.

Response. We want to clarify that, as proposed and as finalized, the TEFCA Manner Exception does not permit physicians to redirect all requests for access, exchange, or use of EHI to a QHIN. However, TEFCA participation and meeting the exception in applicable circumstances may allow physicians to redirect a significant portion of EHI requests. The exception outlines the specific circumstances under which an actor, who is part of TEFCA, may respond to a requestor, who is also part of TEFCA, via TEFCA services regardless of the manner requested, unless the requestor asked for the access via the standards adopted in 45 CFR 170.215, including versions of those standards approved pursuant to 45 CFR 170.405(b)(8). Further, the requestor must be capable of accessing, exchanging, or using the EHI, as applicable to the circumstances, via TEFCA. Therefore, there will be circumstances when both the actor and requestor may be part of TEFCA, but the exception would not apply because the requestor cannot, for technical reasons or due to TEFCA-related agreements, access, exchange, or use the EHI via TEFCA. We also emphasize, again, that individuals cannot be “part of TEFCA;” thus, if the requestor is an individual, the TEFCA Manner Exception will not be available to any actor.

Comment. A commenter suggested ONC simplify the information blocking regulations and create separate exceptions/conditions for providers different from those for developers and networks and explore provider-targeted exception options not tied to certified Health IT Module use or TEFCA participation.

Response. We appreciate the comment, but we did not propose exceptions specific to any one of the three categories of actors (health care provider, HIN/HIE, and health IT developer of certified health IT), and decline to adopt such an approach in this final rule. The exceptions address reasonable and necessary activities that are not considered information blocking and are designed to be used by any of the regulated actors where appropriate. Generally, they are not contingent on the use of certified health IT. Further, all of the exceptions set forth in subparts B and C of 45 CFR part 171 are available to any actor, when they are satisfied, regardless of whether the actor has chosen to become a part of the TEFCA ecosystem. Health care providers interested in learning more about any or all of the information blocking exceptions can find more information about the exceptions at https://www.healthit.gov/topic/information-blocking. The exceptions themselves can be found in their entirety in 42 CFR part 171 (available online at: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-171?toc=1 ).

Comments Beyond the Scope of the Proposal

Comments. A commenter asked for clarification regarding the participation of entities in TEFCA that are acting on behalf of other entities, like business associates, and the data sharing requirements for those entities.

Response. We appreciate the comment. The regulations and requirements governing TEFCA are out of scope for the proposal.

Comments. One commenter asked ONC to better explain the controls that are in place to ensure that QHIN requested data does not violate HIPAA. Another commenter asked ONC to address how patients will provide consent for the networked sharing of their data via TEFCA, and how patients will even be informed about what of their data has been shared by whom, to whom, and for what use. A few commenters asked ONC to incorporate privacy-protective practices into the Common Agreement.

Response. These comments are beyond the scope of the proposal. However, we offer the following information in response to these comments about TEFCA. TEFCA includes strong privacy protections within the Common Agreement, Qualified Health Information Network Technical Framework (QTF), and standard operating procedures. Most connected entities under TEFCA will be HIPAA covered entities or business associates of covered entities, and thus will already be required to comply with the HIPAA Privacy Rule. The Common Agreement requires each non-HIPAA entity that participates in TEFCA to protect individually identifiable information that it reasonably believes is TEFCA information in substantially the same manner as HIPAA covered entities protect PHI, including having to comply with most provisions of the HIPAA Privacy Rule as if they were subject to the HIPAA Privacy Rule. Further, in some ways, the TEFCA requirements related to the Individual Access Services (IAS) exchange purpose require that IAS providers meet an even higher bar of privacy than HIPAA, including providing individuals with the right to delete their data.

For additional information about TEFCA requirements related to privacy, we refer readers to the most recent versions of the Common Agreement, QTF, and standard operating procedures. ONC's official website, HealthIT.gov, also provides additional information about TEFCA.

Comment. A commenter suggested ONC align with the approach taken by CMS in its promoting interoperability programs to explicitly name TEFCA as an optional alternative for claiming credit under the HIE Objective.

Response. We appreciate the comment. We are uncertain how or in what manner the commenter recommends we align the TEFCA Manner Exception with the approach CMS implemented for TEFCA participation under the promoting interoperability programs. However, as mentioned above, this comment is beyond the scope of the proposal.

Comment. One commenter requested ONC to consider how it can address patient portals that cannot share a full record set with a patient, and interoperability concerns that arise from portal configurations.

Response. We appreciate the feedback. Although ONC does consider and regulate the interoperability capabilities of health IT as it relates to patient portals through the “view, download, and transmit to 3rd party” certification criterion (45 CFR 170.315(e)(1)) of the Program, this comment is beyond the scope of the proposal.

D. Information Blocking Requests for Information

1. Additional Exclusions From Offer Health IT—Request for Information

In the HTI–1 Proposed Rule (at 88 FR 23873), we sought comment on whether we should consider proposing in future rulemaking any additional exclusions from the offer health information technology or offer health IT definition proposed in § 171.102 of this proposal. We also welcomed information specific to how potential additional exclusions could be structured or balanced by other measures to mitigate risks of unintended consequences of such exclusions. We also indicated we would welcome comments on other steps ONC might consider taking to further encourage lawful donation or other subsidized provision of certified health IT to health care providers who may otherwise struggle to afford modern, interoperable health IT.

Comments. We received 14 comment submissions that included comments in response to this RFI.

Response. We thank the commenters for their feedback. As noted in the HTI–1 Proposed Rule, we may use this feedback to inform a future rulemaking.

2. Possible Additional TEFCA Reasonable and Necessary Activities—Request for Information

In the HTI–1 Proposed Rule (at 88 FR 23873 through 23874), we sought comment on whether any other particular practices that are not otherwise required by law, but are required of an individual person or entity by virtue of their status as a QHIN, Participant, or Subparticipant pursuant to the Common Agreement, pose a substantial concern or uncertainty regarding whether such practices could constitute information blocking as defined in 45 CFR 171.103. We sought comment on which particular practices the commenters believe are not covered by existing information blocking exceptions and that the commenters would advocate we assess for potential identification as reasonable and necessary activities that do not constitute information blocking as defined in 45 CFR 171.103. We also sought comment on whether and how any such identification of additional reasonable and necessary activities might pose concerns about unintended consequences for EHI access, exchange, or use by individuals or entities that are not QHINs, Participants, or Subparticipants.

Comments. We received 16 comment submissions that included comments in response to this RFI.

Response. We thank the commenters for their feedback. As noted in the HTI–1 Proposed Rule, we may use this feedback to inform future rulemaking.

3. Health IT Capabilities for Data Segmentation and User/Patient Access—Request for Information

In the HTI–1 Proposed Rule (at 88 FR 23874 through 23875), we discussed the importance of data segmentation capabilities and a variety of situations in which segmentation of data may be required or requested, including use cases where special handling or other restriction of access, exchange, or use of particular portion(s) of a patient's EHI is required by law or consistent with an individual patient's expressed preference regarding their own or others' access to their EHI. The HTI–1 Proposed Rule included a primary and several alternative proposals for a new certification criterion specifically focused on supporting patient preferences related to their right to request restrictions on certain uses and disclosures of their PHI under the HIPAA Privacy Rule (see 45 CFR 164.522). This proposal is addressed in section III.C.10 of this final rule (see section III.C.10 for further detail).

In addition to the specific right to request a restriction on disclosure consistent with 45 CFR 164.522, there are other use cases related to patient preferences—and specific nuances within use cases—which present challenges from a technical point of view.

We sought comment to inform steps we might consider taking to improve the availability and accessibility of solutions supporting health care providers' and other information blocking actors' efforts to honor patients' expressed preferences regarding their EHI (88 FR 23874). We also specifically sought (88 FR 23875) comment on additional topics related to the capabilities of health IT products to segment data, such as experiences with the availability and utility of certified health IT products' capabilities to segment data in use cases, including, but not limited to, the illustrative examples above.

Comments. We received 102 comment submissions that included comments in response to this RFI.

Response. We thank the commenters for their feedback. As noted in the HTI–1 Proposed Rule, we may use this feedback to inform a future rulemaking.

V. Incorporation by Reference

The Office of the Federal Register has established requirements for materials ( e.g., standards and implementation specifications) that agencies incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). Specifically, § 51.5(b) requires agencies to discuss, in the preamble of a final rule, the ways that the materials they incorporate by reference are reasonably available to interested parties or how it worked to make those materials reasonably available to interested parties; and summarize, in the preamble of the final rule, the material they incorporate by reference.

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

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

As required by § 51.5(b), we provide summaries of the standards we have adopted and incorporate by reference in the Code of Federal Regulations. We also provide relevant information about these standards and implementation specifications throughout the preamble.

We have organized the following standards and implementation specifications that we have adopted through this rulemaking according to the sections of the CFR in which they would be codified and cross-referenced for associated certification criteria and requirements that we have adopted.

Content Exchange Standards and Implementation Specifications for Exchanging Electronic Health Information—45 CFR 170.205

• Health Level 7 (HL7®) CDA® R2 Implementation Guide: C–CDA Templates for Clinical Notes STU Companion Guide, Release 4.1—US Realm, June 2023, Specification Version: 4.1.1.

URL: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=447.

Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.

Summary: The Consolidated Clinical Document Architecture (C–CDA) Companion Guide R4.1, provides essential implementer guidance to continuously expand interoperability for clinical information shared via structured clinical notes. The guidance supplements specifications established in the Health Level Seven (HL7) CDA® R2.1 IG: C–CDA Templates for Clinical Notes. This additional guidance is intended to make implementers aware of expectations and best practices for C–CDA document exchange. The objective is to increase consistency and expand interoperability across the community of data sharing partners who utilize C–CDA for information exchange.

• HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm 2.1.0—STU 2 US (HL7 FHIR eCR IG), August 31, 2022.

URL: https://build.fhir.org/ig/HL7/case-reporting/.

Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.

Summary: With the adoption and maturing of Electronic Health Records (EHRs), there are opportunities to better support public health surveillance as well as to better support the delivery of relevant public health information to clinical care. Electronic Case Reporting (eCR) can provide more complete and timely case data, support disease/condition monitoring, and assist in outbreak management and control. It can also improve bidirectional communications through the delivery of public health information in the context of a patient's condition and local disease trends and by facilitating ad hoc communications, as well as reduce health care provider burden by automating the completion of legal reporting requirements. The purpose of this FHIR IG is to offer opportunities to further enable automated triggering and reporting of cases from EHRs, to ease implementation and integration, to support the acquisition of public health investigation supplemental data, and to connect public health information ( e.g., guidelines) with clinical workflows. Over time, FHIR may also support the distribution of reporting rules to clinical care to better align data authorities and make broader clinical data available to public health decision support services inside the clinical care environment.

• HL7 CDA® R2 Implementation Guide: Public Health Case Report—the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1—US Realm (HL7 CDA eICR IG), July 2022.

URL: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=436.

Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.

Summary: The purpose of this implementation guide (IG) is to specify a standard for electronic submission of electronic initial public health case reports using HL7 Version 3 Clinical Document Architecture (CDA), Release 2 format. This implementation guide specifies a standard that will allow health care providers to electronically communicate the specific data needed in initial public health case reports (required by state laws/regulations) to jurisdictional public health agencies in CDA format—an interoperable, industry-standard format.

• HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG), July 2022.

URL: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=470.

Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.

Summary: The purpose of this implementation guide (IG) is to specify a standard for a response document for a public health electronic Initial Case Report (HL7 eICR all releases) using HL7 Version 3 Clinical Document Architecture (CDA), Release 2 format. Through the Reportability Response, public health seeks to support bidirectional communication with clinical care for reportable conditions in CDA format, which is an interoperable, industry-standard format.

• Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022.

URL: https://ecr.aimsplatform.org/ehr-implementers/triggering/.

Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.

Summary: The Reportable Condition Trigger Codes (RCTC) are a nation-wide set of standardized codes to be implemented within an electronic health record (EHR) that provide a preliminary identification of events that may be of interest to public health for electronic case reporting. The RCTC are the first step in a two-step process to determine reportability. The RCTC are single factor codes that represent any event that may be reportable to any public health agency in the United States. A second level of evaluation still must be done against jurisdiction-specific reporting regulations, to confirm whether the event is reportable and to which public health agency or agencies. The RCTC currently includes ICD 10 CM, SNOMED CT, LOINC, RxNorm, CVX, and CPT, representing condition-specific diagnoses, resulted lab tests names, lab results, lab orders for conditions reportable upon suspicion, and medications for select conditions.

Vocabulary Standards for Representing Electronic Health Information—45 CFR 170.207

• HL7 Standard Code Set CVX—Vaccines Administered, dated June 15, 2022.

URL: https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx.

This is a direct access link.

Summary: The CDC's National Center of Immunization and Respiratory Diseases (NCIRD) developed and maintains the CVX (vaccine administered) code set. It includes both active and inactive vaccines available in the US. CVX codes for inactive vaccines allow transmission of historical immunization records. When a MVX (manufacturer) code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated. These codes should be used for immunization messages using HL7 Version 2.5.1.

• National Drug Code Directory (NDC)—Vaccine NDC Linker, dated July 19, 2022.

URL: https://www2.cdc.gov/vaccines/iis/iisstandards/ndc_tableaccess.asp.

This is a direct access link.

Summary: The Drug Listing Act of 1972 requires registered drug establishments to provide the FDA with a current list of all drugs manufactured, prepared, propagated, compounded, or processed by it for commercial distribution. Drug products are identified and reported using a unique, three-segment number, called the National Drug Code (NDC), which serves as the universal product identifier for drugs. This standard is limited to the NDC vaccine codes identified by CDC.

• CDC Race and Ethnicity Code Set version 1.2, (July 08, 2021).

URL: https://www.cdc.gov/phin/resources/vocabulary/index.html.

The code set can be accessed through this link.

Summary: The CDC has prepared a code set for use in coding race and ethnicity data. This code set is based on current federal standards for classifying data on race and ethnicity, specifically the minimum race and ethnicity categories defined by the U.S. Office of Management and Budget (OMB) and a more detailed set of race and ethnicity categories maintained by the U.S. Bureau of the Census (BC). The main purpose of the code set is to facilitate use of federal standards for classifying data on race and ethnicity when these data are exchanged, stored, retrieved, or analyzed in electronic form. At the same time, the code set can be applied to paper-based record systems to the extent that these systems are used to collect, maintain, and report data on race and ethnicity in accordance with current federal standards.

• Medicare Provider and Supplier Taxonomy Crosswalk, 2021.

URL: https://data.cms.gov/provider-characteristics/medicare-provider-supplier-enrollment/medicare-provider-and-supplier-taxonomy-crosswalk/data/2021.

This is a direct access link.

Summary: The Medicare Provider and Supplier Taxonomy Crosswalk dataset lists the providers and suppliers eligible to enroll in Medicare programs with the proper healthcare provider taxonomy code. This data includes the Medicare specialty codes, if available, provider/supplier type description, taxonomy code, and the taxonomy description. The Healthcare Provider Taxonomy Code Set is a hierarchical code set that consists of codes, descriptions, and definitions. Healthcare Provider Taxonomy Codes are designed to categorize the type, classification, and/or specialization of health care providers. The Code Set is available from the Washington Publishing Company ( https://wpc-edi.com/ ). The Code Set is maintained by the National Uniform Claim Committee ( https://www.nucc.org/ ).

• Public Health Data Standards Consortium Users Guide for Source of Payment Typology Code Set, December 2020, Version 9.2.

URL: https://nahdo.org/sites/default/files/2020-12/SourceofPaymentTypologyUsersGuideVersion9.2December2020.pdf.

This is a direct access link.

Summary: The Source of Payment Typology was developed to create a standard for reporting payer type data that will enhance the payer data classification; it is also intended for use by those collecting data or analyzing healthcare claims information. Modeled loosely after the ICD typology for classifying medical conditions, the proposed typology identifies broad Payer categories with related subcategories that are more specific. This format provides analysts with flexibility to either use payer codes at a highly detailed level or to roll up codes to broader hierarchical categories for comparative analyses across payers and locations.

• Logical Observation Identifiers Names and Codes (LOINC ®) Database Version 2.72, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc., February 16, 2022.

URL: https://loinc.org/downloads/.

Access requires registration, a user account, and license agreement. There is no monetary cost for registration, a user account, and license agreement.

Summary: Informed by tracking healthcare trends, evaluating concept requests, and listening to guidance from the community, this release contains new and edited concepts in Laboratory, Clinical, Survey, Document Type, and other domains. It also includes a newly streamlined release file structure for more efficient download and use.

• The Unified Code for Units of Measure, Revision 2.1, November 21, 2017.

URL: https://ucum.org/ucum.html.

This is a direct access link.

Summary: The Unified Code for Units of Measure is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans. A typical application of The Unified Code for Units of Measure are electronic data interchange (EDI) protocols, but there is nothing that prevents it from being used in other types of machine communication.

• Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, March 2022.

URL: https://www.nlm.nih.gov/healthit/snomedct/us_edition.html.

Access requires a user account and license agreement. There is no monetary cost for a user account and license agreement.

Summary: In addition to the 279 new active concepts specific to the US Edition, the March 2022 SNOMED CT US Edition also includes the SNOMED CT COVID–19 Related Content published in the January 2022 SNOMED CT International Edition. This latest version of the US Edition also includes the SNOMED CT to ICD–10–CM reference set, with over 126,000 SNOMED CT source concepts mapped to ICD–10–CM targets.

• RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, July 5, 2022, Full Update Release.

URL: https://www.nlm.nih.gov/research/umls/rxnorm/docs/rxnormfiles.html.

Access requires a user account and license agreement. There is no monetary cost for a user account and license agreement.

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

United States Core Data for Interoperability—45 CFR 170.213

• United States Core Data for Interoperability (USCDI), October 2022 Errata, Version 3 (v3).

URL: https://www.healthit.gov/USCDI.

This is a direct access link.

Summary: The United States Core Data for Interoperability (USCDI establishes a minimum set of data classes that are required to be interoperable nationwide and is designed to be expanded in an iterative and predictable way over time. Data classes listed in the USCDI are represented in a technically agnostic manner to set a foundation for broader sharing of electronic health information. ONC has established a predictable, transparent, and collaborative expansion process for USCDI based on public evaluation of previous versions and submissions by the health IT community and the public, including input from a federal advisory committee.

Application Programming Interface Standards—45 CFR 170.215

• HL7 FHIR US Core Implementation Guide Version 6.1.0—STU6, June 19, 2023.

URL: http://hl7.org/fhir/us/core/.

This is a direct access link.

Summary: The US Core Implementation Guide is based on FHIR Version R4.0.1 and defines the minimum set of constraints on the FHIR resources to create the US Core Profiles. It also defines the minimum set of FHIR RESTful interactions for each of the US Core Profiles to access patient data. By establishing the “floor” of standards to promote interoperability and adoption through common implementation, it allows for further standards development evolution for specific uses cases.

• HL7 FHIR® SMART App Launch Implementation Guide Release 2.0.0, November 26, 2021.

URL: http://hl7.org/fhir/smart-app-launch/.

This is a direct access link.

Summary: This implementation guide describes a set of foundational patterns based on OAuth 2.0 for client applications to authorize, authenticate, and integrate with FHIR-based data systems.

VI. Collection of Information Requirements

Under the Paperwork Reduction Act of 1995 (PRA), codified as amended at 44 U.S.C. 3501 et seq., agencies are required to provide a 30-day notice in the Federal Register and solicit public comment on a proposed collection of information before it is submitted to the Office of Management and Budget for review and approval. In order to fairly evaluate whether an information collection should be approved by the OMB, section 3506(c)(2)(A) of the PRA requires that we solicit comment on the following issues:

1. Whether the information collection is necessary and useful to carry out the proper functions of the agency.

2. The accuracy of the agency's estimate of the information collection burden.

3. The quality, utility, and clarity of the information to be collected; and

4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.

Under the PRA, the time, effort, and financial resources necessary to meet the information collection requirements referenced in this section are to be considered. We solicited comment on these issues in the HTI–1 Proposed Rule (88 FR 23878 through 23880) for the matters discussed in detail below.

A. Independent Entity

As stated in the HTI–1 Proposed Rule (88 FR 23847), we proposed that response submissions related to the Insights Condition and Maintenance of Certification requirements would be submitted to an independent entity on behalf of ONC, and that we intend to award a grant, contract, or other agreement to an independent entity as part of the implementation of the Insights Condition and Maintenance of Certification requirements.

For estimating potential burden, we stated that we believe the independent entity would take approximately 5 minutes to review a response submission for completeness, and approximately 30 minutes to submit the completed response submission to ONC, based on how many products a developer of certified health IT may be required to submit responses for. We also stated that we plan to minimize burden for the independent entity by automating parts of the response review and submission process via an online tool.

Comments. We did not receive any comments specific to the response submissions related to the Insights Condition and Maintenance of Certification requirements that would be submitted to an independent entity on behalf of ONC.

Response. We continue to maintain our estimated annualized burden hours for an independent entity to take approximately 5 minutes to review a response submission for completeness, and approximately 30 minutes to submit the completed response submission to ONC. We refer readers to section VII (Regulatory Impact Analysis) of this final rule for the cost estimates related to the Insights Condition.

B. Health IT Developers

We stated in the HTI–1 Proposed Rule (88 FR 23846), developers of certified health IT would be required to submit responses associated with the Insights Condition and Maintenance of Certification requirements to an independent entity twice a year. For the purposes of estimating potential burden, we estimated 52 developers of certified health IT would be required to report on the Insights Condition. We estimated it would take approximately 21,136 to 44,900 hours on average for a developer of certified health IT to collect and report on the proposed measures within the Insights Condition and Maintenance of Certification requirements. For the purposes of estimating the total potential burden for developers of certified health IT, we estimated an average burden of 2,334,800 hours. We stated that this was crude upper bound estimate as there are multiple measures with varying complexity associated with the Insights Condition and Maintenance of Certification, and the number of developers of certified health IT required to report changes by each measure.

In the HTI–1 Proposed Rule (88 FR 23797), we stated for § 170.315(b)(11)(vii)(B), health IT developers would compile documentation regarding the intervention risk management practices listed in § 170.315(b)(11)(vii)(A), and upon request from ONC, make available such detailed documentation for any Predictive DSI, as defined in § 170.102, that the certified Health IT Module enables or interfaces with. We stated that we believe ONC has the authority to conduct Direct Review consistent with § 170.580(a)(2) for any known non-conformity or where it has a reasonable belief that a non-conformity exists enabling ONC to have oversight of these requirements. The PRA, however, exempts these information collections. Specifically, 44 U.S.C. 3518(c)(1)(B)(ii) excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities.

Comments. We did not receive any comments specific to either collection of information from developers of health IT or our corresponding PRA determinations.

Response. For the first information collection, we have provided updated burden estimates above in Table 4 to reflect revisions we have finalized for the Insights Condition. Recognizing that there was some overlap for the Insights and Real World Testing Condition of Certification, we have finalized that health IT developers who were required to report for the Insights Condition could leverage relevant Insights measures for real world testing annual reporting to reduce costs. In addition, due to significant overlap we have finalized across many of the measures, we have reduced the estimated burden hours assuming there will be a 10% overlap of developing infrastructure across all measures. For a more detailed discussion and the cost estimates of these new regulatory requirements associated with the Insights Condition and Maintenance of Certification, we refer readers to section VII (Regulatory Impact Analysis) of this final rule.

For the second information collection, we continue to maintain that information collected pursuant to an administrative enforcement action is not subject to the PRA under 44 U.S.C. 3518(c)(1)(B)(ii), which excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities.

C. ONC–ACBs

As stated in the HTI–1 Proposed Rule (88 FR 23782), we proposed in § 170.315(b)(11)(vii)(C) that a health IT developer that attests “yes” in § 170.315(b)(11)(v)(A) submit summary information of the intervention risk management practices listed in § 170.315(b)(11)(vii)(A)( 1) through ( 3) to its ONC–ACB via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. To support submission of documentation, and consistent with other Principles of Proper Conduct in § 170.523(f)(1), we proposed a new Principle of Proper Conduct for documentation related to § 170.315(b)(11)(vii)(C) in § 170.523(f)(1)(xxi). In the 2015 Edition Proposed Rule (80 FR 16894), we estimated fewer than ten annual respondents for all of the regulatory “collection of information” requirements that applied to the ONC–ACBs, including those previously approved by OMB. In the 2015 Edition Final Rule (80 FR 62733), we concluded that the regulatory “collection of information” requirements for the ONC–ACBs were not subject under the implementing regulations of the PRA at 5 CFR 1320.3(c).

Comments. We did not receive any comments specific to the new Principle of Proper Conduct for the submission of documentation in § 170.523(f)(1)(xxi).

Response. We have finalized the requirements in § 170.523(f)(1)(xxi), as proposed, which will require ONC–ACBs to ensure that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) submit summary information of intervention risk management practices (for each Predictive DSI supplied by the health IT developer as part of its Health IT Module) via publicly accessible hyperlinks that allow any person to access the summary information directly without any preconditions or additional steps. We continue to maintain our past determinations in that we estimate less than ten annual respondents for all the regulatory “collection of information” requirements for ONC–ACBs under part 170 of title 45, including those previously approved by OMB and in this final rule, and that the regulatory “collection of information” requirements under the Program described in this section are not subject under the implementing regulations of the PRA at 5 CFR 1320.3(c). For the cost estimates of these new regulatory requirements, we refer readers to section VII (Regulatory Impact Analysis) of this final rule.

VII. Regulatory Impact Analysis

A. Statement of Need

This final rule is necessary to meet our statutory responsibilities under the Cures Act and to advance HHS policy goals to promote interoperability and mitigate burden for health IT developers and users. Policies that could result in monetary costs for health IT developers and users include: (1) updates to ONC Certification Criteria for Health IT; (2) the Insights Condition and Maintenance of Certification requirements; and (3) policies related to information blocking.

While much of this final rule's costs will fall on health IT developers who seek to certify health IT under the Program, we believe the implementation and use of ONC Certification Criteria for Health IT, compliance with the Insights Condition and Maintenance of Certification requirements (“Insights Condition”), and the provisions related to information blocking will ultimately result in significant benefits for health care providers and patients. We outline some of these benefits below. We emphasize in this regulatory impact analysis (RIA) that we believe this final rule will remove barriers to interoperability and EHI exchange, which will greatly benefit health care providers and patients.

We note in this RIA that there were instances in which we had difficulty quantifying certain benefits due to a lack of applicable studies, data, or both. However, in such instances, we highlight the significant non-quantified benefits of our policies to advance an interoperable health system that empowers individuals to use their EHI to the fullest extent and enables health care providers and communities to deliver smarter, safer, and more efficient care.

B. Alternatives Considered

If there are alternatives to our policies, we have described them within each of the sections within this RIA. In some cases, we have been unable to identify alternatives that would appropriately implement our responsibilities under the Cures Act and support interoperability. We believe our policies take the necessary steps to fulfill the mandates specified in the Public Health Service Act (PHSA), as amended by the Health Information Technology for Economic and Clinical Health (HITECH) Act and the Cures Act, in the least burdensome way. We welcomed comments on our assessment and any alternatives we should consider.

C. Overall Impact

We have examined the impacts of this rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), Executive Order 14094 entitled “Modernizing Regulatory Review” (April 6, 2023), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96–354), section 1102(b) of the Social Security Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995; Pub. L. 104–4), Executive Order 13132 on Federalism (August 4, 1999), and the Congressional Review Act (5 U.S.C. 804(2)).

Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). The Executive Order 14094 entitled “Modernizing Regulatory Review” (hereinafter, the Modernizing E.O.) amends section 3(f)(1) of Executive Order 12866 (Regulatory Planning and Review). The amended section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action that is likely to result in a rule: (1) having an annual effect on the economy of $200 million or more in any 1 year (adjusted every 3 years by the Administrator of OIRA for changes in gross domestic product), or adversely affect in a material way the economy, a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local, territorial, or tribal governments or communities; (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise legal or policy issues for which centralized review would meaningfully further the President's priorities or the principles set forth in this Executive order, as specifically authorized in a timely manner by the Administrator of OIRA in each case.

A regulatory impact analysis (RIA) must be prepared for major rules with significant regulatory actions and/or with significant effects as per section 3(f)(1) ($200 million or more in any 1 year).

Based on our estimates, OMB's Office of Information and Regulatory Affairs has determined this rulemaking is significant per section 3(f)(1) as measured by the $200 million or more in any 1 year, and hence also a major rule under Subtitle E of the Small Business Regulatory Enforcement Fairness Act of 1996 (also known as the Congressional Review Act) (Pub. L. 104–121, Mar. 29, 1996).

a. Costs and Benefits

We have estimated the potential monetary costs and benefits of this final rule for health IT developers, health care providers, patients, and the Federal Government ( i.e., ONC), and have broken those costs and benefits out by section. In accordance with Executive Order 12866, we have included the RIA summary table as Table 37.

Our cost calculations quantify health IT developers' time and effort to implement these policies through new development and administrative activities. We recognize that the costs developers incur as a result of these policies may be passed on to certified health IT end-users. These end-users include but are not limited to the nearly 5,000 non-federal hospitals who provide acute, inpatient care and over one million clinicians who provide outpatient care to all Americans. Official statistics show that nearly all U.S. non-federal acute care hospitals ( https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records ) and the vast majority of outpatient physicians use certified health IT ( https://www.healthit.gov/data/quickstats/office-based-physician-electronic-health-record-adoption ). These policies affect the technology that all these health care providers use.

The benefits, both quantifiable and not quantifiable, articulated in this impact analysis have the potential to remove barriers to interoperability and EHI exchange for all these health care providers. Though these policies first require effort by developers of certified health IT to reflect them in their software, they must then be implemented by end-users to achieve the stated benefits—to improve healthcare delivery and the overall efficacy of the technology to document, transmit, and integrate EHI across multiple data systems.

To this end, we acknowledge that these estimated costs may not be borne solely by the developers of certified health IT and could be passed on to end-users through health IT developers' licensing, maintenance, and other operating fees and costs. We assume health IT developers may pass on up to the estimated costs of these policies, but not amounts above those estimated totals.

However, we have limited data on the fees and costs charged by health IT developers and how those fees and costs are distributed across various customer organizations. Given the ongoing nature of updates made by ONC to the Certification Program, EHR developers may have already built in the costs associated with making these updates in their existing contracts. To the extent the costs associated with the updates have not been taken into account, these costs may be passed on to end-users in different ways by developers of certified health IT and across different health care provider organization types. Large integrated healthcare systems may face different fees and other pricing than different sized or structured health care provider organizations. The incredible diversity of the healthcare system also limits our ability to accurately model how these costs could be passed on, even if there were data available to estimate how these policies might alter the pricing models and fee rates of the nearly 400 health IT developers we estimate will be impacted.

What we can say with more certainty is the overall impact of these policies on the healthcare system as a whole. These policies affect the certified health IT used by the providers who give care to a vast majority of Americans. Nearly all emergency room visits, hospital stays, and regular check-ups are documented and managed using certified health IT. These policies affect the interoperability of EHI for these care events and patients' electronic access to their health information. Certified health IT is now a nearly ubiquitous part of U.S. healthcare, and the costs and benefits estimated here encompass the widespread use of these technologies and their impact on all facets of care.

Overall, it is highly speculative to quantify benefits associated with the new technical requirements and standards for certification criteria we have adopted in this final rule. Emerging technologies may be used in ways not originally predicted. For example, ONC helped support the development of SMART on FHIR, which defines a process for an application to securely request access to data, and then receive and use that data. ONC could not have predicted the scale this technical approach has already achieved. Not only is it used to support major EHR products, but is also leveraged, for example, by Apple to connect its Health® App to hundreds of healthcare systems and for apps to launch on the Microsoft Azure® product. It is also speculative to quantify benefits for specific groups because benefits associated with many of ONC's policies, which advance interoperability, don't necessarily accrue to parties making the investments in developing and implementing the technologies. Benefits related to interoperability are spread across the healthcare ecosystem and can be considered a societal benefit. We have sought to describe benefits for each of the specific policies, and we welcomed comments on how to quantify these benefits across a variety of interested parties.

We note that we have rounded all estimates to the nearest dollar and that all estimates are expressed in 2022 dollars as it is the most recent data available to address all cost and benefit estimates consistently. The wages used to derive the cost estimates are from the May 2022 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics. We also note that estimates presented in the following “Employee Assumptions and Hourly Wage,” “Quantifying the Estimated Number of Health IT Developers and Products,” and “Number of End Users that Might Be Impacted by ONC's Proposed Regulations” sections are used throughout this RIA.

For policies where research supported direct estimates of impact, we estimated the benefits. For policies where no such research was identified to be available, we developed estimates based on a reasonable proxy.

We note that interoperability can positively impact patient safety, efficacy, care coordination, and improve healthcare processes and other health-related outcomes. However, achieving interoperability is a function of a number of factors including the capability of the technology used by health care providers. Therefore, to assess the benefits of our policies, we must first consider how to assess their respective effects on interoperability holding other factors constant.

Employee Assumptions and Hourly Wage

We have made employee assumptions about the level of expertise needed to complete the requirements in this section. Unless indicated otherwise, for wage calculations for federal employees and ONC–ACBs, we have correlated the employee's expertise with the corresponding grade and step of an employee classified under the General Schedule (GS) Federal Salary Classification, relying on the associated employee hourly rates for the Washington, DC, locality pay area as published by the Office of Personnel Management for 2022. We have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages. Therefore, we have doubled the employee's hourly wage to account for other indirect costs. We have concluded that a 100% expenditure on benefits and overhead is an appropriate estimate based on research conducted by HHS. Unless otherwise noted, we have consistently used the May 2022 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics (BLS) to calculate private sector employee wage estimates ( e.g., health IT developers, health care providers, HINs, attorneys, etc.), as we believe BLS provides the most accurate and comprehensive wage data for private sector positions. Just as with the General Schedule Federal Salary Classification calculations, we have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages. We welcomed comments on our methodology for estimating labor costs.

Quantifying the Estimated Number of Health IT Developers and Products

In this section, we describe the methodology used to assess the potential impact of new certification requirements on the availability of certified products in the health IT market. This analysis is based on the number of health IT developers that certified Health IT Modules for the 2015 Edition and the estimated number of developers that will participate in the future and the number of products these developers will certify.

These estimations are based on observed and expected conformance to 2015 Edition Cures Update requirements, market consolidation, industry trends and business decisions by participating developers, and other voluntary and involuntary withdrawals from the Program. In Table 5 below, we quantify the number of participating developers and certified products for the 2011 Edition, 2014 Edition, and 2015 Edition. We found that the number of health IT developers certifying products between the 2011 Edition and 2014 Edition decreased by 22.1% and the number of certified products available decreased by 23.2%. Furthermore, we found that between the 2014 Edition and 2015 Edition the number of participating developers and certified products decreased by 38.3% and 33.9%.

We recognize that certification for 2015 Edition and 2015 Edition Cures Update is ongoing and the number of health IT developers certifying products to the 2015 Edition and 2015 Edition Cures Update is subject to change. The figures for 2015 Edition in Table 5 reflect certifications through 2021 to provide a fixed point for analysis. We have found it prudent to use certification data that represent entire calendar years, and not to use certification stats mid-year. Therefore, 2015 Edition counts do not account for all certificates as of the publication of this rulemaking.

These figures give us insight into how participation in the Program and certification for individual certification editions has changed over time—the effect of both market and regulatory forces. Given historical trends and the asymmetric costs faced by developers of certified technology with large and small client bases, we must consider the effect of certification requirements going into effect and adopted in this rulemaking on future participation in the Program to make our best estimates of the cost and benefits of this rulemaking.

Our estimates of health IT developers and certified products specifically factor in a reduction in Program participation due to non-conformance with the 2015 Edition Cures Update criterion, “standardized API for patient and population services (“standardized API criterion”). The criterion replaces the 2015 Edition criterion, “application access—data category request” (“data category request criterion”). The data category request criterion required no content and exchange standard, although ONC communicated its intent to support a standard for future rulemaking and did encourage the use of the FHIR standard to meet criterion requirements. The new standardized API criterion does require FHIR as a content and exchange standard. Products that certified the data category request criterion must certify the standardized API criterion by December 31, 2022.

In the RIA for the ONC Cures Act Final Rule, we estimated that certified API products that did not support FHIR and must do so to meet regulatory requirements may face up to $1.9 million in development and other labor and maintenance costs to develop this technology for the first time (85 FR 25921). In 2018 and 2021 analyses, we found that support for FHIR was not common among 2015 Edition certified API products, although health IT market leaders predominantly supported the standard and used it as the content and exchange standard for their certified API technology. As of the end of 2021, our analysis of certification data found that approximately 60% of certified API developers did not support FHIR as part of their certified API technology. Considering this variation in support for the standard under the 2015 Edition and the costs faced by developers of certified health IT to meet this requirement, we expect some attrition from the Program.

Our model assumes that 1 in 4 certified API developers that do not currently support FHIR will not certify the standardized API criterion and withdraw their certificates. This is based on available market data and the historical trend of developers with small client bases to exit the Program as program requirements and their costs increase. Our estimates may change as health IT developers meet 2015 Edition Cures Update requirements and developers certify the standardized API criterion.

At the end of 2021, 414 health IT developers certified 569 products with active certificates for the 2015 Edition or 2015 Edition Cures Update. This is a 15% decrease in the number of health IT developers and a 20% decrease in 2015 Edition certified products, overall. Using our model of certification for the standard API criterion, we estimate an additional 11% decrease in the number of health IT developers and a 12% decrease in the number of certified products. For this RIA, we will use 368 as the number of health IT developers and 502 as the number of certified health IT products impacted by this rulemaking.

Number of End Users That Might Be Impacted by ONC's Finalized Regulations

For the purpose of this analysis, the population of end users impacted are the number of health care providers that possess certified health IT. Due to data limitations, our analysis is based on the number of hospitals and clinicians who participate in Medicare and who may be required to use certified health IT to participate in various CMS programs, inclusive of those providers who received incentive payments to adopt certified health IT as part of the Medicare EHR Incentive Program (now known as the Promoting Interoperability Program).

One limitation of this approach is that we are unable to account for the impact of our provisions on users of health IT that were ineligible or did not participate in the CMS EHR Incentive Programs or current Medicare performance programs ( e.g., Promoting Interoperability and Advanced Payment Model (APM) programs). For example, in 2017, 78 percent of home health agencies and 66 percent of skilled nursing facilities reported adopting an EHR ( https://www.healthit.gov/data/data-briefs/electronic-health-record-adoption-and-interoperability-among-us-skilled-nursing ). Nearly half of these facilities reported engaging aspects of health information exchange. However, we are unable to quantify, specifically the use of certified health IT products, among these provider types.

Despite these limitations, these Medicare program participants represent an adequate sample on which to base our estimates. An analysis of the CMS Provider of Services file for Hospitals ( https://data.cms.gov/provider-characteristics/hospitals-and-other-facilities/provider-of-services-file-hospital-non-hospital-facilities ) and CMS National Downloadable File of Doctors and Clinicians ( https://data.cms.gov/provider-data/dataset/mj5m-pzi6 ) provides a current accounting of Medicare-participating hospitals and practice locations. In total, we estimated about 4,800 non-federal acute care hospitals from the Provider of Services file and 1.25 million clinicians (including doctors and advanced nurse practitioners) across over 350,000 practice locations. If we assume that 96% of these hospitals and 80% of these practice locations use certified health IT, as survey data estimate, approximately 4,600 hospitals and 283,000 practice locations may face some passed-on costs from these requirements.

We understand there will likely not be a proportional impact of these costs across all health care providers. We can assume a hospital will face different costs than a physician practice, and no two hospitals will face the same costs, as those costs may vary based upon various characteristics, including but not limited to: staff size, patient volume, and ownership. The same is true for individual clinical practices, for which costs may vary across the same characteristics as hospitals. However, given our limited data, our approach to model pass-through costs onto health care providers assumes that hospitals face the same average costs and that they face a higher average cost per site than an individual clinical practice. Furthermore, we assume that clinical practices face the same average costs and lower average costs per site than the average hospital.

Based upon our prior modeling work for the ONC Cures Act Final Rule ( https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification ), we assume that one-third of estimated costs will be passed on to hospitals and the remaining amount on to clinician practices. Table 7 shows an assumed distribution of the costs across technology users. The cost to any one hospital or practice is small compared to the cost as a whole. The average hospital user of certified health IT could be expected to face up to $65,217 in average additional costs associated with implementing technology that adopt these policies. The average clinician practice site could be expected to face up to $2,170 in average additional costs associated with implementing technology that adopt these policies. These are considered pass-through costs incurred by the health IT developer to adopt these policies and not additional costs exogenous to health IT developer efforts to adopt and engineer these policies into their certified health IT.

These costs are not expected to be borne at once. Requirements from this finalized rulemaking may be implemented over several years, so in some cases an individual hospital or clinician's share of pass-through costs from their health IT developer may be distributed over one or more years. One issue to reiterate is that some of these costs may have already been incorporated within existing contracts and thus it is possible that the actual additional costs experienced by hospitals and clinicians may be lower than what is estimated. We do not have insights into proprietary contracts between EHR developers and their clients, and thus cannot speculate the extent to which the estimated additional costs will be passed on to their clients.

It's unknown if the estimated benefits will have the same distribution. A single clinician may not benefit the same as a single hospital, nor will one hospital benefit the same as another. However, given the same constraints to model costs across different provider types, we must assume a similar distribution for benefits as we propose for costs.

General Comments on the RIA

Comments. Commenters were generally concerned with unmeasured costs on entities beyond developers of certified health IT, including public health authorities, health care providers, and patients, noting that the proposed regulations have effects beyond developers of certified health IT.

Response. We appreciate these comments and understand concerns about the broader overall downstream impact of the proposed rulemaking on entities beyond developers of certified health IT, which are specifically regulated by ONC authorities. The impact analysis measures the estimated costs for developers of certified health IT to meet the proposed new Certification Program requirements—for example, to develop or modify the technical functionality of their certified health IT or adopt a new standard or standard version. These are the expected direct costs of the proposals on developers of certified health IT. However, we recognize that developers of certified health IT are largely private businesses who operate in a competitive marketplace and that they may not bear all costs to meet these requirements. We include in the “Costs and Benefits” section of the Regulatory Impact Analysis the estimated impact on certified health IT end users. In this case, health care providers, such as hospitals and clinicians. We believe these estimates provide a general, but not necessarily comprehensive, understanding of the possible pass-through costs borne by users of certified health IT.

Comments. Several commenters provided suggestions to broaden the scope and depth of the regulatory impact analysis, with specific recommendations to include patient-level measures.

Response. We appreciate commenters' thoughtful suggestions to build upon the proposed regulatory impact analysis, however, we're confident that the impact analysis provides the correct measurement of quantifiable costs and benefits. Though patient-level impacts are inherent to technology use, given the interconnectedness of healthcare, we believe that patient impacts are more directly tied to the implementation of the technology and not to its development and sale. It is hard to predict the effect on patient outcomes of one unique software technology from another, given that developers may choose to differentiate their product offerings to provide choices and competitive options to their customers. Furthermore, how the technology end-user, here defined as the health care provider, chooses to use the technology can affect outcomes for patient care, exogenous to the requirements that must be met by the developers of certified health IT, as part of Certification Program participation. Disentangling or singling out differential impacts of how technology is used and how it was designed or developed to be used is difficult to do and out of scope for this impact analysis.

Comments. Several commenters expressed concerns about the total costs measured and limited quantified benefits for this proposed rulemaking and the broader impact of these costs on end-users, who must adopt, learn, and use new versions of certified health IT.

Response. We understand commenters' concerns about the estimated cost amounts for the proposed rulemaking and acknowledge the limited quantifiable benefits for some of these proposals. The ONC Health IT Certification Program, although voluntary, attracts participation from hundreds of developers who certify hundreds of health IT products. The impact analysis assesses the expected costs and benefits across all these developers and products. The high rates of certified health IT use further show the expansive market for health IT. In the “Costs and Benefits” section of the Regulatory Impact Analysis, we estimate the expected costs on certified health IT end-users, here defined as the health care provider. When costs are distributed across these end users, we see the expected average costs passed on to individual health care providers. We recognize the hardships faced by health care providers to finance technology upgrades and pay for new software versions that incorporate the final rule's updates. We believe the benefits from interoperability improvements, transparency, patient access, and increased data sharing outweigh those costs.

“The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”

As discussed in section III.A of this preamble, we proposed to rename § 170.315 as the “ONC Certification Criteria for Health IT” and replace all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this would impact §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550).

Costs

This policy is not intended to place additional burden on developers of certified health IT and does not require new development or implementation. We expect the costs associated with attesting to these criteria to be de minimis because we do not expect any additional effort on the part of health IT developers.

Benefits

Maintaining a single set of “ONC Certification Criteria for Health IT” will create more stability for the health IT community and Program partners and make it easier for developers of certified health IT to maintain their product certificates over time. For example, when new rules are released, unchanged certification criteria will remain exactly as they are, rather than being placed in a new CFR section and requiring health IT developers to seek an updated certificate attributed to the new CFR section.

Comments. We received no comments on this impact analysis.

Response. We have finalized the impact analysis as proposed.

United States Core Data for Interoperability Version 3 (USCDI v3)

As discussed in section III.C.1 of this preamble, we have finalized to update the USCDI standard in § 170.213 by adding USCDI v3 and by establishing an expiration date for USCDI v1 (July 2020 Errata) on January 1, 2026, for purposes of the Program. We have finalized to add USCDI v3 in § 170.213(b) and incorporate it by reference in § 170.299. We have finalized to codify the existing reference to USCDI v1 (July 2020 Errata) in § 170.213(a). We have finalized that as of January 1, 2026, any Health IT Modules seeking certification for criteria referencing § 170.213 would need to be capable of exchanging the data classes and data elements that comprise USCDI v3. Additionally, once the USCDI standard in § 170.213 is updated to include USCDI v3, we have finalized that in order for previously certified Health IT Modules to maintain certification, health IT developers would be required to update their certified Health IT Modules to be capable of exchanging the data classes and data elements that comprise USCDI v3 for all certification criteria referencing § 170.213 by December 31, 2025. USCDI, via cross-reference to § 170.213, is currently referenced in the following criteria, each of which would refer to USCDI v1 and USCDI v3 until December 31, 2025 and only to USCDI v3 thereafter:

• “Care coordination—transitions of care—create” (§ 170.315(b)(1)(iii)(A)( 1)).

• “Care coordination—clinical information reconciliation and incorporation—reconciliation” (§ 170.315(b)(2)(iii)(D)( 1) through ( 3));

• “Patient engagement—view, download, and transmit to 3rd party—view” (§ 170.315(e)(1)(i)(A)( 1)).

• “Design and performance—consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A)).

• “Design and performance—application access—all data request—functional requirements” (§ 170.315(g)(9)(i)(A)( 1)); and

• “Design and performance—standardized API for patient and population services—data response” (§ 170.315(g)(10)(i)(A) and (B)).

We note that § 170.315(f)(5) also currently references § 170.213. However, we have finalized to rely on specific implementation guides for this certification criterion, rather than referencing § 170.213. Health IT Modules certified to § 170.315(f)(5) are no longer required to support USCDI, as finalized by this rule.

Costs

The USCDI v3 adds five new data classes and 46 new data elements that were not in USCDI v1. This will require updates to the Consolidated Clinical Document Architecture (C–CDA) standard, the FHIR US Core Implementation Guide, and updates to the criteria listed above. We have estimated the cost to health IT developers to add support for the additional data classes and data elements in USCDI v3 in C–CDA, and to make the necessary updates to the affected certification criteria. These estimates are detailed in Table 8 below and are based on the following assumptions:

1. Health IT developers will experience the assumed average costs of labor and data model use. Table 8 shows the estimated labor costs per product for a health IT developer to develop support for the additional data elements and data classes in USCDI v3 for each affected certification criteria. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur, on average, the costs noted in Table 8.

2. We estimate that 346 products certified by 269 developers will be affected. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.

We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this policy. However, not all these developers and products certify USCDI applicable criteria and need to meet the USCDI update requirements. As of the end of 2021, 73% of developers and 69% of products certified to one of the USCDI applicable criteria, listed above. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the USCDI updates. In Table 9, we also applied separate modifiers for individual criteria, calculated from an analysis of certificates through 2021. This allows us to assess USCDI update costs more accurately for individual criterion.

3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including other indirect costs is $127.82.

The cost to a health IT developer to develop support for the additional USCDI data classes and elements vary by the number of applicable criteria certified for a Health IT Module. On average, the cost to update C–CDA creation to support the additional USCDI data elements range from $230,400 to $460,800 per product. The cost to make updates to individual criteria to support the new data classes and elements range from $25,600 to $76,800 per product. Therefore, assuming 346 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers will, on average, range from $123 million to $289 million. This will be a one-time cost to developers per product that is certified to the specified certification criteria and will not be perpetual.

Benefits

We believe this policy will benefit health care providers, patients, and the industry collectively. The USCDI comprises a core set of structured and unstructured data needed to support patient care and facilitate patient access to health information using health IT; establishes a consistent baseline of harmonized data elements that can be broadly reused across use cases, including those outside of patient care and patient access; and will expand over time via a predictable, transparent, and collaborative process, weighing both anticipated benefits and industry-wide impacts. In Standards Bulletin 2022–2, we noted that based on these principles and the established prioritization criteria, USCDI v3 contains data elements whose collection and exchange promote equity, reduce disparities, and support public health data interoperability as discussed in Standards Bulletin 2021–3, where we highlighted that the collection, access, use, and reporting of SDOH as well as sexual orientation and gender identity data can help identify and address differences in health equity and improve health outcomes at an individual and population level. The additional data elements in USCDI v3 expand the baseline set of data available for health information exchange and thus provide more comprehensive health data for both providers and patients. We expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. In addition, we believe the increased availability of the additional data elements in USCDI v3 as interoperable structured data will facilitate improvements in the efficiency, accuracy, and timeliness of public health reporting, quality measurement, health care operations, and clinical research. However, we are not aware of an approach for quantifying these benefits and welcomed comments on potential approaches to quantifying these benefits.

Comments. We received no comments regarding the impact analysis for required adoption of USCDI v3 by applicable developers of certified health IT.

Response. The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.

Electronic Case Reporting

In section III.C.4 of this preamble, we discuss the finalized updates to the 2015 Edition certification criterion for “transmission to public health agencies—electronic case reporting” that would require developers of certified health IT to adopt specific electronic standards to support functional requirements that were previously adopted as part of the § 170.315(f)(5) certification criterion. We have finalized as proposed that Health IT Modules certified to this criterion must enable a user to: (i) create an electronic initial case report (eICR) according to at least the Health Level Seven (HL7) Clinical Document Architecture (CDA) eICR implementation guide (IG) or the eICR profiles defined in the HL7 Fast Health Interoperability Resources (FHIR) eCR IG and (ii) consume and process a reportability response (RR) according to at least the HL7 CDA RR IG or the RR profiles defined in the HL7 FHIR eCR IG. For the standards-based requirements in § 170.315(f)(5)(i) through (ii), we have finalized as proposed that Health IT Modules support all “mandatory” and “must support” data elements as applicable in the respective implementation guides (IGs). We have also finalized as proposed that Health IT Modules support the use of a version of the Reportable Conditions Trigger Code (RCTC) value set in § 170.315(f)(5)(1)(B) for determining potential case reportability.

Costs

This section describes the estimated costs of meeting the requirements in the updated “transmission to public health agencies—electronic case reporting” criterion. The cost estimates are based on the following assumptions:

• Health IT developers will experience the assumed average costs of labor and data model use. Tables 10–11 show the estimated labor costs per product for a health IT developer to meet the requirements in the eCR certification criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will, on average, incur the costs noted in the tables below.

• The number of products that will update to the new eCR criterion is estimated based on the total number of currently certified products plus the number of new products we expect to certify to the eCR criterion. Both estimates are adjusted for attrition. As of 2021, 54 developers certified 63 products to the eCR certification criterion or 13% of developers and 11% of products. Beginning in 2022, CMS required eligible hospitals and critical access hospitals in the Medicare Promoting Interoperability Program and eligible clinicians reporting on the Promoting Interoperability performance category in MIPS to report on use of eCR as part of the Public Health and Clinical Data Exchange Objective. The Electronic Case Reporting measure was optional in prior program years. Due to this new program requirement, we expect more Health IT Modules to certify the criterion in the coming year(s). As a proxy for possible future certification of eCR, we used the number of products that are currently certified to § 170.315(f)(1) (transmission to immunization registries) to estimate future certification of the eCR criterion. As of 2021, 31% of developers and 28% of products certified to the immunization criterion, but not the eCR certification criterion. We used these rates to estimate future certification of the eCR criterion. We estimate that 368 developers will certify 502 products impacted by this rulemaking. We estimate updates to the eCR certification criterion will impact 141 products certified by 114 developers for the first time (“New”) and 55 products already certified by 48 developers (“Current”) for an estimated total of 196 products certified by 162 developers.

• Wages are determined using BLS estimates. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. We assume that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage, including other indirect costs, is $127.82.

Total Costs, TC can be represented by the following equation:

Number of currently certified products, p _c = 55

Number of new certified products, p _n = 141

Fully loaded wage, w = 127.82

Labor hours for IG implementation, h _k , for each profile or IG, k

Labor hours for reporting, h _r

Based on the stated assumptions and costs outlined in Tables 13–15, the total estimated cost for certified health IT products to meet the finalized eCR certification criterion requirements will range from $36 million to $72.1 million. Assuming 162 health IT developers, there will be an average cost per developer ranging from $222,501 to $445,287, with an average cost per product ranging from $255,640 to $403,911 for new products and $0 to $276,091 for currently certified products.

Benefits

The primary benefit of adopting standards-based requirements for the eCR certification criterion is to improve consistency and promote interoperability over time. eCR is one of the pillars of ONC's and CMS' broader efforts to support effective healthcare data interoperability, which ensures that electronic health information is shared appropriately between healthcare organizations and public health agencies (PHAs) in the right format, through the right channel at the right time. Adopting a standards-based approach to eCR facilitates the exchange of health information between healthcare and public health by requiring the use of a common format for the creation of case reports and processing of a reportability response.

Potential benefits of a centralized approach to eCR have been assessed in an Association of State and Territorial Health Officials (ASTHO)-sponsored economic analysis of the efficiencies gained at PHAs by using centralized eCR services through the Association of Public Health Laboratories (APHL) Informatics Messaging Services (AIMS) platform, rather than using localized eCR solutions or manual, paper-based methods. A key component of this service is the inclusion of the CDC supported Council of State and Territorial Epidemiologists' (CSTE) developed decision support tool, Reportable Condition Knowledge Management System (RCKMS), which helps determine whether initial case reports are reportable in specific public health jurisdictions and eliminates confusion regarding where reports should be sent. According to the analysis, centralized eCR components could provide, “$2.5 million in increased efficiency per jurisdiction over 15 years” compared to manual reporting and “$310,000 of net benefits over 15 years” compared to localized eCR solutions.

Benefits of eCR to the healthcare sector and public health that will be promoted through standards adoption:

• Automatic, complete, accurate data reported in real-time (faster and more complete than manual entry) facilitates evidence-based decision-making for public health.
• Directly benefits public health response efforts by supporting situational awareness, case management, contract tracing, and efforts to coordinate isolation.
• Helps improve public health efficiency for evaluation and follow-up by providing PHAs with higher quality patient and clinical data in a timely manner.
• Reduces reporting burden for health care providers without disrupting clinical workflow, which can result in time and cost savings for the healthcare sector.
• Fulfills legal reporting requirements as well as CMS PI Program requirements for eCR, meaning benefits to public health would not come at an additional cost to health care providers who are already required to report.
• Streamlines reporting to multiple jurisdictions.

Benefits of certification criterion update:

• Adoption of standards for eCR will improve consistency and interoperability over time.

• Consistency in the reporting of specific data elements will increase the efficiency of exchange ( e.g., by facilitating automated reporting, enabling RCKMS and PHA processing of eICRs and bi-directional communication between providers and public health).

• RCTC value set establishes a baseline for use in the Program and enables developers of certified health IT to support newer or updated versions of RCTC value sets as soon as new releases are available.

Comments. We received no comments regarding the impact analysis for updates to the electronic care reporting criterion.

Response. The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.

Decision Support Interventions and Predictive Models

In section III.C.5 of this preamble, we have finalized the proposed new certification criterion for “decisions support interventions” in § 170.315(b)(11) with modifications, including more clearly separating technical functionality and ongoing maintenance for transparency purposes. The intent of this certification criterion is to ensure the availability of sufficient information on decision support interventions based on predictive models, including machine learning and artificial intelligence, through a more comprehensive list of source attributes and through the conduct and documentation of risk management activities. That information is intended to enable the selection and use of fair ( i.e., unbiased), appropriate, valid, and effective interventions. The certification criterion also would provide additional transparency into evidence-based decision support interventions by requiring that products allow decision support to be enabled based on specific data classes.

Alternatives Considered

We considered several alternative regulatory approaches, but believe this approach implies the lowest burden of available options while having a high likelihood of impacting decision-making. Because we seek to address a market failure related to inadequate and asymmetric information, we proposed an informational intervention. The approach is market-oriented and aimed at ensuring that model purchasers and users have sufficient information to select and use models responsibly. We believe that several alternative approaches, such as performance or design standards would imply substantially higher regulatory burden and are inappropriate given the ongoing research and development in this area and uncertainty inherent in predictive model development.

Rather than mandatory reporting, we considered the potential for a voluntary database to which model developers might report information on the quality of their models. However, we are concerned that such a database would achieve relatively low participation because of disincentives for some developers to make the performance of their models' public. We believe that the current approach in which we have required reporting of a set of core source attributes that we strongly believe should be available for all models ( e.g., intended use) and reporting of other attributes ( e.g., external validation results) as required if available but otherwise providing the option to clearly label as missing, is a more effective balance between prescriptive requirements and voluntary participation. Given the national availability of many models, Federal regulation is beneficial to set a common set of expectations across the national market.

Costs

This section describes the estimated costs of the “Decision Support Intervention” certification criterion and associated maintenance of certification requirements. The cost estimates are based on the following assumptions:

• Health IT developers will experience the assumed average costs of labor and data model use. Table 16 shows the estimated labor costs per product for a health IT developer to develop support for the predictive decision support certification criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will, on average, incur the costs noted in Table 16.

• The number of health IT developers and products certified will closely align with certification of the 2015 Edition clinical decision support (CDS) criterion. We estimate that 301 products certified by 243 developers will be affected by our policy. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, we estimate that not all these developers and products will certify the new Decision Support Intervention criterion. As of the end of 2021, 66% of developers and 60% of products certified to the CDS criterion. We assume that all products certified to the CDS criterion will certify the new Decision Support Intervention criterion. We, therefore, use certification of the CDS criterion as a proxy for the percent of developers and products that will certify the Decision Support Intervention criterion in the future. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products that will certify this criterion and be impacted by the costs of this new criterion.

• Wages are determined using BLS estimates. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. We assume that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage, including other indirect costs, is $127.82.

We believe developers will expend substantial initial effort to develop the technical capabilities to support the criterion and that their effort will be varied depending on the extent, scope, and scale necessary on their part to develop initial documentation related to source attributes and intervention risk management as required as part of their maintenance of certification to this certification criterion. In this final rule, we require that developers maintain and keep current information source attribute information for certain decision support interventions. We also have finalized requirements for an annual review of risk management information and documentation. We believe that both requirements imply sustained annual effort, which we have estimated in Table 16. However, we have constrained the scope of responsibility for developers of certified health IT under this final rule.

Table 17 provides the overall costs projecting that 301 products will be certified to the criterion.

Benefits

Predictive DSIs are common, with some individual interventions being applied to tens or hundreds of millions of individuals despite, in some cases, crucial insufficiencies in the performance of those models. However, there are a wide range of potential applications of Predictive DSI, and we believe that the healthcare delivery field is far from fully adopting these interventions in the circumstances where they would be beneficial. Because Predictive DSIs are currently, and potentially can be, applied to a wide range of contexts, comprehensively estimating quantitative benefits from improved interventions and underlying models is challenging, and for some types of benefits infeasible. However, we have generated some quantitative benefits related to the scope of potential cost savings and have identified additional benefits, characterized qualitatively, to the adopted certification criterion and its associated maintenance of certification requirements.

We believe that the most directly quantifiable benefits of the adopted changes to predictive decision support relate to increased use of more accurate and effective Predictive DSIs. We believe that increased transparency into the performance of models and risk management practices related to their development will result in (1) wider uptake of Predictive DSIs overall due to greater certainty about the intervention's performance, and (2) selection of fairer, more appropriate, more accurate, more effective and safer models through greater information on the available choices. However, we acknowledge that there is substantial uncertainty in the degree to which the policy will result in wider uptake and use of more effective interventions.

Given the sheer number of algorithms and applicable conditions and uses, we have selected two relevant scenarios—sepsis onset and ambulatory care sensitive admission—which have a fair amount of supporting research, to show the potential benefits of our policy. First, in patient populations in whom the risk of sepsis is moderate to high, risk-assessments based on patient factors and characteristics ( i.e., data elements) are (or should be) made for implementing rapid risk-based patient care. The potential impact of using Predictive DSIs to more effectively conduct these risk-assessments can illustrate the benefits. Admissions for sepsis cost $24 billion per year and early detection of sepsis can lead to interventions that dramatically reduce those costs. However, advanced Predictive DSIs for the identification of sepsis are not widely used and instead older models, such as Sequential Organ Failure Assessment (SOFA), are dominant.

Existing evidence indicates that more advanced predictive models can provide substantial performance improvements over simpler, widely used models. The potential benefits of more advanced models are large. A prospectively evaluated sepsis Predictive DSI decreased in-hospital mortality related to sepsis by 39.5%, decreased length of stay by 32.3% and decreased readmission by 22.7% in one clinical trial. However, there is also substantial uncertainty about whether models will offer that benefit when implemented on a broad scale. Performance of the same model evaluated in that clinical trial was substantially lower in a separate evaluation, and that difference may be attributable to difference in performance in varied deployments and locations.

Transparency has the potential to shed light on the variation in performance across models and to drive uptake of higher performing models. A systematic review of predictive models designed to detect early onset of sepsis found that published evaluations demonstrated sensitivities ranging from 64% to 98%. One sepsis model that was recently widely adopted was found in subsequent validation to have relatively poor performance with a sensitivity of 33%. This again highlights the potential value of greater information to evaluate these models.

Given the heterogeneity in the literature, it is challenging to estimate the extent to which the availability of information that will be facilitated by our policy will impact the average quality of predictive models used or how that average quality will evolve over time. Because models often perform less effectively in real-world implementation than in test environments, we believe the likely impact will be smaller than that implied by the literature but believe an impact on the average sensitivity of models used of 5 percentage points is reasonable. We note that in the cited systematic review, the median sensitivity of included models was 81% so that our assumption is that with the rule in place median sensitivity of available models will increase by 5 percentage points to 86%. Based on cost savings indicated in the available literature, we estimate that early detection of onset will result in cost savings of 50% for the incrementally more commonly detected patient event.

Beyond increases in the accuracy and effectiveness of models used, it is also challenging to estimate the extent to which the adopted certification criterion will result in increased use of more accurate decision support interventions. Findings on other transparency related public policies, such as nutrition labels, indicate that use of labels can have substantial impacts on consumers choices. While these findings indicate a likely increase in use of interventions from transparency related policies, we believe it is difficult to transfer these findings to the specific case of Predictive DSIs. We are assuming that the policy will relate to application of improved models (with an average increased sensitivity of 5%) by 2% a year beginning in the year that requirements commenced.

Another example we wish to highlight along with sepsis is the use of models to identify patients at risk for ambulatory care sensitive conditions (ACSCs). Such conditions result in costs of $33.7 billion (bn) per year. As in the sepsis example, there are several existing predictive models, and they exhibit a wide range accuracy. We therefore believe it is reasonable to apply the estimates used in the prior example related to sepsis onset to estimate potential benefits related to ambulatory care-sensitive admissions. Given substantial differences in the sensitivity of models intended to identify patients at risk of ambulatory care-sensitive admissions, we believe this assumption is reasonable.

We estimate all benefits on a 10-year time horizon. Because developers of certified health IT with Health IT Modules certified to the existing certification criterion in § 170.315(a)(9) are not required to certify to the adopted criterion in § 170.315(b)(11) until 2024, we note that benefits would not commence until the third year. We believe that period of time allows sufficient time for the full impact of the policy to take effect, including developer certification to the criterion, publication of risk management information, and hospital resorting to improved predictive models. We expect that the use of predictive models in healthcare will continue to evolve well beyond that time horizon; however, given the dynamic and uncertain nature of this area, we do not believe it would be appropriate to provide estimates beyond that period.

We examined the sensitivity of our estimated benefits based on uncertainty in the underlying rates. We varied two rates: the average increase in the sensitivity of models used and the increased rate at which more accurate models were used. Specifically, we recalculated benefits with an assumed sensitivity increase of 2.5%, 5% or 10% (with 5% representing our primary estimate) and an assumed increase in application of models of 1%, 2% and 3% (with 2% representing our primary estimate). In these analyses, we estimated that the 10-year undiscounted incremental impacts ranged from $259,650,000 to $3,115,800,000. We also estimated the annualized benefits of the incremental impacts using alternative modeling assumptions and present them in Table 19.

We have highlighted one condition and one event that will benefit from the more widespread use of more accurate predictive models under this final rule. There are numerous other conditions and events in which increased sensitivity could offer substantial cost savings. However, given uncertainty in the estimates around the included estimates, and important differences across various conditions and the extent to which Predictive DSIs might impact care, we are not confident that the assumptions generated here are transferable to other contexts.

In addition to benefits associated with more sensitive models, we believe that there are numerous other potential benefits related to the more widespread use of more accurate predictive decision support. However, many of the benefits associated with greater accuracy, specific models, such as reduced inappropriate treatment or reduced burdens on providers, are difficult to quantify and have to date been targeted by fewer predictive models. For salient examples, we note that false-positives for screening for with $4 billion per year and that more specific interventions could reduce the rates of false-positives. We further note that provider burnout and fatigue are important and costly issues, we believe these benefits may be large. However, since we are aware of fewer estimates around the potential impact of Predictive DSIs to address these issues, we have not attempted to quantify the potential benefits associated with their use.

Beyond the benefits associated with greater use of accurate models, we believe there will be several important benefits associated with the adopted transparency requirements. We believe that increased transparency into the intended use of models will increase the appropriate use of models. There is concern that models will be applied to populations, contexts, and decisions for which they are not well-suited to provide accurate information. A transparent display of the intended use and what is out of scope could reduce the occurrence of treatment decisions resulting in harm. However, we are not aware of efforts to quantify harm from misapplied models today.

We believe increased transparency into models and practices will result in the selection and use of fairer models. Biased models, for instance, exhibit higher sensitivity or specificity for some groups than others and are likely to deprioritize treatment for certain groups. They are also likely to recommend inappropriate treatment for certain groups resulting in limited benefit and potential harm to those certain groups relative to those for whom models the perform well. Reliance on biased models, particularly those used in the context of preventive care or early identification of a disease, could result in greater costs for groups in which the model performs poorly compared to developing a fairer model or not using the model altogether. Greater transparency into the fairness of models will enable users to select fairer models and reward producers of fairer models. This will lead to the selection of models that further, opposed to hinder, the equitable delivery of healthcare to groups that have been marginalized. We requested comment on the feasibility of quantifying benefits associated with increased model fairness, which may be identifiable through the increased benefits to groups that have been marginalized.

We believe that increased transparency will lead to an effective market for predictive models that adequately incentivizes and rewards high-quality models. Currently, model developers have an information advantage relative to consumers, and consumers of models act under considerable uncertainty regarding the quality of the product they are acquiring. This market dynamic can lead to harmful choices by consumers and inadequate reward for high quality developers, potentially leading to a feedback loop through adverse selection that encourages market exit by high quality, high-cost model developers. However, adequately characterizing the benefits of a higher information market to the overall quality of models developed and sold is not feasible.

Comments. We received no comments on this analysis.

Response. The final impact analysis was updated to include the expected annual costs for applicable developers of certified health IT to meet annual documentation requirements. Cost estimates were also updated to reflect wages of software developers as of 2022.

Synchronized Clocks Standard

In section III.C.6 of this preamble, we discuss the proposed removal of the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905), in 45 CFR 170.210(g). However, we proposed to maintain an expectation that Health IT Modules certified to applicable certification criteria continue to utilize any network time protocol (NTP) standard that can ensure a system clock has been synchronized and meets the time accuracy requirements as defined in the applicable certification criteria in § 170.315(d)(2), (3), (10), and (e)(1).

Costs

This policy is not intended to place additional burden on health IT developers as it does not require new development or implementation. Rather, a health IT developer's costs will be de minimis because we are providing flexibility to allow health IT developers to use any NTP standard that exists. We welcomed comments on these expectations.

Benefits

We believe leveraging existing NTP standards and not requiring a specific standard allows for more flexibility. We have heard from health IT developers that the current required functionality is in place but not fully used. This policy allows for additional flexibility to meet the time accuracy requirements as defined in applicable certification criteria. For example, under this policy, Microsoft-based certified health IT using Operating System to synchronize network time, may use Microsoft's version of Network Time Protocol (MS NTP) as an alternative to Network Time Protocol Version 4 (NTP v4) of RFC 5905 as specified in § 170.210(g), and must meet the time accuracy requirement as defined in the certification criteria. We welcomed comments regarding potential approaches for quantifying these benefits.

Comments. We received no comments on this section of the analysis.

Response. We have finalized the impact analysis as proposed for this section.

Standardized API for Patient and Population Services

As discussed in section III.C.7 of this preamble, we have finalized as proposed, to update the certification criterion, “standardized API for patient and population services,” to align with updated standards and new requirements. We have finalized as proposed, to adopt the SMART App Launch Implementation Guide Release 2.0.0 in § 170.215(c)(2), which would replace SMART Application Launch Framework Implementation Guide Release 1.0.0 in § 170.215(a)(3) (finalized in this rule in § 170.215(c)(1)).

We also have finalized as proposed, to revise the requirement in § 170.315(g)(10)(vi) to specify that Health IT Modules presented for certification that allow short-lived access tokens to expire, in lieu of immediate access token revocation, must be able to revoke an authorized application's access at a patient's direction within one hour of the request.

Additionally, we have finalized to amend the API Condition and Maintenance of Certification requirements by adding the requirement that Certified API Developers with patient-facing APIs must publish their service base URLs for all customers, regardless of whether the certified Health IT Modules are centrally managed by the Certified API Developer or locally deployed by an API Information Source. We have finalized that these service base URLs must conform to a specific data format.

Finally, we have also adopted the FHIR US Core Implementation Guide STU version 6.1.0 in § 170.215(b)(1)(ii). Health IT systems that adopt this version of the US Core IG can provide the latest consensus-based capabilities for providing access to USCDI v3 data classes and elements using a FHIR API.

Costs

We have estimated the cost to health IT developers to make these updates. These estimates are detailed in Table 20 below and are based on the following assumptions:

1. Health IT developers will experience the assumed average costs of labor and data model use. Table 20 shows the estimated labor costs per product for a health IT developer to implement these updates to the criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will on average, incur the costs noted in Table 20.

2.We estimate that 276 products certified by 228 developers will be affected by our policies. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. We estimate that in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, not all these developers and products will certify the Standardized API criterion and need to meet these adopted requirements. As of the end of 2021, 62% of developers and 55% of products certified the “application access—data category request” criterion. By December 31, 2022, all products that certify this criterion must certify the new standardized API criterion. We, therefore, use current certification of the data category request criterion as a proxy for the percent of developers and products certified to the standardized API criterion in the future. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by these updates to the standardized API criterion.

3. Wages are determined using BLS estimates. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including other indirect costs is $128.

The cost to a health IT developer to update the standardized API criterion for their certified Health IT Modules will range from $166,000 to $397,000 per product, on average. Therefore, assuming 276 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers will on average, range from $44 million to $103 million. This will be a one-time cost to developers per product that is certified to the specified certification criterion and will not be perpetual.

Benefits

We believe these policies will benefit health care providers, patients, and the industry. The adoption of the FHIR US Core IG v6.1.0 will, with the additional data elements in USCDI v3, expand the baseline set of data available and provide more comprehensive health data for both providers and patients. Updates to the SMART App Launch Framework IG 2.0 will align the certified API functionality with current adopted standards-based methods to connect patients' health information to the app of their choice. Furthermore, updated requirements to the service-base URL publication API maintenance of certification requirement will provide a standard format for all published FHIR endpoints to be securely discovered and consumed by authorized applications. The standard publication format will reduce the burden on patients, app developers, and other third parties to find and connect to the appropriate FHIR endpoint to initiate data access. This will directly benefit the speed and efficiency of making these connections and reduce the level of effort on third parties to access and use these standards-based APIs.

We expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. In the ONC Cures Act Final Rule (85 FR 25925), we estimated the total annual benefit of APIs on average, to range from $0.34 billion to $1.43 billion. These updates to the criterion ensure the benefits of APIs are maintained and the annual benefit due to improved health outcomes and patients having access to their online medical record is realized.

As described previously, there are additional potential future benefits to the expanded availability of an interoperable API for patient and population services that are not quantifiable at this time. For some use cases, there is a clear indication of future technical direction, but currently there is insufficient implementation to clearly quantify the scope. For example, CMS has identified an intent to leverage APIs for population services in order to modernize quality measurement and quality reporting under value-based payment programs. In 2016, a report found that quality measurement reporting bears an estimate $15.4 billion cost on clinicians for chart abstraction, data validation, and measure reporting. The potential future use of FHIR-based APIs for quality measurement could provide greater ability to implement real time data for quality purposes and drastically reduce the costs of manual quality reporting workflows. We sought comment on potential means to estimate these benefits and future cost savings.

Comments. We received no comments related to this impact analysis of updates to the standardized API criterion.

Response. The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.

Patient Demographics and Observations Certification Criterion

As discussed in section III.C.8 of this preamble, we have finalized as proposed to rename the “demographics” certification criterion (§ 170.315(a)(5)) to “ patient demographics and observations.” We have finalized as proposed to add the data elements “Sex Parameter for Clinical Use” in § 170.315(a)(5)(i)(F), “Name to Use” in § 170.315(a)(5)(i)(G), and “Pronouns” in § 170.315(a)(5)(i)(H) to the “Patient demographics and observations” certification criterion (§ 170.315(a)(5)). Additionally, we have finalized as proposed to replace the terminology standards specified for “Sex” in § 170.315(a)(5)(i)(C), “Sexual Orientation” in § 170.315(a)(5)(i)(D), and “Gender Identity” in § 170.315(a)(5)(i)(E). As such, ONC has finalized as proposed to remove the fixed list of terms for “Sex” in § 170.315(a)(5)(i)(C), “Sexual Orientation” in § 170.315(a)(5)(i)(D), and “Gender Identity” in § 170.315(a)(5)(i)(E) which are represented by SNOMED CT and HL7® Value Sets for AdministrativeGender and NullFlavor in § 170.207(o)(1) and (2)), and replace it with the SNOMED CT code sets specified in § 170.207(n)(2) and (o)(3).

The proposed modifications to the “patient demographics and observations” criterion will provide greater clarity and standardization to how a patient's sexual orientation and gender identity are recorded electronically in the electronic health record. The USCDI v3 standard includes new data elements for Sexual Orientation and Gender Identity. These data elements are required to be included as part of a patient's electronic health information and included in any record shared with the patient, the patient's caregiver, or health care provider.

Costs

The adopted modifications to the “patient demographics and observations” criterion include 6 tasks: (1) Modify Sex, (2) Modify Sexual Orientation, (3) Modify Gender Identity, (4) Add Sex Parameter for Clinical Use, (5) Add Pronouns, and (6) Add Name to Use. These tasks have their own level of effort, and these estimates are detailed in Table 23 below and are based on the following assumptions:

1. Health IT developers will use the same labor costs and data models. Table 23 shows the estimated labor costs per product to modify the “patient demographics and observations” criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Table 23.

2. We estimate that 321 products certified by 261 developers will be affected by our policy. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.

The estimate of 321 products certified by 261 developers is derived as follows. We estimate that, in total, 368 health IT developers would certify 502 health IT products impacted by this rulemaking. However, not all these developers and products certify the “patient demographics and observations” criterion and need to meet the adopted requirements. As of the end of 2021, 71% of developers and 64% of products certified to the criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the modifications to the criterion.

3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including other indirect costs is $128.

The cost to a health IT developer to make the modifications to the “patient demographics and observations” criterion for their certified Health IT Modules will range from $92,160 to $238,080 per product, on average. Therefore, assuming 321 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers will, on average, range from $30 million to $76 million. This will be a one-time cost to developers per product that is certified to the specified certification criterion.

Benefits

Improved recording of sexual orientation and gender identity in the medical record has multiple benefits. This has clinical benefits for patients in the immediate term as information related to gender identity and sexual orientation is critical for informing treatment. Additionally, advances in treatment may result from researchers having more reliable and accurate sexual orientation and gender identity data available. Not only will this benefit clinical care teams who are treating patients within a particular clinical setting, this will improve the interoperability of this data when shared electronically with the patient or the patient's authorized representative through the technology of their choosing or when shared electronically with a third party elected by the patient, such as an application developer, health care provider, or other entity.

The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. Furthermore, having a patient's information recorded uniformly and available across their medical records would improve the patient's access to their information and ensure the information is available uniformly across technologies.

Comments. We received no comments specific to this update to the “demographics” criterion.

Response. The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.

Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)

As discussed in section III.C.9 of this preamble, we proposed to modify the “transitions of care” certification criterion in § 170.315(b)(1). We proposed to replace the fixed value set for the USCDI data element Sex and instead enable health IT developers to represent sex with the standard adopted in § 170.207(n)(1) for the time-period up to and including December 31, 2025; or § 170.207(n)(2).

Costs

1. Health IT developers will use the same labor costs and data models. Table 26 shows the estimated labor costs per product to modify the transitions of care criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Table 26.

2. We estimate that 281 products certified by 236 developers will be affected by our policy. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.

The estimate of 281 products certified by 236 developers is derived as follows. We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, not all these developers and products certify the transitions of care criterion and need to meet the adopted requirements. As of the end of 2021, 64% of developers and 56% of products certified to the transitions of care criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the modifications to the criterion.

3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $128.

The cost to a health IT developer to make the modifications to the transitions of care criterion for their certified Health IT Modules will range from $0 to $5,120 per product, on average. Therefore, assuming 281 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers will, on average, range from $0 to $1.5 million. This will be a one-time cost to developers per product that is certified to the specified certification criterion.

Benefits

There are multiple benefits associated with having more granular information available related to improved recording of sexual orientation and gender identity. This has clinical benefits for patients in the immediate term as information related to gender identity and sexual orientation is critical for informing treatment. Additionally, advances in treatment may result from researchers having more reliable and accurate sexual orientation and gender identity data available. Not only will this benefit clinical care teams who are treating patients within a particular clinical setting, this will improve the interoperability of this data when shared electronically with the patient or the patient's caregiver through the technology of their choosing or when shared electronically with a third party elected by the patient, such as an application developer, health care provider, or other entity.

The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. Furthermore, having a patient's information recorded uniformly and available across their medical records will improve the patient's access to their information and ensure the information is available uniformly across technologies.

Comments. We received no comments related to the impact analysis of updates to the Transitions of care criterion.

Response. The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.

Patient Right To Request a Restriction on Use or Disclosure

As discussed in section III.C.10 of this preamble, we have finalized as proposed to modify the existing criterion in § 170.315(e)(1) to add a paragraph (iii) stating patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. This policy is standards agnostic for the implementation of functional requirements supporting workflows for a patient to exercise their right to request restrictions on certain uses and disclosures of their EHI and for a HIPAA covered entity, such as a clinician that transmits any health information in electronic form in connection with a HHS adopted standard transactions, to honor such request.

Costs

The update to § 170.315(e)(1) includes a new technical functionality that provides patients (and their authorized representatives) the ability to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. This task has its own level of effort, and this estimate is detailed in Table 28 below and is based on the following assumptions:

1. Health IT developers will use the same labor costs and data models. Table 29 shows the estimated labor costs per product to modify § 170.315(e)(1). We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Table 29.

2. We estimate that 246 products certified by 210 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.

The estimate of 246 products certified by 210 developers is derived as follows. We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(e)(1) and need to meet the proposed requirements. As of the end of 2021, 57% of developers and 49% of products certified § 170.315(e)(1). We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the criterion.

3. According to the Month 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $128.

The cost to a health IT developer to modify § 170.315(e)(1) for their Health IT Modules would range from $30,720 to $74,240 per product, on average. Therefore, assuming 246 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers would, on average, range from $7.5 million to $18 million. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual.

Benefits

In the ONC Cures Act Final Rule, we noted that the updated criteria in § 170.315(b)(7) and (b)(8) (“security tags—summary of care—send” and “security tags—summary of care—receive”) would benefit providers, patients, and ONC because it would support more complete records, contribute to patient safety, and enhance care coordination. We stated that implementing security tags enables providers to share patient records more effectively with sensitive information, thereby protecting patient privacy while still delivering actionable clinical content. We emphasized that health care providers already have processes and workflows to address their existing compliance obligations, which could be made more efficient and cost effective using health IT. We were, however, unable to quantify these benefits at the time because we did not have adequate information to support quantitative estimates (85 FR 25927).

Since we issued the ONC Cures Act Final Rule, the number of developers certified to the voluntary criteria in § 170.315(b)(7) and (b)(8) has increased, but it remains a small percentage of the total products certified. While we believe there will be similar benefits to patients and other covered entities from our policies in this rule to support privacy workflows, we similarly are limited in our ability to estimate such impact at this time.

Comments. We received no comments specific to this impact analysis of patient requested restrictions.