[Federal Register Volume 89, Number 6 (Tuesday, January 9, 2024)]
[Rules and Regulations]
[Pages 1192-1438]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2023-28857]



[[Page 1191]]

Vol. 89

Tuesday,

No. 6

January 9, 2024

Part III





Department of Health and Human Services





-----------------------------------------------------------------------





 45 Parts 170 and 171





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

Federal Register / Vol. 89, No. 6 / Tuesday, January 9, 2024 / Rules 
and Regulations

[[Page 1192]]


-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Parts 170, 171

RIN 0955-AA03


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 Sec.  170.315(a)(5)
    ix. Updates to Transitions of Care Certification Criterion in 
Sec.  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 Sec.  170.315(a)(5)
    9. Updates to Transitions of Care Certification Criterion in 
Sec.  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

[[Page 1193]]

    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.\1\ 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.
---------------------------------------------------------------------------

    \1\ Reasonable and necessary activities that do not constitute 
information blocking, also known as information blocking exceptions, 
are identified in 45 CFR part 171 subparts B and C. ONC's official 
website, HealthIT.gov, offers a variety of resources on the topic of 
Information Blocking, including fact sheets, recorded webinars, and 
frequently asked questions. To learn more, please visit: https://www.healthit.gov/topic/information-blocking/.
---------------------------------------------------------------------------

    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.<SUP>2 3</SUP> Additionally, 
this final rule

[[Page 1194]]

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

    \2\ ONC. (2022, October 18). API Resource Guide. ONC Health IT 
Certification Program API Resource Guide. Retrieved March 16, 2023, 
from https://onc-healthit.github.io/api-resource-guide/.
    \3\ Section 4002 of the 21st Century Cures Act (Cures Act) 
establishes a condition of certification that requires health IT 
developers to publish application programming interfaces (APIs) that 
allow ``health information from such technology to be accessed, 
exchanged, and used without special effort through the use of APIs 
or successor technology or standards, as provided for under 
applicable law.'' The Cures Act's API Condition of Certification 
requirement also states that a developer must, through an API, 
``provide access to all data elements of a patient's electronic 
health record to the extent permissible under applicable privacy 
laws.'' The API Conditions and Maintenance of Certification 
requirements and certification criteria are identified in 45 CFR 
part 170.
---------------------------------------------------------------------------

    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,\4\ and E.O. 14091 of February 16, 2023, Further 
Advancing Racial Equity and Support for Underserved Communities Through 
the Federal Government.\5\ 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.
---------------------------------------------------------------------------

    \4\ United States, Executive Office of the President [Joseph 
Biden]. Executive Order 13985: Advancing Racial Equity and Support 
for Underserved Communities Through the Federal Government. Jan 20, 
2021. 86 FR 7009-7013, https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government.
    \5\ United States, Executive Office of the President [Joseph 
Biden]. Executive Order 14091: Further Advancing Racial Equity and 
Support for Underserved Communities Through the Federal Government. 
Feb 16, 2023. 88 FR 10825-10833, https://www.federalregister.gov/documents/2023/02/22/2023-03779/further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal.
---------------------------------------------------------------------------

    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'',\6\ 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.
---------------------------------------------------------------------------

    \6\ HealthIT.gov: Embracing Health Equity by Design. https://www.healthit.gov/buzz-blog/health-it/embracing-health-equity-by-design.
---------------------------------------------------------------------------

    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.\7\ 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.''
---------------------------------------------------------------------------

    \7\ United States, Executive Office of the President [Joseph 
Biden]. Executive Order 14110: Safe, Secure, and Trustworthy 
Development and Use of Artificial Intelligence. Oct. 20, 2023. 88 FR 
75191. https://www.federalregister.gov/documents/2023/11/01/2023-24283/safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence.
---------------------------------------------------------------------------

    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.'' \8\ The 
memorandum provides policy guidance to federal agencies and departments 
to promote improved public access to and transparency of federally 
funded

[[Page 1195]]

research. The finalized DSI certification criterion aligns with the 
goals of the memorandum by establishing requirements to make 
information available through Sec.  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.
---------------------------------------------------------------------------

    \8\ Ensuring Free, Immediate, and Equitable Access to Federally 
Funded Research. Office of Science and Technology Policy (OSTP) 
(2022). https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-access-Memo.pdf.
---------------------------------------------------------------------------

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

    \9\ United States, Executive Office of the President [Joseph 
Biden]. Executive Order 14036: Promoting Competition in the American 
Economy. Jul 9, 2021. 86 FR 36987-36999, https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy.
---------------------------------------------------------------------------

    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.\10\ 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,\11\ 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).\12\ 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.
---------------------------------------------------------------------------

    \10\ See, e.g., Martin Gaynor, Farzad Mostashari, and Paul B. 
Ginsberg, Making Health Care Markets Work: Competition Policy for 
Health Care, 16-17 (Apr. 2017), available at http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930; Diego A. Martinez et al., A 
Strategic Gaming Model For Health Information Exchange Markets, 
Health Care Mgmt. Science (Sept. 2016). (``[S]ome healthcare 
provider entities may be interfering with HIE across disparate and 
unaffiliated providers to gain market advantage.'') Niam Yaraghi, A 
Sustainable Business Model for Health Information Exchange 
Platforms: The Solution to Interoperability in Healthcare IT (2015), 
available at http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-exchange-yaraghi; 
Thomas C. Tsai Ashish K. Jha, Hospital Consolidation, Competition, 
and Quality: Is Bigger Necessarily Better? 312 J. AM. MED. ASSOC. 
29, 29 (2014).
    \11\ The information blocking regulations in 45 CFR part 171 
apply to health care providers, health IT developers of certified 
health IT, and health information networks (HIN) and health 
information exchanges (HIE), as each is defined in 45 CFR 171.102. 
Any individual or entity that meets one of these definitions is an 
``actor'' and subject to the information blocking regulation in 45 
CFR part 171.
    \12\ See also Martin Gaynor, Farzad Mostashari, and Paul B. 
Ginsberg, Making Health Care Markets Work: Competition Policy for 
Health Care, 16-17 (Apr. 2017), available at http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930.
---------------------------------------------------------------------------

    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.\13\ 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.
---------------------------------------------------------------------------

    \13\ United States, Executive Office of the President [Joseph 
Biden]. Executive Order 14058: Transforming Federal Customer 
Experience and Service Delivery To Rebuild Trust in Government. Dec 
13, 2021. 86 FR 71357-71366, https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government.
---------------------------------------------------------------------------

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

[[Page 1196]]

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 Sec.  170.213(a) and to add USCDI v3 to Sec.  170.213 (to 
be codified as Sec.  170.213(b)). We have incorporated USCDI v3 by 
reference in Sec.  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 Sec.  170.213(a) will expire on January 1, 2026. As 
codified in Sec.  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[supreg] CDA[supreg] R2 Implementation Guide: C-CDA Templates 
for Clinical Notes STU Companion Guide, Release 4.1--US Realm (C-CDA 
Companion Guide R4.1) in Sec.  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:

<bullet> Sec.  170.207(a)--Problems
<bullet> Sec.  170.207(c)--Laboratory tests
<bullet> Sec.  170.207(d)--Medications
<bullet> Sec.  170.207(e)--Immunizations
<bullet> Sec.  170.207(f)--Race and ethnicity
<bullet> Sec.  170.207(m)--Numerical references
<bullet> Sec.  170.207(n)--Sex
<bullet> Sec.  170.207(o)--Sexual orientation and gender information
<bullet> Sec.  170.207(p)--Social, psychological, and behavioral data
<bullet> Sec.  170.207(r)--Provider type
<bullet> Sec.  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 
Sec.  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 Sec.  
170.207(o) to ``sexual orientation and gender information'' to 
acknowledge that Sec.  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 Sec.  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 Sec.  170.315(f)(5). These 
standards will support the following requirements for Health IT Modules 
certified to Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(a)(9) (88 FR 
23751). The DSI criterion, as finalized, ensures that Health IT Modules 
certified to Sec.  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 Sec.  
170.102, and we have finalized that Health IT Modules certified to 
Sec.  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 Sec.  170.315(b)(11)(iii). Additionally, we have finalized 
that Health IT Modules certified to Sec.  170.315(b)(11) must support 
``source attributes''--categories of technical performance and quality 
information--for both evidence-based

[[Page 1197]]

and Predictive DSIs in Sec.  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 Sec.  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 Sec.  170.315(b)(11)(v)(A). Moreover, we have finalized 
in Sec.  170.315(b)(11)(v)(B) requirements that Health IT Modules 
certified to Sec.  170.315(b)(11) must enable a limited set of 
identified users to record and change source attributes listed in 
paragraphs Sec.  170.315(b)(11)(iv)(A) and (B).
    We have also finalized in Sec.  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 Sec.  
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 Sec.  170.315(b)(11)(v)(A) and (B), 
risk management practices described in Sec.  170.315(b)(11)(vi), and 
summary information provided through Sec.  170.523(f)(1)(xxi). We have 
finalized in Sec.  170.402(b)(4) that developers with products 
certified to Sec.  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 Sec.  170.102,\14\ 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 Sec.  
170.315(a)(9), or being certified to the revised DSI criterion in Sec.  
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 Sec.  
170.315(b)(11) will be included in the Base EHR definition and the 
adoption of the criterion in Sec.  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.
---------------------------------------------------------------------------

    \14\ In section III.C.5.a.i., we discuss finalizing our proposal 
to adopt a definition of ``Base EHR'' and remove the prior 
definition of ``2015 Edition Base EHR.''
---------------------------------------------------------------------------

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 Sec.  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 Sec.  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 Sec.  170.215(c).
    We have also finalized the proposed revisions in Sec.  
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[supreg] FHIR[supreg] US Core 
Implementation Guide (IG) STU version 6.1.0 (FHIR US Core 6.1.0) in 
Sec.  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 Sec.  170.215(c)(2), which replaces the SMART 
Application Launch Framework Implementation Guide Release 1.0.0 (SMART 
v1 Guide) as the standard in Sec.  170.215(a)(3) (finalized in this 
rule as Sec.  170.215(c)(1)). Adoption of this standard impacts the 
certification criterion in Sec.  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 
Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(a)(5), as discussed in section III.C.8.

[[Page 1198]]

    We have finalized the replacement of the specific concepts 
referenced in Sec.  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[supreg]) code set, as 
referenced in the standard in Sec.  170.207(o)(3). We have also 
finalized our proposal that the adoption of the code sets referenced in 
Sec.  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 Sec.  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 
Sec.  170.315(a)(5)(i)(F). The data element definition did not change. 
Additionally, we have finalized new data elements--Name to Use in Sec.  
170.315(a)(5)(i)(G) and Pronouns in Sec.  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 Sec.  
170.315(b)(1)
    We have finalized, as discussed in section III.C.9, the proposed 
updates to the ``transitions of care'' certification criterion (Sec.  
170.315(b)(1)) to align it with our adoption of USCDI v3 in Sec.  
170.213(b). This change ensures that Health IT Modules certified to 
Sec.  170.315(b)(1) are capable of accessing, exchanging, and using 
USCDI data elements referenced in the standards in Sec.  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) \15\ 
Privacy Rule \16\ 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 \17\ (PHI) (see also 45 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 Sec.  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.
---------------------------------------------------------------------------

    \15\ Public Law 104-191,110 Stat. 1936 (August 21, 1996), 
codified at 42 U.S.C. 1320d-1320d8.
    \16\ 45 CFR part 160 and subparts A and E of part 164.
    \17\ 45 CFR 160.103 (definition of ``Protected health 
information'').
---------------------------------------------------------------------------

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 Sec.  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 
Sec.  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 Sec.  170.315 will need to update 
their previously certified Health IT Modules to be compliant with any 
revised certification criterion adopted in Sec.  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 Sec.  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).\18\ 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).
---------------------------------------------------------------------------

    \18\ See 2015 Edition Cures Update Fact Sheet: https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf.
---------------------------------------------------------------------------

    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,

[[Page 1199]]

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 Sec.  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 
Sec.  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 Sec.  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 Sec.  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 (Sec.  171.103) was limited to a subset of EHI that 
was identified by the data elements represented in the USCDI standard 
adopted in Sec.  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 (Sec.  171.103) is EHI as defined in Sec.  
171.102 (88 FR 23754, see also 85 FR 25793, 25876, 70069, and

[[Page 1200]]

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 Sec.  171.103 as discussed in section IV.B.3 
and as shown in updated text we have finalized in Sec.  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 Sec.  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 (Sec.  171.301(a)(1) and (2)), we proposed to revise 
Sec.  171.301 to remove from the regulatory text the existing Sec.  
171.301(a)(1) and (2) as no longer necessary (88 FR 23754). We have 
finalized the revisions to Sec.  171.301 to remove the regulatory text 
in subparagraphs (a)(1) and (2) as no longer necessary and rename Sec.  
171.301 the Manner Exception. We have finalized the redesignation of 
the paragraphs now codified within Sec.  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 Sec.  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 Sec.  171.204(a)(1) to further clarify when an 
actor's practice meets the uncontrollable events condition. Our 
finalized revision to Sec.  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 Sec.  171.204.
    The first new infeasibility condition in Sec.  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.\19\ 
In support of this new condition, we have finalized as proposed a 
definition of ``business associate'' in Sec.  171.102. That definition 
is, by cross-reference to 45 CFR 160.103, the HIPAA Privacy Rule's 
definition of ``business associate.''
---------------------------------------------------------------------------

    \19\ See definition of ``business associate'' at 45 CFR 160.103. 
Business associates include a subcontractor that creates, receives, 
maintains, or transmits protected health information on behalf of 
the business associate.
---------------------------------------------------------------------------

    The second new infeasibility condition in Sec.  171.204(a)(4), 
discussed in Section IV.C.1.c, will apply where an actor has exhausted 
the Manner Exception in Sec.  171.301, including offering at least two 
alternative manners in accordance with Sec.  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 (Sec.  
171.301(b)(1)(i)) or published content and transport standards 
consistent with Sec.  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 Sec.  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 (Sec.  
171.302) and Licensing (Sec.  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 \20\ and 13563 \21\ 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 \22\ 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

[[Page 1201]]

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

    \20\ https://www.archives.gov/files/federal-register/executive-orders/pdf/12866.pdf.
    \21\ https://obamawhitehouse.archives.gov/the-press-office/2011/01/18/executive-order-13563-improving-regulation-and-regulatory-review.
    \22\ https://www.whitehouse.gov/briefing-room/presidential-actions/2023/04/06/executive-order-on-modernizing-regulatory-review/.
---------------------------------------------------------------------------

    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.\23\ 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.
---------------------------------------------------------------------------

    \23\ May 2021 National Occupational Employment and Wage 
Estimates, United States. U.S. Bureau of Labor Statistics. https://www.bls.gov/oes/current/oes_nat.htm.
---------------------------------------------------------------------------

    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

[[Page 1202]]

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

[[Page 1203]]

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

[[Page 1204]]

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

[[Page 1205]]

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

[[Page 1206]]

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

[[Page 1207]]

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 Sec.  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 Sec.  
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 Sec.  170.315 as the ``ONC Certification Criteria for 
Health IT'' and replaced references to the ``2015 Edition'' in 
Sec. Sec.  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:
    <bullet> ``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.
    <bullet> ``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.
    <bullet> ``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).

[[Page 1208]]

    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 Sec.  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 \24\ and resource guides,\25\ 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).
---------------------------------------------------------------------------

    \24\ See 2015 Edition Cures Update Fact Sheet: https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf.
    \25\ See API Resource Guide: https://onc-healthit.github.io/api-resource-guide/.
---------------------------------------------------------------------------

    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 \26\ has a discussion related to 
this policy, and we invite readers to review the discussion at 88 FR 
52547.
---------------------------------------------------------------------------

    \26\ ``Medicare and Medicaid Programs; CY 2024 Payment Policies 
Under the Physician Fee Schedule and Other Changes to Part B Payment 
and Coverage Policies; Medicare Shared Savings Program Requirements; 
Medicare Advantage; Medicare and Medicaid Provider and Supplier 
Enrollment Policies; and Basic Health Program'' (88 FR 52262).
---------------------------------------------------------------------------

    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.

       Table 1--List of Finalized Health IT Certification Criteria
------------------------------------------------------------------------
 
------------------------------------------------------------------------
                     Revised Certification Criteria
------------------------------------------------------------------------
Sec.   170.315(a)(5).................  Clinical--Patient demographics
                                        and observations (currently
                                        Demographics).
Sec.   170.315(a)(9).................  Clinical--Clinical decision
                                        support (CDS) at Sec.
                                        170.315(a)(9) (to be moved to
                                        the ``Care Coordination''
                                        certification criteria as the
                                        ``decision support
                                        intervention'' criterion at Sec.
                                          170.315(b)(11)'').
Sec.   170.315(b)(1).................  Care Coordination--Transitions of
                                        care.
Sec.   170.315(e)(1).................  Patient Engagement--View,
                                        download, and transmit to 3rd
                                        party.
Sec.   170.315(f)(5).................  Public Health--Transmission to
                                        public health agencies--
                                        electronic case reporting.
Sec.   170.315(g)(10)................  Design and Performance--
                                        Standardized API for patient and
                                        population services.
------------------------------------------------------------------------
           Revised Certification Criteria (standards updates)
------------------------------------------------------------------------
Sec.   170.315(a)(12)................  Clinical--Family health history.
Sec.   170.315(b)(2).................  Care Coordination--Clinical
                                        information reconciliation and
                                        incorporation.
Sec.   170.315(b)(6).................  Care Coordination--Data export.
Sec.   170.315(b)(9).................  Care Coordination--Care plan.
Sec.   170.315(c)(4).................  Clinical Quality Measures--
                                        Clinical quality measures--
                                        filter.
Sec.   170.315(f)(1).................  Public Health--Transmission to
                                        immunization registries.
Sec.   170.315(f)(3).................  Public Health--Transmission to
                                        public health agencies--
                                        reportable laboratory tests and
                                        values/results.

[[Page 1209]]

 
Sec.   170.315(f)(4).................  Public Health--Transmission to
                                        cancer registries.
Sec.   170.315(g)(3).................  Design and Performance--Safety-
                                        enhanced design.
Sec.   170.315(g)(6).................  Design and Performance--
                                        Consolidated CDA creation
                                        performance.
Sec.   170.315(g)(9).................  Design and Performance--
                                        Application access--all data
                                        request.
------------------------------------------------------------------------

    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 Sec. Sec.  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 Sec.  170.523 and Sec.  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 Sec. Sec.  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

[[Page 1210]]

the ``Complete EHR'' language from all reference points in Sec. Sec.  
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 Sec. Sec.  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 \27\ 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.
---------------------------------------------------------------------------

    \27\ https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf.
---------------------------------------------------------------------------

    In this final rule, we use voluntary consensus standards except 
for:
    <bullet> The standard adopted in Sec.  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
    <bullet> The standard adopted in Sec.  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 \28\ (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.
---------------------------------------------------------------------------

    \28\ https://www.healthit.gov/isa/united-states-core-data-interoperability-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.\29\ 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

[[Page 1211]]

elements for consideration for inclusion in future versions of 
USCDI.\30\
---------------------------------------------------------------------------

    \29\ https://www.healthit.gov/buzz-blog/interoperability/uscdi-onc-new-data-element-and-class-submission-system-now-available.
    \30\ https://www.healthit.gov/isa/ONDEC.
---------------------------------------------------------------------------

    In the HTI-1 Proposed Rule, we proposed to update the USCDI 
standard in Sec.  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 
Sec.  170.213(b) and incorporate it by reference in Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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.\31\ 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.
---------------------------------------------------------------------------

    \31\ https://www.healthit.gov/sites/default/files/2023-07/2023_SVAP_Fact_Sheet.pdf.
---------------------------------------------------------------------------

    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

[[Page 1212]]

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.\32\ 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.\33\
---------------------------------------------------------------------------

    \32\ https://www.healthit.gov/sites/default/files/page/2023-07/Standards_Bulletin_2023-2.pdf.
    \33\ https://www.healthit.gov/topic/standards-version-advancement-process-svap.
---------------------------------------------------------------------------

    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 Sec.  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[supreg] Implementation Guide: Data 
Segmentation for Privacy (DS4P), Release 1 adopted in Sec.  
170.205(o)(1) and incorporated by reference in Sec.  170.299. In 
addition, we have adopted a new requirement as part of the 
certification criterion in Sec.  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 Sec.  
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 Sec.  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

[[Page 1213]]

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[supreg] FHIR[supreg] 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 \34\ and Inferno \35\ 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.\36\
---------------------------------------------------------------------------

    \34\ https://site.healthit.gov/sandbox-ccda/ccda-validator.
    \35\ https://inferno.healthit.gov/.
    \36\ https://www.healthit.gov/sites/default/files/page/2023-04/LEAP%20FY2023%20SEN_508.pdf.
---------------------------------------------------------------------------

    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 Sec.  170.213 at this time. We have 
adopted USCDI v3 in Sec.  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).\37\
---------------------------------------------------------------------------

    \37\ ``Medicare and Medicaid Programs; Patient Protection and 
Affordable Care Act; Advancing Interoperability and Improving Prior 
Authorization Processes for Medicare Advantage Organizations, 
Medicaid Managed Care Plans, State Medicaid Agencies, Children's 
Health Insurance Program (CHIP) Agencies and CHIP Managed Care 
Entities, Issuers of Qualified Health Plans on the Federally-
Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) 
Eligible Clinicians, and Eligible Hospitals and Critical Access 
Hospitals in the Medicare Promoting Interoperability Program.'' (87 
FR 76238). See https://www.federalregister.gov/documents/2022/12/13/2022-26479/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability.
---------------------------------------------------------------------------

    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.\38\ 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.
---------------------------------------------------------------------------

    \38\ https://www.healthit.gov/topic/certification-ehrs/certification-health-it.
---------------------------------------------------------------------------

    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

[[Page 1214]]

---------------------------------------------------------------------------
data elements in future versions of USCDI, including the following:

<bullet> marital status
<bullet> education
<bullet> water insecurity
<bullet> value-based care
<bullet> prescription drug insurance information
<bullet> advance directive documentation
<bullet> clinical orders
<bullet> care experience preference
<bullet> newborn delivery information
<bullet> vaccine administration date
<bullet> vaccination event record type
<bullet> medical record number
<bullet> mother's maiden name
<bullet> multiple birth indicator
<bullet> 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 Sec.  170.213, in 
certain certification criteria (88 FR 23763). The criteria cross-
referencing to USCDI via cross-reference to Sec.  170.213 are as 
follows:
    <bullet> ``Care coordination--Transitions of care--Create'' (Sec.  
170.315(b)(1)(iii)(A)(1));
    <bullet> ``Care coordination--Clinical information reconciliation 
and incorporation--Reconciliation'' (Sec.  170.315(b)(2)(iii)(D)(1) 
through (3));
    <bullet> ``Patient engagement--View, download, and transmit to 3rd 
party--View'' (Sec.  170.315(e)(1)(i)(A)(1));
    <bullet> ``Design and performance--Consolidated CDA creation 
performance'' (Sec.  170.315(g)(6)(i)(A));
    <bullet> ``Design and performance--Application access--all data 
request--Functional requirements'' (Sec.  170.315(g)(9)(i)(A)(1)); and
    <bullet> ``Design and performance--Standardized API for patient and 
population services--Data response'' (Sec.  170.315(g)(10)(i)(A) and 
(B)).
    We noted in the HTI-1 Proposed Rule that Sec.  170.315(f)(5) also 
currently references Sec.  170.213; however, we proposed to rely on 
specific IGs for that criterion, rather than reference Sec.  170.213 
(88 FR 23763). We proposed that through December 31, 2024, a Health IT 
Module certified to the criteria above that cross-reference Sec.  
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 Sec.  
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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  170.215(b)(1)(ii) and the HL7 CDA[supreg] R2 IG: C-CDA 
Templates for Clinical Notes R2.1 Companion Guide, Release 3 in Sec.  
170.205(a)(6). We noted in the HTI-1 Proposed Rule that if the FHIR US 
Core Implementation Guide and the HL7 CDA[supreg] 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: Sec.  
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 Sec.  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

[[Page 1215]]

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 Sec.  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 Sec.  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 Sec.  170.213 and be incorporated by reference in Sec.  
170.299 as part of our proposal to adopt USCDI v3.
i. Social Determinants of Health (SDOH)
    SDOH \39\ 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.\40\ 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.
---------------------------------------------------------------------------

    \39\ See SDOH Toolkit for more information, https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf.
    \40\ https://www.healthit.gov/topic/health-it-health-care-settings/social-determinants-health.
---------------------------------------------------------------------------

    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

[[Page 1216]]

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.\41\ 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.
---------------------------------------------------------------------------

    \41\ http://hl7.org/fhir/us/sdoh-clinicalcare/STU2/.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  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 Sec.  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 
Sec.  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,\42\ regarding the access, exchange, and use of information 
about patients and the use of certified health IT.
---------------------------------------------------------------------------

    \42\ See e.g., https://www.healthit.gov/topic/patient-access-health-records/patient-access-health-records.
---------------------------------------------------------------------------

    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.\43\ In 2021, we funded a Leading 
Edge Acceleration Project for Referral Management to Address SDOH 
Aligned with Clinical Care.
---------------------------------------------------------------------------

    \43\ https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf.
---------------------------------------------------------------------------

    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

[[Page 1217]]

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 (Sec.  
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[supreg]) 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[supreg] 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

[[Page 1218]]

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 Sec.  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[supreg] 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 Sec.  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 Sec.  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 Sec.  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

[[Page 1219]]

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

[[Page 1220]]

become effective for Program use after a 60-day period.\44\
---------------------------------------------------------------------------

    \44\ https://www.healthit.gov/sites/default/files/2023-07/2023_SVAP_Fact_Sheet.pdf.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(a)(5)(i)(D) 
and for Gender Identity in the demographics criterion in Sec.  
170.315(a)(5)(i)(E) that included requirements to code Sexual 
Orientation and Gender Identity according to the adopted SNOMED 
CT[supreg] U.S. Edition codes and HL7 Version 3 Standard, Value Sets 
for AdministrativeGender and NullFlavor, as referenced Sec.  
170.207(o)(1) and Sec.  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 Sec.  170.213 would be required 
to be capable of representing Sexual Orientation and Gender Identity in 
SNOMED CT[supreg] 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[supreg] 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 Sec.  170.315(a)(5)(i)(C) and 
Sec.  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 Sec.  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 Sec.  170.207(n)(1) until 
December 31, 2025, or in accordance with the standard in proposed Sec.  
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 Sec.  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

[[Page 1221]]

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 Sec.  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@),\45\ 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.
---------------------------------------------------------------------------

    \45\ https://oncprojectracking.healthit.gov/wiki/pages/viewpage.action?pageId=180486153.
---------------------------------------------------------------------------

    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

[[Page 1222]]

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

[[Page 1223]]

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 Sec.  170.215(b)(1) and incorporated by 
reference in Sec.  170.299 and the HL7 C-CDA R2.1 base standard adopted 
in Sec.  170.205(a)(4) and incorporated by reference in Sec.  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 Sec.  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[supreg] CDA[supreg] R2 Implementation 
Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 
3--US Realm in Sec.  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 Sec.  170.205(a)(6), 
since we proposed to adopt USCDI v3 as the baseline (88 FR 23767).
    As mentioned above, HL7[supreg] 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 Sec.  170.205(a)(6) and incorporate 
it by reference in Sec.  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 Sec.  
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 Sec.  170.205(a)(5) to add that the adoption of the 
standard in Sec.  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 Sec.  170.205(a)(5) would have to 
update those Health IT Modules to Sec.  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[supreg] 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[supreg] R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion 
Guide, Release 3 in Sec.  170.205(a)(6) by January 1, 2025:
    <bullet> ``transitions of care'' (Sec.  170.315(b)(1)(iii)(A));
    <bullet> ``clinical information reconciliation and incorporation'' 
(Sec.  170.315(b)(2)(i), (ii), and (iv));
    <bullet> ``care plan'' (Sec.  170.315(b)(9)(ii));
    <bullet> ``view, download, and transmit to 3rd party'' (Sec.  
170.315(e)(1)(i)(A) and (B));
    <bullet> ``consolidated CDA creation performance'' (Sec.  
170.315(g)(6)(i)); and
    <bullet> ``application access--all data request'' (Sec.  
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[supreg] R2 IG: C-CDA Templates for Clinical Notes R2.1 
Companion Guide, Release 3 as proposed in Sec.  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

[[Page 1224]]

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 Sec.  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 Sec.  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 Sec.  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).
    <bullet> Sec.  170.207(a)--Problems
    We proposed to remove and reserve Sec.  170.207(a)(3), IHTSDO 
SNOMED CT[supreg] International Release July 2012 and US Extension to 
SNOMED CT[supreg] March 2012 Release. We proposed to revise Sec.  
170.207(a)(1), which is currently reserved, to reference SNOMED CT US 
Edition March 2022 and incorporate it by reference in Sec.  170.299.
    <bullet> Sec.  170.207(c)--Laboratory tests
    We proposed to remove and reserve Sec.  170.207(c)(2), Logical 
Observation Identifiers Names and Codes (LOINC[supreg]) Database 
version 2.40. We proposed to revise Sec.  170.207(c)(1), which is 
currently reserved, to reference LOINC Database version 2.72, February 
16, 2022, and incorporate it by reference in Sec.  170.299.
    <bullet> Sec.  170.207(d)--Medications
    We proposed to revise Sec.  170.207(d)(1), which is currently 
reserved, to reference RxNorm July 5, 2022, Full Monthly Release and 
incorporate it by reference in Sec.  170.299. We proposed in Sec.  
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 Sec.  170.207(d).
    <bullet> Sec.  170.207(e)--Immunizations
    We proposed to revise Sec.  170.207(e)(1), which is currently 
reserved, to reference CVX--VaccinesAdministered, updates through June 
15, 2022, and incorporate it by reference in Sec.  170.299. We also 
proposed to revise Sec.  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 Sec.  
170.299.
    <bullet> Sec.  170.207(f)--Race and ethnicity
    We proposed to add Sec.  170.207(f)(3) to reference CDC Race and 
Ethnicity Code Set Version 1.2 (July 15, 2021) and incorporate it by 
reference in Sec.  170.299.
    <bullet> Sec.  170.207(m)--Numerical references
    We proposed to revise Sec.  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 Sec.  
170.299.
    <bullet> Sec.  170.207(n)--Sex
    We proposed to revise Sec.  170.207(n)(2), which is currently 
reserved, to reference the version of SNOMED CT [supreg] U.S. Edition 
codes specified in Sec.  170.207(a)(1). We also proposed to add Sec.  
170.207(n)(3) to reference the version of LOINC [supreg] codes 
specified in Sec.  170.207(c)(1).
    <bullet> Sec.  170.207(o)--Sexual orientation and gender 
information
    We proposed to change the heading of Sec.  170.207(o) from ``sexual 
orientation and gender identity'' to ``sexual orientation and gender 
information'' to acknowledge that Sec.  170.207(o) includes

[[Page 1225]]

standard code sets to support other gender related data items. We 
proposed to add Sec.  170.207(o)(3) to reference the version of SNOMED 
CT [supreg] U.S. Edition codes specified in Sec.  170.207(a)(1) and to 
add Sec.  170.207(o)(4) to reference the version of LOINC [supreg] 
codes specified in Sec.  170.207(c)(1) for Pronouns.
    <bullet> Sec.  170.207(p)--Social, psychological, and behavioral 
data
    We proposed to revise Sec.  170.207(p)(1) through (8) to reference 
the version of LOINC[supreg] codes specified in proposed Sec.  
170.207(c)(1) instead of Sec.  170.207(c)(3). We proposed to revise 
Sec.  170.207(p)(4), (5) and (7) and (8) to reference the version of 
the Unified Code of Units of Measure in proposed Sec.  170.207(m)(2), 
instead of Sec.  170.207(m)(1). We also proposed to revise Sec.  
170.207(p)(6) to include a reference to the version of the Unified Code 
of Units of Measure in proposed Sec.  170.207(m)(2).
    <bullet> Sec.  170.207(r)--Provider type
    We proposed to revise Sec.  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 Sec.  
170.299.
    <bullet> Sec.  170.207(s)--Patient insurance
    We proposed to revise Sec.  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 Sec.  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 Sec.  170.207(a) Problems by 
replacing the reference to Sec.  170.207(a)(4) in those criteria that 
reference it with a reference to the new proposed Sec.  170.207(a)(1). 
These criteria include Sec.  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 Sec.  170.315(f)(3)(ii) by replacing the reference to Sec.  
170.207(a)(3) with a reference to the new proposed Sec.  170.207(a)(1).
    We proposed to update the certification criteria that reference 
Sec.  170.207(c) Laboratory Tests by replacing the references to Sec.  
170.207(c)(2) and (c)(3) in those criteria with a reference to the new 
proposed Sec.  170.207(c)(1). These criteria include Sec.  
170.315(f)(3)(ii) and (f)(4)(ii).
    We proposed to update two certification criteria that reference 
Sec.  170.207(e) Immunizations. We proposed to update the certification 
criterion Sec.  170.315(f)(1)(i)(B), which references Sec.  
170.207(e)(3), to instead reference the new proposed Sec.  
170.207(e)(1). We also proposed to update the certification criterion 
Sec.  170.315(f)(1)(i)(C), which references Sec.  170.207(e)(4), by 
replacing the reference to Sec.  170.207(e)(4) in that criterion with a 
reference to the new proposed Sec.  170.207(e)(2).
    We proposed to update several certification criteria that reference 
Sec.  170.207(f) Race and Ethnicity. We proposed to update 
certification criteria that reference Sec.  170.207(f)(2) to instead 
reference the new proposed Sec.  170.207(f)(3). These criteria include 
Sec.  170.315(a)(5)(i)(A)(1) and (2) and Sec.  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 Sec.  170.207(n) Sex by 
updating criteria that reference Sec.  170.207(n)(1) to reference the 
new proposed Sec.  170.207(n)(2). More specifically, we proposed to 
update Sec.  170.315(a)(5)(i)(C) to reference Sec.  170.207(n)(1) for 
the time period up to and including December 31, 2025, or to reference 
Sec.  170.207(n)(2). We also proposed to update Sec.  
170.315(c)(4)(iii)(G) and Sec.  170.315(b)(1)(iii)(G)(3) to reference 
Sec.  170.207(n)(2). We note that, in the HTI-1 Proposed Rule 
regulation text in Sec.  170.315(b)(1)(iii)(G)(3), we inadvertently 
included a reference to Sec.  170.213 (88 FR 23909) instead of 
including Sec.  170.207(n)(2) as discussed in our proposal (88 FR 
23821). ONC has finalized Sec.  170.315(b)(1)(iii)(G)(3) without the 
proposed reference to Sec.  170.213. We have finalized Sec.  
170.315(b)(1)(iii)(G)(3) to include a reference to Sec.  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 Sec.  
170.207(o) Sexual orientation and gender information (as we proposed to 
rename the criterion) by updating criteria that reference Sec.  
170.207(o)(1) and (2). We proposed to replace the reference to Sec.  
170.207(o)(1) in Sec.  170.315(a)(5)(i)(D) with a reference to the new 
proposed Sec.  170.207(o)(3) and proposed to replace the reference to 
Sec.  170.207(o)(2) in Sec.  170.315(a)(5)(i)(E) with a reference to 
the new proposed Sec.  170.207(o)(3). More specifically, we proposed to 
update Sec.  170.315(a)(5)(i)(D) to reference Sec.  170.207(o)(1) for 
the time period up to and including December 31, 2025, or to reference 
Sec.  170.207(o)(3), as well as whether a patient declines to specify 
sexual orientation. We proposed to update Sec.  170.315(a)(5)(i)(E) to 
reference Sec.  170.207(o)(2) for the time period up to and including 
December 31, 2025, or to reference Sec.  170.207(o)(3), as well as 
whether a patient declines to specify gender identity.
    We also proposed to update Sec.  170.315(c)(4)(iii)(C), which 
references Sec.  170.207(r) Provider Type. Specifically, we proposed to 
replace the reference to Sec.  170.207(r)(1) in that criterion with a 
reference to the new proposed Sec.  170.207(r)(2). We also proposed to 
update Sec.  170.315(c)(4)(iii)(E), which references Sec.  170.207(s) 
Patient insurance. Specifically, we proposed to replace the reference 
to Sec.  170.207(s)(1) in that criterion with a reference to the new 
proposed Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(a)(5) to ``patient demographics 
and observations'' to acknowledge that not all data described in that 
section are understood to be demographics.

[[Page 1226]]

    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 Sec.  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 Sec.  
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 Sec.  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.\46\ These standards pertain to 
both HL7[supreg] FHIR and HL7[supreg] CDA and include multiple 
Implementation Guides (IGs).
---------------------------------------------------------------------------

    \46\ See work group membership at: https://confluence.hl7.org/display/PHWG/Public+Health+Work+Group.
---------------------------------------------------------------------------

    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 Sec.  
170.315(f)(5)(ii). This included a proposal in Sec.  
170.315(f)(5)(ii)(A) that a Health IT Module certified to Sec.  
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 Sec.  170.205(t)(4) received from 
the eRSD profiles as specified in the HL7 FHIR eCR IG in Sec.  
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 Sec.  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[supreg] standards: 
in accordance with the electronic initial case report (eICR) profiles 
specified in the HL7 FHIR eCR IG in Sec.  170.205(t)(1) or in 
accordance with the HL7 CDA eICR IG in Sec.  170.205(t)(2). Finally, we 
proposed in Sec.  170.315(f)(5)(ii)(C) to require that Health IT 
Modules certified to Sec.  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

[[Page 1227]]

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 Sec.  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 Sec.  170.205(t)(1) or the HL7 CDA eICR IG 
Sec.  170.205(t)(2). Additionally, we have finalized in Sec.  
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 Sec.  170.205(t)(1) or the 
HL7 CDA RR IG in Sec.  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 Sec.  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[supreg] 
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 Sec.  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 Sec.  
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 Sec.  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

[[Page 1228]]

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 Sec.  170.315(f)(5)(ii)(A) our proposal that Health IT 
Modules certified to Sec.  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 Sec.  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 Sec.  
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 Sec.  
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 Sec.  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 
Sec.  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 Sec.  170.205(t)(4) is a 
minimum standard code set, and that Health IT Modules certifying to 
Sec.  170.315(f)(5) by way of Sec.  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 Sec.  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.\47\ 
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.
---------------------------------------------------------------------------

    \47\ Electronic Reporting and Surveillance Distribution page 
managed by the Association of Public Health Laboratories: https://ersd.aimsplatform.org/#/home.
---------------------------------------------------------------------------

    Finally, we note that the CDA IG cross-references the RCTC value 
set specified in the HL7 FHIR eCR IG.\48\ Therefore, Health IT Modules 
certified to Sec.  170.315(f)(5) using the HL7 CDA IG as described in 
Sec.  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 Sec.  
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.
---------------------------------------------------------------------------

    \48\ See section 1.11.2 of the CDA eICR IG titled, ``Using the 
eRSD (from the FHIR eCR IG).'' https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436.
---------------------------------------------------------------------------

    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 
Sec.  170.315(f)(5) that Health IT Modules must enable a user to create 
a case report for electronic transmission meeting requirements in Sec.  
170.315(f)(5)(i) for the time period up to and including December 31, 
2025, or meet the requirements in Sec.  170.315(f)(5)(ii). This 
approach will allow developers to continue to certify to functional 
requirements for case reporting according to Sec.  170.315(f)(5)(i) 
while allowing developers to certify to the standards-based approach to 
case reporting in Sec.  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 Sec.  170.315(f)(5)(ii). In 
addition, previously certified products will need to update their 
certification to the standards-based approach described in Sec.  
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 Sec.  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 Sec.  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

[[Page 1229]]

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.\49\ We believe the timeline for requiring 
standards-based electronic case reporting for Health IT Modules 
certified to Sec.  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.
---------------------------------------------------------------------------

    \49\ https://www.cdc.gov/ophdst/public-health-data-strategy/Public_Health_Data_Strategy-final-P.pdf.
---------------------------------------------------------------------------

    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 Sec.  170.315(g)(10) has provided a baseline 
for reusable services to advance interoperability nationwide.

[[Page 1230]]

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.\50\ Notably, the US 
Core IG is part of the certification criterion at Sec.  170.315(g)(10), 
adopted in Sec.  170.215(b)(1) and incorporated by reference in Sec.  
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.
---------------------------------------------------------------------------

    \50\ https://hl7.org/fhir/R4/profiling.html#reslicing.
---------------------------------------------------------------------------

    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 Sec.  
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 Sec.  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).\51\ 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 Sec.  170.315(f)(5) to 
specifically connect to AIMS or support RCKMS \52\ to meet the proposed 
requirements in Sec.  170.315(f)(5)(ii)(D). While we

[[Page 1231]]

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 Sec.  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 Sec.  
170.315(f)(5)(ii)(D) to ``transmit a case report electronically to a 
system capable of receiving an electronic case report,'' as proposed.
---------------------------------------------------------------------------

    \51\ https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf.
    \52\ https://www.rckms.org/.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  
170.405(b)(1)(iii). We decline to establish specific requirements for 
real world testing plans beyond what is established in Sec.  
170.405(b)(1)(iii) for electronic case reporting currently. We also 
note that our requirement for Health IT Modules certifying to Sec.  
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 Sec.  170.315(f)(5) with modifications. First, we have 
finalized a modification of the proposed description in Sec.  
170.315(f)(5) from ``an electronic case report'' to ``a case report for 
electronic transmission'' consistent with the prior functional 
criterion in Sec.  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 Sec.  
170.315(f)(5)(i) Functional electronic case reporting. For the 
standards-based version of the criterion in Sec.  170.315(f)(5) and 
specified in Sec.  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 
Sec.  170.205(t)(4) without including the reference to the HL7 FHIR eCR 
IG in Sec.  170.315(f)(5)(ii)(A). We have finalized a modification to 
the proposed regulation text as described above to reference only the 
HL7[supreg] CDA[supreg] eICR IG in Sec.  170.315(f)(5)(ii)(B)(2). We 
have finalized a modification to the proposed regulation text for the 
capabilities described in Sec.  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 Sec.  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) \53\ 
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 Sec.  170.315(a)(9) (80 FR 
62622).
---------------------------------------------------------------------------

    \53\ Health Informational Technology Policy Committee (HITPC) 
Transmittal Letter to the National Coordinator. June 2011. https://www.healthit.gov/sites/default/files/facas/hitpc-stage-2-mu-recommendations.pdf#page=4.
---------------------------------------------------------------------------

    Since the CDS criterion was first adopted in Sec.  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.\54\ 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.\55\ Both

[[Page 1232]]

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.<SUP>56 57</SUP> 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.<SUP>58 59</SUP>
---------------------------------------------------------------------------

    \54\ See, e.g., American Hospital Association. ``Surveying the 
AI Health Care Landscape'' 2019. https://www.aha.org/system/files/media/file/2019/10/Market_Insights_AI-Landscape.pdf; Darshali A 
Vyas, et al., Hidden in plain sight--reconsidering the use of race 
correction in clinical algorithms Sec.  383 (Mass Medical Soc 2020); 
Fact Versus Fiction: Clinical Decision Support Tools and the 
(Mis)use of Race. (2021); Goldhill, Olivia. Artificial intelligence 
can now predict suicide with remarkable accuracy, Quartz, (July 
2022), https://qz.com/1001968/artificial-intelligence-can-now-predict-suicide-with-remarkable-accuracy/ (discussing the use of ML 
algorithms to predict and prevent suicide).
    \55\ See, e.g., Burdick, Hoyt, et al. ``Effect of a sepsis 
prediction algorithm on patient mortality, length of stay and 
readmission: a prospective multicentre clinical outcomes evaluation 
of real-world patient data from US hospitals.'' BMJ health & care 
informatics 27.1 (2020).
    \56\ Landi, H. Epic taps Microsoft to accelerate generative AI-
powered `copilot' tools to help clinicians save time. Fierce 
Healthcare. August 22, 2023 https://www.fiercehealthcare.com/ai-and-machine-learning/epic-expands-ai-partnership-microsoft-rolls-out-copilot-tools-help.
    \57\ See 88 FR 23860 where we discuss that a production 
environment is 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).
    \58\ Fox, A. NextGen introduces AI-enabled ambient listening 
that syncs with EHR. Healthcare IT News. October 11, 2023. https://www.healthcareitnews.com/news/nextgen-introduces-ai-enabled-ambient-listening-syncs-ehr.
    \59\ Miliard, M. Oracle Cerner adds generative AI to its EHR 
platforms. September 19, 2023. https://www.healthcareitnews.com/news/oracle-cerner-adds-generative-ai-its-ehr-platforms.
---------------------------------------------------------------------------

    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.'' \60\ 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.'' \61\
---------------------------------------------------------------------------

    \60\ Michael Matheny, et al., Artificial intelligence in health 
care: the hope, the hype, the promise, the peril, Washington, DC: 
National Academy of Medicine (2019).
    \61\ Id.
---------------------------------------------------------------------------

    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.'' \62\ This was 
followed by an executive order in December 2020, E.O. 13960 Promoting 
the Use of Trustworthy Artificial Intelligence in the Federal 
Government.\63\ 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).
---------------------------------------------------------------------------

    \62\ OMB--EOP--Memorandum for the Heads of Executive Departments 
and Agencies on Guidance for Regulation of Artificial Intelligence 
M-21-06, p. 6 (Nov. 17, 2020).
    \63\ E.O. No. 13960, 85 FR 78939: https://www.federalregister.gov/documents/2020/12/08/2020-27065/promoting-the-use-of-trustworthy-artificial-intelligence-in-the-federal-government.
---------------------------------------------------------------------------

    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.\64\
---------------------------------------------------------------------------

    \64\ GAO, Artificial Intelligence: An Accountability Framework 
for Federal Agencies and Other Entities: (June 2021), https://www.gao.gov/assets/gao-21-519sp.pdf. See generally Artificial 
Intelligence in Health Care: Benefits and Challenges of Technologies 
to Augment Patient Care, (Nov. 2020), https://www.gao.gov/products/gao-21-7sp.
---------------------------------------------------------------------------

    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.\65\ 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.\66\
---------------------------------------------------------------------------

    \65\ See White House, Principles for Enhancing Competition and 
Tech Platform Accountability, Sept. 8, 2022, https://www.whitehouse.gov/briefing-room/statements-releases/2022/09/08/readout-of-white-house-listening-session-on-tech-platform-accountability/.
    \66\ See White House, Blueprint for an AI Bill of Rights 
(October 4, 2022), https://www.whitehouse.gov/ostp/ai-bill-of-rights/.
---------------------------------------------------------------------------

    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).\67\ E.O. 14091 builds upon previous 
equity-related executive orders, including E.O. 13985.\68\ 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.''
---------------------------------------------------------------------------

    \67\ E.O. 14091, 88 FR 10825-10833: https://www.federalregister.gov/documents/2023/02/22/2023-03779/further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal. See https://www.whitehouse.gov/briefing-room/statements-releases/2023/10/30/fact-sheet-president-biden-issues-executive-order-on-safe-secure-and-trustworthy-artificial-intelligence/.
    \68\ E.O. 13985, 88 FR 7009: https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government.
---------------------------------------------------------------------------

    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.\69\ 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

[[Page 1233]]

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

    \69\ E.O. 14110. 88 FR 75191: https://www.federalregister.gov/documents/2023/11/01/2023-24283/safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence.
    \70\ In addition to the E.O., on November 1, the Office of 
Management and Budget (OMB) released draft guidance for federal 
agencies, ``Advancing Governance, Innovation, and Risk Management 
for Agency Use of Artificial Intelligence'' available at: https://ai.gov/wp-content/uploads/2023/11/AI-in-Government-Memo-Public-Comment.pdf.
---------------------------------------------------------------------------

    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.\71\ 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.\72\ 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 Sec.  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.\73\
---------------------------------------------------------------------------

    \71\ We discuss additional federal and HHS activities--including 
activities resulting from the executive orders--in the subsection 
below entitled ``Relationship to Other Federal Agencies' Relevant 
Activities, Interests, and Regulatory Authority.''
    \72\ See e.g., U.S. Dep't. of Health, Education, & Welfare 
(HEW), Secretary's Advisory Committee on Automated Personal Data 
Systems, Records, Computers, and the Rights of citizens viii (1973) 
https://aspe.hhs.gov/report/records-computers-and-rights-citizens 
https://aspe.hhs.gov/report/records-computers-and-rights-citizens 
(The origination of the code of fair information practices, more 
commonly known as the fair information practice principles (FIPPs)).
    \73\ HHS, Statements on New Plan to Advance Equity in the 
Delivery of Health and Human Services, April 14, 2022, https://www.hhs.gov/about/news/2022/04/14/hhs-statements-on-new-plan-advance-equity-delivery-health-human-services.html.
---------------------------------------------------------------------------

    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 \74\ discussed 
in the HTI-1 Proposed Rule (88 FR 23780).
---------------------------------------------------------------------------

    \74\ Michael Matheny, et al., Artificial intelligence in health 
care: the hope, the hype, the promise, the peril, Washington, DC: 
National Academy of Medicine (2019).
---------------------------------------------------------------------------

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 Sec.  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 Sec.  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 Sec.  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,\75\ model nutrition 
labels,\76\ datasheets,\77\ data cards,\78\ or algorithmic audits.\79\ 
However, we also

[[Page 1234]]

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.\80\ 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.
---------------------------------------------------------------------------

    \75\ Mitchell, Margaret, et al. ``Model cards for model 
reporting.'' Proceedings of the conference on fairness, 
accountability, and transparency. 2019.
    \76\ Sendak MP, Gao M, Brajer N, Balu S. Presenting machine 
learning model information to clinical end users with model facts 
labels. NPJ Digit Med. 2020 Mar 23;3:41. Doi: 10.1038/s41746-020-
0253-3.
    \77\ Gebru, Morgenstern, Vecchione, et al, Datasheets for 
Datasets, https://arxiv.org/abs/1803.09010.
    \78\ FaccT `22: 2022 ACM Conference on Fairness, Accountability, 
and Transparency (June 2022) Pages 1776-1826, https://dl.acm.org/doi/proceedings/10.1145/3531146.
    \79\ See lag Guszcza, et al., Why We Need to Audit Algorithms. 
Harvard Business Review. Nov. 28, 2018. https://hbr.org/2018/11/why-we-need-to-audit-algorithms; Xiaoxuan Liu, et al., The medical 
algorithmic audit, The Lancet Digital Health (2022). See generally 
Outsider Oversight: Designing a Third-Party Audit Ecosystem for AI 
Governance, ID Raji, P Xu, C Honigsberg, D Ho--Proceedings of the 
2022 AAAI/ACM Conference on AI, 2022, https://dl.acm.org/doi/pdf/10.1145/3514094.3534181.
    \80\ Public availability and transparency aims align with the 
OSTP Memorandum to federal departments and agencies (August 2022): 
``Ensuring Free, Immediate, and Equitable Access to Federally Funded 
Research'' https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-access-Memo.pdf.
---------------------------------------------------------------------------

    We noted at 88 FR 23780-23781 that the proposed requirements for 
the certification criterion in Sec.  170.315(b)(11) also supported 
health equity by design,\81\ for example, (1) emphasizing transparency 
regarding the use of specific data elements relevant to health equity 
\82\ 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.
---------------------------------------------------------------------------

    \81\ See ``Embracing Health Equity by Design'' ONC, February 
2022: https://www.healthit.gov/buzz-blog/health-it/embracing-health-equity-by-design.
    \82\ See HHS's Strategic Approach to Addressing Social 
Determinants of Health to Advance Health Equity--At a Glance (April 
2022), https://aspe.hhs.gov/sites/default/files/documents/aabf48cbd391be21e5186eeae728ccd7/SDOH-Action-Plan-At-a-Glance.pdf.
---------------------------------------------------------------------------

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

[[Page 1235]]

    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 Sec.  
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.\83\ 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.\84\ We clarify that nothing from our proposals nor our 
finalized criterion would require a user of a Health IT Module 
certified to Sec.  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.\85\
---------------------------------------------------------------------------

    \83\ See Sec.  170.315(b)(11)(iv)(B)(v)(5)-(9).
    \84\ See Sec.  170.315(b)(11)(iv)(A)(5)-(13).
    \85\ See U.S. Dept of Health & Human Servs., Office for Civil 
Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health 
Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities (prohibiting 
discrimination on the basis of race, color, national origin 
(including limited English proficiency), sex (including sexual 
orientation and gender identity), age, or disability in certain 
health programs or activities through the use of clinical algorithms 
in their decision-making); Title VI of the Civil Rights Act of 1964, 
42 U.S.C. 2000d et seq. (prohibiting discrimination on the basis of 
race, color, or national origin (including limited English 
proficiency) in federally funded programs or activities); Title IX 
of the Education Amendments of 1972, 20 U.S.C. 1681 et seq. 
(prohibiting sex discrimination in federally funded education 
programs or activities); the Age Discrimination Act of 1975, 42 
U.S.C. 6101 et seq. (prohibiting age discrimination in federally 
funded programs or activities); Section 504 of the Rehabilitation 
Act of 1973, 29 U.S.C. 794 (prohibiting disability discrimination in 
federally funded or federally conducted programs or activities); and 
the Americans with Disabilities Act, 42 U.S.C. 12101 et seq. 
(prohibiting disability discrimination by employers, state and local 
government entities, and businesses that are open to the public, 
among others).
---------------------------------------------------------------------------

    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).\86\ 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 Sec.  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

[[Page 1236]]

decision-making based on outputs (e.g., recommendations) from 
Predictive DSIs, including:
---------------------------------------------------------------------------

    \86\ ONC finalized in Sec.  170.304(e) the ``clinical decision 
support'' certification criteria in the interim final rule, ``Health 
Information Technology: Initial Set of Standards, Implementation 
Specifications, and Certification Criteria for Electronic Health 
Record Technology,'' January 13, 2010 (75 FR 2014).
---------------------------------------------------------------------------

    <bullet> An expanded set of ``source attributes'' in Sec.  
170.315(b)(11)(iv);
    <bullet> 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 Sec.  
170.315(b)(11)(v);
    <bullet> 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 Sec.  170.315(b)(11)(vi); and
    <bullet> Requirements for summary information related to how 
intervention risk is managed to be publicly accessible in Sec.  
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 Sec. Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(b)(11) review and update 
as necessary, source attribute information in Sec.  
170.315(b)(11)(v)(A) and (B), risk management practices described in 
Sec.  170.315(b)(11)(vi), and summary information provided through 
Sec.  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 Sec.  
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 
Sec.  170.523(f)(1)(xxi). We have finalized that developers with Health 
IT Modules certified to Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  
170.315(b)(11)(vi) and did not adopt the requirement for detailed 
documentation we proposed in Sec.  170.315(b)(11)(vi)(B). The finalized 
Sec.  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 Sec.  170.315(b)(11)(vii)(A) in the HTI-1 Proposed Rule (88 FR 
23798).
    We have also finalized in Sec.  170.102, as proposed, the date for 
which the requirements of Sec.  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 Sec.  170.102 that would 
allow a Health IT Module to meet said definition if it has been 
certified to Sec.  170.315(a)(9) or (b)(11) for the period up to and 
including December 31, 2024, and Sec.  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 
Sec.  170.315(b)(11) must apply IRM practices for each Predictive DSI 
supplied by the health IT developer as described in Sec.  
170.315(b)(11)(vi) and submit summary information of their IRM 
practices to its ONC-ACB via publicly accessible hyperlink according to 
Sec.  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 Sec.  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 Sec.  
170.315(b)(11) as a ``revised certification criterion'' according to 
the

[[Page 1237]]

proposed definition in Sec.  170.102. The proposed criterion in Sec.  
170.315(b)(11) was a revised version of 45 CFR 170.315(a)(9), 
``clinical decision support (CDS).'' In Sec.  170.315(b)(11), we 
proposed to adopt a substantially similar structure as is currently in 
Sec.  170.315(a)(9). In the revised certification criterion at Sec.  
170.315(b)(11), we proposed to modify the existing requirements in 
Sec.  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 Sec.  
170.315(a)(9)(i) through (iv) would be included as Sec.  
170.315(b)(11)(i) through (iv) with modifications. We proposed to 
introduce a new intervention type in Sec.  170.315(b)(11), Predictive 
DSIs, with a corresponding definition in Sec.  170.102 for the term.
    At 88 FR 23782, we discussed our rationale for these proposals and 
stated our view that proposed Sec.  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 Sec.  
170.315(b).
    At 88 FR 23783, we proposed modifications to the Base EHR 
definition in Sec.  170.102 to identify the dates when Sec.  
170.315(b)(11) would replace Sec.  170.315(a)(9) in the Base EHR 
definition. In keeping with the proposal to modify the Base EHR 
definition in Sec.  170.102, we proposed that the adoption of Sec.  
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 Sec.  170.315(a)(9) would 
need to certify those Health IT Modules to Sec.  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 Sec.  170.315(b), we noted that developers of certified 
health IT with Health IT Module(s) certified to Sec.  170.315(b)(11) 
would be required to submit real world testing plans and corresponding 
real world testing results, consistent with Sec.  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 Sec.  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 Sec.  170.315(a)(9) 
as the DSI criterion in Sec.  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 Sec.  170.315(a)(9) is 
suitable to be implemented in a revised version in Sec.  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 Sec.  170.315(b)(11) are 
substantially similar to what already exists in Sec.  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 Sec.  
170.315(b)(11) as a ``revised certification criterion'' according to 
the proposed definition in Sec.  170.102 and as part of the ``care 
coordination certification criteria,'' in Sec.  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 
Sec.  170.315(b)(11) as part of the Base EHR definition in Sec.  
170.102, and that beginning January 1, 2025, the certification 
criterion at Sec.  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 Sec.  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 
Sec.  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 Sec.  170.315(b)(11).
    Finally, as we noted in the HTI-1 Proposed Rule (88 FR 23783), as a 
consequence of adopting this revised

[[Page 1238]]

criterion in Sec.  170.315(b), developers of certified health IT with 
Health IT Module(s) certified to Sec.  170.315(b)(11) are required to 
submit real world testing plans and corresponding real world testing 
results, consistent with Sec.  170.405, demonstrating the real world 
use of each type of DSI in Sec.  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 Sec.  170.315(b), developers of certified health IT with 
Health IT Module(s) certified to Sec.  170.315(b)(11) are required to 
submit real world testing plans and corresponding real world testing 
results, consistent with Sec.  170.405, demonstrating the real-world 
use of each type of DSI in Sec.  170.315(b)(11), including evidence-
based DSIs and Predictive DSIs.
ii. Decision Support Configuration
    At 88 FR 23783, we proposed in Sec.  170.315(b)(11)(ii) to 
establish ``decision support configuration'' requirements based on what 
is currently in Sec.  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 Sec.  170.315(b)(11)(ii)(B)(1)(i) through 
(iii) and (v) through (viii) be expressed according to the standards 
expressed in Sec.  170.213, including the proposed USCDI v3. We 
proposed to reference the USCDI in Sec.  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 Sec.  170.315(b)(11) must be capable of supporting DSIs that use 
those data elements listed in Sec.  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 Sec.  
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 Sec.  170.315(b)(11) the existing 
reference in Sec.  170.315(a)(9)(ii)(B)(1)(iv) to demographic data in 
Sec.  170.315(a)(5)(i).
    Additionally, at 88 FR 23783 we proposed to include two USCDI data 
classes not currently found in Sec.  170.315(a)(9)(ii)(B)(1). In Sec.  
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 
Sec.  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 Sec.  
170.315(b)(11)(ii)(B)(1)(vii).
    At 88 FR 23784, we proposed to adopt in Sec.  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 Sec.  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 
Sec.  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.'' 
\87\ We did not propose to require specific formatting requirements for 
such feedback mechanisms.
---------------------------------------------------------------------------

    \87\ See also 85 FR 25879 discussion of machine readable.
---------------------------------------------------------------------------

    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 Sec.  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 
Sec.  170.315(b)(11) be capable of supporting interventions that use 
those listed data elements (88 FR 23783). The criterion at Sec.  
170.315(a)(9)(ii)(B)(1) listed many of the same types of information, 
such as medications for example, but the criterion at Sec.  
170.315(a)(9) did so without specifying a standard. As the result of 
our finalizing references to the standards in Sec.  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 Sec.  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 Sec.  
170.315(a)(9)(ii)(A)), as this example is unnecessary. We have also 
finalized the list of data elements proposed at Sec.  
170.315(b)(11)(ii)(B)(1) with the following modifications in 
consideration of comments. We have moved the list from proposed Sec.  
170.315(b)(11)(ii)(B)(1) and finalized the list at Sec.  
170.315(b)(11)(iii)(A)(1) and finalized the list as proposed. We have 
finalized the list of data elements in Sec.  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 Sec.  170.315(b)(11) as 
well as scope the evidence-based DSIs that are subject to requirements 
in Sec.  170.315(b)(11)(v). Including the list in Sec.  
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 Sec.  170.213 for USCDI v1 to occur on January 1, 
2026. Consistent with the applicable dates for the versions of the

[[Page 1239]]

USCDI in Sec.  170.213, this means Health IT Modules certified to Sec.  
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 
Sec.  170.315(b)(11) may support the data elements according to the 
USCDI v3 standard adopted in Sec.  170.213 as of the effective date of 
this final rule. On and after January 1, 2026, Health IT Modules 
certified to Sec.  170.315(b)(11) must support those listed data 
elements according to the USCDI v3 standard consistent with Sec.  
170.213.
    We have also finalized Sec.  170.315(b)(11)(ii)(B)(2) as Sec.  
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 Sec.  170.315(b)(11)(ii)(B) in transposing the 
proposed regulatory text from the regulation text at Sec.  
170.315(a)(9)(ii)(B)(2), and we have finalized regulation text proposed 
at Sec.  170.315(b)(11)(ii)(B)(2) using existing language found at 
Sec.  170.315(a)(9)(ii)(B)(2) at Sec.  170.315(b)(11)(ii)(B).
    Comments. Commenters generally expressed support for the proposal 
at Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  
170.315(b)(11)(iii), with a minor revision to current requirements that 
are part of the CDS criterion in Sec.  170.315(a)(9)(iii). We explained 
that this proposal would replace the current construct in Sec.  
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

[[Page 1240]]

Sec.  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 Sec.  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 Sec.  
170.213, including USCDI v3, which we proposed to adopt in Sec.  
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 Sec.  170.315(b)(11)(iii), in 
combination with the data referenced in Sec.  170.315(b)(11)(ii)(B)(1), 
represented the scope of evidence-based DSIs and scope of data that 
Health IT Modules certified to Sec.  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 Sec.  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 Sec.  
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 Sec.  
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 Sec.  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 Sec.  
170.315(b)(11) pertain to these DSI types. We also note that some data 
elements in Sec.  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 Sec.  
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 Sec.  
170.315(a)(9) definition of clinical decision support and that the 
Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(b)(11) be capable of 
supporting interventions based on specified data (as proposed in Sec.  
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,'' \88\ 
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).
---------------------------------------------------------------------------

    \88\ The ONC 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 note that there may be a software-
as-a-medical device (SaMD) that is considered a ``clinical 
intervention'' and subject to FDA authority.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  170.102.\89\ In the context of 
Program

[[Page 1241]]

requirements, this means that if a developer of certified health IT 
with a Health IT Module certified to Sec.  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 
Sec.  170.315(b)(11). We note that if the DSI in question meets the 
definition of Predictive DSI at Sec.  170.102, then requirements that 
apply to those types of interventions within Sec.  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.
---------------------------------------------------------------------------

    \89\ We note that this clarification is aligned with FDA's 
Clinical Decision Support Software Guidance, specifically the 
software functionalities described under Criterion 3, which refers 
to condition-, disease-, or patient-specific recommendations to a 
health care professional to enhance, inform, or influence a health 
care decision. Note that we reference the FDA CDS Guidance only to 
clarify the scope of which kinds of evidence-based DSIs are subject 
to applicable requirements in Sec.  170.315(b)(11). See https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software.
---------------------------------------------------------------------------

    Beyond this clarification, we have finalized Sec.  
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 Sec.  170.315(b)(11)(iii)(A) 
(for evidence-based DSIs) and Sec.  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 Sec.  170.315(b)(11)(v) in this final 
rule and we have narrowed the overall scope of technologies impacted by 
finalized requirements in Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  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 Sec.  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 Sec.  170.315(b)(11)(iii) is 
consistent with the historic and current expectation for evidence-based 
DSIs in Sec.  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 Sec.  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 Sec.  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 (Sec.  170.213(a)) and v3 (Sec.  
170.213(b)).\90\
---------------------------------------------------------------------------

    \90\ https://www.healthit.gov/isa/uscdi-data-class/unique-device-identifiers-a-patients-implantable-devices#uscdi-v1.
---------------------------------------------------------------------------

    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

[[Page 1242]]

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 Sec.  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 Sec.  
170.315(a)(9)(iv) as Sec.  170.315(b)(11)(iv) with a modification to 
reference the criterion in Sec.  170.315(b)(11) wherever the current 
reference is to Sec.  170.315(a)(9). We welcomed comment regarding the 
functionalities and standards listed in Sec.  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 Sec.  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 Sec.  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 Sec.  
170.315(a)(9), we have finalized Sec.  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 Sec.  
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 Sec.  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 Sec.  
170.315(b)(11)(v), and we proposed a corresponding definition in Sec.  
170.102. We also proposed in Sec.  170.315(b)(11)(v)(A) that developers 
of certified health IT with Health IT Modules certified to Sec.  
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 Sec.  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 Sec.  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

[[Page 1243]]

autonomous.\91\ 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.
---------------------------------------------------------------------------

    \91\ See generally IMDRF [verbar] Software as a Medical Device: 
Possible Framework for Risk Categorization and Corresponding 
Considerations: https://www.imdrf.org/documents/software-medical-device-possible-framework-risk-categorization-and-corresponding-considerations.
    See AMA [verbar] CPT[supreg] Appendix S: Artificial Intelligence 
Taxonomy for Medical Services and Procedures: https://www.ama-assn.org/system/files/cpt-appendix-s.pdf for definitions of 
``augmentative'' and ``autonomous''; ANSI/CTA Standard, The Use of 
Artificial Intelligence in Health Care: Trustworthiness ANSI/CTA-
2090: https://shop.cta.tech/collections/standards/products/the-use-of-artificial-intelligence-in-healthcare-trustworthiness-cta-2090?_ga=2.195226476.1947214965.1652722036-709349392.1645133306.
---------------------------------------------------------------------------

    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 Sec.  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 
<SUP>92 93 94</SUP> where the task of delineating between those 
predictive algorithms and models can have unintended consequences.
---------------------------------------------------------------------------

    \92\ Samorani M., Harris S.L., Blount L.G., et al (2021) 
Overbooked and Overlooked: Machine Learning and Racial Bias in 
Medical Appointment Scheduling. Manufacturing & Service Operations 
Management 24(6):2825-2842. https://doi.org/10.1287/msom.2021.0999.
    \93\ Vyas D.A., Eisenstein L.G., Jones D.S. Hidden in Plain 
Sight--Reconsidering the Use of Race Correction in Clinical 
Algorithms. Aug. 2020. N Engl J Med 2020; 383:874-882. DOI: 10.1056/
NEJMms2004740.
    \94\ Ziad Obermeyer et al., Dissecting racial bias in an 
algorithm used to manage the health of populations. Science 366, 
447-453 (2019). DOI:10. 1126/science.aax2342.
---------------------------------------------------------------------------

    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

[[Page 1244]]

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 Sec.  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 Sec.  170.315(b)(11).
    We have finalized our proposed definition for Predictive DSI with 
modification. Specifically, we have finalized the definition in Sec.  
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.\95\ 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.
---------------------------------------------------------------------------

    \95\ Michael Matheny, et al., Artificial intelligence in health 
care: the hope, the hype, the promise, the peril, Washington, DC: 
National Academy of Medicine (2019).
    Artificial Intelligence in Health Care: Benefits and Challenges 
of Technologies to Augment Patient Care, (Nov. 2020), https://www.gao.gov/products/gao-21-7sp. Deo, Rahul C. ``Machine learning in 
medicine.'' Circulation 132.20 (2015): 1920-1930.
    American Hospital Association. ``Surveying the AI Health Care 
Landscape'' 2019. https://www.aha.org/system/files/media/file/2019/10/Market_Insights_AI-Landscape.pdf.
---------------------------------------------------------------------------

    Comments. Several commenters expressed concern about consistency, 
duplication, and redundant requirements across various federal

[[Page 1245]]

programs. Commenters recommended that ONC tailor the scope of the 
proposed term Predictive DSI, and the proposed definition at Sec.  
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 Sec.  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,\96\ and we note that our requirements in Sec.  
170.315(b)(11) are complementary to FDA's Content of Premarket 
Submissions for Device Software Functions guidance, finalized in June 
2023.\97\ 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.
---------------------------------------------------------------------------

    \96\ See https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software.
    \97\ See https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions.
---------------------------------------------------------------------------

    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).\98\ 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.'' \99\ 
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).
---------------------------------------------------------------------------

    \98\ See U.S. Dept of Health & Human Servs., Office for Civil 
Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health 
Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities (prohibiting 
discrimination on the basis of race, color, national origin 
(including limited English proficiency), sex (including sexual 
orientation and gender identity), age, or disability in certain 
health programs or activities through the use of clinical algorithms 
in their decision-making).
    \99\ A device, as defined in section 201(h) of the FD&C Act, can 
include an instrument, apparatus, implement, machine, contrivance, 
implant, in vitro reagent, or other similar or related article, 
including a component part, or accessory which is, among other 
criteria, intended for use in the diagnosis of disease or other 
conditions, or in the cure, mitigation, treatment, or prevention of 
disease in man. The term ``device'' does not include software 
functions excluded pursuant to section 520(o) of the FD&C Act. For 
more information about determining whether a software function is 
potentially the focus of the FDA's oversight, please visit the FDA's 
Digital Health Policy Navigator Tool: https://www.fda.gov/medical-devices/digital-health-center-excellence/digital-health-policy-navigator.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  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 Sec.  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.\100\
---------------------------------------------------------------------------

    \100\ Pierson, Emma, et al. ``An algorithmic approach to 
reducing unexplained pain disparities in underserved populations.'' 
Nature Medicine 27.1 (2021): 136-140. Hosny, Ahmed, et al. 
``Artificial intelligence in radiology.'' Nature Reviews Cancer 18.8 
(2018): 500-510.
---------------------------------------------------------------------------

    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

[[Page 1246]]

regression and machine learning techniques, and are used to support 
decision making, would likely be considered Predictive DSIs.\101\
---------------------------------------------------------------------------

    \101\ van Walraven, Carl, Jenna Wong, and Alan J. Forster. 
``LACE+ index: extension of a validated index to predict early death 
or urgent readmission after hospital discharge using administrative 
data.'' Open Medicine 6.3 (2012): e80.
    Levey, Andrew S., et al. ``A more accurate method to estimate 
glomerular filtration rate from serum creatinine: a new prediction 
equation.'' Annals of internal medicine 130.6 (1999): 461-470.
    Walsh, Colin G., Jessica D. Ribeiro, and Joseph C. Franklin. 
``Predicting risk of suicide attempts over time through machine 
learning.'' Clinical Psychological Science 5.3 (2017): 457-469.
    Fleuren, Lucas M., et al. ``Machine learning for the prediction 
of sepsis: a systematic review and meta-analysis of diagnostic test 
accuracy.'' Intensive care medicine 46 (2020): 383-400.
---------------------------------------------------------------------------

    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.\102\
---------------------------------------------------------------------------

    \102\ Vincent, J -L., et al. ``The SOFA (Sepsis-related Organ 
Failure Assessment) score to describe organ dysfunction/failure: On 
behalf of the Working Group on Sepsis-Related Problems of the 
European Society of Intensive Care Medicine (see contributors to the 
project in the appendix).'' (1996): 707-710.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  170.315(b)(11) requires the health IT 
developer's Health IT Module certified to Sec.  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 Sec.  
170.315(b)(11) to, at a minimum, have the technical capability for 
users and other parties to populate the source attributes listed in 
Sec.  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 
Sec.  170.315(b)(11)(iv)(B) of this final rule. This will enable users 
to identify source

[[Page 1247]]

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

    \103\ Vincent, J.L., et al. ``The SOFA (Sepsis-related Organ 
Failure Assessment) score to describe organ dysfunction/failure: On 
behalf of the Working Group on Sepsis-Related Problems of the 
European Society of Intensive Care Medicine (see contributors to the 
project in the appendix).'' (1996): 707-710.
    van Walraven, Carl, Jenna Wong, and Alan J. Forster. ``LACE+ 
index: extension of a validated index to predict early death or 
urgent readmission after hospital discharge using administrative 
data.'' Open Medicine 6.3 (2012): e80.
---------------------------------------------------------------------------

    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 
Sec.  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 Sec.  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 Sec.  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.\104\ Together, we believe these factors warrant a broad and 
inclusive definition for Predictive DSI.
---------------------------------------------------------------------------

    \104\ Samorani M., Harris S.L., Blount L.G., et al (2021) 
Overbooked and Overlooked: Machine Learning and Racial Bias in 
Medical Appointment Scheduling. Manufacturing & Service Operations 
Management 24(6):2825-2842. https://doi.org/10.1287/msom.2021.0999.
    Vyas D.A., Eisenstein L.G., Jones D.S. Hidden in Plain Sight--
Reconsidering the Use of Race Correction in Clinical Algorithms. 
Aug. 2020. N Engl J Med 2020; 383:874-882. DOI: 10.1056/
NEJMms2004740.
    Ziad Obermeyer et al.,Dissecting racial bias in an algorithm 
used to manage the health of populations. Science 366, 447-453 
(2019). DOI: 10.1126/science.aax2342.
    Delgado, Cynthia, et al. ``A unifying approach for GFR 
estimation: recommendations of the NKF-ASN task force on reassessing 
the inclusion of race in diagnosing kidney disease.'' Journal of the 
American Society of Nephrology 32.12 (2021): 2994-3015.
---------------------------------------------------------------------------

    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.

[[Page 1248]]

    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 Sec.  
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.\105\ 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).\106\
---------------------------------------------------------------------------

    \105\ See, e.g., See U.S. Dept of Health & Human Servs., Office 
for Civil Rights, Notice of Proposed Rulemaking, Nondiscrimination 
in Health Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 
2022), https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities 
(prohibiting discrimination on the basis of race, color, national 
origin (including limited English proficiency), sex (including 
sexual orientation and gender identity), age, or disability in 
certain health programs or activities through the use of clinical 
algorithms in their decision-making).
    CMS Medicare Advantage Program Final Rule (April 2023), https://www.federalregister.gov/documents/2023/04/12/2023-07115/medicare-program-contract-year-2024-policy-and-technical-changes-to-the-medicare-advantage-program (The rule clarified coverage criteria for 
basic benefits and the use of prior authorization, added continuity 
of care requirements, and required an annual review of utilization 
management tools).
    \106\ The Federal Trade Commission (FTC) has addressed AI 
repeatedly in its work through a combination of law enforcement, 
business education and policy initiatives. For example, numerous FTC 
orders have required companies to delete data and algorithms. See 
``Amazon/Alexa'' case, https://www.ftc.gov/news-events/news/press-releases/2023/05/ftc-doj-charge-amazon-violating-childrens-privacy-law-keeping-kids-alexa-voice-recordings-forever (settling 
allegations that Amazon retained children's voice recordings 
indefinitely to feed its voice recognition algorithm in violation of 
a children's privacy law); ``Ring'' case, https://www.ftc.gov/news-events/news/press-releases/2023/05/ftc-says-ring-employees-illegally-surveilled-customers-failed-stop-hackers-taking-control-users (settling allegations that home security company allowed 
employees to access consumers' private videos); ``Weight Watchers/
Kurbo'' case, https://www.justice.gov/opa/pr/weight-management-companies-kurbo-inc-and-ww-international-inc-agree-15-million-civil-penalty (settling allegations that weight loss app for use by 
children as young as eight collected their personal information 
without parental permission); ``Everalbum'' case, https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3172-everalbum-inc-matter (settling allegations that the company deceived 
consumers about the use of facial recognition to analyze users' 
private images, including in connection with training FRT models); 
the ``Mole Detective'' case, https://www.ftc.gov/legal-library/browse/cases-proceedings/132-3210-new-consumer-solutions-llc-mole-detective (alleging deceptive conduct, where app developers claimed 
in advertisements that their consumer-facing app could determine 
based on photographs whether a mole was cancerous). In May 2023, the 
FTC issued a Policy Statement discussing the application of Section 
5 of the FTC Act to the collection and use of biometric information 
(such as finger or hand prints, facial images or geometry, voice 
recordings, or genetic information), including the use of biometric 
information technologies developed using machine learning and 
similar techniques. Fed. Trade Comm'n, Policy Statement of the 
Federal Trade Commission on Biometric Information and Section 5 of 
the Federal Trade Commission Act (May 18, 2023), https://www.ftc.gov/system/files/ftc_gov/pdf/p225402biometricpolicystatement.pdf. In November 2023, the FTC filed 
a comment with the Copyright Office on Artificial Intelligence. See 
https://www.ftc.gov/legal-library/browse/advocacy-filings/comment-federal-trade-commission-artificial-intelligence-copyright. FTC 
staff guidance has warned companies about their obligation to use AI 
responsibly and identified concerns from consumers and about 
competition. See, e.g., Consumers Are Voicing Concerns About AI, 
https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2023/10/consumers-are-voicing-concerns-about-ai (October 3, 2023); Watching 
the detectives: Suspicious marketing claims for tools that spot AI-
generated content (July 6, 2023); https://www.ftc.gov/business-guidance/blog/2023/07/watching-detectives-suspicious-marketing-claims-tools-spot-ai-generated-content; Generative AI Raises 
Competition Concerns, https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2023/06/generative-ai-raises-competition-concerns (June 
29, 2023); Hey, Alexa! What are you doing with my data? (June 13, 
2023), https://www.ftc.gov/business-guidance/blog/2023/06/hey-alexa-what-are-you-doing-my-data; The Luring Test: AI and the engineering 
of consumer trust (May 1, 2023), https://www.ftc.gov/business-guidance/blog/2023/05/luring-test-ai-engineering-consumer-trust; 
Chatbots, deepfakes, and voice clones: AI deception for sale (March 
20, 2023), https://www.ftc.gov/business-guidance/blog/2023/03/chatbots-deepfakes-voice-clones-ai-deception-sale; and Keep your AI 
claims in check (February 27, 2023): Keep your AI claims in check 
(February 2, 2023), https://www.ftc.gov/business-guidance/blog/2023/02/keep-your-ai-claims-check; Aiming for truth, fairness, and equity 
in your company's use of AI (April 19, 2021), https://www.ftc.gov/business-guidance/blog/2021/04/aiming-truth-fairness-equity-your-companys-use-ai; Artificial Intelligence and Algorithms (Apr. 8, 
2020), https://www.ftc.gov/news-events/blogs/business-blog/2020/04/using-artificial-intelligence-algorithms; The Commission has issued 
numerous reports related to algorithmic decision making. See FTC, 
Combatting Online Harms Through Innovation: A Report to Congress 
(June 2022), https://www.ftc.gov/reports/combatting-online-harms-through-innovation; FTC Report to Congress on Privacy and Security, 
September 2021, https://www.ftc.gov/system/files/documents/reports/ftc-report-congress-privacy-security/report_to_congress_on_privacy_and_data_security_2021.pdf; Fed. Trade 
Comm'n, Big Data: A Tool for Inclusion or Exclusion? (Jan. 2016), 
https://www.ftc.gov/system/files/documents/reports/big-data-tool-inclusion-or-exclusion-understanding-issues/160106big-data-rpt.pdf. 
For information on best practices to reduce bias and discrimination, 
see generally Rebecca Kelly Slaughter, Algorithms and Economic 
Justice, Yale J.L. & Tech. (Aug. 2021), https://law.yale.edu/sites/default/files/area/center/isp/documents/algorithms_and_economic_justice_master_final.pdf. The agency has 
also held several public events focused on AI issues, including a 
workshop on generative AI, workshops on dark patterns and voice 
cloning, sessions on AI and algorithmic bias at PrivacyCon 2020 and 
2021, a hearing on competition and consumer protection issues with 
algorithms and AI, a FinTech Forum on AI and blockchain, and an 
early forum on facial recognition technology (resulting in a 2012 
staff report). See https://www.ftc.gov/news-events/events/2023/10/creative-economy-generative-ai; https://www.ftc.gov/news-events/events/2021/04/bringing-dark-patterns-light-ftc-workshop; https://www.ftc.gov/news-events/events-calendar/you-dont-say-ftc-workshop-voice-cloning-technologies; https://www.ftc.gov/news-events/events-calendar/privacycon-2021; https://www.ftc.gov/news-events/eventscalendar/privacycon-2020; https://www.ftc.gov/news-events/events-calendar/ftc-hearing-7-competition-consumerprotection-21st-century; https://www.ftc.gov/news-events/events-calendar/2017/03/fintech-forum-blockchainartificial-intelligence; and https://www.ftc.gov/news-events/events-calendar/2011/12/face-facts-forum-facialrecognition-technology.The Commission has issued an advanced 
notice of proposed rulemaking that poses questions about the harms 
to consumers that may result from commercial surveillance, including 
as related to algorithmic decision making. See FTC, Advance Notice 
of Proposed Rulemaking regarding Commercial Surveillance and Data 
Security (August 11, 2022), https://www.ftc.gov/legal-library/browse/federal-register-notices/commercial-surveillance-data-security-rulemaking.
---------------------------------------------------------------------------

    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

[[Page 1249]]

commenter urged ONC to survey the definitions of healthcare AI 
currently in use, including the American Medical Association Current 
Procedural Terminology (CPT[supreg]) 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[supreg]) 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 Sec.  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 Sec.  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 Sec.  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.\107\ 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.
---------------------------------------------------------------------------

    \107\ Samorani M., Harris S.L., Blount L.G., et al (2021) 
Overbooked and Overlooked: Machine Learning and Racial Bias in 
Medical Appointment Scheduling. Manufacturing & Service Operations 
Management 24(6):2825-2842. https://doi.org/10.1287/msom.2021.0999.
---------------------------------------------------------------------------

    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

[[Page 1250]]

care provider who self-develops a tool that meets our definition of 
Predictive DSI is not subject to the requirements in Sec.  
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 Sec.  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 Sec.  
170.315(b)(11). We describe requirements further below that Health IT 
Modules certified to Sec.  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,\108\ the CMS Appropriate 
Use Criteria program,\109\ or Medicare Advantage Program regulations 
related to utilization management.\110\ 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 Sec.  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.
---------------------------------------------------------------------------

    \108\ CLIA regulations include federal standards applicable to 
all U.S. facilities or sites that test human specimens for health 
assessment for to diagnose, prevent, or treat disease. CDC, in 
partnership with CMS and FDA, supports the CLIA program and clinical 
laboratory quality. For more information, see https://www.cdc.gov/clia/index.html.
    \109\ We note that CMS rescinded the regulations for the AUC 
program in the 2024 Physician Fee Schedule Final Rule (88 FR 79262). 
For more information about the program, see https://www.cms.gov/medicare/quality/appropriate-use-criteria-program.
    \110\ See, e.g., CMS Medicare Advantage Program Final Rule 
(April 2023), https://www.federalregister.gov/documents/2023/04/12/2023-07115/medicare-program-contract-year-2024-policy-and-technical-changes-to-the-medicare-advantage-program (clarified coverage 
criteria for basic benefits and the use of prior authorization, 
added continuity of care requirements, and required an annual review 
of utilization management tools).
---------------------------------------------------------------------------

    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.\111\ 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.
---------------------------------------------------------------------------

    \111\ Government Accountability Office. Health Information 
Technology: Approaches and Challenges to Electronically Matching 
Patients' Records across Providers. Jan 15, 2019.
---------------------------------------------------------------------------

    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

[[Page 1251]]

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 Sec.  170.315(b)(11)(v)(A), at 88 FR 23786, we proposed 
that developers of certified health IT with Health IT Modules certified 
to Sec.  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 Sec.  170.213. This 
attestation requirement would have the effect of permitting developers 
of certified health IT to certify to Sec.  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 Sec.  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 \112\ 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.
---------------------------------------------------------------------------

    \112\ Please note that ``other party'' is a term of art we 
described at 88 FR 23796. In this final rule, we have italicized 
other party and other parties to assist readers' understanding that 
we are using this term of art and not misspelling ``another.''
---------------------------------------------------------------------------

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

[[Page 1252]]

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 Sec.  170.315(b)(11)), it was unclear whether the 
developer would need to reengage its ONC-ACB to change its certificate 
for Sec.  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 Sec.  
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 Sec.  170.315(b)(11) would still be 
able to get certified to Sec.  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 Sec.  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 
Sec.  170.315(b)(11) while also maintaining a construction that enables 
a developer of certified health IT to certify a Health IT Module to 
Sec.  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 
Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  
170.315(b)(11)(A)).
    Second, the finalization of Sec.  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 Sec.  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-

[[Page 1253]]

developed or other party-developed Predictive DSIs. This is because 
Predictive DSI-related source attribute fields (proposed in Sec.  
170.315(b)(11)(vi)(C)) and Predictive DSI-related capabilities to 
author and revise source attributes (proposed in Sec.  
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 Sec.  
170.315(b)(11)(iv) across Health IT Modules certified to Sec.  
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 Sec.  170.315(b)(11) while keeping the 
intent of the attestation statement we proposed. For instance, our 
finalized policy in Sec.  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 Sec.  170.315(b)(11) and will not have to meet, for 
example, IRM practice requirements in Sec.  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 Sec.  
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 Sec.  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+,\113\ 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.
---------------------------------------------------------------------------

    \113\ van Walraven, Carl, Jenna Wong, and Alan J. Forster. 
``LACE+ index: extension of a validated index to predict early death 
or urgent readmission after hospital discharge using administrative 
data.'' Open Medicine 6.3 (2012): e80.
---------------------------------------------------------------------------

    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.\114\ 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 Sec.  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.
---------------------------------------------------------------------------

    \114\ As noted in HTI-1 Proposed Rule, Other parties can 
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 (88 FR 23796).
---------------------------------------------------------------------------

    We note that Health IT Modules certified to Sec.  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 Sec.  
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 Sec.  
170.315(b)(11)(v)(A)(1) to enable user access to updated descriptions 
of source attribute information at Sec.  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 Sec.  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 Sec.  170.523(f)(1)(xxi).
    This Maintenance of Certification requirement is a Sec.  
170.315(b)(11)-specific instantiation of general Program requirements 
described in Sec.  170.402(a) as well as an adaptation of what we 
proposed at Sec.  170.315(b)(11)(vii)(D), which proposed to establish 
an ``annual

[[Page 1254]]

and, as necessary, update'' requirement for developers with Health IT 
Modules certified to Sec.  170.315(b)(11) (88 FR 23805). In 
consideration of comments received on Sec.  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 Sec.  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 Sec.  
170.402(b)(4) that starting January 1, 2025, and on an ongoing basis, 
developers of Health IT Modules certified to Sec.  170.315(b)(11) must 
review and update, as necessary, source attribute information in Sec.  
170.315(b)(11)(iv)(A) and (B), risk management practices described in 
Sec.  170.315(b)(11)(vi), and summary information provided through 
Sec.  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 Sec.  
170.315(b)(11) to have complete and up-to-date descriptions of source 
attribute information (in Sec.  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 Sec.  170.315(b)(11). This Maintenance of 
Certification requirement builds on three existing Assurances Condition 
of Certification requirements at Sec.  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 Sec.  
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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(b)(11) review and update as 
necessary risk management practices described in Sec.  
170.315(b)(11)(vi). This is substantially similar to what we proposed 
at Sec.  170.315(b)(11)(vii)(D), which was to review annually and, as 
necessary, update IRM practice documentation. We discuss comments 
received to proposed Sec.  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 Sec.  170.315(b)(11) review and update as 
necessary summary information provided to the developer's ONC-ACB, 
consistent with what we proposed at Sec.  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 Sec.  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 Sec.  170.315(b)(11)(vii)(C) were 
available via public hyperlink. We discuss comments received to 
proposed Sec.  170.315(b)(11)(vii)(C) and Sec.  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

[[Page 1255]]

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 Sec.  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 Sec.  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 Sec.  170.315(b)(11)(v) and 
regulatory text in Sec.  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 (Sec.  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 Sec.  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 Sec.  170.315(b)(11) for 
source attributes. We also note that the phrase ``supplied by'' is also 
included in the text of Sec.  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 Sec.  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 (Sec.  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 Sec.  
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 Sec.  170.315(b)(11)(vi) that Health 
IT Modules certified to Sec.  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 Sec.  170.315(g)(3) ``safety-enhanced 
design,'' applies to the existing Sec.  170.315(a)(9) criterion and in 
keeping with that applicability, we proposed that safety-enhanced and 
user-centered design processes described in Sec.  170.315(g)(3) would 
apply to the new certification criterion proposed in Sec.  
170.315(b)(11) as well. We proposed to update Sec.  170.315(g)(3) 
accordingly to reference the proposed Sec.  170.315(b)(11).
    Comments. Commenters were generally split on supporting or not 
supporting the proposal in Sec.  170.315(b)(11)(vi) that Health IT 
Modules certified to Sec.  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

[[Page 1256]]

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 Sec.  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 Sec.  
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 Sec.  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 Sec.  170.315(b)(11)(iv), we reiterate the requirement in Sec.  
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 Sec.  
170.315(b)(11)(iv)(A) and Sec.  170.315(b)(11)(iv)(B). And we have also 
included a requirement in Sec.  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 Sec.  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 Sec.  
170.315(b)(11). We continue to believe that just as the CDS criterion 
in Sec.  170.315(a)(9) was subject to safety-enhanced design 
requirements, so too should the revised criterion in Sec.  
170.315(b)(11). Thus, we have finalized our proposed modification to 
Sec.  170.315(g)(3) ``safety-enhanced design,'' to reference the 
certification criterion finalized in Sec.  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 Sec.  170.315(b)(11)(v)(A) and requirements related 
to enabling customers to modify source attributes and source attribute 
information for DSI at Sec.  170.315(b)(11)(v)(B). We also separately 
list source attribute categories for evidence-based and Predictive DSI 
at Sec.  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 Sec.  
170.315(b)(11), we have finalized uniform requirements in Sec.  
170.315(b)(11)(iv) for Health IT Modules to support source attributes 
listed at Sec.  170.315(b)(11)(iv)(A) and (B). This means that all 
Health IT Modules certified to Sec.  170.315(b)(11) must support the 
categories, but not necessarily the content, for each source attribute 
listed at Sec.  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 Sec.  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 Sec.  
170.315(b)(11)(v). As described above, we have not finalized our 
proposal for an attestation statement. Rather, we have finalized in 
Sec.  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 Sec.  170.315(b)(11) in 
the HTI-1 Proposed Rule.
    First, we have finalized requirements for ``Source attribute access 
and modification'' in Sec.  170.315(b)(11)(v). Specifically, we 
finalized a requirement in Sec.  170.315(b)(11)(v)(A)(1) that is 
substantially similar to what we proposed in Sec.  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 Sec.  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 Sec.  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 Sec.  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

[[Page 1257]]

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 Sec.  170.315(b)(11)(vi)(D)(1) and Sec.  
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 Sec.  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 (Sec.  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 Sec.  170.315(b)(11)(v)(B). At Sec.  
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 Sec.  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 Sec.  170.315(b)(11)(iv)(B). These requirements are 
substantially similar to what we proposed in Sec.  
170.315(b)(11)(vi)(E) while retaining the ability to access or review 
this information as would have been required in proposed Sec.  
170.315(b)(11)(v). In proposed Sec.  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 Sec.  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 Sec.  170.315(b)(11)(vi)(A) and deployment 
of or engagement in intervention risk management practices discussed in 
Sec.  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 Sec.  
170.315(b)(11)(vi)(A)(1) through (4) the source attributes currently 
found in Sec.  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 Sec.  170.315(b)(11)(vi)(A)--
Demographic data elements in Sec.  170.315(b)(11)(vi)(A)(5), SDOH data 
elements in Sec.  170.315(b)(11)(vi)(A)(6), and Health Status 
Assessment data elements in Sec.  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 Sec.  
170.315(b)(11)(vi)(A) relative to the existing attributes in Sec.  
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 Sec.  170.315(b)(11)(vi), we have 
finalized modified versions of these requirements as part of Sec.  
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

[[Page 1258]]

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,\115\ 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 Sec.  170.315(b)(11)(iv)(A)(5)-(13) (as expressed by the 
standards in Sec.  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.
---------------------------------------------------------------------------

    \115\ For purposes of this final rule, health status assessments 
are assessments of a health-related matter of interest, importance, 
or worry to a patient, patient's family, or patient's health care 
provider that could identify a need, problem, or condition. See 
ONC's Interoperability Standards Advisory (ISA) at https://www.healthit.gov/isa/uscdi-data-class/health-status-assessments#uscdi-v3.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  
170.213) is used as part of the evidence-based DSI.
    After consideration of comments, we have finalized as part of Sec.  
170.315(b)(11)(iv)(A) patient demographic, SDOH, and health status 
assessment data elements in Sec.  170.315(b)(11)(iv)(A)(5) through (13) 
as expressed in the standards in Sec.  170.213. We note that, 
consistent with the dates established in Sec.  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 Sec.  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 Sec.  
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

[[Page 1259]]

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 Sec.  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.\116\ This proposed requirement applied to 
developers of certified health IT that attest ``yes'' in Sec.  
170.315(b)(11)(v)(A).
---------------------------------------------------------------------------

    \116\ Mitchell, Margaret, et al. ``Model cards for model 
reporting.'' Proceedings of the conference on fairness, 
accountability, and transparency. 2019.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  170.315(b)(11)(vi), we proposed 
that these new source attributes listed in Sec.  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 
Sec.  170.315(b)(11) and for which the developer attested ``yes'' in 
Sec.  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 Sec.  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 Sec.  170.315(b)(11)(vi)(C), we 
have finalized modified versions of these requirements as part of Sec.  
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 Sec.  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 Sec.  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.\117\

[[Page 1260]]

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

    \117\ Scott, Ian, Stacy Carter, and Enrico Coiera. ``Clinician 
checklist for assessing suitability of machine learning applications 
in healthcare.'' BMJ Health & Care Informatics 28.1 (2021).
    Liu X, Cruz Rivera S, Moher D, Calvert MJ, Denniston AK; SPIRIT-
AI and CONSORT-AI Working Group. Reporting guidelines for clinical 
trial reports for interventions involving artificial intelligence: 
the CONSORT-AI extension. Nat Med. 2020;26(9):1364-1374. 
doi:10.1038/s41591-020-1034-x.
    Moons KGM, Kengne AP, Woodward M, et al. Risk prediction models, 
I: development, internal validation, and assessing the incremental 
value of a new (bio)marker. Heart. 2012;98(9):683-690. doi:10.1136/
heartjnl-2011-301246.
    Rivera SC, Liu X, Chan AW, Denniston AK, Calvert MJ; SPIRIT-AI 
and CONSORT-AI Working Group. Guidelines for clinical trial 
protocols for interventions involving artificial intelligence: the 
SPIRIT-AI Extension. BMJ. 2020;370:m3210. doi:10.1136/bmj.m3210.
    Steyerberg EW, Vergouwe Y. Towards better clinical prediction 
models: seven steps for development and an ABCD for validation. Eur 
Heart J. 2014;35(29):1925-1931. doi:10.1093/eurheartj/ehu207.
    Moons KGM, de Groot JAH, Bouwmeester W, et al. Critical 
appraisal and data extraction for systematic reviews of prediction 
modelling studies: the CHARMS checklist. PLoS Med. 
2014;11(10):e1001744.
    Collins GS, Reitsma JB, Altman DG, Moons KGM. Transparent 
Reporting of a Multivariable Prediction Model for Individual 
Prognosis or Diagnosis (TRIPOD): the TRIPOD statement. Br J Surg. 
2015;102(3):148-158.
    Cohen JF, Korevaar DA, Altman DG, et al. STARD 2015 guidelines 
for reporting diagnostic accuracy studies: explanation and 
elaboration. BMJ Open. 2016;6(11):e012799. doi:10.1136/bmjopen-2016-
012799.
    Luo W, Phung D, Tran T, et al. Guidelines for developing and 
reporting machine learning predictive models in biomedical research: 
a multidisciplinary view. J Med internet Res. 2016;18(12):e323. 
doi:10.2196/jmir.5870.
    Breck E, Cai S, Nielsen E, Salib M, Sculley D. The ML Test 
Score: a rubric for ML production readiness and technical debt 
reduction. Proceedings of the 2017 IEEE International Conference on 
Big Data. December 11-14, 2017:1123-1132. doi:10.1109/
BigData.2017.8258038.
    Wolff RF, Moons KGM, Riley RD, et al; PROBAST Group[dagger]. 
PROBAST: a tool to assess the risk of bias and applicability of 
prediction model studies. Ann Intern Med. 2019;170(1):51-58. 
doi:10.7326/M18-1376.
    Mitchell M, Wu S, Zaldivar A, et al. Model Cards for model 
reporting. In: Proceedings of the Conference on Fairness, 
Accountability, and Transparency. Association for Computing 
Machinery; January 29, 2019.
    Sendak MP, Gao M, Brajer N, Balu S. Presenting machine learning 
model information to clinical end users with model facts labels. NPJ 
Digit Med. 2020;3:41. doi:10.1038/s41746-020-0253-3.
    Hernandez-Boussard T, Bozkurt S, Ioannidis JPA, Shah NH. MINIMAR 
(Minimum Information for Medical AI Reporting): developing reporting 
standards for artificial intelligence in health care. J Am Med 
Inform Assoc. 2020;27(12):2011-2015.doi:10.1093/jamia/ocaa088.
    Norgeot B, Quer G, Beaulieu-Jones BK, et al. Minimum Information 
About Clinical Artificial Intelligence Modeling: the MI-CLAIM 
checklist. Nat Med. 2020;26(9):1320-1324. doi:10.1038/s41591-020-
1041-y.
    Silcox C, Dentzer S, Bates DW. AI-enabled clinical decision 
support software: a ``trust and value checklist'' for clinicians. 
NEJM Catalyst. 2020;1(6). doi:10.1056/CAT.20.0212.
    Vasey, Baptiste, et al. ``Reporting guideline for the early-
stage clinical evaluation of decision support systems driven by 
artificial intelligence: DECIDE-AI.'' Nature medicine 28.5 (2022): 
924-933.
---------------------------------------------------------------------------

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

[[Page 1261]]

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 Sec.  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.\118\ 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.\119\
---------------------------------------------------------------------------

    \118\ See footnote 117.
    \119\ Table 1. Summary of 15 Model Reporting Guideline Papers. 
Lu JH, Callahan A, Patel BS, et al. Assessment of Adherence to 
Reporting Guidelines by Commonly Used Clinical Prediction Models 
From a Single Vendor: A Systematic Review. JAMA Netw Open. 
2022;5(8):e2227779. doi:10.1001/jamanetworkopen.2022.27779.
---------------------------------------------------------------------------

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

[[Page 1262]]

does not supply a Predictive DSI as part of its Health IT Module, due 
to requirements at Sec.  170.315(b)(11)(iii)(B) and Sec.  
170.315(b)(11)(iv)(B)). Further, if developer of certified health IT a 
with Health IT Module certified to Sec.  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 Sec.  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.\120\ 
We believe our requirements at Sec.  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.
---------------------------------------------------------------------------

    \120\ Health AI Partnership. ``Define performance targets,'' 
https://healthaipartnership.org/guiding-question/define-performance-targets Data Science and Public Policy, Carnegie Mellon University. 
``Aequitas'' http://www.datasciencepublicpolicy.org/our-work/tools-guides/aequitas/.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  170.315(b)(11) is 
complementary and not conflicting with the information that FDA 
describes in its CDS Guidance, finalized in September 2022.\121\ 
Specifically, we believe that both (1) the

[[Page 1263]]

content of the information described for source attributes in Sec.  
170.315(b)(11)(iv) and (2) the capabilities required in Sec.  
170.315(b)(11)(iii) and Sec.  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.
---------------------------------------------------------------------------

    \121\ See https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software.
---------------------------------------------------------------------------

    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:
    <bullet> Sec.  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).
    <bullet> Sec.  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 Sec.  
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.
    <bullet> Sec.  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 Sec.  170.315(b)(11) 
and Sec.  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 Sec.  170.315(b)(11)(iii) and access source 
attributes for these DSIs in Sec.  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 Sec.  170.315(b)(11)(iii) and access source 
attribute information in Sec.  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 Sec.  
170.315(b)(11)(iv)(B) and IRM practices described in Sec.  
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) \122\ 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 Sec.  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 Sec.  
170.315(b)(11)(iv)(B)(8)(iv)) and

[[Page 1264]]

descriptions of the frequency by which the intervention's performance 
is corrected when risks related to validity and fairness are identified 
(at Sec.  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.
---------------------------------------------------------------------------

    \122\ See https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial.
---------------------------------------------------------------------------

    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 Sec.  
170.315(b)(11)(iv)(B)(1) for details and output of the intervention and 
Sec.  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 Sec.  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 Sec.  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 Sec.  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

[[Page 1265]]

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 Sec.  
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 Sec.  
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.\123\
---------------------------------------------------------------------------

    \123\ See U.S. Dept of Health & Human Servs., Office for Civil 
Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health 
Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), https://www.federalregister.gov/documents/2022/08/04/202216217/nondiscrimination-in-health-programs-and-activities (prohibiting 
discrimination on the basis of race, color, national origin 
(including limited English proficiency), sex (including sexual 
orientation and gender identity), age, or disability in certain 
health programs or activities through the use of clinical algorithms 
in their decisionmaking); Title VI of the Civil Rights Act of 1964, 
42 U.S.C. 2000d et seq. (prohibiting discrimination on the basis of 
race, color, or national origin (including limited English 
proficiency) in federally funded programs or activities); Title IX 
of the Education Amendments of 1972, 20 U.S.C. 1681 et seq. 
(prohibiting sex discrimination in federally funded education 
programs or activities); the Age Discrimination Act of 1975, 42 
U.S.C. 6101 et seq. (prohibiting age discrimination in federally 
funded programs or activities); Section 504 of the Rehabilitation 
Act of 1973, 29 U.S.C. 794 (prohibiting disability discrimination in 
federally funded or federally conducted programs or activities); and 
the Americans with Disabilities Act, 42 U.S.C. 12101 et seq. 
(prohibiting disability discrimination by employers, state and local 
government entities, and businesses that are open to the public, 
among others).
---------------------------------------------------------------------------

    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 
Sec.  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 Sec.  170.403 users have explicit rights 
to discuss publicly various aspects regarding the performance of 
certified health IT. Specifically, we note that in Sec.  
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

[[Page 1266]]

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

    \124\ 45 CFR 164.524.
---------------------------------------------------------------------------

    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.\125\ 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.\126\ 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.\127\
---------------------------------------------------------------------------

    \125\ See definitions of ``business associate'' and ``covered 
entity'' at 45 CFR 160.103.
    \126\ For more information about the HIPAA Privacy Rule 
individual's right of access, see OCR's HIPAA Access Guidance: 
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html.
    \127\ See, e.g., OCR's HIPAA FAQs 2048 and 2049, https://www.hhs.gov/guidance/document/faq-2048-does-individual-have-right-access-genomic-information-generated-clinical; https://www.hhs.gov/
hipaa/for-professionals/faq/2049/does-an-individual-have-a-right-
under/
index.html#:~:text=Under%20the%20HIPAA%20Privacy%20Rule,a%20clinical%
20laboratory%20may%20hold.
---------------------------------------------------------------------------

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

[[Page 1267]]

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 Sec.  
170.315(b)(11)(iv)(B)(1) to include similar general attribute 
information. Specifically, at Sec.  170.315(b)(11)(iv)(B)(1)(i) we 
require ``The name and contact information for the developer of the 
intervention,'' and at Sec.  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 Sec.  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 Sec.  170.315(b)(11)(iv)(A) were 
duplicative of source attributes in Sec.  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 Sec.  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 Sec.  170.315(b)(11)(iv)(B).
    Response. We agree and have finalized regulation text at Sec.  
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 Sec.  
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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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

[[Page 1268]]

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

[[Page 1269]]

    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 Sec.  
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 Sec.  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 Sec.  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 Sec.  
170.315(b)(11)(v)(A)(2); and (2) developers of certified health IT with 
Health IT Modules certified to Sec.  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,\128\ may not have access to 
training data that would allow them to: 1) provide a description of 
demographic representativeness of the training data (Sec.  
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 
(Sec.  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 (Sec.  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 
Sec.  170.315(b)(11)(v).
---------------------------------------------------------------------------

    \128\ Goff Jr, David C., et al. ``2013 ACC/AHA guideline on the 
assessment of cardiovascular risk: a report of the American College 
of Cardiology/American Heart Association Task Force on Practice 
Guidelines.'' Circulation 129.25_suppl_2 (2014): S49-S73.
    Levey, Andrew S., et al. ``A more accurate method to estimate 
glomerular filtration rate from serum creatinine: a new prediction 
equation.'' Annals of internal medicine 130.6 (1999): 461-470.
---------------------------------------------------------------------------

    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 
Sec.  170.315(b)(11)(v)(A)(2) that only source attributes in Sec.  
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

[[Page 1270]]

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 Sec.  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 Sec.  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 Sec.  170.315(b)(11)(vi)(E), we proposed that Health IT 
Modules certified to Sec.  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 Sec.  170.315(b)(11)(vi)(A) and (C).
    Comments. A majority of commenters did not support the proposal 
that Health IT Modules certified to Sec.  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

[[Page 1271]]

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 Sec.  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 Sec.  
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 Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  170.315(b)(11)(iv)(A) and (b)(11)(iv)(B). As 
previously discussed, Sec.  170.315(b)(11)(v)(B) is a modified version 
of proposed Sec.  170.315(b)(11)(iv) and Sec.  170.315(b)(11)(vi)(E), 
combining the ``author and revise'' concepts of Sec.  
170.315(b)(11)(iv)(E) with the ``review'' concept in Sec.  
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 Sec.  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.\129\ 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 Sec.  
170.315(b)(11)(v)(B)(2) around authoring source attributes in addition 
to those listed in Sec.  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.
---------------------------------------------------------------------------

    \129\ See, for instance, work by the coalition for health AI 
https://www.coalitionforhealthai.org/ and the health AI partnership 
https://healthaipartnership.org/.
---------------------------------------------------------------------------

    In Sec.  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

[[Page 1272]]

capability to only Predictive DSI source attributes in Sec.  
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 Sec.  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 Sec.  
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 Sec.  
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 Sec.  170.315(b)(11)(vii)(A)(3) (88 FR 23802-23803).
    With respect to documentation, we proposed at Sec.  
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 Sec.  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 Sec.  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 Sec.  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.\130\ 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.
---------------------------------------------------------------------------

    \130\ NIST AI Risk Management Framework, https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  170.523(f)(1)(xxi) as well as the annual review 
and updated documentation requirements in Sec.  170.402(b)(4). We have 
not finalized our proposal that developers of certified health IT 
compile detailed documentation of IRM practices listed in Sec.  
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.\131\ 
While we encourage the use of

[[Page 1273]]

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

    \131\ As noted in the HTI-1 Proposed Rule (88 FR 23810) 
(footnote 289), we are aware of and coordinated with multiple 
federal agencies and activities focused on AI, including the NAIC, 
that are also exploring policies to prevent and mitigate bias in AI/
ML and the intersection with privacy, equity, and civil rights. For 
more information about the Congressionally-created NAIC and its 
recommendation for federal agencies, please see the NAIC Year 1 
Report (May 2023), available at: https://www.ai.gov/wp-content/uploads/2023/05/NAIAC-Report-Year1.pdf.
---------------------------------------------------------------------------

    We appreciate commenters' suggestions on additional characteristics 
and additional kinds of risks that developers of certified health IT 
with Health IT Modules certified to Sec.  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 Sec.  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,\132\ as part of these requirements.
---------------------------------------------------------------------------

    \132\ Kim J., Hasan A., Kellogg K., et al. Development and 
preliminary testing of Health Equity Across the AI Lifecycle 
(HEAAL): A framework for healthcare delivery organizations to 
mitigate the risk of AI solutions worsening health inequities. 
medRxiv 2023.10.16.23297076; doi: https://doi.org/10.1101/2023.10.16.23297076.
---------------------------------------------------------------------------

    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 (Sec.  170.315(g)(3) ``safety-enhanced design'' (SED) and 
Sec.  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 Sec.  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 Sec.  
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

[[Page 1274]]

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.\133\ 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.\134\ 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.\135\ 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.
---------------------------------------------------------------------------

    \133\ Off. Comptroller Currency, Comptroller's Handbook: Model 
Risk Management (Aug. 2021), https://www.occ.gov/publications-and-resources/publications/comptrollers-handbook/files/model-risk-management/index-model-risk-management.html.
    \134\ Id.
    \135\ Id.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  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 Sec.  170.315(b)(11)(v) and what we have 
finalized in Sec.  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 Sec.  
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 Sec.  
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 Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(b)(11)(vii)(C) 
and what we proposed as a modification the Principles of Proper Conduct 
for ONC-ACB in Sec.  170.523(f)(1)(xxi)
    Finally, as stated previously, we have finalized a new Assurances 
Maintenance of Certification requirement in Sec.  170.402(b)(4) that 
requires developers of Health IT Modules certified to Sec.  
170.315(b)(11), starting January 1, 2025, and on an ongoing basis 
thereafter, review and update, as necessary, source attribute 
information in Sec.  170.315(b)(11)(iv)(A) and (B), risk management 
practices described in Sec.  170.315(b)(11)(vi), and summary 
information provided through Sec.  170.523(f)(1)(xxi). This requirement 
is substantially similar to what we had included in our proposal (such 
as Sec.  170.315(b)(11)(vii)(D)). We provide additional details on 
Sec.  170.402(b)(4) in previous comment responses in section III.C.5.v. 
``Predictive Decision Support Interventions, Attestation for Predictive

[[Page 1275]]

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 Sec.  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 Sec.  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.\136\ 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.
---------------------------------------------------------------------------

    \136\ See e.g., U.S. Dept of Health & Human Servs., Office for 
Civil Rights, Notice of Proposed Rulemaking, Nondiscrimination in 
Health Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), 
https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities (prohibiting 
discrimination on the basis of race, color, national origin 
(including limited English proficiency), sex (including sexual 
orientation and gender identity), age, or disability in certain 
health programs or activities through the use of clinical algorithms 
in their decision-making); Title VI of the Civil Rights Act of 1964, 
42 U.S.C. 2000d et seq. (prohibiting discrimination on the basis of 
race, color, or national origin (including limited English 
proficiency) in federally funded programs or activities); Title IX 
of the Education Amendments of 1972, 20 U.S.C. 1681 et seq. 
(prohibiting sex discrimination in federally funded education 
programs or activities); the Age Discrimination Act of 1975, 42 
U.S.C. 6101 et seq. (prohibiting age discrimination in federally 
funded programs or activities); Section 504 of the Rehabilitation 
Act of 1973, 29 U.S.C. 794 (prohibiting disability discrimination in 
federally funded or federally conducted programs or activities); and 
the Americans with Disabilities Act, 42 U.S.C. 12101 et seq. 
(prohibiting disability discrimination by employers, state and local 
government entities, and businesses that are open to the public, 
among others); The Health Insurance Portability and Accountability 
Act (HIPAA) Public Law 104-191,110 Stat. 1936 (August 21, 1996), 
codified at 42 U.S.C. 1320d-1320d8; HIPAA Privacy Rule, 45 CFR part 
160 and subparts A and E of part 164; and The HIPAA Security Rule, 
45 CFR part 160 and subparts A and C of part 164.
---------------------------------------------------------------------------

    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

[[Page 1276]]

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 Sec.  170.315(b)(11)(iv) there are two that would 
enable users to know if a Predictive DSI was tested for fairness at 
Sec.  170.315(b)(11)(iv)(B)(8)(iii) and (iv) and validity in local data 
at Sec.  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 Sec.  170.315(b)(11) must 
participate in real world testing as a Condition and Maintenance of 
Certification requirement as stipulated in Sec.  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.[thinsp]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.\137\
---------------------------------------------------------------------------

    \137\ See generally HHS Press Release (April 2023), https://www.hhs.gov/about/news/2023/04/11/hhs-propose-new-rule-to-further-implement-the-21st-century-cures-act.html.
---------------------------------------------------------------------------

    After consideration of these comments, we have finalized 
requirements at Sec.  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

[[Page 1277]]

the HTI-1 Proposed Rule, we proposed Sec.  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,\138\ 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.\139\ We also reiterate that 
developers of certified health IT with Health IT Modules certified to 
Sec.  170.315(b)(11) will be required to engage in real world testing 
per requirements at Sec.  170.405.
---------------------------------------------------------------------------

    \138\ See HIPAA Privacy and Security Rules, 45 CFR part 160 and 
subparts A and E of part 164; 15 U.S.C. 45(a) (Section 5 of the FTC 
Act) and Health Breach Notification Rule in 16 CFR part 318; U.S. 
Dept of Health & Human Servs., Office for Civil Rights, Notice of 
Proposed Rulemaking, Nondiscrimination in Health Programs and 
Activities, 87 FR 47824, 47880 (Aug. 4, 2022), https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities (prohibiting 
discrimination on the basis of race, color, national origin 
(including limited English proficiency), sex (including sexual 
orientation and gender identity), age, or disability in certain 
health programs or activities through the use of clinical algorithms 
in their decision-making); Title VI of the Civil Rights Act of 1964, 
42 U.S.C. 2000d et seq. (prohibiting discrimination on the basis of 
race, color, or national origin (including limited English 
proficiency) in federally funded programs or activities); Title IX 
of the Education Amendments of 1972, 20 U.S.C. 1681 et seq. 
(prohibiting sex discrimination in federally funded education 
programs or activities); the Age Discrimination Act of 1975, 42 
U.S.C. 6101 et seq. (prohibiting age discrimination in federally 
funded programs or activities); Section 504 of the Rehabilitation 
Act of 1973, 29 U.S.C. 794 (prohibiting disability discrimination in 
federally funded or federally conducted programs or activities); and 
the Americans with Disabilities Act, 42 U.S.C. 12101 et seq. 
(prohibiting disability discrimination by employers, state and local 
government entities, and businesses that are open to the public, 
among others).
    \139\ https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2.
---------------------------------------------------------------------------

    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 Sec.  
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,\140\ 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.\141\
---------------------------------------------------------------------------

    \140\ See definitions of ``business associate'' and ``covered 
entity'' at 45 CFR 160.103.
    \141\ See the definition of ``electronic protected health 
information'' at 45 CFR 160.103.
---------------------------------------------------------------------------

    As noted in the HTI-1 Proposed Rule, similar to when a HIPAA 
covered entity or business associate engages with a cloud service 
provider,\142\ a developer of certified health IT, supplying an other 
party-developed Predictive DSI as part of its Health IT Module,\143\ 
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

[[Page 1278]]

policies, as well as enter into appropriate Business Associate \144\ 
Agreements (BAAs).\145\ 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.\146\ Under the HIPAA Security 
Rule, business associates have an independent obligation to identify 
and manage risks, regardless of whether or not a BAA exists.\147\ 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.
---------------------------------------------------------------------------

    \142\ U.S. Department of Health and Human Services, Office for 
Civil Rights (OCR), Guidance on HIPAA & Cloud Computing: https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html.
    \143\ As noted in HTI-1 Proposed Rule at 88 FR 23796, we note 
that these ``other parties'' may or may not have a contractual 
relationship with the developer of certified health IT.
    \144\ See definition of ``business associate'' at 45 CFR 
160.103. Business associates include a subcontractor that creates, 
receives, maintains, or transmits protected health information on 
behalf of the business associate.
    \145\ See 45 CFR 164.308(b) for information about the Security 
Rule's requirements for BAAs. 45 CFR 164.502(e) permits a covered 
entity to disclose PHI to a business associate and to allow a 
business associate to create, receive, maintain, or transmit PHI on 
its behalf, if the covered entity obtains satisfactory assurance 
that the business associate will appropriately safeguard the 
information. Additional guidance on BAAs, often referred to as 
business associate contracts, is available at https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html.
    \146\ The risk is based on the connection permitted to the 
certified health IT product by the health IT developer and not 
whether the developer has a direct or contractual relationship to 
the other party.
    \147\ Business associates are required to comply with the 
requirements of the HIPAA Security Rule. 45 CFR 164.302. See OCR's 
Direct Liability of Business Associates, https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/factsheet/index.html; OCR's Security Rule Guidance material, available at: 
https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html?language=es.
---------------------------------------------------------------------------

    After consideration of these comments, we have finalized at Sec.  
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 Sec.  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 Sec.  
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.\148\ Governance should encompass models, 
software and data developed or provided by other parties as well as 
internally developed interventions.\149\
---------------------------------------------------------------------------

    \148\ See, e.g., The Organisation for Economic Co-operation and 
Development (OECD), Recommendation of the Council on Health Data 
Governance, https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0433; General Accountability Office (GAO), AI: An 
Accountability Framework for Federal Agencies and Other Entities 
(June 2021), https://www.gao.gov/assets/gao-21-519sp.pdf; See 
generally GAO, Artificial Intelligence in Health Care: Benefits and 
Challenges of Technologies to Augment Patient Care, (Nov. 2020), 
https://www.gao.gov/products/gao-21-7sp.
    \149\ See NIST AI RMF 1.0, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf.
---------------------------------------------------------------------------

    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.\150\
---------------------------------------------------------------------------

    \150\ See for example Federal Data Strategy, Data Governance 
Playbook, https://resources.data.gov/assets/documents/fds-data-governance-playbook.pdf.
---------------------------------------------------------------------------

    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 Sec.  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.\151\ 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.\152\ 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.\153\ 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''.\154\
---------------------------------------------------------------------------

    \151\ NIST AI RMF. Govern, Section 6. Available at: https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern.
    \152\ Ibid. Transparency and Documentation.
    \153\ See Bd. Governors Fed. Rsrv. Sys., Off. of Comptroller of 
the Currency, Supervisory Guidance on Model Risk Management, SR 
Letter 11-7, (April 2011), https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm; Off. Comptroller Currency, 
Comptroller's Handbook: Model Risk Management (Aug. 2021), https://www.occ.gov/publications-and-resources/publications/comptrollers-handbook/files/model-risk-management/index-model-risk-management.html.
    \154\ Id.

---------------------------------------------------------------------------

[[Page 1279]]

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 Sec.  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 Sec.  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 Sec.  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
    <bullet> 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.
    <bullet> 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.
    <bullet> 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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  170.523(f)(1), we proposed a new 
Principle of Proper Conduct for IRM practice documentation in Sec.  
170.523(f)(1)(xxi) that ONC-ACBs report the information required in 
Sec.  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

[[Page 1280]]

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 Sec.  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 Sec.  170.523(f)(1)(xxi) requiring that ONC-
ACBs shall, where applicable, ensure that summary information of the 
IRM practices listed in paragraph Sec.  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.\155\
---------------------------------------------------------------------------

    \155\ Please visit the Program's Certified Health IT Product 
List (CHPL) for information about the Program's authoritative 
listing of all certified health IT that have been successfully 
tested and certified, available at https://chpl.healthit.gov/#/search.
---------------------------------------------------------------------------

xiii. Annual Review
    Finally, in the HTI-1 Proposed Rule at Sec.  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,\156\ 
which requires covered entities and business associates to conduct 
ongoing risk analysis,\157\ 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.
---------------------------------------------------------------------------

    \156\ 45 CFR part 160 and subparts A and C of part 164.
    \157\ 45 CFR. 164.306(e) and 164.316(b)(2)(iii); see also OCR 
Guidance on Risk Analysis, https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html 
(noting that ``in order for an entity to update and document its 
security measures `as needed,' which the HIPAA Security Rule 
requires, it should conduct continuous risk analysis to identity 
when updates are needed'').
---------------------------------------------------------------------------

    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 Sec.  170.402(b)(4) that developers with Health IT 
Modules certified to Sec.  170.315(b)(11), starting January 1, 2025 and 
on an ongoing basis thereafter review and update, as necessary, 
information in Sec.  170.315(b)(11)(v)(A) and (B), risk management 
practices described in Sec.  170.315(b)(11)(vi), and summary 
information provided through Sec.  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

[[Page 1281]]

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 Sec.  
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 Sec.  
170.315(b)(11)(vi), and summary information provided through Sec.  
170.523(f)(1)(xxi).
    As for the finalized requirement in Sec.  170.402(b)(4) to review 
and update source attribute information in Sec.  170.315(b)(11)(v)(A) 
and (B), we believe this is a clearer articulation of our intention 
proposed at Sec.  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 Sec.  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 Sec.  170.102 to identify that a Health IT Module can be 
certified to either Sec.  170.315(a)(9) or Sec.  170.315(b)(11) to 
satisfy the definition for the period up to and including December 31, 
2024. We also proposed that Sec.  170.315(a)(9) would no longer be 
included as part of the Base EHR definition after December 31, 2024. 
Rather, only Sec.  170.315(b)(11) and not Sec.  170.315(a)(9) will be 
available as a certification criterion to satisfy the definition of 
Base EHR beginning January 1, 2025.
    Additionally, in Sec.  170.315(a)(9)(vi) we proposed that the 
adoption of Sec.  170.315(a)(9) would expire on January 1, 2025, for 
purposes of the Program. Together, these proposals identified the dates 
when Sec.  170.315(b)(11) replaces Sec.  170.315(a)(9) in the Base EHR 
definition, and they indicated when Health IT Modules certified to 
Sec.  170.315(a)(9) will need to be certified to Sec.  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 Sec.  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 Sec.  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 Sec.  170.102 to identify 
the dates when Sec.  170.315(b)(11) replaces Sec.  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 Sec.  170.315(a)(9) as part of the Base EHR definition 
in Sec.  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 
Sec.  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 Sec.  170.315(b)(11). We also note for purposes of the 
Program that the certification criterion at Sec.  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 Sec.  170.405(a) to 
include Sec.  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 Sec.  170.315(a)(9) would be subject to 
the requirements set forth in Sec.  170.405(a) (88 FR 23808). We noted 
that the effects of including Health IT Modules certified to Sec.  
170.315(a)(9) in Sec.  170.405(a) and the effect of proposing a revised 
version of the CDS criterion in Sec.  170.315(b)(11) would require 
developers of certified health IT certified to Sec.  170.315(a)(9) and 
Sec.  170.315(b)(11) to follow the testing plans, methods, and results 
reporting; submission dates; and August 31 deployment deadline 
requirements in Sec.  170.405(b) similar to the requirements of other 
applicable certification criteria listed in Sec.  170.405(a) (88 FR 
23809). We anticipated that if finalized as proposed this would mean 
that Health IT Modules certified to Sec.  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 Sec.  170.315(a)(9) to the list of applicable 
certification criteria for the real world testing Condition and 
Maintenance of Certification requirement in Sec.  170.405(a) and thus 
requiring developers certified to Sec.  170.315(a)(9) or Sec.  
170.315(b)(11) to participate in real world testing plan and results 
submission. Commenters that did not support including Sec.  
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 
Sec.  170.315(b)(11). Commenters suggested that by only including Sec.  
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

[[Page 1282]]

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 Sec.  
170.315(a)(9), thus requiring developers certified to Sec.  
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 
Sec.  170.405(a) to include Sec.  170.315(a)(9). Given the mixed 
support from commenters and finalization of our policy to replace Sec.  
170.315(a)(9) with Sec.  170.315(b)(11) as of January 1, 2025, we have 
not finalized our proposal to modify Sec.  170.405(a) to include Health 
IT Modules certified to Sec.  170.315(a)(9). We agree with commenters 
that requiring developers of certified health IT with Health IT Modules 
certified to Sec.  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 Sec.  
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 Sec.  170.315(b)(11) and Sec.  
170.402(b)(4) by January 1, 2025.
    We note that because all criteria in Sec.  170.315(b) are already 
subject to real world testing requirements in Sec.  170.405, Health IT 
Modules certified to Sec.  170.315(b)(11) prior to August 31, 2024, 
would need to, among other requirements, address each of the elements 
in Sec.  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 
Sec.  170.315(a)(9) or Sec.  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 Sec.  170.315(a)(9) 
in real world testing, with the proposed updates, but only if ONC would 
keep Sec.  170.315(a)(9) as a certification criterion and add Sec.  
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 Sec.  170.405(a) to include Health IT Modules 
certified to Sec.  170.315(a)(9). We note that certification criteria 
at Sec.  170.315(b) are already subject to real world testing 
requirements identified in Sec.  170.405; thus, Health IT Modules 
certified to Sec.  170.315(b)(11) will be subject to the same 
requirements currently applied to Health IT Modules certified to Sec.  
170.315(b)(1), for example. We believe real world testing would not be 
overly burdensome with the implementation of the DSI requirements under 
Sec.  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 Sec.  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 Sec.  170.210(g), or 
cross-reference a provision that references Sec.  170.210(g), include 
Sec.  170.315(d)(2), Sec.  170.315(d)(3), Sec.  170.315(d)(10), and 
Sec.  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

[[Page 1283]]

associations, uniformly agreed with our proposal to remove the named 
standard in Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  170.215 as proposed. This 
restructuring will impact cross-references in the certification 
criterion at Sec.  170.315(g)(10) in several subparagraphs, including 
Sec.  170.315(g)(10)(i)(A) and (B); Sec.  170.315(g)(10)(ii); Sec.  
170.315(g)(10)(iv)(A) and (B); Sec.  170.315(g)(10)(v)(A)(1)(i) and 
(ii); Sec.  170.315(g)(10)(v)(A)(2)(i) and (ii); Sec.  
170.315(g)(10)(v)(B); and Sec.  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 Sec.  170.315(g)(10)(v)(A), would apply to ``native 
applications.'' \158\ 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 Sec.  170.315(g)(10)(v)(A)(1)(ii) and 
Sec.  170.315(g)(10)(v)(A)(2)(ii), as well as to revise Sec.  
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 Sec.  
170.215(c)'' (88 FR 23813). We also proposed to revise Sec.  
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 
Sec.  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 Sec.  170.315(g)(10)(v)(A)(1)(iii), 
remained unchanged.
---------------------------------------------------------------------------

    \158\ According to IETF RFC 6749, ``native applications are 
``clients installed and executed on the device used by the resource 
owner (i.e., desktop application, native mobile application).'' 
See[thinsp]IETF RFC 6749: https://tools.ietf.org/html/rfc6749.
---------------------------------------------------------------------------

    We also stated in the HTI-1 Proposed Rule that we would continue to 
monitor implementation of Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  170.315(g)(10) must issue refresh tokens 
valid for a period of no less than three months.\159\ 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 Sec.  
170.315(g)(10). Specifically, at Sec.  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

[[Page 1284]]

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

    \159\ See Sec.  170.315(g)(10)(v)(A)(1)(ii), (iii), and (2)(ii) 
in 85 FR 70083.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  170.315(g)(10)-certified Health IT 
Modules are not prohibited from implementing their Sec.  
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 Sec.  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 Sec.  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 Sec.  170.215(b)(1)(ii) 
and incorporate it by reference in Sec.  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 Sec.  170.215(a)(2) in Sec.  
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 Sec.  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 Sec.  
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 Sec.  170.215(b)(1)(ii).
    Comments. Commenters overwhelmingly supported our proposal to 
advance the version of the FHIR US Core IG included in Sec.  170.215 
and incorporated by reference in Sec.  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

[[Page 1285]]

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 Sec.  
170.215 and incorporated it by reference in Sec.  170.299. We have also 
finalized our proposal to restructure the standards in Sec.  170.215 
and adopted the FHIR US Core 6.1.0 at Sec.  170.215(b)(1)(ii). 
Likewise, we have finalized our proposal to categorize the FHIR US Core 
IG v3.1.1 in Sec.  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 Sec.  
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 Sec.  
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,\160\ a primary objective within the Federal Health IT 
Strategic Plan.\161\
---------------------------------------------------------------------------

    \160\ https://www.healthit.gov/buzz-blog/healthit-certification/shining-a-light-on-fhir-implementation-progress-toward-publishing-fhir-endpoints.
    \161\ See objective 1b in the 2020-2025 Federal Health IT 
Strategic Plan at https://www.healthit.gov/topic/2020-2025-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.\162\ 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.
---------------------------------------------------------------------------

    \162\ https://www.healthit.gov/news/events/onc-lantern-workshop.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  170.404(b)(2), we also proposed to incorporate the 
following existing requirements in Sec.  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 
Sec.  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 
Sec.  170.404(b)(2). We proposed that Certified API Developers publish 
these standardized details by December 31, 2024.
    In Sec.  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 Sec.  170.215(a) (88 FR 23814). Additionally, 
in Sec.  170.404(b)(2)(ii) and subparagraphs Sec.  170.404(b)(2)(ii)(A) 
and Sec.  170.404(b)(2)(ii)(B), we proposed to require that 
organization details such as name, location, and provider identifiers

[[Page 1286]]

(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 Sec.  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 Sec.  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 Sec.  
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.'' \163\ 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.
---------------------------------------------------------------------------

    \163\ https://hl7.org/fhir/R4/endpoint.html.
---------------------------------------------------------------------------

    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.'' \164\ To 
standardize a link between published ``Endpoint'' resources and 
organization details relating to the organization that services these 
endpoints, we proposed to require, in Sec.  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.
---------------------------------------------------------------------------

    \164\ https://www.hl7.org/fhir/organization.html.
---------------------------------------------------------------------------

    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 Sec.  
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 Sec.  170.404(b)(2)(iii), requirements for 
collection and maintenance of Endpoint and organization resources. 
Specifically, in Sec.  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 Sec.  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.\165\ 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.'' \166\ 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 Sec.  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.
---------------------------------------------------------------------------

    \165\ http://hl7.org/fhir/R4/bundle.html.
    \166\ http://ndjson.org/.
---------------------------------------------------------------------------

    We also proposed, in Sec.  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 Sec.  170.315(g)(10) criterion will only meet initial certification 
requirements, and we proposed to establish in Sec.  
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

[[Page 1287]]

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.\167\ Additionally, at the September 
2023 HL7 Working Group Meeting, the FHIR community discussed and 
finalized new changes to the Patient-access Brands model.\168\ 
Currently, the Patient-access Brands model is incorporated into a 
section of the continuous build draft version of the SMART App Launch 
IG.\169\ 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.
---------------------------------------------------------------------------

    \167\ More information on this connectathon can be found at 
https://confluence.hl7.org/pages/viewpage.action?pageId=90350859#EndpointCallNotes-2023-5-312-5pET:Connectathon.
    \168\ See https://jira.hl7.org/browse/FHIR-42134.
    \169\ https://build.fhir.org/ig/HL7/smart-app-launch/branches/pab/brands.html.
---------------------------------------------------------------------------

    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.\170\ 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.
---------------------------------------------------------------------------

    \170\ During the public comment period for the HTI-1 Proposed 
Rule, the draft Patient-access Brands specification called for the 
use of the ``managiningOrganization'' element in the ``Endpoint'' 
resource for linking ``Endpoint'' and ``Organization'' resources. At 
the September 2023 HL7 Working Group Meeting, occurring after the 
comment period for the HTI-1 Proposed Rule closed, the FHIR 
community approved a change to use the ``endpoint'' element in the 
``Organization'' resource instead of the ``managiningOrganization'' 
element in the ``Endpoint'' resource for linking ``Endpoint'' and 
``Organization'' resources. See https://jira.hl7.org/browse/FHIR-42134.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  170.404(b)(2). We have modified the 
standard referenced in Sec.  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 Sec.  170.404(b)(2)(ii) to reference the 
standard adopted in Sec. [thinsp]170.215(a). We emphasize that 
subparagraphs of finalized Sec.  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 Sec.  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 Sec.  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

[[Page 1288]]

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. 
\171\ 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 Sec.  
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.
---------------------------------------------------------------------------

    \171\ https://rce.sequoiaproject.org/RCEIG/output/index.html.
---------------------------------------------------------------------------

    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 
Sec.  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 Sec.  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 Sec.  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 Sec.  170.404(b)(2)(ii) (see response to 
comments above), US Core is no longer in scope. We have modified the 
standard referenced in Sec.  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 Sec.  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

[[Page 1289]]

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.\172\ We 
believe that our finalized requirement for publication using the FHIR 
Bundle resource format sufficiently supports app developers and aligns 
with industry direction.
---------------------------------------------------------------------------

    \172\ https://build.fhir.org/ig/HL7/smart-app-launch/branches/pab/brands.html.
---------------------------------------------------------------------------

    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.'' \173\ 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.
---------------------------------------------------------------------------

    \173\ https://lantern.healthit.gov/?tab=dashboard_tab.
---------------------------------------------------------------------------

    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 
Sec.  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.\174\
---------------------------------------------------------------------------

    \174\ https://www.healthit.gov/topic/certified-health-it-complaint-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.\175\ 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.
---------------------------------------------------------------------------

    \175\ https://lantern.healthit.gov/?tab=about_tab.
---------------------------------------------------------------------------

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

[[Page 1290]]

this criterion on service base URLs and related organization details 
for Health IT Modules certified to Sec.  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 
Sec.  170.315(g)(10)(vi) that for Health IT Modules certified to Sec.  
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 
Sec.  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 Sec.  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,\176\ 
IETF RFC 7009,\177\ 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.
---------------------------------------------------------------------------

    \176\ Available at: https://www.rfc-editor.org/pdfrfc/rfc6819.txt.pdf.
    \177\ Available at: https://www.rfc-editor.org/pdfrfc/rfc7009.txt.pdf.
---------------------------------------------------------------------------

    Comments. The majority of commenters supported our proposal to 
revise Sec.  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 Sec.  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 Sec.  
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

[[Page 1291]]

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 Sec.  171.204 (85 FR 25866-25875), and our discussion of 
the Infeasibility Exception and its responding to requests condition 
(Sec.  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 Sec.  
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 Sec.  
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 Sec.  
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 Sec.  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 Sec.  170.215(a)(3) to enable apps to securely perform 
authentication and authorization with the Health IT Module in a 
standardized manner. Additionally, the Sec.  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 Sec.  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 Sec.  
170.215(a)(3), Health IT Modules presented for testing and 
certification to Sec.  170.315(g)(10), via cross-references to Sec.  
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 Sec.  170.213 and 
implementation specification adopted in Sec.  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.\178\ 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 Sec.  
170.215(c)(2), and we proposed that the adoption of the SMART v1 Guide 
in Sec.  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 Sec.  170.215(c) until the expiration date of 
January 1, 2025, after which time only the SMART v2 Guide will be 
available for certification.
---------------------------------------------------------------------------

    \178\ https://hl7.org/fhir/smart-app-launch/STU2/index.html.
---------------------------------------------------------------------------

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

[[Page 1292]]

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 Sec.  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 Sec.  170.315(g)(10) criterion, 
respectively at Sec.  170.315(g)(10)(i)(A), Sec.  
170.315(g)(10)(ii)(A), Sec.  170.315(g)(10)(iii), Sec.  
170.315(g)(10)(iv)(A), Sec.  170.315(g)(10)(v)(A), and Sec.  
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 Sec.  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.\179\ 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.
---------------------------------------------------------------------------

    \179\ https://www.oauth.com/oauth2-servers/pkce/.
---------------------------------------------------------------------------

    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,\180\ 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.
---------------------------------------------------------------------------

    \180\ See IETF RFC 7636 at: https://www.rfc-editor.org/rfc/rfc7636.
---------------------------------------------------------------------------

    Support for PKCE is important because PKCE makes health app access

[[Page 1293]]

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 Sec.  
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 Sec.  
170.315(g)(10) certification criterion only requires health IT 
developers to support ``read'' capabilities according to the standard 
and implementation specifications adopted in Sec.  170.215(a) and in 
Sec.  170.215(b)(1), including the mandatory capabilities described in 
``US Core Server Capability Statement.'' Our proposal aligns with this 
existing policy for Sec.  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 Sec.  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 Sec.  
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 Sec.  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 Sec.  
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

[[Page 1294]]

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 Sec.  
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 Sec.  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 Sec.  &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 Sec.  
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 Sec.  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

[[Page 1295]]

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 
Sec.  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 (Sec.  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 \181\ 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.
---------------------------------------------------------------------------

    \181\ https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project.
---------------------------------------------------------------------------

    We outline our proposals as discussed in the HTI-1 Proposed Rule to 
modify the ``Demographics'' certification criterion (Sec.  
170.315(a)(5)) (88 FR 23820):
    We proposed to rename Sec.  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 
Sec.  170.315(a)(5)(i)(F), ``Name to Use'' in Sec.  
170.315(a)(5)(i)(G), and ``Pronouns'' in Sec.  170.315(a)(5)(i)(H) to 
the ``patient demographics and observations'' certification criterion 
(Sec.  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 Sec.  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 
Sec.  170.315(a)(5)(i)(C), which are represented by HL7[reg] Value Sets 
for Administrative Gender and NullFlavor in Sec.  170.207(n)(1). We 
proposed to ultimately replace Sec.  170.207(n)(1) with the SNOMED 
CT[reg] U.S. Edition code set proposed in Sec.  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 Sec.  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[reg] U.S. Edition by 
January 1, 2026. By having Sec.  170.207(n)(1) expire at the end of 
2025 and adding Sec.  170.207(n)(2) as a requirement for Health IT 
Modules certified to Sec.  170.315(a)(5) beginning January 1, 2026, we 
proposed to enable health IT developers to specify any appropriate 
value from the SNOMED CT[reg] U.S. Edition code set with the standard 
specified in Sec.  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[reg] codes specified in Sec.  170.207(c)(1).
    Additionally, we proposed to replace the terminology standards 
specified for Sexual Orientation in Sec.  170.315(a)(5)(i)(D), and 
Gender Identity in Sec.  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 
Sec.  170.315(a)(5)(i)(D), and Gender Identity in Sec.  
170.315(a)(5)I(E), which are represented by SNOMED CT[reg] U.S. Edition 
and HL7[reg] Value Set for NullFlavor in Sec.  170.207(o)(1) and (2), 
and ultimately replace it with the SNOMED CT[reg] U.S. Edition code set 
specified in Sec.  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 Sec.  170.207(o)(1) 
and (o)(2). This allows the use of either the value sets in Sec.  
170.207(o)(1) and (o)(2) or the standard proposed in Sec.  
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 Sec.  
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 Sec.  
170.207(o)(1) or (o)(2) would have to update those Health IT Modules to 
Sec.  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 Sec.  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[reg] terminology 
code set standard specified in proposed Sec.  170.207(n)(3).

[[Page 1296]]

    We proposed to add new data elements Name to Use in Sec.  
170.315(a)(5)(i)(G) and Pronouns in Sec.  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[reg] terminology code set standard specified in 
proposed Sec.  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 Sec.  
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 Sec.  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 Sec.  
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 Sec.  
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.

[[Page 1297]]

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

[[Page 1298]]

criterion in Sec.  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 Sec.  170.213.
Base EHR Definition
    We proposed to revise and update the ``demographics'' certification 
criterion (Sec.  170.315(a)(5)), to rename as ``patient demographics 
and observations,'' and which is included in the Base EHR definition in 
Sec.  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 Sec.  
170.315(g)(8) in Sec.  170.102 Base EHR Definition (3)(ii) and 
replacing the references to Sec.  170.315(g)(10) in Sec.  170.102 Base 
EHR Definition (3)(ii) and (iii) with a single reference to Sec.  
170.315(g)(10) in Sec.  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 Sec.  
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 Sec.  170.207(n)(2) (88 FR 23821). We proposed 
that health IT developers can continue using the specific codes for Sex 
represented in Sec.  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 Sec.  170.207(n), including 
the expiration of the adoption of the standard in Sec.  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 Sec.  170.207(n)(1) would have to update those 
Health IT Modules to Sec.  170.207(n)(2) and provide them to customers 
by January 1, 2026. We note that, in the proposed rule regulation text 
in Sec.  170.315(b)(1)(iii)(G)(3), we inadvertently included a 
reference to Sec.  170.213 (88 FR 23909) instead of including Sec.  
170.207(n)(2) as discussed in our proposal (88 FR 23821). ONC has not 
finalized Sec.  170.213 as proposed in Sec.  170.315(b)(1)(iii)(G)(3), 
as Sec.  170.213 references a version of SNOMED CT U.S. Edition that is 
older than the one referenced in Sec.  170.207(n)(2). We have finalized 
the reference to Sec.  170.207(n)(2) in Sec.  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 Sec.  170.315(b)(1) to 
update the listed minimum standard code sets for Problems in Sec.  
170.315(b)(1)(iii)(B)(2) (88 FR 23821). We proposed that Health IT 
Modules certified to Sec.  170.315(b)(1) use, at a minimum, the version 
of the standard specified in Sec.  170.207(a)(1).
    Comments. All commenters agreed with the proposal to update the 
transitions of care certification criterion Sec.  
170.315(b)(1)(iii)(G)(3) to include the adoption of USCDI v3 in Sec.  
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 Sec.  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 Sec.  170.315(d)(14), 
an addition to ONC's Privacy and Security Framework under the Program 
in Sec.  170.550(h), and a revision to an existing ``view, download, 
and transmit to 3rd party'' certification criterion in Sec.  
170.315(e)(1) to support additional tools for implementing patient 
requested privacy restrictions (88 FR 23822 through 23824).

[[Page 1299]]

    We proposed to adopt a new certification criterion ``patient 
requested restrictions'' in Sec.  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 Sec.  
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 Sec.  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 Sec.  170.315(d)(14) for this 
new criterion ``patient requested restrictions'':
    <bullet> For any data expressed in the standards in Sec.  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
    <bullet> 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 Sec.  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 Sec.  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.\182\ 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.
---------------------------------------------------------------------------

    \182\ For example, the USCDI v3 includes a provenance data class 
(https://www.healthit.gov/isa/uscdi-data-class/provenance#uscdi-v3) 
and submissions in ISA include digital signature as a potential 
addition to provenance within the USCDI: https://www.healthit.gov/isa/uscdi-data/signature. Further specifications for provenance data 
and digital signatures in the context of FHIR-based transactions are 
also referenced in ISA: https://www.healthit.gov/isa/representing-data-provenance.
---------------------------------------------------------------------------

    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 Sec.  
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 
Sec.  170.550(h) to add the proposed new criterion. Specifically, we 
proposed to modify Sec.  170.550(h)(iii) in reference to the certain of 
``care coordination'' certification criteria in Sec.  170.315(b); Sec.  
170.550(h)(v) in reference to the ``view, download, and transmit to 3rd 
party'' certification criterion in Sec.  170.315(e)(1); and to Sec.  
170.550(h)(viii) in reference to the Sec.  ``application access'' 
certification criteria at Sec.  170.315(g)(7) through (g)(9) and the 
``standardized API for patient and population services'' certification 
criterion at Sec.  170.315(g)(10).
    We proposed that the new ``patient requested restrictions'' 
certification criterion in Sec.  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 Sec.  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 Sec.  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 Sec.  
170.213. Specifically, we proposed to modify Sec.  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 Sec.  170.213.
    We proposed that conformance with this update to the ``view, 
download, and transmit to 3rd party'' certification criterion in Sec.  
170.315(e)(1)(iii) would be required by January 1, 2026, for Health IT 
Modules certified to Sec.  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 Sec.  
170.315(e)(1) would have to update those Health IT Modules to Sec.  
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 Sec.  170.315(b)(7) and Sec.  
170.315(b)(8) respectively; however, we noted that the inclusion of the 
proposed new certification criterion in Sec.  170.315(d)(14) into the 
Privacy and Security Framework in Sec.  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 Sec.  
164.522(a)(1)(iii) and (iv) or termination of a restriction under Sec.  
164.522(a)(2).

[[Page 1300]]

    We sought public comment on each part of this proposal--the new 
criterion in Sec.  170.315(d)(14), the inclusion of the request 
capability for patients in Sec.  170.315(e)(1), and the requirements 
with the Privacy and Security Framework in Sec.  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 Sec.  170.550(h).
    In addition, we sought comment on any unintended consequences that 
the new criterion in Sec.  170.315(d)(14) or the addition to the 
Privacy and Security Framework in Sec.  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 Sec.  
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 Sec.  170.315(d)(14), the 
new functionality in the existing criterion in Sec.  170.315(e)(1), and 
the addition to the Privacy and Security Framework in Sec.  170.550(h).
    Comments. Overall, in response to our new proposal for Patient 
Requested Restrictions Criterion in Sec.  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 Sec.  
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 Sec.  170.315(d)(14) should be optional and that adoption 
of the criterion within the privacy and security framework in Sec.  
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 Sec.  170.315(d)(14). One commenter also

[[Page 1301]]

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 Sec.  170.315(d)(14) and the 
inclusion of the criterion in the privacy and security framework in 
Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  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 Sec.  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 Sec.  
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 
Sec.  170.315(b)(7) and Sec.  170.315(b)(8) which support the 
application and persistence of security labels for document-based 
exchange and reference the standards adopted in Sec.  170.205(o)(1), 
the HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), 
Release 1 (HL7 CDA DS4P IG) incorporated by reference in Sec.  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 Sec.  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 Sec.  
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 Sec.  170.315(b)(7) and Sec.  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

[[Page 1302]]

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 Sec.  170.315(e)(1), to add Sec.  
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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  170.315(e)(1) would not, by itself, fully 
discharge a covered entity's obligations

[[Page 1303]]

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

[[Page 1304]]

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.\183\ 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.
---------------------------------------------------------------------------

    \183\ ONC website: HealthIT.gov ``Information Blocking''. 
https://www.healthit.gov/topic/information-blocking.
---------------------------------------------------------------------------

    Finally, we appreciate commenters' suggestions about ONC's role in 
educating patients about health IT capabilities and standards as they 
relate

[[Page 1305]]

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 Sec.  170.315(e)(1) 
within the context of the implementation burden for that proposed 
revision and the proposed new criterion in Sec.  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 Sec.  
170.315(e)(1) in addition to the proposed new criterion in Sec.  
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 Sec.  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 Sec.  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 Sec.  170.315(d)(14) nor 
the corresponding changes to Sec.  170.550(h). We have only finalized 
the revisions to the criterion in Sec.  170.315(e)(1). We believe that 
the reduced scope of the changes we have finalized--focusing on the 
revised criterion in Sec.  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 Sec.  
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 Sec.  
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 Sec.  170.315(e)(1) 
described in this section. We have finalized that these revisions to 
the criterion in Sec.  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 Sec.  
170.315(e)(1) as proposed, with the specific revision in Sec.  
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 Sec.  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 Sec.  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 Sec.  170.315 
(88 FR 23827). We proposed that health IT developers with health IT 
certified to any of the certification criteria in Sec.  170.315 would 
need to update their previously certified Health IT Modules to be 
compliant with any revised certification criterion adopted in Sec.  
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

[[Page 1306]]

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.\184\ 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.
---------------------------------------------------------------------------

    \184\ See ONC Achieving a Major Milestone: Health IT Developers 
Certify to Cures Update https://www.healthit.gov/buzz-blog/health-it/achieving-a-major-milestone-health-it-developers-certify-to-cures-update.
---------------------------------------------------------------------------

    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 Sec.  171.102, which stated that ``Provide is defined as 
it is in Sec.  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 
Sec.  171.102.
    We have finalized in Sec.  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

[[Page 1307]]

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),\185\ 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.
---------------------------------------------------------------------------

    \185\ ONC Certified Health IT Product List: https://chpl.healthit.gov.
---------------------------------------------------------------------------

    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 Sec. Sec.  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 Sec.  170.102, and updates to 
applicable health IT certification criteria in Sec.  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 Sec.  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 Sec.  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 Sec.  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

[[Page 1308]]

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 Sec.  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 Sec.  170.102, and 
updates to applicable health IT certification criteria in Sec.  
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

[[Page 1309]]

program participants within CMS proposed or final rules (see, for 
example, 85 FR 84818-84828).
2. Maintenance of Certification Requirements
    We proposed, in Sec.  170.402(b)(3)(i), that a health IT developer 
must update a Health IT Module, once certified to a certification 
criterion adopted in Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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

[[Page 1310]]

``[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 Sec.  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'' (Sec.  170.402(b)(3)(iii)(A)). This 
means that the compliance dates included in the certification criteria 
in Sec.  170.315 and standards in subpart B will establish when health 
IT developers need to comply with these Maintenance of Certification 
requirements. In Sec.  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 Sec.  
170.405(b), as proposed at 88 FR 23830, in that we removed most of the 
``update and provide'' requirements currently found in Sec.  
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 Sec.  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 Sec.  
170.405(a) that a health IT developer with Health IT Module(s) 
certified to Sec.  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 Sec.  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 
Sec.  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 (Sec.  
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.\186\ 
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.
---------------------------------------------------------------------------

    \186\ https://www.healthit.gov/sites/default/files/policy/public_applicability_of_gap_certification_and_inherited_certified_status.pdf.
---------------------------------------------------------------------------

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

[[Page 1311]]

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.\187\ Currently, 
certification criteria identified in Sec.  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 (Sec.  170.315(b), (c)(1) through (3), (e)(1), (f), 
(g)(7) through (10), and (h)).\188\ 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 Sec.  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.
---------------------------------------------------------------------------

    \187\ See Real World Testing Resource Guide and other resources 
at: https://www.healthit.gov/topic/certification-ehrs/real-world-testing.
    \188\ Please see the Real World Testing Fact Sheet, page 3, for 
a list of certification criteria at: https://www.healthit.gov/sites/default/files/page/2021-02/Real-World-Testing-Fact-Sheet.pdf#page=3.
---------------------------------------------------------------------------

    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 Sec.  170.405. Congress required 
the real world testing of certified health IT for interoperability in 
the Cures Act (PHSA Sec.  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.\189\ 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.\190\ 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.
---------------------------------------------------------------------------

    \189\ https://chpl.healthit.gov/#/collections/real-world-testing.
    \190\ See Real World Testing Resource Guide and other resources 
at: https://www.healthit.gov/topic/certification-ehrs/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.

[[Page 1312]]

    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.\191\
---------------------------------------------------------------------------

    \191\ Urban Institute. See https://www.urban.org/policy-centers/health-policy-center/projects/ehr-reporting-program.
---------------------------------------------------------------------------

    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)).<SUP>192 193</SUP> 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.
---------------------------------------------------------------------------

    \192\ https://ecqi.healthit.gov/.
    \193\ https://mmshub.cms.gov/get-involved/public-comments/overview.
---------------------------------------------------------------------------

    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

[[Page 1313]]

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

[[Page 1314]]

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 (Sec.  170.315(e)(1)), or the 
``standardized API for patient and population services'' certification 
criterion (Sec.  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 Sec.  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 Sec.  170.315(g)(10); (2) 
patient portal using technology certified to the ``view, download, and 
transmit to 3rd party'' certification criterion under Sec.  
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 Sec.  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 Sec.  170.315(g)(10) criterion; and (2) a measure applicable to 
Health IT Modules certified to the Sec.  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 Sec.  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 Sec.  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 Sec.  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

[[Page 1315]]

(Sec.  170.315(g)(10) or Sec.  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 Sec.  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 Sec.  
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.\194\ 
The finalized measure only counts individuals.
---------------------------------------------------------------------------

    \194\ CMS. 2022 MEDICARE PROMOTING INTEROPERABILITY PROGRAM FOR 
ELIGIBLE HOSPITALS AND CRITICAL ACCESS HOSPITALS. Provider to 
Patient Exchange Objective Fact Sheet https://www.cms.gov/files/document/2022-provider-patient-exchange-objective-fact-sheet.pdf.
---------------------------------------------------------------------------

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

[[Page 1316]]

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 Sec.  
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,\195\ we would expect a health IT developer using 
relied upon software in its Health IT Module to meet the certification 
requirement associated with Sec.  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.
---------------------------------------------------------------------------

    \195\ ONC Health IT Certification Program. Real World Testing 
Guide. (Last updated: May 23, 2023). See p. 18. https://www.healthit.gov/sites/default/files/page/2021-08/ONC-Real%20World%20Testing%20Resource%20Guide_Aug%202021.pdf.
---------------------------------------------------------------------------

Finalization of Measure
    We have finalized the measure as ``individuals' access to 
electronic health information through certified health IT'' in Sec.  
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 Sec.  
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 Sec.  
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 Sec.  170.315(g)(10) or 
patient portals using technology certified to the ``view, download, and 
transmit to 3rd party'' certification criterion under Sec.  
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 Sec.  
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

[[Page 1317]]

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 
Sec.  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 Sec.  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 Sec.  170.407(a)(3), which would 
capture the number of C-CDA documents that are reconciled and 
incorporated (as defined in Sec.  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 Sec.  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 Sec.  170.315(b)(2).
    We proposed (88 FR 23836) the denominators for this measure, using

[[Page 1318]]

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.''\196\ 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

[[Page 1319]]

C-CDAs containing identical information would not be counted as a 
duplicate if they have different document IDs.
---------------------------------------------------------------------------

    \196\ ONC Health IT Certification Program Insights Condition: 
Consolidated Clinical Document Architecture (C-CDA) Medications, 
Allergies, and Problems Reconciliation and Incorporation Using 
Certified Health IT https://www.healthit.gov/sites/default/files/2023-04/3.Measure_Spec_CCDA_Reconcile_1.3.pdf.
---------------------------------------------------------------------------

    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.\197\ 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.
---------------------------------------------------------------------------

    \197\ HITAC recommendation: HTI-1-PR-TF-2023_Recommendation 33 
in Recommendations on the Health Data, Technology, and 
Interoperability: Certification Program Updates, Algorithm 
Transparency, and Information Sharing (HTI1) Proposed Rule https://www.healthit.gov/sites/default/files/page/2023-06/2023-06-15_HTI-1-PR-TF-2023_Recommendations_Report_Final_508.pdf.
---------------------------------------------------------------------------

    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.\198\ 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.
---------------------------------------------------------------------------

    \198\ ONC Health IT Certification Program Insights Condition: 
Consolidated Clinical Document Architecture (C-CDA) Medications, 
Allergies, and Problems Reconciliation and Incorporation Using 
Certified Health IT https://www.healthit.gov/sites/default/files/2023-04/3.Measure_Spec_CCDA_Reconcile_1.3.pdf.
---------------------------------------------------------------------------

    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:
    <bullet> ``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.
    <bullet> ``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

[[Page 1320]]

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.
    <bullet> ``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.
    <bullet> ``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.
    <bullet> 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.
    <bullet> 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

[[Page 1321]]

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'' (Sec.  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 Sec.  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'' (Sec.  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

[[Page 1322]]

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'' (Sec.  
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 Sec.  
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 Sec.  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

[[Page 1323]]

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 Sec.  
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'' (Sec.  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 Sec.  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 Sec.  
170.315(g)(10) criterion. We noted that the app registration process 
required under Sec.  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 Sec.  170.315(g)(10) obtain and report the 
intended purpose(s) for each app connected to their certified API 
technology using the following categories:
    <bullet> Administrative Tasks (e.g., scheduling & check-in, billing 
& payment)
    <bullet> Clinical Tools (e.g., clinical decision support, risk 
calculators, remote patient monitoring)
    <bullet> Individuals' Access to their EHI (e.g., enables patients 
to access their health information, medications, test results, vaccine 
records)
    <bullet> Research (e.g., used to perform clinical research)
    <bullet> Population Data (e.g., bulk transfer of data, population 
analytics & reporting)
    <bullet> Public Health (e.g., electronic case reporting)
    <bullet> Patient-Provider Communication (e.g., secure messaging, 
telehealth)
    <bullet> Educational Resources (e.g., patient and provider 
educational resources)
    <bullet> Other Intended Purpose
    <bullet> 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 Sec.  170.315(g)(10) criterion. The 
categories we proposed under this measure were informed by app category 
taxonomies in published literature from Barker &

[[Page 1324]]

Johnson (2021),\199\ Ritchie and Welch (2020),\200\ and Gordon and 
Rudin (2022).\201\ 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.
---------------------------------------------------------------------------

    \199\ The ecosystem of apps and software integrated with 
certified health information technology: https://academic.oup.com/jamia/article/28/11/2379/6364773?login=false.
    \200\ Categorization of Third-Party Apps in Electronic Health 
Record App Marketplaces: Systematic Search and Analysis: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7293052/.
    \201\ Gordon WJ, Rudin RS. Why APIs? Anticipated value, 
barriers, and opportunities for standards-based application 
programming interfaces in healthcare: perspectives of US thought 
leaders. JAMIA Open. 2022 Apr 6;5(2):ooac023. doi: 10.1093/
jamiaopen/ooac023. PMID: 35474716; PMCID: PMC9030107.
---------------------------------------------------------------------------

    Additionally, we proposed (88 FR 23838) that developers of 
certified health IT with Health IT Modules certified to Sec.  
170.315(g)(10) obtain the following intended user(s) categories for 
each app connected to their certified API technology:
    <bullet> Individual/Caregiver
    <bullet> Clinician
    <bullet> Healthcare Organization
    <bullet> Payer
    <bullet> Researcher
    <bullet> Other Intended User
    <bullet> Unknown (e.g., missing)
    We also proposed (88 FR 23838) that developers of certified health 
IT with Health IT Modules certified to Sec.  170.315(g)(10) obtain the 
status for each app connected to their certified API technology using 
the following categories:
    <bullet> 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
    <bullet> 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 Sec.  
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 (Sec.  
170.404(b)). Specifically, the requirements in Sec.  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 Sec.  
170.404(b)(1)(i) and consistent with Sec.  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 
Sec.  170.315(g)(10). Another commenter indicated that some Sec.  
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 Sec.  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

[[Page 1325]]

IT certified to Sec.  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 
Sec.  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 Sec.  
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 Sec.  
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 Sec.  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 (Sec.  
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 Sec.  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:

<bullet> Individual/Caregiver
<bullet> Clinical Team
<bullet> Healthcare Administrator/Executive
<bullet> Payer
<bullet> Researcher
<bullet> Other Intended User
<bullet> 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

[[Page 1326]]

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.\202\ An 
ONC internal analysis of the Google Play<SUP>TM</SUP> 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.\203\ 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.
---------------------------------------------------------------------------

    \202\ https://www.healthit.gov/sites/default/files/page/2020-11/Accelerating_APIs_Consumer_Perspective.pdf.
    \203\ https://www.mobius.md/2021/10/25/11-mobile-health-statistics/.
---------------------------------------------------------------------------

    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,\204\ Children's 
Online Privacy Protection Act (COPPA) \205\ and the COPPA Rule,\206\ 
and other industry initiatives \207\ supporting consumers in app 
privacy, security, and transparency.
---------------------------------------------------------------------------

    \204\ https://www.federalreserve.gov/boarddocs/supmanual/cch/200806/ftca.pdf.
    \205\ https://www.govinfo.gov/content/pkg/PLAW-105publ277/pdf/PLAW-105publ277.pdf.
    \206\ https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa.
    \207\ https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.
---------------------------------------------------------------------------

Finalization of Measure
    We have finalized the ``applications supported through certified 
health IT'' measure in Sec.  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 Sec.  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

[[Page 1327]]

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'' (Sec.  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 
Sec.  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 Sec.  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 Sec.  170.315(g)(10).
    Response. We appreciate the feedback on the burden associated with 
the

[[Page 1328]]

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 Sec.  170.315(g)(10). FHIR resources supported 
by and within the scope of the Sec.  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 Sec.  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

[[Page 1329]]

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 Sec.  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 Sec.  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:
    <bullet> Number of requests made to distinct certified health IT 
deployments that returned at least 1 FHIR resource by FHIR resource 
type.
    <bullet> 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).
    <bullet> 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):
    <bullet> 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 Sec.  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[supreg] 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'' (Sec.  
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

[[Page 1330]]

API for patient and population services'' (Sec.  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'' (Sec.  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 Sec.  
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,

[[Page 1331]]

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 
Sec.  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 Sec.  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 Sec.  
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'' (Sec.  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 Sec.  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''

[[Page 1332]]

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 
Sec.  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.\208\ Therefore, in Sec.  
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.
---------------------------------------------------------------------------

    \208\ Dixon BE, Rahurkar S, Apathy NC. Interoperability and 
health information exchange for public health. In Public health 
Informatics and information systems 2020 (pp. 307-324). Springer, 
Cham. https://doi-org.ezproxyhhs.nihlibrary.nih.gov/10.1007/978-3-030-41215-9_18.
---------------------------------------------------------------------------

    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'' (Sec.  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 
Sec.  170.407(a)(8) a public health exchange measure that would report 
on the volume of immunization administrations electronically submitted

[[Page 1333]]

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'' (Sec.  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 
Sec.  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 Sec.  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 Sec.  
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) \209\ 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.
---------------------------------------------------------------------------

    \209\ HL7 Version 2.5.1. Implementation Guide for Immunization 
Messaging. Release 1.5. October 1, 2014. https://www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide-1-5-2014-11.pdf.
---------------------------------------------------------------------------

    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'' 
(Sec.  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

[[Page 1334]]

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

[[Page 1335]]

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

[[Page 1336]]

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'' (Sec.  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 Sec.  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 Sec.  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

[[Page 1337]]

registries'' (Sec.  170.315(f)(1)) criterion. Therefore, we proposed 
(88 FR 23843) that developers of certified health IT with Health IT 
Modules certified to Sec.  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 Sec.  
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 Sec.  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

[[Page 1338]]

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'' (Sec.  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.

[[Page 1339]]

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'' (Sec.  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.\210\ 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.
---------------------------------------------------------------------------

    \210\ NVAC Standards for Adult Immunization Practice: https://www.cdc.gov/vaccines/hcp/adults/for-practice/standards/index.html.
---------------------------------------------------------------------------

Finalization of Measure
    We have finalized the measure as ``immunization history and 
forecasts through certified health IT'' in Sec.  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.<SUP>211 212</SUP> For inpatient codes, 
developers should use SNOMED CT codes 4525004, 183452005, 32485007, 
8715000, and 448951000124107.\213\ Listed below is a description of 
each SNOMED CT code:
---------------------------------------------------------------------------

    \211\ See: 2022 Quality Rating System Measure Technical 
Specifications. Published October 2021. https://www.cms.gov/files/document/2022-qrs-measure-technical-specifications.pdf.
    \212\ NCQA's Outpatient Value Set is available with a user ID 
and login at https://store.ncqa.org/my-2021-quality-rating-system-qrs-hedis-value-set-directory.html; or https://vsac.nlm.nih.gov/valueset/expansions?pr=all OID: 
2.16.840.1.113883.3.464.1003.101.12.1087.
    \213\ Available for search at https://www.findacode.com/index.html.

<bullet> Emergency department patient visit (procedure)--4525004
<bullet> Emergency hospital admission (procedure)--183452005
<bullet> Hospital admission (procedure)--32485007
<bullet> Hospital admission, elective (procedure)--8715000
<bullet> 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.\214\
---------------------------------------------------------------------------

    \214\ https://build.fhir.org/ig/HL7/US-Core/index.html.
---------------------------------------------------------------------------

    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

[[Page 1340]]

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.\215\ Developers of 
certified health IT have years of experience with those reporting 
efforts. Specifically, health IT certified to any criterion in Sec.  
170.315(c)(1) through (4) supports recording, importing, reporting or 
filtering CQMs, and health IT certified to Sec.  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 Sec.  170.315(g)(1) or 
(2) and the CQMs that they have presented for certification as part of 
certification to Sec.  170.315(c). For those developers that do not 
attest to any of the certification criteria at Sec.  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 
Sec.  170.315(b)(2), 281 are certified to at least one of the included 
criteria, with 232 certified to criterion in Sec.  170.315(c) and 260 
certified to Sec.  170.315(g)(1) or (g)(2).
---------------------------------------------------------------------------

    \215\ Medicare Promoting Interoperability Program Specification 
Sheets https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs/resource-library.
    eCQM Library https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/eCQM_Library.
---------------------------------------------------------------------------

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

[[Page 1341]]

    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:
    <bullet> 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.
    <bullet> 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.
    <bullet> 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'').
    <bullet> 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.
    <bullet> Reduced the frequency of measure reporting from semiannual 
to annual, and changed the submission date for more convenience to 
health IT developers.
    <bullet> 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.
    <bullet> 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.
    <bullet> 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.
    <bullet> 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.<SUP>216 217</SUP> 
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.
---------------------------------------------------------------------------

    \216\ 42 CFR 495.40(a)(2)(i)(H). Demonstration of meaningful use 
criteria. https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-G/part-495#p-495.40(a)(2)(i)(H).
    \217\ 42 CFR 414.1375(b)(3). Promoting Interoperability (PI) 
performance category. https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-B/part-414/subpart-O/section-414.1375.
---------------------------------------------------------------------------

    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

[[Page 1342]]

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.

                               Table 2--List of Insights Condition Measure Metrics
----------------------------------------------------------------------------------------------------------------
                                  Associated certification
         Measure title                    criteria                        Metrics                 Program year
----------------------------------------------------------------------------------------------------------------
Individuals' Access to           Sec.   170.315(g)(10).....  1. Number of unique individuals   Year 1.
 Electronic Health Information                                who accessed their EHI using
 Through Certified Health IT.                                 technology certified to
                                                              ``standardized API for patient
                                                              population services''
                                                              certification criterion under
                                                              Sec.   170.315(g)(10).
                                 Sec.   170.315(e)(1)......  2. Number of unique individuals   Year 1.
                                                              who accessed their EHI using
                                                              technology certified to the
                                                              ``view, download, and transmit
                                                              to 3rd party'' certification
                                                              criterion under Sec.
                                                              170.315(e)(1).
                                 Sec.   170.315(g)(10) or..  3. Number of unique individuals   Year 1.
                                 Sec.   170.315(e)(1)......   who accessed their EHI using
                                                              any method..
Consolidated Clinical Document   Sec.   170.315(b)(2)......  4. Number of encounters.........  Year 2.
 Architecture (C-CDA) Problems,
 Medications, and Allergies
 Reconciliation and
 Incorporation Through
 Certified Health IT.
                                                             5. Number of unique patients      Year 2.
                                                              with an encounter.
                                                             6. Number of unique patients      Year 2.
                                                              with an associated C-CDA
                                                              document.

[[Page 1343]]

 
                                                             7. Number of total C-CDA          Year 2.
                                                              documents obtained.
                                                             8. Number of unique C-CDA         Year 2.
                                                              documents obtained.
                                                             9. Number of total C-CDA          Year 2.
                                                              documents obtained that were
                                                              pre-processed.
                                                             10. Number of total C-CDA         Year 2.
                                                              documents obtained that were
                                                              not pre-processed.
                                                             11. Number of total C-CDA         Year 3.
                                                              documents obtained that were
                                                              pre-processed where problems,
                                                              medications, or allergies and
                                                              intolerances were reconciled
                                                              and incorporated via any method.
                                                             12. Number of total C-CDA         Year 3.
                                                              documents obtained that were
                                                              not pre-processed where
                                                              problems, medications, or
                                                              allergies and intolerances were
                                                              reconciled and incorporated via
                                                              any method.
                                                             13. Number of total C-CDA         Year 3.
                                                              documents obtained that were
                                                              determined to have no new
                                                              problems, medications, or
                                                              allergies and intolerances
                                                              information by pre-processes or
                                                              fully automated processes.
Applications Supported Through   Sec.   170.315(g)(10).....  14. Application name(s).........  Year 1.
 Certified Health IT.
                                                             15. Application developer         Year 1.
                                                              name(s).
                                                             16. Intended purpose(s) of        Year 1.
                                                              application.
                                                             17. Intended application user(s)  Year 1.
                                                             18. Application status..........  Year 1.
Use of FHIR in Apps Through      Sec.   170.315(g)(10).....  19. Number of distinct certified  Year 1.
 Certified Health IT.                                         health IT deployments (across
                                                              clients) active at any time
                                                              during the reporting period,
                                                              overall and by user type.
                                                             20. Number of requests made to    Year 1.
                                                              distinct certified health IT
                                                              deployments that returned at
                                                              least one FHIR resource by FHIR
                                                              resource type.
                                                             21. Number of distinct certified  Year 1.
                                                              health IT deployments (across
                                                              clients) associated with at
                                                              least one FHIR resource
                                                              returned overall and by user
                                                              type.
                                                             22. Number of distinct certified  Year 2.
                                                              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     Sec.   170.315(g)(10).....  23. Number of distinct certified  Year 2.
 Through Certified Health IT.                                 health IT deployments (across
                                                              clients) that completed at
                                                              least one bulk data access
                                                              request.
                                 Sec.   170.315(g)(10).....  24. Number of bulk data access    Year 2.
                                                              requests completed (across
                                                              clients) to export all data
                                                              requested for patients within a
                                                              specified group.
Immunization Administrations     Sec.   170.315(f)(1)......  25. Number of immunizations       Year 1
 Electronically Submitted to                                  administered overall.            (overall).
 Immunization Information
 Systems Through Certified
 Health IT.
                                 Sec.   170.315(f)(1)......  26. Number of immunizations       Year 2
                                                              administered overall, by IIS     (by IIS and age
                                                              and by age category.              category).
                                 Sec.   170.315(f)(1)......  27. Number of immunizations       Year 1
                                                              administered electronically      (overall).
                                                              submitted successfully to IISs
                                                              overall.
                                 Sec.   170.315(f)(1)......  28. Number of immunizations       Year 2
                                                              administered electronically      (by IIS and age
                                                              submitted successfully to IISs    category).
                                                              overall, by IIS and by age
                                                              category.
Immunization History and         Sec.   170.315(f)(1)......  29. Number of immunization        Year 2
 Forecasts Through Certified                                  queries sent to IISs overall.    (overall).
 Health IT.
                                 Sec.   170.315(f)(1)......  30. Number of immunization        Year 3
                                                              queries sent to IISs overall by  (by IIS).
                                                              IIS.
                                 Sec.   170.315(f)(1)......  31. Number of query responses     Year 2
                                                              received successfully from IISs  (overall).
                                                              overall.
                                 Sec.   170.315(f)(1)......  32. Number of query responses     Year 3
                                                              received successfully from IISs  (by IIS).
                                                              overall by IIS.
----------------------------------------------------------------------------------------------------------------

    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

[[Page 1344]]

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

[[Page 1345]]

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.\218\
---------------------------------------------------------------------------

    \218\ The Freedom of Information Act, 18 U.S.C. 1905, and the 
Uniform Trade Secrets Act, 18 U.S.C. Chapter 90, generally govern 
the disclosure and descriptions of these types of information.
---------------------------------------------------------------------------

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

[[Page 1346]]

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

[[Page 1347]]

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

[[Page 1348]]

    Based upon the suggestion we received via comments, we have 
finalized in Sec.  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 Sec.  
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 Sec.  
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 Sec.  
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 Sec.  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 Sec.  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.

[[Page 1349]]

    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 \219\ 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 \220\ 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.
---------------------------------------------------------------------------

    \219\ https://www.urban.org/research/publication/what-comparative-information-needed-ehr-reporting-program.
    \220\ https://www.healthit.gov/sites/default/files/page/2022-07/2021-09-09_EHRRP_TF_2021__HITAC%20Recommendations_Report_signed_508_Edit.pdf.

---------------------------------------------------------------------------

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

[[Page 1350]]

certification criterion.\221\ 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.
---------------------------------------------------------------------------

    \221\ For further information about implementing the NCPDP RTPB 
standard version 12, see resources at https://standards.ncpdp.org/Access-to-Standards.aspx.
---------------------------------------------------------------------------

    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 Sec.  
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 
Sec.  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 Sec.  
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 Sec.  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 (Sec.  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 (Sec.  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 
Sec.  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 (see 88 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

[[Page 1351]]

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 Sec.  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 (Sec.  171.202) and 
the Infeasibility Exception (Sec.  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 Sec.  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 (see 85 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

[[Page 1352]]

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.\222\
---------------------------------------------------------------------------

    \222\ https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/phi-reproductive-health/index.html.
---------------------------------------------------------------------------

    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 (Sec.  
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 Sec.  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 Sec.  
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'' \223\ 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:
---------------------------------------------------------------------------

    \223\ https://www.healthit.gov/buzz-blog/information-blocking/information-blocking-regulations-work-in-concert-with-hipaa-rules-and-other-privacy-laws-to-support-health-information-privacy. 
(Retrieved 7/12/2023.)
---------------------------------------------------------------------------

    <bullet> 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? \224\
---------------------------------------------------------------------------

    \224\ Information blocking FAQ identifier: IB.FAQ48.1.2023APR. 
URL: https://www.healthit.gov/faq/would-it-be-information-blocking-if-actor-does-not-fulfill-request-access-exchange-or-use-ehi. 
(Retrieved 7/12/2023.)
---------------------------------------------------------------------------

    <bullet> 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? 
\225\
---------------------------------------------------------------------------

    \225\ Information blocking FAQ identifier: IB.FAQ49.1.2023APR. 
URL: https://www.healthit.gov/faq/if-actor-such-health-care-provider-operates-more-one-state-it-consistent-information-blocking. 
(Retrieved 7/12/2023.)
---------------------------------------------------------------------------

    <bullet> 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? \226\
---------------------------------------------------------------------------

    \226\ Information blocking FAQ identifier: IB.FAQ47.1.2023APR. 
URL: https://www.healthit.gov/faq/if-individual-requests-their-ehi-not-be-disclosed-it-information-blocking-if-actor-does-not. 
(Retrieved 7/12/2023.)
---------------------------------------------------------------------------

    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 Sec.  
171.204(a) and also meets the condition in Sec.  171.204(b) (see 85 FR 
25958, see also preamble discussion at 85 FR 25866 through 25870). The 
segmentation condition of the Infeasibility Exception (Sec.  
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:
    <bullet> 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); \227\
---------------------------------------------------------------------------

    \227\ We use ``individual'' here, and for purposes of Sec.  
171.204 in general, as it is defined in Sec.  171.202(a).
---------------------------------------------------------------------------

    <bullet> 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
    <bullet> 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 Sec.  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 Sec.  164.522

[[Page 1353]]

requires covered entities to permit an individual to make. As we 
discuss above, and in accordance with the Sec.  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 
Sec.  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 Sec.  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, Sec.  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 Sec.  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 (Sec.  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.\228\
---------------------------------------------------------------------------

    \228\ It is important to remember that the information blocking 
exceptions defined in 45 CFR part 171 subparts B and C are 
voluntary, offering actors certainty that any practice meeting the 
conditions of one or more exceptions would not be considered 
information blocking. An actor's practice that does not meet the 
conditions of an exception would not automatically constitute 
information blocking. See, e.g., IB.FAQ29.1.2020NOV, URL: https://www.healthit.gov/faq/if-actor-does-not-fulfill-request-access-exchange-and-use-ehi-any-manner-requested-they-have. (Retrieved 7/
12/2023.)
---------------------------------------------------------------------------

    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 (Sec.  171.202) or the Preventing Harm Exception 
(Sec.  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 (Sec.  171.204) with the 
Privacy Exception (Sec.  171.202) or with the Preventing Harm Exception 
(Sec.  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 Sec.  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 Sec.  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.
    <bullet> 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 Sec.  171.202(e) Respecting an Individual's Request 
Not to Share Information sub-exception of the Privacy Exception. (Note: 
for purposes of the Sec.  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) \229\ 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.
---------------------------------------------------------------------------

    \229\ ``Entity'' as used in this paragraph could be an 
individual (such as a licensed health care professional) or an 
organization (such as a health care facility).
---------------------------------------------------------------------------

    <bullet> Second, the actor cannot unambiguously segment certain EHI 
from the EHI that would not be made available due to the individual's 
request

[[Page 1354]]

that the actor has agreed to honor. The Infeasibility Exception is 
satisfied by a practice that meets a condition in paragraph (a) of 
Sec.  171.204, such as the segmentation condition (171.204(a)(2)) and 
the responding to requests condition in Sec.  171.204(b). Meeting the 
Sec.  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 Sec.  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 \230\ as 
well as the frequently asked questions referenced and linked above.
---------------------------------------------------------------------------

    \230\ https://www.healthit.gov/buzz-blog/information-blocking/information-blocking-regulations-work-in-concert-with-hipaa-rules-and-other-privacy-laws-to-support-health-information-privacy 
(Retrieved 12/07/2023.).
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  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 (see 88 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 Sec.  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

[[Page 1355]]

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.\231\ (see 88 FR 
23860 through 23864).
---------------------------------------------------------------------------

    \231\ Because we are aware that health care provider 
organizations may be, have, or include one or more physician or 
other clinicians' professional practices, we note for readers' 
clarity that unless otherwise specified (such as by being preceded 
by ``clinician'' or ``office''), we use the word ``practice'' 
throughout the section IV of this preamble with the meaning it has 
in 45 CFR 171.102 (i.e., ``an act or omission by an actor'').
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  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 Sec.  170.404(c) and (by cross-
reference) Sec.  171.102. Specifically, we believe that wording the 
offer health IT definition in Sec.  171.102 to focus (as proposed, see 
88 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 
Sec.  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 Sec.  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 (see 84 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 Sec.  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 Sec.  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).\232\
---------------------------------------------------------------------------

    \232\ As we clarified in the ONC Cures Act Final Rule (85 FR 
25749), health care providers are not subject to the Condition and 
Maintenance of Certification requirements in Sec.  170.404(c) 
``unless they are serving the role of a `Certified API Developer.' 
''
---------------------------------------------------------------------------

    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 
Sec.  171.102 by cross-reference to Sec.  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

[[Page 1356]]

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 Sec.  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 Sec.  171.102:
    <bullet> 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).
    <bullet> 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.
    <bullet> 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 Sec.  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.\233\ 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.\234\
---------------------------------------------------------------------------

    \233\ See definitions of the adjective ``necessary'' by
    <bullet> Merriam-Webster Dictionary: ``1: Absolutely needed: 
required; 2 a of an inevitable nature'' (https://www.merriam-
webster.com/dictionary/
necessary#:~:text=%3A%20absolutely%20needed%20%3A%20required,of%20an%
20inevitable%20nature%20%3A%20inescapable, retrieved Nov 7, 2023);
    <bullet> Dictionary.com: ``1. Essential, indispensable, or 
requisite. 2. Happening or existing by necessity.'' (https://www.dictionary.com/browse/necessary, retrieved Nov 7, 2023).
    \234\ The offer health IT definition exclusion in subparagraph 
(3)(i) encompasses the activities by counsel it describes for both 
EHI and other electronically stored information (ESI). For purposes 
of legal discovery, ESI includes writings, drawings, graphs, charts, 
photographs, sound recordings, images, or other data or data 
compilations. (See, e.g., Fed. R. Civ. P. 34(a)(1)(A).).
---------------------------------------------------------------------------

    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.\235\ 
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.
---------------------------------------------------------------------------

    \235\ See e.g., https://www.merriam-webster.com/dictionary/hold%20out (Retrieved Jul 6, 2023): ``to present something as 
realizable: proffer.''
---------------------------------------------------------------------------

    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

[[Page 1357]]

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 Sec.  
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 Sec.  171.102 and we believe the finalized 
definition of offer health IT provides clarity that deploying \236\ 
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.
---------------------------------------------------------------------------

    \236\ As discussed above, the individual or entity ``deploying'' 
the health IT need not, for purposes of the offer health IT 
definition, do any or all of the implementation or maintenance of 
the health IT. The deploying individual or entity could have any or 
all implementation and maintenance work for the health IT done for 
them by the offeror or one or more third party(ies).
---------------------------------------------------------------------------

    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 Sec.  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? \237\
---------------------------------------------------------------------------

    \237\ For ease of reference, we may sometimes refer to suites, 
bundles, or other combinations of health IT items, services, or 
functions that include one or more Health IT Modules certified under 
the Program as ``certified health IT products.''
---------------------------------------------------------------------------

    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

[[Page 1358]]

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

[[Page 1359]]

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 Sec.  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.\238\ We note that we may consider amending this 
definition in future rulemaking in response to changing market 
conditions.
---------------------------------------------------------------------------

    \238\ Patterns described to us in claims or suggestions of 
possible information blocking submitted through the Report 
Information Blocking Portal represent just one example of the ways 
such signals may come to our attention. (The Report Information 
Blocking Portal's URL is: https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6). Information on the claims process 
that is publicly available on HealthIT.gov (https://www.healthit.gov/topic/information-blocking) includes a fact sheet 
on the Report Information Blocking portal process (https://www.healthit.gov/sites/default/files/page2/2021-11/Information-Blocking-Portal-Process.pdf) and a resource titled ``Information 
Blocking Claims: By the Numbers'' (https://www.healthit.gov/data/quickstats/information-blocking-claims-numbers). As of October 2023, 
``Information Blocking Claims: By the Numbers'' provides the total 
number of portal submissions received since April 5, 2021, the 
number of these submissions that represent claims of possible 
information blocking, and the number of these claims by type of 
potential actor and type of claimant. (URLs confirmed Oct 18, 2023.)
---------------------------------------------------------------------------

    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

[[Page 1360]]

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 (Sec.  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):
    <bullet> holds out the health IT for sale, resale, license, or 
relicense for deployment by or for other individual(s) or entity(ies);
    <bullet> sells, resells, licenses, relicenses the health IT for 
deployment by or for other individual(s) or entity(ies); or
    <bullet> 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

[[Page 1361]]

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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 
Sec.  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.\239\
---------------------------------------------------------------------------

    \239\ The health information network or health information 
exchange definition is a functional definition. See 45 CFR 171.102, 
see also 85 FR 25800 through 85 FR 25803.
---------------------------------------------------------------------------

    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. (See 45 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

[[Page 1362]]

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 Sec.  171.102.\240\
---------------------------------------------------------------------------

    \240\ The Sec.  171.102 health care provider and HIN/HIE 
definitions do not have a definitional component related to 
certified health IT. An individual or entity can meet either or both 
of these definitions without having, using, or offering any 
certified health IT.
---------------------------------------------------------------------------

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

[[Page 1363]]

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 (see 88 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 Sec.  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:
    <bullet> a health care provider organization or other entity uses 
pre-production staging or test environments for certified health IT;
    <bullet> use of health IT for purposes of clinical education and 
improvement activities, including in simulation environments where no 
care is furnished to actual patients;
    <bullet> a health care provider providing a public health 
authority's employees or contractors with access to its health IT 
systems;
    <bullet> 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 Sec.  171.102 by cross-reference to Sec.  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 Sec.  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

[[Page 1364]]

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 Sec.  171.404(c) or an analogous role 
for health IT other than ``Certified API Technology'' as defined in 
Sec.  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) (see 88 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,

[[Page 1365]]

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),\241\ 
Medicare's Quality Innovation Network--Quality Improvement Organization 
(QIN-QIO),\242\ 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).
---------------------------------------------------------------------------

    \241\ Patient Safety Organizations (PSOs) collect and analyze 
data voluntarily reported by healthcare providers to help improve 
patient safety and healthcare quality. PSOs provide feedback to 
healthcare providers aimed at promoting learning and preventing 
future patient safety events. Under the Patient Safety and Quality 
Improvement Act of 2005 (the Patient Safety Act), the Agency for 
Healthcare Research and Quality (AHRQ) certifies and lists PSOs. 
(https://pso.ahrq.gov/, retrieved Nov 24, 2023.)
    \242\ Administered by CMS, the Quality Improvement Organizations 
(QIO) Program is one of the largest federal programs dedicated to 
improving health quality for Medicare beneficiaries. The QIO 
Program's Quality Innovation Network-QIOs (QIN-QIOs) bring Medicare 
beneficiaries, providers, and communities together in data-driven 
initiatives that increase patient safety, make communities 
healthier, better coordinate post-hospital care, and improve 
clinical quality. By serving regions of two to six states each, QIN-
QIOs are able to help best practices for better care spread more 
quickly, while still accommodating local conditions and cultural 
factors. (https://www.cms.gov/medicare/quality/quality-improvement-organizations, retrieved Nov 24, 2023.)
---------------------------------------------------------------------------

    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:
    <bullet> legal services furnished by attorneys that are not in-
house counsel \243\ of the provider (commonly referred to as ``outside 
counsel'');
---------------------------------------------------------------------------

    \243\ As noted in the HTI-1 Proposed Rule (see 88 FR 23860 and 
23861 (footnote 407)), in-house counsel would for purposes of the 
offer definition be considered ``employees'' of the provider. 
Furnishing use of the provider's health IT to in-house counsel would 
no more be an offer of that health IT than would be furnishing use 
of that same health IT to members of the provider's nursing or 
medical records staff.
---------------------------------------------------------------------------

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

[[Page 1366]]

    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:
    <bullet> 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
    <bullet> 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 \244\ 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.''\245\ 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).
---------------------------------------------------------------------------

    \244\ See e.g., University of Michigan School of Information 
(https://www.si.umich.edu/programs/master-health-informatics, 
retrieved 10/25/2023); University of Pittsburgh School of Health and 
Rehabilitation Sciences blog post ``Why Health Informatics Is Its 
Own Discipline,'' Oct. 7, 2021 (https://online.shrs.pitt.edu/blog/why-health-informatics-is-its-own-discipline/, retrieved Oct. 25, 
2023).
    \245\ The definition including this quote appeared in frequently 
asked questions (FAQs) for ``Health Services Research Information 
Central'' updated Apr. 23, 2014, on a web page of the National 
Library of Medicine's National Information Center on Health Services 
Research and Health Care Technology (NICHSR). The quote's 
attribution and citation on that web page read ``Procter, R. Dr. 
(Editor, Health Informatics Journal, Edinburgh, United Kingdom). 
Definition of health informatics [internet]. Message to: Virginia 
Van Horne (Content Manager, HSR Information Central, Bethesda, MD). 
2009 Aug 16 [cited 2009 Sept 21]. [1 paragraph].'' (https://wayback.archive-it.org/7189/20170515160548/https://www.nlm.nih.gov/hsrinfo/hsric_topic_definitions.html, retrieved Oct. 25, 2023).
---------------------------------------------------------------------------

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

[[Page 1367]]

Sec.  171.102 definition of a health care provider. Thus, the physician 
in this example is a Sec.  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 Sec.  171.102 health care provider, 
health IT developer of certified health IT, or HIN/HIE, and would only 
meet the Sec.  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 Sec.  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:
    <bullet> 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
    <bullet> 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

[[Page 1368]]

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:
    <bullet> The individual or entity furnishing the administrative or 
operational management consulting services acts as the agent of the 
provider or otherwise on behalf of \246\ 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;
---------------------------------------------------------------------------

    \246\ At 88 FR 23863, we used ``stands in the shoes of'' instead 
of ``on behalf of, to parallel the wording of the subparagraph as 
presented in the Proposed Rule. We have updated the statement of 
this factor here to match the wording of the finalized subparagraph 
(3)(iii).
---------------------------------------------------------------------------

    <bullet> 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; \247\
---------------------------------------------------------------------------

    \247\ At 88 FR 23863, we referenced one example type of health 
care provider (clinician practice) and various roles individuals 
might have within health care provider organizations. We also used 
the more colloquial ``fall on'' than ``be executed by.'' We used 
that wording at 88 FR 23863 to parallel the wording of the 
subparagraph as presented in the Proposed Rule. We have updated the 
statement of this factor here to match the wording of the finalized 
subparagraph (3)(iii).
---------------------------------------------------------------------------

    <bullet> 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
    <bullet> The non-health IT services must represent more than half 
of each of--
    [cir] 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
    [cir] 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 (see 88 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

[[Page 1369]]

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 Sec.  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 Sec.  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 Sec.  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 Sec.  171.102 is offset by customers' 
potential preferences to receive services from consultants who are 
Sec.  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 Sec.  
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 Sec.  
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 Sec.  
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 Sec.  
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 Sec.  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):
    <bullet> Revised the second sentence of subparagraph (i) to remove 
unnecessary

[[Page 1370]]

words, increase precision, and improve readability, as follows:
    [cir] 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.''
    [cir] 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.''
    [cir] Revised the final phrase of the sentence from ``as necessary 
or appropriate to legal discovery'' to ``as appropriate to legal 
discovery.''
    <bullet> 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).
    <bullet> 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).''
    <bullet> 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.''
    <bullet> 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.
    <bullet> To improve readability of subparagraph (3)(iii), we have 
revised its wording in the following ways:
    [cir] 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).
    [cir] 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.''
    [cir] 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.''
    [cir] 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).''
    [cir] 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.''
    [cir] 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 Sec.  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

[[Page 1371]]

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 Sec.  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 Sec.  
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 Sec.  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'' (See 88 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 Sec.  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 
(Sec.  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 Sec.  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 Sec.  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

[[Page 1372]]

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 Sec.  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 Sec.  171.102 and the text of statutory cross-
references within the PHSA section 3000 definition of health care 
provider.\248\
---------------------------------------------------------------------------

    \248\ Health Care Provider Definition and Cross-Reference Table, 
available at: https://www.healthit.gov/sites/default/files/page2/2020-08/Health_Care_Provider_Definitions_v3.pdf (Retrieved Jun 28, 
2023.)
---------------------------------------------------------------------------

    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 Sec.  171.102) will meet the finalized revised 
Sec.  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 Sec.  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 (Sec.  171.103) and the Content and Manner Exception (Sec.  
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 Sec.  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 (Sec.  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 Sec.  171.103(b), as finalized in 
2020, and removal of this paragraph allows for redesignation of 
remaining paragraphs within Sec.  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 (Sec.  171.301(a)(1) and (2)), we 
proposed to revise Sec.  171.301 to remove the existing Sec.  
171.301(a)(1) and (2) as no longer necessary (88 FR 23864 through 23865 
and 88 FR 23916). The proposed revised version of Sec.  171.301 refers 
simply to EHI. We further proposed to renumber several of the existing 
provisions in Sec.  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 (Sec.  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

[[Page 1373]]

(Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  171.102) that seeks access, exchange, or use of 
EHI for any permissible purpose (as defined in Sec.  171.102).
    Comments. A commenter requested we retain ``Content and Manner'' as 
the title of the exception codified in Sec.  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 Sec.  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 Sec.  171.301 for only some 
of the EHI requested. This commenter also stated that the proposed 
revision to Sec.  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 Sec.  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 Sec. Sec.  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 Sec.  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 Sec.  171.204(a)(1)) will not be 
considered information blocking provided such practice also meets the 
condition in Sec.  171.204(b). In the HTI-1 Proposed Rule, we proposed 
to revise Sec.  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 (Sec.  171.204(a)(1); 85 
FR 25874) will not be considered information blocking provided such 
practice also meets the condition in Sec.  171.204(b). We explained 
that the fact that an uncontrollable event specified in Sec.  
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 Sec.  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 Sec.  171.204(a)(1). If the federal

[[Page 1374]]

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 (Sec.  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 Sec.  
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 
Sec.  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 (Sec.  171.204(a)(1)). However, having 
considered commenters' feedback, adding text to the finalized revision 
to Sec.  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 Sec.  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 Sec.  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 Sec.  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

[[Page 1375]]

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 (Sec.  171.204(b)). Both conditions 
remain the same in this regard. The responding to requests condition 
(Sec.  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 Sec.  171.204(a) and the condition in Sec.  
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 (Sec.  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 (Sec.  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 Sec.  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 Sec.  171. 204 has been in place since the Infeasibility 
Exception (Sec.  171.204) was established in the ONC Cures Act Final 
Rule (85 FR 25869 and 85 FR 25958; see also 85 FR 25867). Thus, as is 
the case for a practice meeting any of the conditions codified in Sec.  
171.204(a), an actor's practice consistent with the Sec.  171.204(a)(1) 
uncontrollable events condition would also need to meet the 
requirements of Sec.  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 (Sec.  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 
(Sec.  171.204(b)) does not focus on when the requestor sends or 
attempts to make the request. Rather, the responding to requests 
condition (Sec.  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 Sec.  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 Sec.  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 (Sec.  171.204(a)(1)):

[[Page 1376]]

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 Sec.  171.204(a). 
As discussed in response to comments, we have also added to the end of 
the text of Sec.  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 Sec.  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 
Sec.  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 Sec.  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 Sec.  170.102 and maintains within or through use of that 
technology any instance(s) of any electronic health information as 
defined in Sec.  171.102. As a reminder, to fully satisfy the exception 
in Sec.  171.204, an actor's practice must meet one of the conditions 
in paragraph (a) of Sec.  171.204 and the requirements in paragraph (b) 
of Sec.  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 Sec.  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 Sec.  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 
Sec.  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 Sec.  
171.102) of EHI.
    The information blocking definition (Sec.  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 Sec.  
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 Sec.  171.102. It is important to 
note that the term ``modification use'' in the proposed and finalized 
Sec.  171.204(a)(3) refers to a specific type of use within the Sec.  
171.102 definition of the term use.\249\ 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 Sec.  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.\250\ We note that the third 
party seeking modification use condition does not imply or indicate any 
change to the HIPAA Rules (see 88 FR 23865).
---------------------------------------------------------------------------

    \249\ In Sec.  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.''
    \250\ We discuss information blocking regulations' accommodation 
of HIPAA and other privacy laws in section 4.A, general comments.
---------------------------------------------------------------------------

    We proposed to add a definition of business associate to Sec.  
171.102 because we use the term in the third party seeking modification 
use condition. We proposed that the definition of business associate in 
Sec.  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 Sec.  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 \251\), terms or 
provisions of

[[Page 1377]]

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''; Sec.  
171.102) the access, exchange, or use of EHI, and whether the actor had 
the requisite intent (85 FR 25812).
---------------------------------------------------------------------------

    \251\ IB.FAQ28.2.2021APR: ``Do the information blocking 
regulations require actors to violate existing business associate 
agreements in order to not be considered information blockers?'' 
(Available at https://www.healthit.gov/faq/do-information-blocking-regulations-require-actors-violate-existing-business-associate. 
Retrieved Sep 14, 2023.)
---------------------------------------------------------------------------

    Comments. Comments received on the proposed Sec.  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 Sec.  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 Sec.  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 Sec.  
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 Sec.  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 \252\ on ONC's website, HealthIT.gov.\253\

[[Page 1378]]

Information received by ONC through the Information Blocking Portal as 
well as the Health IT Feedback and Inquiry Portal \254\ also helps 
inform the development of resources we make publicly available on ONC's 
website, HealthIT.gov.
---------------------------------------------------------------------------

    \252\ URL https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6 (URL confirmed current and operational as of Sep 14, 
2023).
    \253\ URL to Information Blocking topic section of HealthIT.gov: 
https://www.healthit.gov/topic/information-blocking. (URL confirmed 
current and operational as of Sep 14, 2023.)
    \254\ URL https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2 (URL confirmed current and operational as of Sep 14, 
2023).
---------------------------------------------------------------------------

    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 (Sec.  171.204(a)(3)) that the condition was met at all 
relevant times and that the condition in Sec.  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 Sec.  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.

[[Page 1379]]

    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 
Sec.  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 (Sec.  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 Sec.  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. \255\
---------------------------------------------------------------------------

    \255\ Whether other conditions in Sec.  171.204(a) or another 
exception codified in subpart B or C of 45 CFR part 171 could be or 
have been satisfied in a particular situation would depend on the 
specific facts and circumstances of the case.
---------------------------------------------------------------------------

    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.\256\
---------------------------------------------------------------------------

    \256\ Patterns described to us in claims or suggestions of 
possible information blocking submitted through the Report 
Information Blocking Portal illustrate just one example of such 
signals coming to our attention. (The Report Information Blocking 
Portal's URL as of Jul 28, 2023, is: https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6).
---------------------------------------------------------------------------

    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:
    <bullet> 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;
    <bullet> 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;
    <bullet> asking ONC to consider whether patients should be 
consulted before data from another health care provider is incorporated 
into their EHI;

[[Page 1380]]

    <bullet> asking ONC to consider what annotation mechanisms are or 
should be in place to create an audit trail for modifications to EHI;
    <bullet> asking ONC to establish incentives for third-party 
applications to utilize best practices regarding maintaining the 
integrity and security of electronic health information;
    <bullet> a request that the ten-business day timeline established 
in Sec.  171.204(b) should be revised to be longer;
    <bullet> 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);
    <bullet> 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;
    <bullet> 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 \257\ that is available year-round and not 
tied to the comment period for a proposed rule.
---------------------------------------------------------------------------

    \257\ URL https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2 (URL confirmed current and operational as of Sep 14, 
2023).
---------------------------------------------------------------------------

    Regarding the relationship between the finalized Sec.  
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 (see 88 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 
Sec.  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 (Sec.  171.204(a)(3)), that it 
met the third party seeking modification condition and also met the 
Sec.  171.204(b) responding to requests condition at all relevant 
times.
    As with every other condition in Sec.  171.204(a), we note that the 
Sec.  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 Sec.  171.204(a) condition. It also means an 
actor's practice that fails to meet the Sec.  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 Sec.  171.204(a)(5).
    We emphasize that other conditions within Sec.  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 Sec.  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 Sec.  171.301 (which we have in this rule renamed Manner 
Exception, see Section IV.A.1), including offering all alternative 
manners in accordance with Sec.  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 (see 85 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 (Sec.  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 Sec.  171.301, for the Manner Exception to apply, an actor must 
fulfill a request for

[[Page 1381]]

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[thinsp]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 Sec.  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 Sec.  171.303 (45 CFR[thinsp]171.301(b)(1)(ii), as 
originally codified) (85 FR 25877).
    Section 171.301(b)(2) (original codification, redesignated in this 
final rule as Sec.  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 Sec.  171.301(b)(2) (original 
codification, now redesignated Sec.  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 Sec.  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 (Sec.  171.204(a)(5); 
previously Sec.  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 Sec.  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 Sec.  171.301--including offering terms for such 
manners that are consistent with the Fees (Sec.  171.302) and Licensing 
(Sec.  171.303) Exceptions. We anticipate that this uncertainty will 
lead actors who, again, have already exhausted the Manner Exception 
(Sec.  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 (Sec.  171.302) and Licensing (Sec.  
171.303) Exceptions for their requested manner or any alternative 
manner consistent with the Manner Exception (Sec.  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 Sec.  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 Sec.  171.301(b) (85 FR 25877) 
(previously Sec.  171.301(b)(2)(i)). Under the Manner Exception, for 
any alternative manner, the requestor must either specify the manner 
they would accept (Sec.  171.301(b)(2)(i)(A) and (B)) or specifically 
agree with the machine-readable format that they would accept (Sec.  
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

[[Page 1382]]

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 Sec.  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 Sec.  171.302 Fees 
Exception or Sec.  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 Sec.  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 Sec.  
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 Sec.  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 Sec.  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

[[Page 1383]]

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 Sec.  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 (Sec.  171.301(b)(1)(i)) or published 
content and transport standards consistent with Sec.  
171.301(b)(1)(ii).
    By requiring actors to offer at least one of the first two 
alternative manners (as listed in Sec.  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., Sec.  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 
Sec.  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 Sec.  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 Sec.  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 (Sec.  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 (Sec.  
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 Sec.  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 Sec.  
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

[[Page 1384]]

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 Sec.  171.301 Manner 
Exception by meeting the manner requested condition would not need to 
also satisfy any condition in the Sec.  171.204 Infeasibility 
Exception, assuming all requested EHI was provided consistent with the 
Manner Exception. The Sec.  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, Sec.  
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 Sec.  171.301(b)(1)(i)-(iii), 
one of which must be either the alternative manner in Sec.  
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 Sec.  
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 Sec.  171.204(a)(5) (originally codified in Sec.  
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 Sec.  
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

[[Page 1385]]

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 Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  171.204(a)(4)(iii) without further definition. We 
unintentionally included a definition of provide in Sec.  171.102 
(information blocking definitions) in the HTI-1 Proposed Rule. We have 
not finalized any definition of the word ``provide'' in Sec.  171.102. 
Further, we emphasize that the definition of provide finalized in Sec.  
170.102 (health information technology certification program

[[Page 1386]]

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 Sec.  
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 Sec.  
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 (Sec.  171.302) and Licensing Exception (Sec.  
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 (Sec.  171.204(a)(4)(iv)) that such 
statuses include requests by individuals, as we define that term in 
Sec.  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.

[[Page 1387]]

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

[[Page 1388]]

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, Sec.  171.400 ``availability 
and effect of exceptions,'' which mirrors Sec. Sec.  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 Sec.  171.401 for definitions in future 
rulemaking and reserved Sec.  171.402 for future use as well. At Sec.  
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 
(Sec.  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 (Sec.  171.302) and the Licensing Exception (Sec.  171.303).
    The first condition, in Sec.  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 Sec.  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 Sec.  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 Sec.  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 Sec.  
171.403(d), states that any fees an actor charges, and any licensing 
terms an actor sets, must comply with the Fees Exception (Sec.  
171.302) and the Licensing Exception (Sec.  171.303). This exception in 
Sec.  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 Sec.  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,

[[Page 1389]]

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 (Sec.  171.302) 
and the Licensing Exception (Sec.  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. (See 88 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 (Sec.  171.302) and the Licensing Exception (Sec.  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 also 88 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 
(Sec.  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 (Sec.  171.302(b)(1) and (2)). 
Regarding patient privacy, all Sec.  171.102 actors are required to 
protect patients' privacy and restrict the access, exchange, and use of

[[Page 1390]]

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 
Sec.  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) \258\ and Cross-
Community Access (XCA) \259\ to enable clinical document exchange 
between disparate communities.\260\ 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.\261\ 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 Sec.  171.102), the new finalized exception would be 
available along with all the other exceptions.
---------------------------------------------------------------------------

    \258\ IHE Cross-Community Patient Discovery (XCPD) profile--
available in the IHE IT Infrastructure (ITI) Technical Framework 
Volume 1: Integration Profiles at: https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev17-0_Vol1_FT_2020-07-20.pdf.
    \259\ IHE Cross-Community Access (XCA) profile--available in the 
IHE IT Infrastructure (ITI) Technical Framework Volume 1: 
Integration Profiles at: https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev17-0_Vol1_FT_2020-07-20.pdf.
    \260\ https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf.
    \261\ https://www.healthit.gov/buzz-blog/tefca/coming-in-hot-tefca-will-soon-be-live-and-add-support-for-fhir-based-exchange.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  171.403(c) is necessary 
to achieve these goals.

[[Page 1391]]

    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 Sec.  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 Sec.  
170.404(c)) or other API technology using the standards and 
implementation specifications adopted in Sec.  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 Sec.  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 Sec.  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 
Sec.  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 Sec.  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 (Sec.  
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 (Sec.  171.302) or the Licensing Exception 
(Sec.  171.303), and would meet the manner requested condition of the 
Manner Exception (Sec.  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 (Sec.  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 (Sec.  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

[[Page 1392]]

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 Sec.  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 (Sec.  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 Sec.  
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,

[[Page 1393]]

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 
(Sec.  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 Sec.  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 (Sec.  
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

[[Page 1394]]

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

    \262\ URLs retrieved Oct 26, 2023.
---------------------------------------------------------------------------

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

[[Page 1395]]

technology or offer health IT definition proposed in Sec.  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, Sec.  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 Sec.  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.

[[Page 1396]]

    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

    <bullet> Health Level 7 (HL7[supreg]) CDA[supreg] 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[supreg] 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.
    <bullet> HL7 FHIR[supreg] 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.
    <bullet> HL7 CDA[supreg] 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.
    <bullet> HL7 CDA[supreg] 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.
    <bullet> 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

    <bullet> 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.
    <bullet> National Drug Code Directory (NDC)--Vaccine NDC Linker, 
dated July 19, 2022.

[[Page 1397]]

    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.
    <bullet> 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.
    <bullet> 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/).
    <bullet> 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.
    <bullet> Logical Observation Identifiers Names and Codes (LOINC 
[supreg]) 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.
    <bullet> 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.
    <bullet> Systematized Nomenclature of Medicine Clinical Terms 
(SNOMED CT[supreg]) 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.
    <bullet> 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

    <bullet> 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

[[Page 1398]]

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

    <bullet> 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.
    <bullet> HL7 FHIR[supreg] 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.

  Table 3--Estimated Annualized Burden Hours for Independent Entity To
   Review and Submit Developer Responses to ONC per Insights Condition
                              Requirements
------------------------------------------------------------------------
                                          Number of    Average
  Code of Federal regulations section    independent    burden    Total
                                            entity      hours
------------------------------------------------------------------------
45 CFR 170.407(a)......................            1         24       24
45 CFR 170.407(b)......................            1        143      143
                                        --------------------------------
    Total Burden Hours.................  ...........  .........      167
------------------------------------------------------------------------

    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.

[[Page 1399]]



 Table 4--Estimated Annualized Total Burden Hours for Health IT Developers To Comply With the Insights Condition
                                  and Maintenance of Certification Requirements
----------------------------------------------------------------------------------------------------------------
                                                                              Average burden     Average burden
          Code of Federal regulations section             Number of health     hours--lower       hours--upper
                                                           IT developers          bound              bound
----------------------------------------------------------------------------------------------------------------
45 CFR 170.407(a)......................................                 52             17,445             38,750
                                                        --------------------------------------------------------
    Total Burden Hours.................................  .................            790,806          1,767,692
----------------------------------------------------------------------------------------------------------------

    In the HTI-1 Proposed Rule (88 FR 23797), we stated for Sec.  
170.315(b)(11)(vii)(B), health IT developers would compile 
documentation regarding the intervention risk management practices 
listed in Sec.  170.315(b)(11)(vii)(A), and upon request from ONC, make 
available such detailed documentation for any Predictive DSI, as 
defined in Sec.  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 Sec.  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 
Sec.  170.315(b)(11)(vii)(C) that a health IT developer that attests 
``yes'' in Sec.  170.315(b)(11)(v)(A) submit summary information of the 
intervention risk management practices listed in Sec.  
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 Sec.  170.523(f)(1), we proposed a new Principle of 
Proper Conduct for documentation related to Sec.  
170.315(b)(11)(vii)(C) in Sec.  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 
Sec.  170.523(f)(1)(xxi).
    Response. We have finalized the requirements in Sec.  
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 Sec.  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.

[[Page 1400]]

    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

[[Page 1401]]

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[supreg] App to hundreds of healthcare systems and for apps to 
launch on the Microsoft Azure[supreg] 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.\263\ 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.
---------------------------------------------------------------------------

    \263\ May 2021 National Occupational Employment and Wage 
Estimates, United States. U.S. Bureau of Labor Statistics. https://www.bls.gov/oes/current/oes_nat.htm.
---------------------------------------------------------------------------

    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.\264\ 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.
---------------------------------------------------------------------------

    \264\ Nir Menachemi, Saurabh Rahurkar, Christopher A Harle, 
Joshua R Vest, The benefits of health information exchange: an 
updated systematic review, Journal of the American Medical 
Informatics Association, Volume 25, Issue 9, September 2018, Pages 
1259-1265, https://doi.org/10.1093/jamia/ocy035.
---------------------------------------------------------------------------

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.\265\ 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.\266\ 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.\267\ 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.
---------------------------------------------------------------------------

    \265\ Office of Personnel and Management. 2022 General Schedule 
(GS) Locality Pay Tables https://www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/2022/general-schedule/.
    \266\ See U.S. Department of Health and Human Services, Office 
of the Assistant Secretary for Planning and Evaluation (ASPE), 
Guidelines for Regulatory Impact Analysis, at 28-30 (2016), 
available at https://aspe.hhs.gov/reports/guidelines-regulatory-impact-analysis.
    \267\ May 2021 National Occupational Employment and Wage 
Estimates, United States. U.S. Bureau of Labor Statistics. https://www.bls.gov/oes/current/oes_nat.htm.
---------------------------------------------------------------------------

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

[[Page 1402]]



         Table 5--Number of Developers and Products for the 2011 Edition, 2014 Edition, and 2015 Edition
----------------------------------------------------------------------------------------------------------------
                                         2011 Edition    2014 Edition    Change (%)   2015 Edition    Change (%)
----------------------------------------------------------------------------------------------------------------
Participating Health IT Developers....           1,017             792        -22.1             489        -38.3
Certified Products Available..........           1,408           1,081        -23.2             714        -33.9
----------------------------------------------------------------------------------------------------------------
Note: Counts for 2015 Edition reflect all certificates through 2021. These counts include certificates that are
  active and withdrawn.

    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 \268\ and 2021 \269\ 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.
---------------------------------------------------------------------------

    \268\ https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019.
    \269\ https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019.
---------------------------------------------------------------------------

    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.

          Table 6--Estimated Number of Developers and Products
------------------------------------------------------------------------
                                 Estimated number of   Estimated number
           Scenario             health IT developers      of products
------------------------------------------------------------------------
All Products--End of 2021.....                   414                 569
All Products--Modeled                            368                 502
 Attrition....................
------------------------------------------------------------------------
Note: End of 2021 counts reflect active products only.

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

[[Page 1403]]

    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.

Table 7--Model of Cost Distribution Based on Estimated Number of Hospitals and Clinical Practices With Certified
                                                    Health IT
----------------------------------------------------------------------------------------------------------------
                                                                                    Est. $ per     Total $ cost
                      Health care provider                          Est. count       provider           (m)
----------------------------------------------------------------------------------------------------------------
Hospitals.......................................................           4,600          65,217             300
Clinical Practices..............................................         283,000           2,170             614
                                                                 -----------------------------------------------
    All.........................................................         287,600           3,178             914
----------------------------------------------------------------------------------------------------------------

    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

[[Page 1404]]

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 Sec.  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 
Sec. Sec.  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 Sec.  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 Sec.  170.213(b) and incorporate it by reference in Sec.  
170.299. We have finalized to codify the existing reference to USCDI v1 
(July 2020 Errata) in Sec.  170.213(a). We have finalized that as of 
January 1, 2026, any Health IT Modules seeking certification for 
criteria referencing Sec.  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 Sec.  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 Sec.  
170.213 by December 31, 2025. USCDI, via cross-reference to Sec.  
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:
    <bullet> ``Care coordination--transitions of care--create'' (Sec.  
170.315(b)(1)(iii)(A)(1)).
    <bullet> ``Care coordination--clinical information reconciliation 
and incorporation--reconciliation'' (Sec.  170.315(b)(2)(iii)(D)(1) 
through (3));
    <bullet> ``Patient engagement--view, download, and transmit to 3rd 
party--view'' (Sec.  170.315(e)(1)(i)(A)(1)).
    <bullet> ``Design and performance--consolidated CDA creation 
performance'' (Sec.  170.315(g)(6)(i)(A)).
    <bullet> ``Design and performance--application access--all data 
request--functional requirements'' (Sec.  170.315(g)(9)(i)(A)(1)); and
    <bullet> ``Design and performance--standardized API for patient and 
population services--data response'' (Sec.  170.315(g)(10)(i)(A) and 
(B)).
    We note that Sec.  170.315(f)(5) also currently references Sec.  
170.213. However, we have finalized to rely on specific implementation 
guides for this certification criterion, rather than referencing Sec.  
170.213. Health IT Modules certified to Sec.  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

[[Page 1405]]

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.

  Table 8--Costs to Health IT Developers To Develop Support for the Additional USCDI Data Elements in Affected
                                             Certification Criteria
----------------------------------------------------------------------------------------------------------------
                                                                      Lower    Upper
                 Tasks                             Details            bound    bound            Remarks
                                                                      hours    hours
----------------------------------------------------------------------------------------------------------------
Update C-CDA creation..................  New development to support    1,800    3,600  (1) Lower bound assumes
                                          USCDI v2 and v3 updates                       health IT product was
                                          and changes to data                           voluntarily updated
                                          classes and constituent                       through the ONC
                                          data elements for C-CDA                       Standards Version
                                          and C-CDA 2.1 Companion                       Advancement Process
                                          Guide.                                        (SVAP) and USCDIv2 data
                                                                                        elements are
                                                                                        incorporated in the
                                                                                        certified product. (2)
                                                                                        Upper bound assumes
                                                                                        certified product
                                                                                        conforms only to USCDIv1
                                                                                        and needs to be updated
                                                                                        to fully conform with
                                                                                        USCDIv3.
Sec.   170.315(b)(1)(iii)(A)(1) Care     New development to support      200      600  Necessary updates to
 coordination--Transitions of care--      USCDI v2 and v3 updates                       health IT to support the
 Create.                                  and changes to data                           new data classes and
                                          classes and constituent                       data elements to meet
                                          data elements for C-CDA                       the criteria
                                          and C-CDA 2.1 Companion                       requirements.
                                          Guide.
Sec.   170.315(b)(2)(iii)(D)(1) through  New development to support      200      600  Necessary updates to
 (3) Care coordination--Clinical          USCDI v2 and v3 updates                       health IT to support the
 information reconciliation and           and changes to data                           new data classes and
 incorporation--Reconciliation.           classes and constituent                       data elements to meet
                                          data elements for C-CDA                       the criteria
                                          and C-CDA 2.1 Companion                       requirements.
                                          Guide.
Sec.   170.315(e)(1)(i)(A)(1) Patient    New development to support      200      600  Necessary updates to
 engagement--View, download, and          USCDI v2 and v3 updates                       health IT to support the
 transmit to 3rd party--View.             and changes to data                           new data classes and
                                          classes and constituent                       data elements to meet
                                          data elements for C-CDA                       the criteria
                                          and C-CDA 2.1 Companion                       requirements.
                                          Guide.
Sec.   170.315(g)(6)(i) Design and       New development to support      200      600  Necessary updates to
 performance--Consolidated CDA creation   USCDI v2 and v3 updates                       health IT to support the
 performance.                             and changes to data                           new data classes and
                                          classes and constituent                       data elements to meet
                                          data elements for C-CDA                       the criteria
                                          and C-CDA 2.1 Companion                       requirements.
                                          Guide.
Sec.   170.315(g)(9)(i)(A)(1) Design     New development to support      200      600  Necessary updates to
 and performance--Application access--    USCDI v2 and v3 updates                       health IT to support the
 all data request--Functional             and changes to data                           new data classes and
 requirements.                            classes and constituent                       data elements to meet
                                          data elements for C-CDA                       the criteria
                                          and C-CDA 2.1 Companion                       requirements.
                                          Guide.
Sec.   170.315(g)(10)(i)(A) and (B)      New development to support      200      600  Necessary updates to
 Design and performance--Standardized     USCDI v2 and v3 updates                       health IT to support the
 API for patient and population           and changes to data                           new data classes and
 services--Data response.                 classes and constituent                       data elements to meet
                                          data elements for C-CDA                       the requirements.
                                          and C-CDA 2.1 Companion
                                          Guide.
----------------------------------------------------------------------------------------------------------------


Table 9--Total Cost To Develop Support for the Additional USCDI Data Elements in Affected Certification Criteria
                                                 [2022 Dollars]
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated            Estimated cost
                              Tasks                                  number of   -------------------------------
                                                                     products       Lower bound     Upper bound
----------------------------------------------------------------------------------------------------------------
Update C-CDA creation...........................................             346     $79,718,400    $159,436,800
Updates to Sec.   170.315(b)(1).................................             281       7,193,600      21,580,800
Updates to Sec.   170.315(b)(2).................................             261       6,681,600      20,044,800
Updates to Sec.   170.315(e)(1).................................             246       6,297,600      18,892,800
Updates to Sec.   170.315(g)(6).................................             341       8,729,600      26,188,800
Updates to Sec.   170.315(g)(9).................................             276       7,065,600      21,196,800
Updates to Sec.   170.15(g)(10).................................             276       7,065,600      21,196,800
                                                                 -----------------------------------------------

[[Page 1406]]

 
    Total Cost..................................................             346     122,752,000     288,537,600
----------------------------------------------------------------------------------------------------------------
Notes: The number of estimated products that certify applicable criteria vary. We estimated separate modifiers
  for each certification criterion to estimate the number of products impacted by the USCDI updates. Estimates
  reflect the percent of all products that certify a criterion through 2021, except. Modifiers: (b)(1): 56%;
  (b)(2): 52%; (e)(1): 49%; (g)(6): 68%; (g)(9): 55%. This estimate is subject to change.

    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,\270\ 
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,\271\ 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.
---------------------------------------------------------------------------

    \270\ https://www.healthit.gov/sites/default/files/page/2022-07/Standards_Bulletin_2022-2.pdf.
    \271\ https://www.healthit.gov/sites/default/files/page/2021-07/Standards_Bulletin_2021-3.pdf.
---------------------------------------------------------------------------

    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 Sec.  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 Sec.  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 Sec.  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:
    <bullet> 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.
    <bullet> 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

[[Page 1407]]

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 Sec.  
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.
    <bullet> 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.\272\ 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.
---------------------------------------------------------------------------

    \272\ https://www.bls.gov/oes/current/oes151252.htm.

              Table 10--Estimated Labor Hours To Meet eCR Certification Requirements--New Products
----------------------------------------------------------------------------------------------------------------
                                                                      Estimated labor
                                                                           hours
                Activity                           Details          ------------------          Remarks
                                                                      Lower    Upper
                                                                      bound    bound
----------------------------------------------------------------------------------------------------------------
Task 1: Case Report Creation...........  (1) Enable a user to          1,000    1,500  (1) Lower bound assumes
                                          create a case report for                      health IT product has
                                          electronic transmission                       begun to implement at
                                          according to (i) eICR                         least one of the two
                                          profiles of HL7 FHIR eCR                      IGs.
                                          IG, or (ii) HL7 CDA eICR                     (2) Upper bound assumes
                                          IG; (2) Support RCTC                          health IT product does
                                          value set.                                    not support either IG or
                                                                                        has not begun to
                                                                                        implement.
Task 2: Case Report Response Receipt...  Health IT Module must be      1,000    1,500  (1) Lower bound assumes
                                          able to consume and                           health IT product has
                                          process a reportability                       begun to implement at
                                          response according to (1)                     least one of the two
                                          RR profiles of HL7 FHIR                       IGs.
                                          eCR IG, or (2) HL7 CDA RR                    (2) Upper bound assumes
                                          IG.                                           health IT product does
                                                                                        not support either IG or
                                                                                        has not begun to
                                                                                        implement.
Task 3: Support for Reporting..........  Health IT Module must be          0      160  (1) Lower bound assumes
                                          able to report to a                           that health IT already
                                          system capable of                             has the technical pre-
                                          receiving case reports                        requisites for reporting
                                          electronically.                               but is not yet connected
                                                                                        to platform or method to
                                                                                        enable reporting.
                                                                                       (2) Upper bound assumes
                                                                                        health IT does not have
                                                                                        technical pre-requisites
                                                                                        for reporting (e.g., no
                                                                                        support for electronic
                                                                                        connection and no
                                                                                        support for available
                                                                                        exchange methods).
----------------------------------------------------------------------------------------------------------------


      Table 11--Estimated Labor Hours to Meet eCR Certification Requirements--Currently Certified Products
----------------------------------------------------------------------------------------------------------------
                                                                      Estimated labor
                                                                           hours
                Activity                           Details          ------------------          Remarks
                                                                      Lower    Upper
                                                                      bound    bound
----------------------------------------------------------------------------------------------------------------
Task 1: Case Report Creation...........  (1) Enable a user to              0    1,000  (1) Lower bound assumes
                                          create a case report for                      health IT product has
                                          electronic transmission                       already implemented at
                                          according to (i) eICR                         least one of the two
                                          profiles of HL7 FHIR eCR                      IGs.
                                          IG, or (ii) HL7 CDA eICR                     (2) Upper bound assumes
                                          IG; (2) Support RCTC                          health IT product has
                                          value set.                                    begun to implement at
                                                                                        least one of the two
                                                                                        IGs.
Task 2: Case Report Response Receipt...  Health IT Module must be          0    1,000  (1) Lower bound assumes
                                          able to consume and                           health IT product has
                                          process a reportability                       already implemented at
                                          response according to (1)                     least one of the two
                                          RR profiles of HL7 FHIR                       IGs.
                                          eCR IG, or (2) HL7 CDA RR                    (2) Upper bound assumes
                                          IG.                                           health IT product has
                                                                                        begun to implement at
                                                                                        least one of the two
                                                                                        IGs.
Task 3: Support for Reporting..........  Health IT Module must be          0      160  (1) Lower bound assumes
                                          able to report to a                           health IT already
                                          system capable of                             supports at least one
                                          receiving case reports                        reporting option, such
                                          electronically.                               as to the AIMS platform,
                                                                                        state-based registries
                                                                                        or health information
                                                                                        exchanges.
                                                                                       (2) Upper bound assumes
                                                                                        health IT does not have
                                                                                        technical pre-requisites
                                                                                        for reporting (e.g., no
                                                                                        support for electronic
                                                                                        connection and no
                                                                                        support for available
                                                                                        exchange methods).
----------------------------------------------------------------------------------------------------------------

Total Costs, TC can be represented by the following equation:
[GRAPHIC] [TIFF OMITTED] TR09JA24.000


[[Page 1408]]


Number of currently certified products, pc = 55
Number of new certified products, pn = 141
Fully loaded wage, w = 127.82
Labor hours for IG implementation, hk, for each profile or IG, k
Labor hours for reporting, hr

 Table 12--Example Calculation for the Lower Bound Estimated Cost to New Products To Perform Task 1 in Table 10
                                     To Meet eCR Certification Requirements
----------------------------------------------------------------------------------------------------------------
                                                                 Estimated
                                                                labor hours                          Projected
                          Activity                           ----------------  Developer salary      products
                                                                Lower bound
----------------------------------------------------------------------------------------------------------------
Task 1......................................................     1,000 hours    $127.82 per hour    141 products
Example Calculation:
    1,000 hours * $127.82 * 141 products = $18,022,620.
----------------------------------------------------------------------------------------------------------------


  Table 13--Costs To Meet eCR Certification Requirements--New Products
------------------------------------------------------------------------
                                               Estimated labor hours
                Activity                 -------------------------------
                                            Lower bound     Upper bound
------------------------------------------------------------------------
Task 1 (141 products)...................     $18,022,620     $27,033,930
Task 2 (141 products)...................      18,022,620      27,033,930
Task 3 (141 products)...................               0       2,883,619
                                         -------------------------------
    Total Cost..........................      36,045,240      56,951,479
------------------------------------------------------------------------


    Table 14--Costs To Meet eCR Certification Requirements--Currently
                           Certified Products
------------------------------------------------------------------------
                                                  Estimated cost
                Activity                 -------------------------------
                                            Lower bound     Upper bound
------------------------------------------------------------------------
Task 1 (55 products)....................              $0      $7,030,100
Task 2 (55 products)....................               0       7,030,100
Task 4 (55 products)....................               0       1,124,816
                                         -------------------------------
    Total Cost..........................               0      15,185,016
------------------------------------------------------------------------


  Table 15--Costs To Meet eCR Certification Requirements--All Products
------------------------------------------------------------------------
                                                  Estimated cost
                Activity                 -------------------------------
                                            Lower bound     Upper bound
------------------------------------------------------------------------
Task 1 (196 products)...................     $18,022,620     $34,064,030
Task 2 (196 products)...................      18,022,620      34,064,030
Task 3 (196 products)...................               0       4,008,435
                                         -------------------------------
    Total Cost..........................      36,045,240      72,136,495
------------------------------------------------------------------------

    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.\273\ 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.
---------------------------------------------------------------------------

    \273\ https://www.cdc.gov/datainteroperability/index.html.
---------------------------------------------------------------------------

    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.\274\ A key component of this service is the inclusion of 
the CDC

[[Page 1409]]

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.<SUP>275 276</SUP> 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.\277\
---------------------------------------------------------------------------

    \274\ https://www.aphl.org/programs/informatics/Pages/aims_platform.aspx.
    \275\ CSTE Surveillance/Informatics: Reportable Conditions 
Knowledge Management Systems. CSTE website. http://www.cste.org/group/RCKMS.
    \276\ https://ecr.aimsplatform.org/cms/resources/blocks/digital-bridge-ecr-evaluation-report-12-32019.pdf.
    \277\ Cooney MA, Iademarco MF, Huang M, MacKenzie WR, Davidson 
AJ. The public health community platform, electronic case reporting, 
and the digital bridge. Journal of Public Health Management and 
Practice. 2018 Mar 1;24(2):185-9.
---------------------------------------------------------------------------

    Benefits of eCR to the healthcare sector and public health that 
will be promoted through standards adoption:
    <bullet> Automatic, complete, accurate data reported in real-time 
(faster and more complete than manual entry) facilitates evidence-based 
decision-making for public health.
    <bullet> Directly benefits public health response efforts by 
supporting situational awareness, case management, contract tracing, 
and efforts to coordinate isolation.
    <bullet> Helps improve public health efficiency for evaluation and 
follow-up by providing PHAs with higher quality patient and clinical 
data in a timely manner.
    <bullet> Reduces reporting burden for health care providers without 
disrupting clinical workflow, which can result in time and cost savings 
for the healthcare sector.
    <bullet> 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.
    <bullet> Streamlines reporting to multiple jurisdictions.
    Benefits of certification criterion update:
    <bullet> Adoption of standards for eCR will improve consistency and 
interoperability over time.
    <bullet> 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).
    <bullet> 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 
Sec.  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:
    <bullet> 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.
    <bullet> 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

[[Page 1410]]

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.
    <bullet> 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.\278\ 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.
---------------------------------------------------------------------------

    \278\ https://www.bls.gov/oes/current/oes151252.htm.
---------------------------------------------------------------------------

    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 16--Estimated Labor Hours To Develop and Maintain Updated Decision Support Functionality
----------------------------------------------------------------------------------------------------------------
                                               Lower bound     Upper bound
                  Activity                        hours           hours                    Remarks
----------------------------------------------------------------------------------------------------------------
Task 1: Update decision support tools to              1,000           1,600  (1) Lower bound assumes health IT
 enable interventions based on additional                                     already has developed decision
 data classes and enable selection of                                         support modules that only need to
 Predictive DSI.                                                              be updated for new data classes.
                                                                             (2) Upper bound assumes further
                                                                              data-structure related work is
                                                                              necessary to facilitate CDS based
                                                                              no additional classes.
Task 2: Enable end-users to provide                     200           1,000  (1) Lower bound assumes that
 feedback on evidence-based DSI.                                              developers have already developed
                                                                              feedback capabilities and will
                                                                              need to make limited updates to
                                                                              the reporting of that information.
                                                                             (2) Upper bound assumes that
                                                                              developer's current capability to
                                                                              support feedback on decision
                                                                              support needs to be significantly
                                                                              enhanced to support enabling end-
                                                                              users to provide effective
                                                                              feedback and to create reports
                                                                              from that feedback.
Task 3: Provide users the ability to                  1,000           2,000  (1) Lower bound assumes that
 record, change and access source attribute                                   existing tools used to create
 information.                                                                 similar forms or documents can be
                                                                              adapted to this purpose.
                                                                             (2) Upper bound assumes a higher
                                                                              burden due to more novel
                                                                              development.
Task 4: Provide complete and up-to-date          0 annually    800 annually  We expect a wide range of effort
 source attribute information for                                             based on the extent to which
 Predictive DSI supplied by the developer.                                    developers make DSI available in
                                                                              the future, and whether they
                                                                              author Predictive DSI s available.
                                                                              For those that author Predictive
                                                                              DSI in the future and, we believe
                                                                              that evaluating and reporting
                                                                              source attributes for those
                                                                              Predictive DSI will imply
                                                                              substantial costs.
Task 5: Additional effort to provide                      0           1,600  We expect a wide range of effort
 information for source attributes related                                    based on the extent to which EHR
 to Predictive DSI available as of December                                   developers currently author
 31, 2024.                                                                    Predictive DSI s. For those that
                                                                              do author predictive decision
                                                                              supported interventions and do not
                                                                              currently evaluate the models on
                                                                              the attributes included, we
                                                                              believe doing so will imply
                                                                              substantial costs.
Task 6: Engage in risk management and            0 annually    285 annually  We expect a wide range of effort
 annually update risk management                                              based on the extent to which EHR
 information.                                                                 developers currently author or
                                                                              execute Predictive DSI s. The
                                                                              total hours estimated to conduct
                                                                              real world testing per developer
                                                                              were 1,140 annually and that
                                                                              accounted for numerous criteria
                                                                              included as eligible for real
                                                                              world testing. We believe that
                                                                              conducting intervention risk
                                                                              management for (b)(11), including
                                                                              the provision of risk management
                                                                              documentation, would require a
                                                                              fraction of that time equivalent
                                                                              to one quarter of the time for
                                                                              real world testing.
Task 7: Additional initial engagement in                  0             570  The total hours estimated to
 risk management and updating risk                                            conduct real world testing per
 management information available as of                                       developer were 1,140 annually and
 December 31, 2024.                                                           that accounted for numerous
                                                                              criteria included as eligible for
                                                                              real world testing. We believe
                                                                              that conducting initial
                                                                              intervention risk management for,
                                                                              including the provision of risk
                                                                              management documentation, would
                                                                              require time equivalent to about
                                                                              one quarter of the time for real
                                                                              world testing.
----------------------------------------------------------------------------------------------------------------

    Table 17 provides the overall costs projecting that 301 products 
will be certified to the criterion.

[[Page 1411]]



        Table 17--Total Cost to Developers To Develop and Maintain Updated Decision Support Functionality
----------------------------------------------------------------------------------------------------------------
                                                                    Estimated Total Cost (10 year) (assuming
                                                                    software developer pay of $58.17 per hour
                                                 Projected               software developers (bls.gov))
                                                  products     -------------------------------------------------
                                                                      Lower bound              Upper bound
----------------------------------------------------------------------------------------------------------------
Task 1.....................................                301              $38,473,820              $61,558,112
Task 2.....................................                301                7,694,764               38,473,820
Task 3.....................................                301               38,473,820               76,947,640
Task 4.....................................                301                        0              307,790,560
Task 5.....................................                301                        0               61,558,112
Task 6.....................................                301                        0              109,650,387
Task 7.....................................                301                        0               21,930,077
                                            --------------------------------------------------------------------
    Total..................................  .................               84,642,404              677,908,708
----------------------------------------------------------------------------------------------------------------

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.\279\ 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.
---------------------------------------------------------------------------

    \279\ Ziad Obermeyer, et al., Dissecting racial bias in an 
algorithm used to manage the health of populations, 366 Science 
(2019).
    Andrew Wong, et al., External validation of a widely implemented 
proprietary sepsis prediction model in hospitalized patients, 181 
JAMA Internal Medicine (2021).
    The Johns Hopkins ACG[supreg] System, available at https://www.johnshopkinssolutions.com/wp-content/uploads/2016/08/ACG-System-Brochure.pdf.
---------------------------------------------------------------------------

    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.\280\ 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.
---------------------------------------------------------------------------

    \280\ https://www.healthit.gov/buzz-blog/health-innovation/back-to-the-future-what-predictive-decision-support-can-learn-from-deloreans-and-the-big-short.
---------------------------------------------------------------------------

    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 \281\ 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.\282\
---------------------------------------------------------------------------

    \281\ Epidemiology and Costs of Sepsis in the United States--An 
Analysis Based on Timing of Diagnosis and Severity Level*--PMC 
(nih.gov).
    \282\ J-L Vincent, et al., The SOFA (Sepsis-related Organ 
Failure Assessment) score to describe organ dysfunction/failure 
(Springer-Verlag 1996).
---------------------------------------------------------------------------

    Existing evidence indicates that more advanced predictive models 
can provide substantial performance improvements over simpler, widely 
used models.\283\ 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.\284\ 
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,\285\ and that difference may be 
attributable to difference in performance in varied deployments and 
locations.
---------------------------------------------------------------------------

    \283\ As one example of a study demonstrating clear accuracy 
improvements over widely used, simpler models see Ryan J Delahanty, 
et al., Development and evaluation of a machine learning model for 
the early identification of patients at risk for sepsis, 73 Annals 
of Emergency Medicine (2019).
    \284\ Burdick, Hoyt, et al. ``Effect of a sepsis prediction 
algorithm on patient mortality, length of stay and readmission: a 
prospective multicentre clinical outcomes evaluation of real-world 
patient data from US hospitals.'' BMJ health & care informatics 27.1 
(2020).
    \285\ Topiwala, Raj, et al. ``Retrospective observational study 
of the clinical performance characteristics of a machine learning 
approach to early sepsis identification.'' Critical Care 
Explorations 1.9 (2019).
---------------------------------------------------------------------------

    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%.\286\ 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

[[Page 1412]]

the potential value of greater information to evaluate these 
models.\287\
---------------------------------------------------------------------------

    \286\ Hassan, Nehal, et al. ``Preventing sepsis; how can 
artificial intelligence inform the clinical decision-making process? 
A systematic review.'' International Journal of Medical Informatics 
150 (2021): 104457.
    Makam, Anil N., Oanh K. Nguyen, and Andrew D. Auerbach. 
``Diagnostic accuracy and effectiveness of automated electronic 
sepsis alert systems: a systematic review.'' Journal of hospital 
medicine 10.6 (2015): 396-402.
    \287\ Wong, Andrew, et al. ``External validation of a widely 
implemented proprietary sepsis prediction model in hospitalized 
patients.'' JAMA Internal Medicine 181.8 (2021): 1065-1070.
---------------------------------------------------------------------------

    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.\288\ 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.
---------------------------------------------------------------------------

    \288\ For examples, see Joanne F Guthrie, et al., Who uses 
nutrition labeling, and what effects does label use have on diet 
quality? 27 Journal of Nutrition education (1995); Marian L 
Neuhouser, et al., Use of food nutrition labels is associated with 
lower fat intake, 99 Journal of the American dietetic Association 
(1999).
---------------------------------------------------------------------------

    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.\289\ As in the sepsis example, there are several 
existing predictive models, and they exhibit a wide range 
accuracy.\290\ 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.\291\
---------------------------------------------------------------------------

    \289\ https://www.hcup-us.ahrq.gov/reports/statbriefs/sb259-Potentially-Preventable-Hospitalizations-2017.jsp.
    \290\ Emma Wallace, et al., Risk prediction models to predict 
emergency hospital admission in community-dwelling adults: a 
systematic review, 52 Medical Care (2014).
    Seung Eun Yi, et al., Predicting hospitalisations related to 
ambulatory care sensitive conditions with machine learning for 
population health planning: derivation and validation cohort study, 
12 BMJ Open (2022).
    \291\ Garcia-Arce, Andres, Florentino Rico, and Jos[eacute] L. 
Zayas-Castro. ``Comparison of machine learning algorithms for the 
prediction of preventable hospital readmissions.'' The Journal for 
Healthcare Quality (JHQ) 40.3 (2018): 129-138.
---------------------------------------------------------------------------

    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 Sec.  170.315(a)(9) are not 
required to certify to the adopted criterion in Sec.  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.

                              Table 18--Select Benefits to Patients and Payers From Updated Decision Support Functionality
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                              Proportion of
                                   Cost of    admissions for   Increased      Assumed        Incremental       Incremental     Incremental
   Year impacts are incurred       sepsis       which more    sensitivity   costs saved        impacts         impacts (7%     impacts (3%
                                  admission  sensitive model   of models   for impacted   (undiscounted) *      discount)       discount)
                                    (bn)           used           used      admissions
--------------------------------------------------------------------------------------------------------------------------------------------------------
1..............................  ..........  ...............  ...........  ............  ..................           $0.00            $0.00
2..............................  ..........  ...............  ...........  ............  ..................            0.00             0.00
3..............................         $24             0.02         0.05           0.5         $12,000,000       9,795,575       10,981,670
4..............................          24             0.04         0.05           0.5          24,000,000      18,309,485       21,323,689
5..............................          24             0.06         0.05           0.5          36,000,000      25,667,502       31,053,916
6..............................          24             0.08         0.05           0.5          48,000,000      31,984,427       40,199,244
7..............................          24              0.1         0.05           0.5          60,000,000      37,364,985       48,785,491
8..............................          24             0.12         0.05           0.5          72,000,000      41,904,656       56,837,465
9..............................          24             0.14         0.05           0.5          84,000,000      45,690,434       64,379,006
10.............................          24             0.16         0.05           0.5          96,000,000      48,801,532       71,433,016
                                ------------------------------------------------------------------------------------------------------------------------
    Total......................  ..........  ...............  ...........  ............      432,000,000.00     259,518,595      344,993,527  PV
                                 ..........  ...............  ...........  ............  ..................      36,949,610       40,443,766  Ann
--------------------------------------------------------------------------------------------------------------------------------------------------------


[[Page 1413]]


 
                                   Cost of    Proportion of
                                 ambulatory   admissions for   Increased      Assumed        Incremental       Incremental     Incremental
   Year impacts are incurred      sensitive     which more    sensitivity   costs saved        impacts         impacts (7%     impacts (3%
                                  admission  sensitive model   of models   for impacted   (undiscounted) *      discount)       discount)
                                    (bn)           used           used      admissions
--------------------------------------------------------------------------------------------------------------------------------------------------------
1..............................  ..........  ...............  ...........  ............  ..................  ..............  ...............
2..............................  ..........  ...............  ...........  ............  ..................  ..............  ...............
3..............................       $33.7             0.02         0.05           0.5         $16,850,000     $13,754,619      $15,420,136
4..............................        33.7             0.04         0.05           0.5          33,700,000      25,709,569       29,942,014
5..............................        33.7             0.06         0.05           0.5          50,550,000      36,041,451       43,604,874
6..............................        33.7             0.08         0.05           0.5          67,400,000      44,911,466       56,446,439
7..............................        33.7              0.1         0.05           0.5          84,250,000      52,466,666       68,502,960
8..............................        33.7             0.12         0.05           0.5         101,100,000      58,841,120       79,809,274
9..............................        33.7             0.14         0.05           0.5         117,950,000      64,156,985       90,398,854
10.............................        33.7             0.16         0.05           0.5         134,800,000      68,525,485      100,303,860
                                ------------------------------------------------------------------------------------------------------------------------
    Total......................  ..........  ...............  ...........  ............         606,600,000     364,407,361      484,428,410  PV
                                 ..........  ...............  ...........  ............  ..................      51,883,410       56,789,788  Ann
--------------------------------------------------------------------------------------------------------------------------------------------------------


Table 19--Select Benefits From Updated Decision Support Functionality Under Alternative Assumptions, $ Millions,
                                          Annualized, 3% Discount Rate
----------------------------------------------------------------------------------------------------------------
                                                                            Impact on model sensitivity
             Impact on annual model application (%)              -----------------------------------------------
                                                                       2.50%            5%              10%
----------------------------------------------------------------------------------------------------------------
1...............................................................           $24.3           $48.6           $97.2
2...............................................................            48.6            97.2           194.5
3...............................................................            72.9           145.9           291.7
----------------------------------------------------------------------------------------------------------------

    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.\292\ We further note that provider burnout and fatigue are 
important and costly issues, we believe these benefits may be 
large.\293\ 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.
---------------------------------------------------------------------------

    \292\ Ong, Mei-Sing, and Kenneth D. Mandl. ``National 
expenditure for false-positive mammograms and breast cancer 
overdiagnoses estimated at $4 billion a year.'' Health affairs 34.4 
(2015): 576-583.
    \293\ Gregory, Megan E., Elise Russo, and Hardeep Singh. 
``Electronic health record alert-related workload as a predictor of 
burnout in primary care providers.'' Applied clinical informatics 
8.03 (2017): 686-697.
---------------------------------------------------------------------------

    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.\294\ 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.
---------------------------------------------------------------------------

    \294\ Richard Rib[oacute]n Fletcher, et al., Addressing 
fairness, bias, and appropriate use of artificial intelligence and 
machine learning in global health, 3 Frontiers in Artificial 
Intelligence (2021).
---------------------------------------------------------------------------

    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

[[Page 1414]]

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 
Sec.  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 Sec.  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 Sec.  170.215(c)(2), 
which would replace SMART Application Launch Framework Implementation 
Guide Release 1.0.0 in Sec.  170.215(a)(3) (finalized in this rule in 
Sec.  170.215(c)(1)).
    We also have finalized as proposed, to revise the requirement in 
Sec.  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 Sec.  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.

[[Page 1415]]



         Table 20--Estimated Labor Hours To Update Standardized API for Patient and Population Services
----------------------------------------------------------------------------------------------------------------
                                                                      Lower    Upper
                  Task                             Details            bound    bound            Remarks
                                                                      hours    hours
----------------------------------------------------------------------------------------------------------------
Task 1: Implementation to the FHIR US    Implement FHIR US Core IG       500    1,000  (1) Lower bound assumes
 Core IG 6.1.0 (per product).             v6.1.0 to update API to                       health IT product
                                          conform to US Core                            voluntarily updated to
                                          v6.1.0, which adopts the                      USCDIv3 through SVAP.
                                          USCDIv3 data classes and                      (2) Upper bound assumes
                                          elements.                                     health IT product only
                                                                                        supports USCDIv1 and
                                                                                        needs to update API to
                                                                                        support resources
                                                                                        aligned with data
                                                                                        elements in USCDIv3.
Task 2: Service-base URL Publication     (1) Publish service-base        250    1,000  (1) Lower bound assumes
 (per developer).                         URL in FHIR Endpoint                          API Technology Supplier
                                          resource format (2)                           met the ONC Cures Act
                                          Publish API Information                       Final Rule service-base
                                          Source organization                           URL maintenance of
                                          information in                                certification
                                          Organization resource                         requirement and
                                          format (3) Make both                          published endpoint and
                                          available as FHIR bundle.                     organization data in
                                                                                        these standard formats.
                                                                                        (2) Upper bound assumes
                                                                                        API Technology Supplier
                                                                                        met the Cures Final Rule
                                                                                        service-base URL
                                                                                        maintenance of
                                                                                        certification
                                                                                        requirement but did not
                                                                                        publish in the standard
                                                                                        format.
Task 3: Develop support of 60-minute     Develop support for              50      100  (1) Lower bound assumes
 access revocation (per product).         patients to revoke access                     developer needs to
                                          to authorized app and for                     modify current
                                          revocation to be                              revocation process and
                                          fulfilled by server                           not rebuild is
                                          within 60 minutes of                          necessary. (2) Upper
                                          request.                                      bound assumes revocation
                                                                                        process exists, as
                                                                                        required by ONC Cures
                                                                                        Act Final Rule, but
                                                                                        needs to be reprogrammed
                                                                                        to accommodate new
                                                                                        revocation step.
Task 4: Update security via SMART App    Update API from SMART App       500    1,000  (1) Lower bound assumes
 Launch Framework to IG 2.0 (per          Launch Framework IG 1.0                       update to SMART App
 product).                                to IG 2.0.                                    Launch Framework IG 2.0
                                                                                        underway. (2) Upper
                                                                                        bound assumes update to
                                                                                        Framework IG 2.0 not
                                                                                        underway.
----------------------------------------------------------------------------------------------------------------


  Table 21--Example Calculation for the Lower Bound Estimated Cost to Products To Perform Task 1 in Table 20 To
                                                   Update API
                                                 [2022 Dollars]
----------------------------------------------------------------------------------------------------------------
                                                               Estimated labor
                                                                    hours          Developer        Projected
                           Activity                           -----------------   salary (per        products
                                                                 Lower bound         hour)
----------------------------------------------------------------------------------------------------------------
Task 1.......................................................             500             $128              276
Example calculation: 500 * $128 * 276 products = $17,664,000.
----------------------------------------------------------------------------------------------------------------


     Table 22--Total Cost To Update Standardized API for Patient and
                           Population Services
                             [2022 Dollars]
------------------------------------------------------------------------
                                                  Estimated cost
                Activity                 -------------------------------
                                            Lower bound     Upper bound
------------------------------------------------------------------------
Task 1 (276 products)...................     $17,664,000     $35,328,000
Task 2 (228 developers).................       7,296,000      29,184,000
Task 3 (276 products)...................       1,766,400       3,532,800
Task 4 (276 products)...................      17,664,000      35,328,000
                                         -------------------------------
    Total (276 products and 228               44,390,400     103,372,800
     developers)........................
------------------------------------------------------------------------

    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

[[Page 1416]]

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.\295\ 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.\296\ 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.
---------------------------------------------------------------------------

    \295\ CMS Digital Quality Roadmap, March 2022: https://ecqi.healthit.gov/sites/default/files/CMSdQMStrategicRoadmap_032822.pdf.
    \296\ Health Aff (Millwood), March 2016. US Physician Practices 
Spend More Than $15.4 Billion Annually To Report Quality Measures. 
https://pubmed.ncbi.nlm.nih.gov/26953292/.
---------------------------------------------------------------------------

    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 
(Sec.  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 Sec.  170.315(a)(5)(i)(F), ``Name to Use'' in Sec.  
170.315(a)(5)(i)(G), and ``Pronouns'' in Sec.  170.315(a)(5)(i)(H) to 
the ``Patient demographics and observations'' certification criterion 
(Sec.  170.315(a)(5)). Additionally, we have finalized as proposed to 
replace the terminology standards specified for ``Sex'' in Sec.  
170.315(a)(5)(i)(C), ``Sexual Orientation'' in Sec.  
170.315(a)(5)(i)(D), and ``Gender Identity'' in Sec.  
170.315(a)(5)(i)(E). As such, ONC has finalized as proposed to remove 
the fixed list of terms for ``Sex'' in Sec.  170.315(a)(5)(i)(C), 
``Sexual Orientation'' in Sec.  170.315(a)(5)(i)(D), and ``Gender 
Identity'' in Sec.  170.315(a)(5)(i)(E) which are represented by SNOMED 
CT and HL7[supreg] Value Sets for AdministrativeGender and NullFlavor 
in Sec.  170.207(o)(1) and (2)), and replace it with the SNOMED CT code 
sets specified in Sec.  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.

[[Page 1417]]



              Table 23--Estimated Labor Hours To Modify Sec.   170.315(a)(5) Demographics Criterion
----------------------------------------------------------------------------------------------------------------
                                                                                       Lower bound   Upper bound
                      Task                                      Details                   hours         hours
----------------------------------------------------------------------------------------------------------------
Task 1: Modify Sex [Sec.   170.315(a)(5)(i)(C)].  Value set for Sex removed and now              0            40
                                                   references SNOMED CT.
Task 2: Modify Sexual Orientation [Sec.           Value set for Sexual Orientation               0            40
 170.315(a)(5)(i)(D)].                             removed and now references SNOMED
                                                   CT.
Task 3: Modify Gender Identity [Sec.              Value set for Gender Identity                  0            40
 170.315(a)(5)(i)(E)].                             removed and now references SNOMED
                                                   CT.
Task 4: Add Sex Parameter for Clinical Use [Sec.  Add ``Sex Parameter for Clinical             240           580
   170.315(a)(5)(i)(F)].                           Use'' using LOINC.
Task 5: Add Pronouns [Sec.                        Add ``Pronouns'' using LOINC......           240           580
 170.315(a)(5)(i)(H)].
Task 6: Add Name to Use [Sec.                     Add ``Name to Use'' as a kind of             240           580
 170.315(a)(5)(i)(G)].                             name field.
----------------------------------------------------------------------------------------------------------------


  Table 24--Example Calculation for the Lower Bound Estimated Cost to Products To Perform Task 1 in Table 23 To
                                               Modify Demographics
                                                 [2022 dollars]
----------------------------------------------------------------------------------------------------------------
                                                           Estimated labor
                                                                hours         Developer salary      Projected
                         Activity                         -----------------      (per hour)          products
                                                             Lower bound
----------------------------------------------------------------------------------------------------------------
Task 1...................................................             200                 $128              321
Example calculation: 200 * $116 * 321 products =
 $7,447,200.
----------------------------------------------------------------------------------------------------------------


               Table 25--Total Cost To Modify Demographics
                             [2022 dollars]
------------------------------------------------------------------------
                                                  Estimated cost
                Activity                 -------------------------------
                                            Lower bound     Upper bound
------------------------------------------------------------------------
Task 1 (321 products)...................              $0      $1,643,520
Task 2 (321 products)...................               0       1,643,520
Task 3 (321 products)...................               0       1,643,520
Task 4 (321 products)...................       9,861,120      23,831,040
Task 5 (321 products)...................       9,861,120      23,831,040
Task 6 (321 products)...................       9,861,120      23,831,040
                                         -------------------------------
    Total (321 products and 261               29,583,360      76,423,680
     developers)........................
------------------------------------------------------------------------

    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 Sec.  
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 Sec.  
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 Sec.  170.207(n)(1) for the time-
period up to and including December 31, 2025; or Sec.  170.207(n)(2).

[[Page 1418]]

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.

          Table 26--Estimated Labor Hours To Modify Sec.   170.315(b)(1) Transitions of Care Criterion
----------------------------------------------------------------------------------------------------------------
                                                                                       Lower bound   Upper bound
                      Task                                      Details                   hours         hours
----------------------------------------------------------------------------------------------------------------
Task 1: Modify Sex [Sec.   170.315(a)(5)(i)(C)].  Value set for Sex removed and now              0            40
                                                   references SNOMED CT.
----------------------------------------------------------------------------------------------------------------


           Table 27--Total Cost To Modify Transitions of Care
                             [2022 dollars]
------------------------------------------------------------------------
                                                  Estimated cost
                Activity                 -------------------------------
                                            Lower bound     Upper bound
------------------------------------------------------------------------
Modify Sex (281 products)...............             $0      $1,438,720
------------------------------------------------------------------------

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

[[Page 1419]]

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

                             Table 28--Estimated Labor Hours To Modify 170.315(e)(1)
----------------------------------------------------------------------------------------------------------------
                                                                         Lower bound     Upper bound
                 Task                              Details                  hours           hours       Remarks
----------------------------------------------------------------------------------------------------------------
Task 1: Add internet-based method for   New technical functionality               240             580
 patients (and their authorized          to be added to criterion
 representatives) to request a           Sec.   170.315(e)(1). This
 restriction.                            is a standards agnostic
                                         method. Developer may choose
                                         internet-based method of
                                         choice (e.g., free-text box,
                                         check boxes for applicable
                                         data classes, etc.).
----------------------------------------------------------------------------------------------------------------


              Table 29--Total Cost To Modify 170.315(e)(1)
                             [2022 dollars]
------------------------------------------------------------------------
                                                 Estimated cost
               Activity                ---------------------------------
                                          Lower bound      Upper bound
------------------------------------------------------------------------
Task 1 (246 products).................      $7,557,120      $18,263,040
------------------------------------------------------------------------

    The cost to a health IT developer to modify Sec.  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 Sec.  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 Sec.  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.
    Response. The final impact analysis was updated to reflect the 
final policy to include the ability for patients to request 
restrictions for their information in the ``view, download, and 
transmit'' criterion.
Insights Condition and Maintenance of Certification Requirements
    The ``Insights Condition'' calls for developers of certified health 
IT to report for each applicable product on measures which focus on 
interoperability. For the initial requirements of the Insights 
Condition, ONC proposed nine measures that relate to individual access 
to electronic health information, clinical care information exchange, 
public health information exchange, and standards adoption and 
conformance.
Alternatives
    Section 4002(c) of the Cures Act requires the creation of an 
Electronic Health Record (EHR) Reporting Program. We have chosen to 
implement the developer reporting through ONC's Health IT Certification 
Program to integrate this legislative mandate with other reporting 
requirements for developers of certified health IT as a Condition and 
Maintenance of Certification requirement. This approach is aligned with 
how we have interpreted other similar provisions of the Cures Act, and 
it is intended to maximize participation among developers of certified 
health IT while aligning participation with other requirements of the 
Program. Other alternatives to implementing this provision of the Cures 
Act could be to conduct a survey of developers of certified health IT 
to report on measures; however, such an effort would reflect only those 
developers who participated in the survey, thus limiting the 
generalizability of the results. A survey approach would also 
complicate ONC's ability to standardize developer results reporting and 
thus the quality and the rigor of the data would be affected. Thus, in 
order to be consistent with ONC's implementation of other Cures Act 
Condition and Maintenance of Certification requirements, to maximize 
the generalizability and accuracy of the data gathered through this 
effort, and to align it with other activities, we have chosen

[[Page 1420]]

to implement the Condition and Maintenance of Certification through 
ONC's Health IT Certification Program.
Costs
    In calculating the cost of reporting each measure m we applied the 
following expression:

Cm = #Hours x Wage x # of Developers

    The data for each of the elements (e.g., #hours, wages, 
#developers) were extracted from various sources and there are 
assumptions associated with each element, which are described in this 
section.
    The #Hours represents the labor hours it takes to produce measure 
m. The developers of certified health IT were asked the average number 
of hours they would need to develop and report a measure. Based on 
their reporting, we created a lower bound that represents 25% less than 
the reported number and an upper bound that represents 35% more than 
the reported number. We adjusted the number of hours required for 
developing each measure according to the difficulty level as ranked by 
developers of certified health IT.\297\ We attributed more hours to 
skillful labor categories (from administrators to programmers and 
managers) than what was provided by developers as we believe these will 
be more accurate estimates.
---------------------------------------------------------------------------

    \297\ Blavin F., et al. 2020. Urban Institute. Electronic Health 
Record (EHR) Reporting Program: Developer-Reported Measures. 
Available at https://www.urban.org/sites/default/files/publication/105427/electronic-health-record-ehr-reporting-program-developer-reported-measures.pdf. Accessed March 16, 2023.
---------------------------------------------------------------------------

    The Wage represents hourly wage of a particular occupation needed 
to produce a measure. The wage estimates were extracted from the 2022 
Bureau of Labor Statistics data and multiplied by two to account for 
administrative and other indirect costs, representing the median hourly 
wage of a software developer ($128) and a management analyst ($101) 
(the numbers incorporate other indirect costs of labor).\298\ We 
assumed that the time used only by these occupations was sufficient for 
completing the task. The number of health IT developers is a function 
of the finalized small developer threshold and certified criteria 
requirements, which are described in more detail in section III.F.3 of 
this preamble under Associated Thresholds for Health IT Developers. We 
used data from the 2019 CMS Promoting Interoperability (PI) program and 
the Certified Health IT Product List to estimate the number of 
developers that would be reporting measures to the program. Per the 
finalized small developer threshold, developers whose certified health 
IT products were used by at least 50 hospitals, or 500 clinicians would 
have to report measures to the Program. In addition to having these 
minimum number of users across their certified health IT products, per 
the policy, we limited developers to those with products that certify 
to at least one of the following criteria associated with the adopted 
measures (see Table 30):
---------------------------------------------------------------------------

    \298\ See BLS at https://www.bls.gov/oes/current/oes_nat.htm. 
Accessed September 15, 2023.

<bullet> Transitions of care Sec.  170.315(b)(1)
<bullet> Clinical information reconciliation and incorporation Sec.  
170.315(b)(2)
<bullet> Transmission to immunization registry Sec.  170.315(f)(1)
<bullet> View, download, and transmit to 3rd party Sec.  170.315(e)(1)
<bullet> Standardized API for patient and population services Sec.  
170.315(g)(10)

    For each measure, the estimated the number of developers of 
certified health IT depended on whether developers' products certified 
to criteria associated with a particular measure (as shown in Table 31) 
and whether they meet the threshold requirement for a small developer.

                                     Table 30--Estimated Number of Hours and Developers Associated for Each Measure
                                                                     [per developer]
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                            Estimated                          Management analyst    Software developer
                                                                            number of     Estimated  number   estimated hours (per  estimated hours (per
                                                                           applicable       of applicable          developer)            developer)
                 Measure                         Related criterion       developers  of     developers  of   -------------------------------------------
                                                                            certified     certified  health
                                                                          health IT (no     IT (threshold       Lower      Upper      Lower      Upper
                                                                           threshold)          applied)         bound      bound      bound      bound
--------------------------------------------------------------------------------------------------------------------------------------------------------
Individuals' Access to EHI...............  Sec.   170.315(e)(1); Sec.               157                   53        320        800      1,100      2,220
                                            170.315(g)(10).
Immunization Submission to IIS...........  Sec.   170.315(f)(1)........             115                   37        480      1,200      2,800      5,600
Immunization History and Forecasts.......  Sec.   170.315(f)(1)........             115                   37        470      1,200      1,380      2,760
C-CDAs Reconciliation and Incorporation..  Sec.   170.315(b)(1); Sec.               171                   56        400      1,400      3,200      8,700
                                            170.315(b)(2).
Apps Supported...........................  Sec.   170.315(g)(10).......             176                   59        320        800      1,850      3,700
Use of FHIR in in Apps...................  Sec.   170.315(g)(10).......             176                   59        400      1,000      2,300      4,600
Use of FHIR Bulk Data Access.............  Sec.   170.315(g)(10).......             176                   59        400      1,000      2,300      4,600
--------------------------------------------------------------------------------------------------------------------------------------------------------
Data Source: ONC analysis of 2019 CMS Promoting Interoperability Program Data & CHPL.

    We decided the small developer thresholds based upon analyses we 
conducted of the 2019 CMS PI Program and Certified Health IT Product 
List. We examined the various alternatives for setting user thresholds 
based on the percentage of users and developers that would be 
represented and reporting measures, respectively in the Program (see 
Table 31 below). The thresholds we decided upon maximize coverage and 
while not unduly disadvantaging smaller developers. The thresholds were 
determined based upon analysis of 2019 CMS PI program data and the CHPL 
data. The data from the CMS PI program included 4,209 non-federal acute 
hospitals and 691,381 clinicians who attested to the program. After 
limiting hospitals and clinicians to those using existing 2015 Edition 
certification criteria, the 2015 Edition Cures Update criteria, or a 
combination of the two; and to those products of developers who had 
certified to at least one of the criteria associated with the measures 
adopted in the Program (see Table 30), we ended up with 3,863 hospitals 
and 689,801 clinicians. For example, based upon a threshold of 50 
hospitals, we would be able to include approximately 99% of all 
hospital users and the top 18 developers (based upon market share) 
while excluding the bottom 33 developers (based upon market share). 
This 99% value is based upon the percentage of users who are not 
exclusively using products from developers who meet the small developer 
threshold. Thus, in the case of a 50-hospital threshold, only 1.4% of 
hospital users are exclusively using

[[Page 1421]]

products from small developers, and thus about 99% of the inpatient 
market is covered.

                               Table 31--Thresholds Options at the Developer Level
----------------------------------------------------------------------------------------------------------------
                                                     Estimated
                                                     number of     Estimated  %      Estimated       Estimated
                                                    users only    of  users only     number of       number of
                                                    using small     using small        small         remaining
                                                    developers      developers      developers      developers
----------------------------------------------------------------------------------------------------------------
Hospitals:
    Option (a) 100 Threshold....................             142             3.7              39              12
    Option (b) 50 Threshold.....................              56             1.4              33              18
Clinicians:
    Option (a) 2,000 Threshold..................          21,075             3.1             176              31
    Option (b) 1,000 Threshold..................          11,251             1.6             160              47
    Option (b) 500 Threshold....................           7,828             1.1             146              61
----------------------------------------------------------------------------------------------------------------

    In calculating the aggregate cost of developing all measures, we 
applied the concept of economies of scope, where the total cost of 
production is not incrementally increasing in the number of measures, 
but it is rather attenuating. Specifically, the aggregate cost in this 
application is governed by the following expression: The total cost 
(TC) of producing measures 1 and 2 is the sum of producing the two 
measures separately minus the cost of producing them together.
    To calculate the cost of producing measures together, developers of 
certified health IT were asked during discussions to provide an 
estimate on the extent to which there would be an overlap in developing 
infrastructure between the measures published by the Urban Institute 
and level of difficulty by measure.\299\ While some measures we have 
finalized differ from those the Urban Institute published, there is 
significant overlap across many of the measures, which would retain the 
validity of these estimates. The weighted average for selected measures 
suggested that there would be considerable overlap on the immunization 
measures (see Table 32). We note that for the incorporation measure, 
there is overlap between the proposed measure and the CMS PI Program 
Measure. We welcomed comments that provide us information on the level 
of perceived overlap so that we can adjust the estimates accordingly 
for the costs associated with that measure.
---------------------------------------------------------------------------

    \299\ Blavin F., et al. 2020. Urban Institute. Electronic Health 
Record (EHR) Reporting Program: Developer-Reported Measures. 
Available at https://www.urban.org/sites/default/files/publication/105427/electronic-health-record-ehr-reporting-program-developer-reported-measures.pdf. Accessed March 16, 2023.

  Table 32--Percent Overlap in Developing the Following Combination of
                                Measures
------------------------------------------------------------------------
                                                             Percent
------------------------------------------------------------------------
Immunization Submission to IIS and Immunization History              50
 and Forecasts.........................................
------------------------------------------------------------------------

    Additionally, we assessed that there will be a 10% overlap of 
developing infrastructure across all measures. We applied these rates 
accordingly when calculating the total cost of developing measures for 
the Insights Condition.
    Following this approach, the aggregate cost estimates over a 10-
year period to develop and report on these measures are presented by 
different alternatives associated with thresholds in Table 33. The 
first row shows the total cost assuming developers have at least 50 
hospital or 500 clinician users, which generates the cost between $98 
and $218 million. In addition to estimating the costs associated with 
the 50 hospitals or 500 clinician user thresholds, we also present the 
cost for two alternatives where the number of users for hospitals is 
100 and for clinician ranges from 1000 to 2000. The total cost would be 
reduced by about a half compared to the previous specification because 
smaller number of developers would qualify for the Insights Condition.

    Table 33--Aggregate Cost Estimates for the Insights Condition by
                         Threshold Alternatives
------------------------------------------------------------------------
                 Options                    Lower bound     Upper bound
------------------------------------------------------------------------
50 Hospitals and 500 Clinicians              $98,373,673    $218,671,106
 Threshold (Proposed Approach)..........
100 Hospitals and 1000 Clinicians             69,268,381     153,852,086
 Threshold (Alternative 1)..............
100 Hospitals and 2000 Clinicians             47,638,637     105,007,568
 Threshold (Alternative 2)..............
No Threshold Applied....................     297,027,045     660,807,830
------------------------------------------------------------------------

    In Table 30, we present the estimated number of labor hours to 
develop and report by measure for each individual developer. This table 
served as the basis for the cost estimates, prior to adjusting as 
described above.
    In Table 34, we present cost estimates for each individual measure 
by developer and across all developers. The measures vary in cost 
because we made adjustments based on synergies discussed above (e.g., 
similar measures, common infrastructure) and the level of

[[Page 1422]]

expected burden to develop each measure.

 Table 34--Estimated Costs by Measure per Developer of Certified Health IT and Across All Eligible Developers of
                                               Certified Health IT
                                                 [No threshold]
----------------------------------------------------------------------------------------------------------------
                                                       Estimated costs (per         Total estimated costs (all
                                Number eligible             developer)                 eligible developers)
           Measure                 developers    ---------------------------------------------------------------
                                                    Lower bound     Upper bound     Lower bound     Upper bound
----------------------------------------------------------------------------------------------------------------
Individuals' Access to EHI...                157        $169,924        $353,846     $26,678,005     $55,553,791
Immunization Submission to                   115         360,023         739,508      41,425,606      85,043,311
 IIS.........................
Immunization History and                     115         109,227         228,908      12,561,105      26,324,363
 Forecasts...................
C-CDAs Reconciliation and                    171         402,305       1,116,610      68,794,070     190,940,267
 Incorporation...............
Applications Supported.......                176         238,088         488,773      41,903,326      86,024,030
Use of FHIR in Apps..........                176         300,186         616,256      52,832,657     108,461,034
Use of FHIR Bulk Data Access.                176         300,186         616,256      52,832,567     108,461,034
                              ----------------------------------------------------------------------------------
    All Measures: Total Cost.  .................       1,880,136       4,160,155     297,027,425     660,807,830
----------------------------------------------------------------------------------------------------------------


 Table 35--Estimated Costs by Measure per Developer of Certified Health IT and Across All Eligible Developers of
                                               Certified Health IT
                                               [Threshold applied]
----------------------------------------------------------------------------------------------------------------
                                                       Estimated costs (per         Total estimated costs (all
                                Number eligible             developer)                 eligible developers)
           Measure                 developers    ---------------------------------------------------------------
                                                    Lower bound     Upper bound     Lower bound     Upper bound
----------------------------------------------------------------------------------------------------------------
Individuals' Access to EHI...                 53        $169,924        $353,846      $9,005,951     $18,753,827
Immunization Submission to                    37         260,223         739,508      13,328,238      27,361,761
 IIS.........................
Immunization History and                      37         109,227         228,908       4,041,399       8,469,578
 Forecasts...................
C-CDAs Reconciliation and                     56         402,305       1,116,610      22,529,052      62,530,146
 Incorporation...............
Apps Supported...............                 59         238,088         488,773      14,047,138      28,837,601
Use of FHIR in Apps..........                 59         300,186         616,256      17,710,948      36,359,097
Use of FHIR Bulk Data Access.                 59         300,186         616,256      17,710,948      36,359,097
                              ----------------------------------------------------------------------------------
    All Measures: Total Cost.  .................       1,880,136      4,160,1550      98,373,673     218,671,106
----------------------------------------------------------------------------------------------------------------

    For the Insights Condition of Certification, we have indicated that 
developers of certified health IT who were required to report for 
Insights could leverage relevant Insights measures for real world 
testing annual reporting. We recognize some overlap in the two 
Conditions of Certification and that Insights measures would be 
appropriate to meet real world testing requirements for applicable 
certification criteria. An analysis of the CHPL shows that among 
developers required to report for Insights, 25% to 50% of their real 
world testing reporting requirements could be satisfied leveraging 
Insights metrics. Considering this we estimate that 25% to 50% of an 
average developer's annual real world testing costs could be saved by 
using Insights reporting as part of their real world testing plans.
    We estimated cost savings for developers required to report for 
Insights. Cost savings were modeled using the real world testing cost 
estimates we have finalized in the ONC Cures Final Rule. We estimated 
in that final rule that a developer, on average, would face annual 
costs of $109,557 (2017 dollars) to meet real world testing reporting 
requirements. In 2022 dollars, we estimate this is $130,811 in annual 
costs. In Table 36 we show the impact of these cost savings on the 
total 10-year cost of developers to meet Insights requirements. We 
estimate this flexibility in meeting both Insights and real world 
testing reporting requirements will yield $13.6 million to $27.4 
million in cost savings in total. We estimate these costs savings will 
reduce the overall total cost of developers reporting for Insights. The 
total cost of Insights is estimated to be $84.7 million to $191.2 
million.

   Table 36--Estimated Cost Savings From Reporting for Both Real World
                          Testing and Insights
------------------------------------------------------------------------
              Options                   Lower bound       Upper bound
------------------------------------------------------------------------
50 Hospitals and 500 Clinicians           $98,373,673       $218,671,106
 Threshold (No Cost Savings
 applied)..........................
50 Hospitals and 500 Clinicians            84,735,783        191,233,443
 Threshold (Cost Savings applied)..
------------------------------------------------------------------------

Benefits
    The ONC Cures Act Final Rule seeks to advance interoperability and 
support the access, exchange, and use of electronic health information. 
There is currently limited transparency and information regarding 
interoperability; this not only stymies informed decision-making by ONC 
but also others in the industry, including health care providers, and 
entities that enable

[[Page 1423]]

exchange, including various types of health information networks and 
health app developers. ONC's measurement of interoperability is 
currently reliant primarily on self-reported survey data from end users 
of health information technology. While this information does provide 
some insights on interoperability from end-user perspectives, the 
insights derived are limited. The adopted measures will provide system-
generated metrics on interoperability that will complement self-
reported, user perspective data sources, such as surveys. Through the 
Insights Condition section of this final rule, we have identified where 
surveys have been limited in providing a clear picture of certain 
aspects of interoperability that these measures will elucidate. In 
addition, they will reach a greater number of health care providers 
than surveys, giving a more complete and representative national 
perspective. Greater transparency and information on interoperability 
of health IT products has the potential to benefit several interested 
parties, including ONC and other entities that enable exchange, 
including health app developers and health information networks. The 
adopted measures are also designed to identify areas that are working 
well and problems that we can monitor over time. This will help 
identify the need for technical and policy solutions as well as spur 
innovation that builds on successes and addresses gaps. While we 
currently do not have a means to quantify these benefits, we welcomed 
any feedback on methods to better quantify the impact these measures 
can have for healthcare and health IT.
    The measures in this final rule for the Insights Condition will 
help improve and inform ONC programmatic and regulatory decision-
making. ONC's programs and policies are designed to make direct and 
positive impacts on health IT use, care delivery, and patient health. 
ONC does this primarily through supporting standards development and 
the Program. The adopted measures will help ONC and others better 
understand the use, progress, and value of health IT standards. This 
has practical implications for improving the work ONC leads that 
increases the use of standards. For example, ONC has limited empirical 
information to provide guidance on the usage of standards associated 
with the Interoperability Standards Advisory. With the addition of the 
adopted measures, ONC can provide guidance to industry that is grounded 
in data from health IT developers rather than anecdotes. This has the 
potential to move industry to adopt standards more quickly, which has 
downstream impacts on improved interoperability. In addition, the 
adopted measures will increase transparency regarding the capability 
and usage of certified products. Through these measures, ONC and other 
interested parties will be able to identify areas that are problematic 
and in need of further investigation, such as cross-cutting policy and 
technical issues. They will also provide needed data to develop 
solutions to these complex problems.
    The adopted measures from the Insights Condition will focus on four 
key priority areas: individual access to electronic health information, 
clinical care information exchange, standards adoption and conformance, 
and public health information exchange. Under the individuals' access 
to electronic health information measurement area, the measure will 
inform on the ONC Cures Act Final Rule goal of increasing access of 
electronic health information to individuals, particularly through the 
use of third-party apps. Increased patient engagement has been 
associated with improved health outcomes, and improved ease of access 
to their own medical records can improve patient engagement.\300\ Thus, 
a better understanding of how patients are using apps through certified 
health IT will help inform ONC and other interested parties on the 
progress to reaching this goal. In addition, this measure will help 
inform app developers and developers of certified health IT, who are 
supporting apps on what individual's needs are to access their EHI. It 
will also inform health care provider organizations regarding action 
they may need to consider in supporting EHI and the need for outreach 
to patients and caregivers.
---------------------------------------------------------------------------

    \300\ Health Affairs. (2013). Health Policy Brief: Patient 
Engagement. Accessed March 16, 2023, at: http://healthaffairs.org/healthpolicybriefs/brief_pdfs/healthpolicybrief_86.pdf.
---------------------------------------------------------------------------

    The clinical care information exchange measure will help ONC and 
other interested parties better understand the volume of information 
exchanged using C-CDA documents and how the information exchange is 
subsequently used via incorporation and reconciliation. Understanding 
the rates of C-CDA document incorporation is valuable for interested 
parties supporting C-CDA document exchange (e.g., is it incorporated 
and used). This measure can also support further development in the 
incorporation of C-CDA documents.
    Currently, ONC has limited data on the use of certified API 
technology in the app market. The ONC Cures Act Final Rule established 
the rules for the use of certified API technology in such a way to 
increase access to health information for both patients and health care 
providers. By understanding which apps are using FHIR-based APIs and 
the volume of transfer of FHIR resources, ONC and standards development 
organizations (SDOs) will be able to prioritize their work toward high-
use data elements as well as explore why some data elements may not 
have as much use as anticipated. This will not only benefit ONC and 
SDOs, but in the long-term this will benefit patient care as exchange 
at the data element level is likely to be less cumbersome than 
document-based exchange. In addition, these measures are expected to 
increase transparency in the health IT app market which should lead to 
improved efficiencies, more competition, and better use of data. 
Greater transparency will inform decision-making among app developers, 
patients, health care providers, and other key parties (e.g., CARIN 
Alliance). Through better insights into the intersections of health IT 
and the app market, gaps as well as areas of strength can be identified 
that may spur further innovations in the market.
    The ONC Cures Act Final Rule also introduced certification criteria 
and policies for the exchange of bulk patient health information. The 
goal of these functionalities is to make patient data requests easier 
and less expensive as well as allow health care providers a greater 
choice of health IT applications. Understanding how these 
functionalities are being used will allow ONC and others to assess the 
progress toward those goals and identify where there may be areas in 
need of refinement. It will provide interested parties, such as 
Accountable Care Organizations (ACO), researchers, and others with 
interest in secondary use of certified health IT data with insights as 
to whether such data is easily moved out of health IT products to 
support a variety of use cases to advance patient care.
    Finally, because of the COVID-19 epidemic, there has been increased 
attention on the capabilities of health care providers to share public 
health information with public health agencies (PHA).\301\ There has 
been a focus on the electronic exchange of immunization data to an 
immunization information system (IIS) via certified health IT. The

[[Page 1424]]

adopted measures will identify trends and patterns in IIS' ability to 
receive immunization data to enable innovative solutions and improve 
the utility of IIS' and IIS data. Thus, this data would be beneficial 
to IIS registries to help make improvements to their systems and 
policies to better support exchange of immunization data. In addition, 
these measures can help support the numerous HHS efforts aimed at 
improving the flow of information between health care providers and 
PHAs, such as ONC's STAR HIE Program and the CDC's ongoing Data 
Modernization Initiative.
---------------------------------------------------------------------------

    \301\ Dixon BE, Caine VA, Halverson PK. Deficient Response to 
COVID-19 Makes the Case for Evolving the Public Health System. 
American Journal of Preventive Medicine. 2020;59(6):887-891. https://doi.org/10.1016/j.amepre.2020.07.024.
---------------------------------------------------------------------------

    Comments. We did not receive specific comments related to the 
Insights impact analysis. Commenters did, however, raise general 
concerns about the overall cost of the rulemaking, including costs 
estimated for Insights.
    Response. We updated the Insights impact analysis based upon 
updates to the condition of certification, as adopted in this final 
rule. The impact analysis reflects reduced costs, as well as cost 
savings, to implement this finalized Condition of Certification.
Information Blocking Enhancements
    We proposed in section IV of this preamble several enhancements 
with respect to the information blocking provisions in the ONC Cures 
Act Final Rule. These include defining in regulation text what it 
means, and what it does not mean, to ``offer'' health IT. The 
enhancements also include updating the Infeasibility (45 CFR 171.204) 
and Manner (45 CFR 171.301, formerly known as the ``Content and 
Manner'') Exceptions for clarity and to add more ways for actors' 
practices to satisfy these exceptions and thus not be considered 
``information blocking'' for purposes of 45 CFR part 171.
Costs
    We expect ONC to incur an annual cost for issuing educational 
resources related to the proposed information blocking enhancements. We 
estimate that ONC would issue educational resources each quarter, or at 
least four times per year. We assume that the resources would be 
provided by ONC staff with the expertise of a GS-15, Step 1 federal 
employee(s). The hourly wage with benefits for a GS-15, Step 1 employee 
located in Washington, DC is approximately $142.\302\ We estimate it 
would take ONC staff between 100 and 200 hours to develop resources 
each quarter, or 400 to 800 hours annually. Therefore, we estimate the 
annual cost to ONC would, on average, range from $56,800 to $113,600.
---------------------------------------------------------------------------

    \302\ Office of Personnel and Management. https://www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/salary-tables/pdf/2022/DCB.pdf. Accessed March 16, 2023.
---------------------------------------------------------------------------

Benefits
    Currently, ONC has limited data and research available to 
reasonably estimate the benefits of how often an actor may avail itself 
of one of the permitted exceptions or the costs for an actor to meet a 
condition to an exception.
    We anticipate that the adopted information blocking enhancements 
will enable actors to determine more easily and with greater certainty 
whether their practices (acts or omissions) that may or do interfere 
with access, exchange, or use of EHI (as defined in 45 CFR 171.102) 
meet the conditions to be considered a ``reasonable and necessary'' 
activity under an information blocking exception. As such, we expect 
these policies will further ease the burden and costs of complying with 
the information blocking regulations, while providing increased 
predictability. This predictability will permit regulated entities to 
plan and invest resources in developing and using interoperable 
technologies and services to improve healthcare efficiency and value 
more effectively. Additionally, we anticipate as a result of the 
revised definitions and exceptions, there will be reduced interference 
with the access, exchange, and use of electronic health information 
because of the added clarity the policies will provide the market 
regarding certain practices. Thus, we anticipate an increase in the 
overall benefits derived from reducing the prevalence of information 
blocking. We welcomed comment on these conclusions and the supporting 
rationale.
Total Annual Cost Estimate
    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 above and throughout this RIA, would result 
in $437 million. The total undiscounted perpetual cost over a 10-year 
period for this final rule (starting in year two), based on the cost 
estimates outlined above, would result in $477 million. We estimate the 
total costs to health IT developers to be $914 million while the 
government (ONC) costs to be between $56,800 to $113,600.
Total Annual Benefit Estimate
    We estimate the total annual benefit for this final rule, based on 
the benefit estimates outlined above, would be on average $1.0 billion.
Total Annual Net Benefit
    We estimate the total undiscounted perpetual annual net benefit for 
this final rule (starting in year three), based on the estimates 
outlined above, would result in a net benefit of $124 million.
b. Accounting Statement and Table
    When a rule is considered significant under Section 3(f)(1) under 
Executive Order 12866 and E.O. 14094, we are required to develop an 
accounting statement indicating the classification of the expenditures 
associated with the provisions of the final rule. Monetary annual 
effects are presented as discounted flows using 3% and 7% factors in 
Table 38 below. We are not able to explicitly define the universe of 
all costs but have provided an average of likely costs of this final 
rule as well as a high and low range of likely costs.

                   Table 37--E.O. 12866 Summary Table
                             [2022 Dollars]
------------------------------------------------------------------------
                                        Primary (3%)      Primary (7%)
------------------------------------------------------------------------
Present Value of Quantified Costs...      $853,114,341      $784,445,719
Present Value of Quantified Benefits       829,421,937       623,925,956
Present Value of Net Benefits.......        23,692,404       160,519,763
Annualized Quantified Costs.........       100,011,026       111,687,422
Annualized Quantified Benefits......       103,155,077       101,704,924
Annualized Net Quantified Benefits..         3,144,051         9,982,498
------------------------------------------------------------------------


[[Page 1425]]


                             Table 38--E.O. 12866 Summary Table Non-Discounted Flows
                                                 [2022 Dollars]
----------------------------------------------------------------------------------------------------------------
                                               Year 1        Year 2        Year 3        Year 4        Year 5
----------------------------------------------------------------------------------------------------------------
Costs.....................................  $437,500,845  $264,945,762   $50,769,243   $31,235,512   $21,692,039
Benefits..................................  ............  ............    28,850,000    57,700,000    86,550,000
----------------------------------------------------------------------------------------------------------------
                                                  Year 6        Year 7        Year 8        Year 9       Year 10
----------------------------------------------------------------------------------------------------------------
Costs.....................................    21,692,039    21,692,039    21,692,039    21,692,039    21,692,039
Benefits..................................   115,400,000   144,250,000   173,100,000   201,950,000   230,800,000
----------------------------------------------------------------------------------------------------------------

D. Regulatory Flexibility Act

    The Regulatory Flexibility Act (RFA) requires agencies to analyze 
options for regulatory relief of small entities, if a rule has a 
significant impact on a substantial number of small entities.
    The Small Business Administration (SBA) establishes the size of 
small businesses for Federal Government programs based on average 
annual receipts or the average employment of a firm.\303\ The entities 
that are likely to be directly affected by the requirements in this 
final rule requirements are health IT developers. We note that the 
finalized updates and clarifications to the reasonable and necessary 
activities that do not constitute information blocking will provide 
flexibilities and relief for health IT developers of certified health 
IT, health information networks, health information exchanges, and 
health care providers in relation to the information blocking provision 
of the Cures Act. We welcomed comments on the impact of our information 
blocking-related proposals on small entities.
---------------------------------------------------------------------------

    \303\ The SBA references that annual receipts mean ``total 
income'' (or in the case of a sole proprietorship, ``gross income'') 
plus ``cost of goods sold'' as these terms are defined and reported 
on Internal Revenue Service tax return forms.
---------------------------------------------------------------------------

    Comments. We received no comments on our approach.
    Response. We have finalized as proposed.
    While health IT developers that pursue certification of their 
health IT under the Program represent a small segment of the overall 
information technology industry, we believe that many health IT 
developers impacted by the requirements adopted in this final rule most 
likely fall under the North American Industry Classification System 
(NAICS) code 541511 ``Custom Computer Programming Services.'' \304\ OMB 
advised that the Federal statistical establishment data published for 
reference years beginning on or after January 1, 2022, should be 
published using the 2022 NAICS United States codes.\305\ The SBA size 
standard associated with this NAICS code is set at $34 million annual 
receipts or less. There is enough data generally available to establish 
that between 75% and 90% of entities that are categorized under the 
NAICS code 541511 are under the SBA size standard. We also note that 
with the exception of aggregate business information available through 
the U.S. Census Bureau and the SBA related to NAICS code 541511, it 
appears that many health IT developers that pursue certification of 
their health IT under the Program are privately held or owned and do 
not regularly, if at all, make their specific annual receipts publicly 
available. As a result, it is difficult to locate empirical data 
related to many of these health IT developers to correlate to the SBA 
size standard. However, although not perfectly correlated to the size 
standard for NAICS code 541511, we do have information indicating that 
over 60% of health IT developers that have had Complete EHRs and/or 
Health IT Modules certified to the 2011 Edition have less than 51 
employees.
---------------------------------------------------------------------------

    \304\ https://www.sba.gov/sites/sbagov/files/2023-06/Table%20of%20Size%20Standardslowbar;Effective%20March%2017%2C%202023%
20%282%29.pdf.
    \305\ https://www.sba.gov/article/2022/feb/01/guidance-using-naics-2022-procurement.
---------------------------------------------------------------------------

    We estimate that the finalized requirements in this final rule will 
have effects on health IT developers, some of which may be small 
entities, that have certified health IT or are likely to pursue 
certification of their health IT under the Program. We believe, 
however, that we have adopted the minimum number of requirements 
necessary to accomplish our primary policy goal of enhancing 
interoperability. Further, as discussed in this RIA above, there are 
very few appropriate regulatory or non-regulatory alternatives that 
could be developed to lessen the compliance burden associated with this 
final rule because at least a few of the policies are derived directly 
from legislative mandates in the Cures Act.
    We do not believe that the finalized requirements of this final 
rule will create a significant impact on a substantial number of small 
entities and we received no comments on whether there are small 
entities that we have not identified that may be affected in a 
significant way. The Predictive DSI policy within the criterion adopted 
in the criterion at Sec.  170.315(b)(11) and the Insights condition of 
certification represent the highest potential costs for health IT 
developers in our estimates. The finalized Decision Support 
Interventions policy establishes different requirements for developers 
of certified health IT that supply Predictive DSIs than those 
developers that do not supply Predictive DSIs. Many developers who 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 Sec.  
170.315(b)(11) while expending limited additional development resources 
on products they have certified currently. Specifically, these 
developers will likely have little to 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. Furthermore, the Insights Condition 
of Certification excludes small entities from reporting on the 
finalized measures. Small entities will face no additional costs for 
meeting the finalized measures, as described in the final policy and 
RIA for the Insights Condition.
    The Secretary certifies that this final rule will not have a 
significant impact on a substantial number of small entities.
    Comments. We received no comments.
    Response. We have finalized as proposed.

E. Executive Order 13132--Federalism

    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a final rule) that imposes 
substantial direct requirement costs on state and local governments, 
preempts state law, or otherwise has federalism implications.

[[Page 1426]]

Nothing in this final rule imposes substantial direct compliance costs 
on state and local governments, preempts state law, or otherwise has 
federalism implications. We are not aware of any state laws or 
regulations that are contradicted or impeded by any of the policies in 
this final rule.
    Comments. We received no comments.
    Response. We have finalized as proposed.

F. Unfunded Mandates Reform Act of 1995

    Section 202 of the Unfunded Mandates Reform Act of 1995 requires 
that agencies assess anticipated costs and benefits before issuing any 
rule that imposes unfunded mandates on state, local, and tribal 
governments or the private sector requiring spending in any one year of 
$100 million in 1995 dollars, updated annually for inflation. The 
current inflation-adjusted statutory threshold is approximately $177 
million in 2023. While the estimated potential cost effects of this 
final rule reach the statutory threshold, we do not believe this final 
rule imposes unfunded mandates on state, local, and tribal governments, 
or the private sector.
    Comments. We received no comments.
    Response. We have finalized as proposed.
    OMB reviewed this final rule.

List of Subjects

45 CFR Part 170

    Computer technology, Electronic health record, Electronic 
information system, Electronic transactions, Health, Healthcare, Health 
information technology, Health insurance, Health records, Hospitals, 
Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, 
Reporting and record keeping requirements, Public health, Security.

45 CFR Part 171

    Computer technology, Electronic health record, Electronic 
information system, Electronic transactions, Health, Healthcare, Health 
care provider, Health information exchange, Health information 
technology, Health information network, Health insurance, Health 
records, Hospitals, Privacy, Reporting and recordkeeping requirements, 
Public health, Security.

    For the reasons set forth in the preamble, 45 CFR subtitle A, 
subchapter D, is amended as follows:

PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION 
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION 
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

0
1. The authority citation for part 170 continues to read as follows:

    Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 553.

0
2. Amend Sec.  170.102 by:
0
a. Removing definitions for ``2015 Edition Base EHR'' and ``2015 
Edition health IT certification criteria''; and
0
b. Adding definitions for ``Base EHR'', ``ONC certification criteria 
for health IT'', ``Predictive Decision Support Intervention'', 
``Provide'', and ``Revised certification criterion (or criteria)'' in 
alphabetical order.
    The additions read as follows:


Sec.  170.102  Definitions.

    Base EHR means an electronic record of health-related information 
on an individual that:
    (1) Includes patient demographic and clinical health information, 
such as medical history and problem lists;
    (2) Has the capacity:
    (i) To provide clinical decision support;
    (ii) To support physician order entry;
    (iii) To capture and query information relevant to healthcare 
quality;
    (iv) To exchange electronic health information with, and integrate 
such information from other sources; and
    (3) Has been certified to the certification criteria adopted by the 
Secretary in--
    (i) Section 170.315(a)(1), (2), or (3); (a)(5) and (14), (b)(1), 
(c)(1), and (g)(7), (9), (10); and (h)(1) or (2);
    (ii) Section 170.315(a)(9) or (b)(11) for the period up to and 
including December 31, 2024; and
    (iii) Section 170.315(b)(11) on and after January 1, 2025.
* * * * *
    ONC certification criteria for health IT means the certification 
criteria in Sec.  170.315.
* * * * *
    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 produces an 
output that results in prediction, classification, recommendation, 
evaluation, or analysis.
* * * * *
    Provide means the action or actions taken by a developer of 
certified Health IT Modules to make the certified health IT available 
to its customers.
* * * * *
    Revised certification criterion (or criteria) means a certification 
criterion that meets at least one of the following:
    (1) Has added or changed the capabilities described in the existing 
criterion in this part;
    (2) Has an added or changed standard or implementation 
specification referenced in the existing criterion in this part; or
    (3) Is specified through notice and comment rulemaking as an 
iterative or replacement version of an existing criterion in this part.
* * * * *

0
3. Amend Sec.  170.205 by:
0
a. Revising paragraph (a)(5); and
0
b. Adding paragraphs (a)(6) and (t).
    The revision and additions read as follows:


Sec.  170.205  Content exchange standards and implementation 
specifications for exchanging electronic health information.

    (a) * * *
    (5) Standard. HL7 CDA[supreg] R2 Implementation Guide: C-CDA 
Templates for Clinical Notes R2.1 Companion Guide, Release 2 
(incorporated by reference, see Sec.  170.299). The adoption of this 
standard expires on January 1, 2026.
    (6) Standard. HL7[supreg] CDA[supreg] R2 Implementation Guide: C-
CDA Templates for Clinical Notes STU Companion Guide, Release 4.1--US 
Realm (incorporated by reference, see Sec.  170.299).
* * * * *
    (t) Public health--electronic case reporting--(1) Standard. 
HL7[supreg] FHIR[supreg] Implementation Guide: Electronic Case 
Reporting (eCR)--US Realm 2.1.0--STU 2 US (HL7 FHIR eCR IG) 
(incorporated by reference, see Sec.  170.299).
    (2) Standard. HL7 CDA[supreg] 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) (incorporated by 
reference, see Sec.  170.299).
    (3) Standard. HL7[supreg] CDA[supreg] R2 Implementation Guide: 
Reportability Response, Release 1, STU Release 1.1--US Realm (HL7 CDA 
RR IG) (incorporated by reference, see Sec.  170.299).
    (4) Standard. Reportable Conditions Trigger Codes Value Set for 
Electronic Case Reporting. (incorporated by reference, see Sec.  
170.299).

0
4. Amend Sec.  170.207 by:
0
a. Adding paragraph (a)(1);
0
b. Removing and reserving paragraph (a)(3);

[[Page 1427]]

0
c. Adding paragraph (c)(1);
0
d. Removing and reserving paragraph (c)(2);
0
e. Adding paragraphs (d)(1) and (4);
0
f. Adding paragraphs (e)(1) and (2), (f)(3)and (m)(2);
0
g. Revising paragraph (n)(1);
0
h. Adding paragraphs (n)(2) and (3);
0
i. Revising paragraphs (o)and (p); and
0
j. Adding paragraphs (r)(2) and (s)(2).
    The additions and revisions read as follows:


Sec.  170.207   Vocabulary standards for representing electronic health 
information.

    (a) * * *
    (1) Standard. SNOMED CT[supreg], U.S. Edition, March 2022 Release 
(incorporated by reference, see Sec.  170.299).
* * * * *
    (c) * * *
    (1) Standard. Logical Observation Identifiers Names and Codes 
(LOINC[supreg]) Database Version 2.72, a universal code system for 
identifying health measurements, observations, and documents produced 
by the Regenstrief Institute, Inc., February 16, 2022 (incorporated by 
reference, see Sec.  170.299).
* * * * *
    (d) * * *
    (1) Standard. RxNorm, a standardized nomenclature for clinical 
drugs produced by the United States National Library of Medicine, July 
5, 2022 (incorporated by reference, see Sec.  170.299).
* * * * *
    (4) Standard. The code set specified at 45 CFR 162.1002(b)(2) as 
referenced in 45 CFR 162.1002(c)(1) for the time period on or after 
October 1, 2015.
    (e) * * *
    (1) Standard. HL7[supreg] Standard Code Set CVX--Vaccines 
Administered, dated through June 15, 2022 (incorporated by reference, 
see Sec.  170.299).
    (2) Standard. National Drug Code Directory (NDC)--Vaccine NDC 
Linker, dated July 19, 2022 (incorporated by reference, see Sec.  
170.299).
* * * * *
    (f) * * *
    (3) Standard. CDC Race and Ethnicity Code Set Version 1.2 (July 08, 
2021) (incorporated by reference, see Sec.  170.299).
* * * * *
    (m) * * *
    (2) Standard. The Unified Code for Units of Measure, Version 2.1, 
November 21, 2017 (incorporated by reference, see Sec.  170.299).
    (n) * * *
    (1) Standard. Birth sex must be coded in accordance with 
HL7[supreg] Version 3 Standard, Value Sets for AdministrativeGender and 
NullFlavor (incorporated by reference, see Sec.  170.299), up until the 
adoption of this standard expires January 1, 2026, attributed as 
follows:
    (i) Male. M;
    (ii) Female. F;
    (iii) Unknown. NullFlavor UNK.
    (2) Standard. Sex must be coded in accordance with, at a minimum, 
the version of SNOMED CT [supreg] U.S. Edition codes specified in 
paragraph (a)(1) of this section.
    (3) Standard. Sex Parameter for Clinical Use must be coded in 
accordance with, at a minimum, the version of LOINC[supreg] codes 
specified in paragraph (c)(1) of this section.
    (o) Sexual orientation and gender information--(1) Standard. Sexual 
orientation must be coded in accordance with, at a minimum, the version 
of SNOMED-CT[supreg] U.S. Edition codes specified in paragraph (a)(4) 
of this section for paragraphs (o)(1)(i) through (iii) of this section 
and HL7 Version 3 Standard, Value Sets for AdministrativeGender and 
NullFlavor (incorporated by reference, see Sec.  170.299), up until the 
adoption of this standard expires on January 1, 2026, for paragraphs 
(o)(1)(iv) through (vi) of this section, attributed as follows:
    (i) Lesbian, gay or homosexual. 38628009
    (ii) Straight or heterosexual. 20430005
    (iii) Bisexual. 42035005
    (iv) Something else, please describe. NullFlavor OTH
    (v) Don't know. NullFlavor UNK
    (vi) Choose not to disclose. NullFlavor ASKU
    (2) Standard. Gender identity must be coded in accordance with, at 
a minimum, the version of SNOMED-CT[supreg] codes specified in 
paragraph (a)(4) of this section for paragraphs (o)(2)(i) through (v) 
of this section and HL7[supreg] Version 3 Standard, Value Sets for 
AdministrativeGender and NullFlavor (incorporated by reference in Sec.  
170.299), up until the adoption of this standard expires January 1, 
2026, for paragraphs (o)(2)(vi) and (vii) of this section, attributed 
as follows:
    (i) Male. 446151000124109
    (ii) Female. 446141000124107
    (iii) Female-to-Male (FTM)/Transgender Male/Trans Man. 407377005
    (iv) Male-to-Female (MTF)/Transgender Female/Trans Woman. 407376001
    (v) Genderqueer, neither exclusively male nor female. 
446131000124102
    (vi) Additional gender category or other, please specify. 
NullFlavor OTH
    (vii) Choose not to disclose. NullFlavor ASKU
    (3) Standard. Sexual Orientation and Gender Identity must be coded 
in accordance with, at a minimum, the version of SNOMED CT[supreg] 
codes specified in paragraph (a)(1) of this section.
    (4) Standard. Pronouns must be coded in accordance with, at a 
minimum, the version of LOINC[supreg] codes specified in paragraph 
(c)(1) of this section.
    (p) Social, psychological, and behavioral data--(1) Financial 
resource strain. Financial resource strain must be coded in accordance 
with, at a minimum, the version of LOINC[supreg] codes specified in 
paragraph (c)(1) of this section and attributed with the LOINC[supreg] 
code 76513-1 and LOINC[supreg] answer list ID LL3266-5.
    (2) Education. Education must be coded in accordance with, at a 
minimum, the version of LOINC[supreg] codes specified in paragraph 
(c)(1) of this section and attributed with LOINC[supreg] code 63504-5 
and LOINC[supreg] answer list ID LL1069-5.
    (3) Stress. Stress must be coded in accordance with, at a minimum, 
the version of LOINC[supreg] codes specified in paragraph (c)(1) of 
this section and attributed with the LOINC[supreg] code 76542-0 and 
LOINC[supreg] answer list LL3267-3.
    (4) Depression. Depression must be coded in accordance with, at a 
minimum, the version of LOINC[supreg] codes specified in paragraph 
(c)(1) of this section and attributed with LOINC[supreg] codes 55757-9, 
44250-9 (with LOINC[supreg] answer list ID LL361-7), 44255-8 (with 
LOINC[supreg] answer list ID LL361-7), and 55758-7 (with the answer 
coded with the associated applicable unit of measure in the standard 
specified in paragraph (m)(2) of this section).
    (5) Physical activity. Physical activity must be coded in 
accordance with, at a minimum, the version of LOINC[supreg] codes 
specified in paragraph (c)(1) of this section and attributed with 
LOINC[supreg] codes 68515-6 and 68516-4. The answers must be coded with 
the associated applicable unit of measure in the standard specified in 
paragraph (m)(2) of this section.
    (6) Alcohol use. Alcohol use must be coded in accordance with, at a 
minimum, the version of LOINC[supreg] codes specified in paragraph 
(c)(1) of this section and attributed with LOINC[supreg] codes 72109-2, 
68518-0 (with LOINC[supreg] answer list ID LL2179-1), 68519-8 (with 
LOINC[supreg] answer list ID LL2180-9), 68520-6 (with LOINC[supreg] 
answer list ID LL2181-7), and 75626-2 (with the answer coded with the 
associated applicable unit of measure in the standard specified in 
paragraph (m)(2) of this section).

[[Page 1428]]

    (7) Social connection and isolation. Social connection and 
isolation must be coded in accordance with, at a minimum, the version 
of LOINC[supreg] codes specified in paragraph (c)(1) of this section 
and attributed with the LOINC[supreg] codes 76506-5, 63503-7 (with 
LOINC[supreg] answer list ID LL1068-7), 76508-1 (with the associated 
applicable unit of measure in the standard specified in paragraph 
(m)(2) of this section), 76509-9 (with the associated applicable unit 
of measure in the standard specified in paragraph (m)(2) of this 
section), 76510-7 (with the associated applicable unit of measure in 
the standard specified in paragraph (m)(2) of this section), 76511-5 
(with LOINC answer list ID LL963-0), and 76512-3 (with the associated 
applicable unit of measure in the standard specified in paragraph 
(m)(2) of this section).
    (8) Exposure to violence (intimate partner violence). Exposure to 
violence: Intimate partner violence must be coded in accordance with, 
at a minimum, the version of LOINC[supreg] codes specified in paragraph 
(c)(1) of this section and attributed with the LOINC[supreg] code 
76499-3, 76500-8 (with LOINC[supreg] answer list ID LL963-0), 76501-6 
(with LOINC[supreg] answer list ID LL963-0), 76502-4 (with 
LOINC[supreg] answer list ID LL963-0), 76503-2 (with LOINC[supreg] 
answer list ID LL963-0), and 76504-0 (with the associated applicable 
unit of measure in the standard specified in paragraph (m)(2) of this 
section).
* * * * *
    (r) * * *
    (2) Standard. Medicare Provider and Supplier Taxonomy Crosswalk, 
2021 (incorporated by reference, see Sec.  170.299).
    (s) * * *
    (2) Standard. Public Health Data Standards Consortium Users Guide 
for Source of Payment Typology, Version 9.2 (incorporated by reference, 
see Sec.  170.299).

0
5. Amend Sec.  170.210 by revising paragraph (g) to read as follows:


Sec.  170.210  Standards for health information technology to protect 
electronic health information created, maintained, and exchanged.

* * * * *
    (g) Synchronized clocks. The date and time recorded utilize a 
system clock that has been synchronized using any Network Time Protocol 
(NTP) standard.
* * * * *

0
6. Revise Sec.  170.213 to read as follows:


Sec.  170.213   United States Core Data for Interoperability.

    The Secretary adopts the following versions of the United States 
Core Data for Interoperability standard:
    (a) Standard. United States Core Data for Interoperability (USCDI), 
July 2020 Errata, Version 1 (v1) (incorporated by reference, see Sec.  
170.299). The adoption of this standard expires on January 1, 2026.
    (b) Standard. United States Core Data for Interoperability Version 
3 (USCDI v3) (incorporated by reference, see Sec.  170.299).

0
7. Revise Sec.  170.215 to read as follows:


Sec.  170.215   Application Programming Interface Standards.

    The Secretary adopts the following standards and associated 
implementation specifications as the available standards for 
application programming interfaces (API):
    (a) API base standard. The following are applicable for purposes of 
standards-based APIs.
    (1) Standard. HL7[supreg] Fast Healthcare Interoperability 
Resources (FHIR[supreg]) Release 4.0.1 (incorporated by reference, see 
Sec.  170.299).
    (2) [Reserved]
    (b) API constraints and profiles. The following are applicable for 
purposes of constraining and profiling data standards.
    (1) United States Core Data Implementation Guides--(i) 
Implementation specification. HL7[supreg] FHIR[supreg] US Core 
Implementation Guide STU 3.1.1 (incorporated by reference in Sec.  
170.299). The adoption of this standard expires on January 1, 2026.
    (ii) Implementation Specification. HL7[supreg] FHIR[supreg] US Core 
Implementation Guide STU 6.1.0 (incorporated by reference, see Sec.  
170.299).
    (2) [Reserved]
    (c) Application access and launch. The following are applicable for 
purposes of enabling client applications to access and integrate with 
data systems.
    (1) Implementation specification. HL7[supreg] SMART Application 
Launch Framework Implementation Guide Release 1.0.0, including 
mandatory support for the ``SMART Core Capabilities'' (incorporated by 
reference, see Sec.  170.299). The adoption of this standard expires on 
January 1, 2026.
    (2) Implementation specification. HL7[supreg] SMART App Launch 
Implementation Guide Release 2.0.0, including mandatory support for the 
``Capability Sets'' of ``Patient Access for Standalone Apps'' and 
``Clinician Access for EHR Launch''; all ``Capabilities'' as defined in 
``8.1.2 Capabilities,'' excepting the ``permission-online'' capability; 
``Token Introspection'' as defined in ``7 Token Introspection'' 
(incorporated by reference, see Sec.  170.299).
    (d) Bulk export and data transfer standards. The following are 
applicable for purposes of enabling access to large volumes of 
information on a group of individuals.
    (1) Implementation specification. FHIR[supreg] Bulk Data Access 
(Flat FHIR[supreg]) (v1.0.0: STU 1), including mandatory support for 
the ``group-export'' ``OperationDefinition'' (incorporated by 
reference, see Sec.  170.299).
    (2) [Reserved]
    (e) API authentication, security, and privacy. The following are 
applicable for purposes of authorizing and authenticating client 
applications.
    (1) Standard. OpenID Connect Core 1.0, incorporating errata set 1 
(incorporated by reference, see Sec.  170.299).
    (2) [Reserved]

0
8. Amend Sec.  170.299 by:
0
a. Revising paragraph (a) and the introductory text of paragraph (d);
0
b. Adding paragraphs (d)(17) through (19);
0
c. Revising the introductory text of paragraph (e) and adding paragraph 
(e)(6)
0
d. Removing paragraph (j) and redesignating paragraphs (f) through (i) 
as paragraphs (g) through (j), respectively;
0
e. Adding new paragraph (f);
0
f. Revising the introductory text of newly redesignated paragraph (g) 
and adding paragraphs (g)(35) through (40);
0
g. Revising the introductory text of paragraph (m) and adding paragraph 
(m)(6);
0
h. Revising the introductory text of paragraph (o) and adding paragraph 
(o)(2);
0
i. Revising the introductory text of paragraph (p) and adding 
paragraphs (p)(5) and (6);
0
j. Revising the introductory text of paragraph (r) and adding 
paragraphs (r)(8) and (9).
    The revisions and additions read as follows:


Sec.  170.299  Incorporation by reference.

    (a) Certain material is incorporated by reference into this part 
with the approval of the Director of the Federal Register under 5 
U.S.C. 552(b) and 1 CFR part 51. All approved incorporation by 
reference (IBR) material is available for inspection at the U.S. 
Department of Health and Human Services (HHS) and at the National 
Archives and Records Administration (NARA). Contact HHS at: U.S. 
Department of Health and

[[Page 1429]]

Human Services, Office of the National Coordinator for Health 
Information Technology, 330 C Street SW, Washington, DC 20201; call 
ahead to arrange for inspection at 202-690-7151. For information on the 
availability of this material at NARA, visit www.archives.gov/federal-register/cfr/ibr-locations or email <a href="/cdn-cgi/l/email-protection#9bfde9b5f2f5e8ebfef8eff2f4f5dbf5fae9fab5fcf4ed"><span class="__cf_email__" data-cfemail="c5a3b7ebacabb6b5a0a6b1acaaab85aba4b7a4eba2aab3">[email protected]</span></a>. The 
material may be obtained from the sources in the following paragraphs 
of this section.
* * * * *
    (d) Centers for Disease Control and Prevention, 2500 Century 
Parkway, Mailstop E-78, Atlanta, GA 30333; phone: (800) 232-4636); 
website: www.cdc.gov/cdc-info/index.html
* * * * *
    (17) HL7[supreg] Standard Code Set CVX--Vaccines Administered, 
dated June 15, 2022; IBR approved for Sec.  170.207(e).
    (18) National Drug Code Directory (NDC)--Vaccine NDC Linker, dated 
July 19, 2022; IBR approved for Sec.  170.207(e).
    (19) CDC Race and Ethnicity Code Set version 1.2 (July 08, 2021); 
IBR approved for Sec.  170.207(f).
    (e) Centers for Medicare & Medicaid Services, Office of Clinical 
Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland 
21244; phone: (410) 786-3000; website: www.cms.gov.
* * * * *
    (6) Medicare Provider and Supplier Taxonomy Crosswalk, 2021; IBR 
approved for Sec.  170.207(r).
    (f) Council of State and Territorial Epidemiologists, 2635 Century 
Parkway NE, Suite 700, Atlanta, GA 30345; phone: (770) 458-3811; 
website: www.cste.org/
    (1) Reportable Conditions Trigger Codes Value Set for Electronic 
Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 
29, 2022; IBR approved for Sec.  170.205(t).
    (2) [Reserved]
    (g) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann 
Arbor, MI 48104; phone: (734) 677-7777; website: www.hl7.org/
* * * * *
    (35) HL7 CDA[supreg] R2 Implementation Guide: C-CDA Templates for 
Clinical Notes STU Companion Guide, Release 4.1 (US Realm) Standard for 
Trial Use, Specification Version: 4.1.1, June 2023 (including 
appendices A and B); IBR approved for Sec.  170.205(a).
    (36) HL7 FHIR[supreg] Implementation Guide: Electronic Case 
Reporting (eCR)--US Realm, Version 2.1.0--STU 2 US (HL7 FHIR eCR IG), 
August 31, 2022; IBR approved for Sec.  170.205(t).
    (37) HL7 CDA[supreg] 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, volumes 1 and 2; 
IBR approved for Sec.  170.205(t).
    (38) HL7 CDA[supreg] R2 Implementation Guide: Reportability 
Response, Release 1, STU Release 1.1--US Realm (HL7 CDA RR IG), July 
2022, volumes 1 through 4; IBR approved for Sec.  170.205(t).
    (39) HL7 FHIR US Core Implementation Guide Version 6.1.0--STU 6, 
June 19, 2023; IBR approved for Sec.  170.215(b).
    (40) HL7 FHIR[supreg] SMART App Launch [Implementation Guide], 
2.0.0--Standard for Trial Use, November 26, 2021; IBR approved for 
Sec.  170.215(c).
* * * * *
    (m) Office of the National Coordinator for Health Information 
Technology (ONC), 330 C Street SW, Washington, DC 20201; phone: (202) 
690-7151; website: https://healthit.gov.
* * * * *
    (6) United States Core Data for Interoperability (USCDI), Version 3 
(v3), October 2022 Errata; IBR approved for Sec.  170.213(b).
* * * * *
    (o) Public Health Data Standards Consortium, 111 South Calvert 
Street, Suite 2700, Baltimore, MD 21202; phone: (801) 532-2299; 
website: www.Ph.D.sc.org/.
* * * * *
    (2) Users Guide for Source of Payment Typology, Version 9.2, 
December 2020; IBR approved for Sec.  170.207(s).
    (p) Regenstrief Institute, Inc., LOINC[supreg] c/o Regenstrief 
Center for Biomedical Informatics, Inc., 410 West 10th Street, Suite 
2000, Indianapolis, IN 46202-3012; phone: (317) 274-9000; website: 
https://loinc.org/ and https://ucum.org/ucum.
* * * * *
    (5) Logical Observation Identifiers Names and Codes (LOINC[supreg]) 
Database Version 2.72, February 2022; IBR approved for Sec.  
170.207(c).
    (6) The Unified Code for Units of Measure, Version 2.1, November 
21, 2017; IBR approved for Sec.  170.207(m).
* * * * *
    (r) U.S. National Library of Medicine, 8600 Rockville Pike, 
Bethesda, MD 20894; phone (301) 594-5983; website: www.nlm.nih.gov/.
* * * * *
    (8) SNOMED CT[supreg] [Systematized Nomenclature of Medicine 
Clinical Terms] U.S. Edition, March 2022 Release; IBR approved for 
Sec.  170.207(a).
    (9) RxNorm, Full Update Release, July 5, 2022; IBR approved for 
Sec.  170.207(d).
* * * * *

0
9. Amend Sec.  170.315 by:
0
a. Revising the section heading, introductory text, and paragraphs 
(a)(5) paragraph heading, (a)(5)(i) introductory text, (a)(5)(i)(A)(1) 
and (2), (a)(5)(i)(C), (D), and (E);
0
b. Adding paragraphs (a)(5)(i)(F), (G), and (H) and (a)(9)(vi);
0
c. Revising paragraphs (a)(12), (b)(1)(iii)(A)(1) and (2); 
(b)(1)(iii)(B)(2), (b)(1)(iii)(G) introductory text, (b)(1)(iii)(G)(3), 
(b)(2)(i) and (ii), (b)(2)(iii)(D), and (b)(2)(iv), (b)(3), 
(b)(6)(ii)(B)(2), (b)(9)(ii);
0
d. Adding paragraph (b)(11);
0
e. Revising paragraphs (c)(4)(iii)(C), (E), (G), (H), and (I);
0
f. Revising paragraphs (e)(1)(i)(A)(1) and (2), (e)(1)(i)(B)(1) and 
(2), and adding paragraph (e)(1)(iii);
0
g. Revising paragraphs (f)(1)(i)(B) and (C), (f)(3)(ii), (f)(4)(ii), 
(f)(5); and
0
h. Revising paragraphs (g)(3) introductory text, (g)(6)(i)(A) and (B), 
(g)(9)(i)(A)(1) and (2), (g)(10)(i)(A) and (B), (g)(10)(ii)(A) and (B), 
(g)(10)(iv)(A) and (B), (g)(10)(v)(A)(1)(i), (ii) and (B), (2)(i) and 
(ii), (g)(10)(vi), and (g)(10)(vii).
    The revisions and additions read as follows:


Sec.  170.315  ONC Certification Criteria for Health IT.

    The Secretary adopts the following certification criteria for 
health IT. Health IT must be able to electronically perform the 
following capabilities in accordance with applicable standards and 
implementation specifications adopted in this part. For all criteria in 
this section, a health IT developer with a Health IT Module certified 
to any revised certification criterion, as defined in Sec.  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.
    (a) * * *
    (5) Patient demographics and observations. (i) Enable a user to 
record, change, and access patient demographic and observations data 
including race, ethnicity, preferred language, sex, sex parameter for 
clinical use, sexual orientation, gender identity, name to use, 
pronouns, and date of birth.
    (A) * * *
    (1) Enable each one of a patient's races to be recorded in 
accordance with, at a minimum, the standard specified in Sec.  
170.207(f)(3) and whether a patient declines to specify race.
    (2) Enable each one of a patient's ethnicities to be recorded in 
accordance with, at a minimum, the standard

[[Page 1430]]

specified in Sec.  170.207(f)(3) and whether a patient declines to 
specify ethnicity.
* * * * *
    (C) Sex. Enable sex to be recorded in accordance with the standard 
specified in Sec.  170.207(n)(1) for the period up to and including 
December 31, 2025; or Sec.  170.207(n)(2).
    (D) Sexual orientation. Enable sexual orientation to be recorded in 
accordance with, at a minimum, the version of the standard specified in 
Sec.  170.207(o)(1) for the period up to and including December 31, 
2025; or Sec.  170.207(o)(3), as well as whether a patient declines to 
specify sexual orientation.
    (E) Gender identity. Enable gender identity to be recorded in 
accordance with, at a minimum, the version of the standard specified in 
Sec.  170.207(o)(2) for the period up to and including December 31, 
2025; or Sec.  170.207(o)(3), as well as whether a patient declines to 
specify gender identity.
    (F) Sex Parameter for Clinical Use. Enable at least one sex 
parameter for clinical use to be recorded in accordance with, at a 
minimum, the version of the standard specified in Sec.  170.207(n)(3). 
Conformance with this paragraph is required by January 1, 2026.
    (G) Name to Use. Enable at least one preferred name to use to be 
recorded. Conformance with this paragraph is required by January 1, 
2026.
    (H) Pronouns. Enable at least one pronoun to be recorded in 
accordance with, at a minimum, the version of the standard specified in 
Sec.  170.207(o)(4). Conformance with this paragraph is required by 
January 1, 2026.
* * * * *
    (9) * * *
    (vi) Expiration of Criterion. The adoption of this criterion for 
purposes of the ONC Health IT Certification Program expires on January 
1, 2025.
* * * * *
    (12) Family health history. Enable a user to record, change, and 
access a patient's family health history in accordance with the 
familial concepts or expressions included in, at a minimum, the version 
of the standard in Sec.  170.207(a)(1).
* * * * *
    (b) * * *
    (1) * * *
    (iii) * * *
    (A) * * *
    (1) The data classes expressed in the standards in Sec.  170.213 
and in accordance with Sec.  170.205(a)(4), (5), and paragraphs 
(b)(1)(iii)(A)(3)(i) through (iii) of this section for the time period 
up to and including December 31, 2025, or
    (2) The data classes expressed in the standards in Sec.  170.213 
and in accordance with Sec.  170.205(a)(4), (6), and paragraphs 
(b)(1)(iii)(A)(3)(i) through (iii) of this section, and
* * * * *
    (B) * * *
    (2) At a minimum, the version of the standard specified in Sec.  
170.207(a)(1).
* * * * *
    (G) Patient matching data. First name, last name, previous name, 
middle name (including middle initial), suffix, date of birth, current 
address, phone number, and sex. The following constraints apply:
* * * * *
    (3) Sex Constraint: Represent sex with the standards adopted in 
Sec.  170.207(n)(2).
    (2) * * *
    (i) General Requirements. Paragraphs (b)(2)(ii) and (iii) of this 
section must be completed based on the receipt of a transition of care/
referral summary formatted in accordance with the standards adopted in 
Sec.  170.205(a)(3) through (5) using the Continuity of Care Document, 
Referral Note, and (inpatient setting only) Discharge Summary document 
templates, for time period up to and including December 31, 2025; or in 
accordance with the standards adopted in Sec.  170.205(a)(3), (4), (6).
    (ii) Correct patient. Upon receipt of a transition of care/referral 
summary formatted according to the standards adopted Sec.  
170.205(a)(3) through (5) for the period up to and including December 
31, 2025; or according to the standards adopted Sec.  170.205(a)(3), 
(4), and (6), technology must be able to demonstrate that the 
transition of care/referral summary received can be properly matched to 
the correct patient.
    (iii) * * *
    (D) Upon a user's confirmation, automatically update the list, and 
incorporate the following data expressed according to the specified 
standards:
* * * * *
    (iv) System verification. Based on the data reconciled and 
incorporated, the technology must be able to create a file formatted 
according to the standard specified in Sec.  170.205(a)(4) using the 
Continuity of Care Document template and the standard specified in 
paragraph (a)(5) of this section for the time period up to and 
including December 31, 2025; or according to the standard specified in 
Sec.  170.205(a)(4) using the Continuity of Care Document template and 
the standard specified in paragraph (a)(6) of this section.
* * * * *
    (3) * * *
    (ii) * * *
    (A) Enable a user to perform the following prescription-related 
electronic transactions in accordance with the standard specified in 
Sec.  170.205(b)(1) and, at a minimum, the version of the standard 
specified in Sec.  170.207(d)(1) as follows:
    (6) * * *
    (ii) * * *
    (B) * * *
    (2) At a minimum, the version of the standard specified in Sec.  
170.207(a)(1).
* * * * *
    (9) * * *
    (ii) The standard in Sec.  170.205(a)(5) for the time period up to 
and including December 31, 2025; or Sec.  170.205(a)(6).
* * * * *
    (11) Decision support interventions --
    (i) Decision support intervention interaction. Interventions 
provided to a user must occur when a user is interacting with 
technology.
    (ii) Decision support configuration. (A) Enable interventions 
specified in paragraphs (b)(11)(iii) of this section to be configured 
by a limited set of identified users based on a user's role.
    (B) Enable interventions when a patient's medications, allergies 
and intolerance, and problems are incorporated from a transition of 
care or referral summary received and pursuant to paragraph 
(b)(2)(iii)(D) of this section.
    (C) Enable a user to provide electronic feedback data for evidence-
based decision support interventions selected via the capability 
provided in paragraph (b)(11)(iii)(A) of this section and make 
available such feedback data to a limited set of identified users for 
export, in a computable format, including at a minimum the 
intervention, action taken, user feedback provided (if applicable), 
user, date, and location.
    (iii) Decision support intervention selection. Enable a limited set 
of identified users to select (i.e., activate) electronic decision 
support interventions (in addition to drug-drug and drug-allergy 
contraindication checking) that are:
    (A) Evidence-based decision support interventions and use any data 
based on the following data expressed in the standards in Sec.  
170.213:
    (1) Problems;
    (2) Medications;
    (3) Allergies and Intolerances;
    (4) At least one demographic specified in paragraph (a)(5)(i) of 
this section;
    (5) Laboratory;
    (6) Vital Signs;
    (7) Unique Device Identifier(s) for a Patient's Implantable 
Device(s); and
    (8) Procedures.
    (B) Predictive Decision Support Interventions and use any data 
expressed in the standards in Sec.  170.213.

[[Page 1431]]

    (iv) Source attributes. Source attributes listed in paragraphs 
(b)(11)(iv)(A) and (B) of this section must be supported.
    (A) For evidence-based decision support interventions:
    (1) Bibliographic citation of the intervention (clinical research 
or guideline);
    (2) Developer of the intervention (translation from clinical 
research or guideline);
    (3) Funding source of the technical implementation for the 
intervention(s) development;
    (4) Release and, if applicable, revision dates of the intervention 
or reference source;
    (5) Use of race as expressed in the standards in Sec.  170.213;
    (6) Use of ethnicity as expressed in the standards in Sec.  
170.213;
    (7) Use of language as expressed in the standards in Sec.  170.213;
    (8) Use of sexual orientation as expressed in the standards in 
Sec.  170.213;
    (9) Use of gender identity as expressed in the standards in Sec.  
170.213;
    (10) Use of sex as expressed in the standards in Sec.  170.213;
    (11) Use of date of birth as expressed in the standards in Sec.  
170.213;
    (12) Use of social determinants of health data as expressed in the 
standards in Sec.  170.213; and
    (13) Use of health status assessments data as expressed in the 
standards in Sec.  170.213.
    (B) For Predictive Decision Support Interventions:
    (1) 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;
    (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.
    (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).
    (3) 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; and
    (ii) Known risks, inappropriate settings, inappropriate uses, or 
known limitations.
    (4) Intervention development details and input features, including 
at a minimum:
    (i) Exclusion and inclusion criteria that influenced the training 
data set;
    (ii) Use of variables in paragraphs (b)(11)(iv)(A)(5) through (13) 
of this section as input features;
    (iii) Description of demographic representativeness according to 
variables in paragraphs (b)(11)(iv)(A)(5) through (13) of this section 
including, at a minimum, those used as input features in the 
intervention;
    (iv) Description of relevance of training data to intended deployed 
setting; and
    (5) 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.
    (6) External validation process, including:
    (i) Description of the data source, clinical setting, or 
environment where an intervention's validity and fairness has been 
assessed, other than the source of training and testing data
    (ii) Party that conducted the external testing;
    (iii) Description of demographic representativeness of external 
data according to variables in paragraph (b)(11)(iv)(A)(5)-(13) 
including, at a minimum, those used as input features in the 
intervention; and
    (iv) Description of external validation process.
    (7) 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;
    (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 outcomes;
    (8) Ongoing maintenance of intervention implementation and use, 
including:
    (i) Description of 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;
    (iv) Fairness of intervention in local data; and
    (9) 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.
    (v) Source attribute access and modification. (A) Access. (1) For 
evidence-based decision support interventions and Predictive Decision 
Support Interventions supplied by the health IT developer as part of 
its Health IT Module, 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 paragraphs 
(b)(11)(iv)(A) and (B) of this section.
    (2) For Predictive Decision Support Interventions 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) of this section.
    (B) Modify. (1) For evidence-based decision support interventions 
and Predictive Decision Support Interventions, 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.
    (2) For Predictive Decision Support Interventions, the Health IT 
Module must enable a limited set of identified users to record, change, 
and access additional source attributes not specified in paragraph 
(b)(11)(iv)(B) of this section.
    (vi) Intervention risk management. Intervention risk management 
practices must be applied for each Predictive Decision Support 
Intervention supplied by the health IT developer as part of its Health 
IT Module.
    (A) Risk analysis. The Predictive Decision Support Intervention(s) 
must be subject to analysis of potential risks and adverse impacts 
associated with the following characteristics: validity, reliability, 
robustness, fairness,

[[Page 1432]]

intelligibility, safety, security, and privacy.
    (B) Risk mitigation. The Predictive Decision Support Intervention 
(s) must be subject to practices to mitigate risks, identified in 
accordance with paragraph (b)(11)(vi)(A) of this section; and
    (C) Governance. The Predictive Decision Support Intervention(s) 
must be subject to policies and implemented controls for governance, 
including how data are acquired, managed, and used.
    (c) * * *
    (4) * * *
    (iii) * * *
    (C) Provider type in accordance with, at a minimum, the standard 
specified in Sec.  170.207(r)(2).
* * * * *
    (E) Patient insurance in accordance with the standard specified in 
Sec.  170.207(s)(2).
* * * * *
    (G) Patient sex in accordance with the version of the standard 
specified in Sec.  170.207(n)(2).
    (H) Patient race and ethnicity in accordance with, at a minimum, 
the version of the standard specified in Sec.  170.207(f)(3).
    (I) Patient problem list data in accordance with, at a minimum, the 
version of the standard specified in Sec.  170.207(a)(1).
    (e) * * *
    (1) * * *
    (i) * * *
    (A) * * *
    (1) The data classes expressed in the standards in Sec.  170.213 
(which should be in their English (i.e., non-coded) representation if 
they associate with a vocabulary/code set), and in accordance with 
Sec.  170.205(a)(4) and (a)(5), and paragraphs (e)(1)(i)(A)(3)(i) 
through (iii) of this section for the time period up to and including 
December 31, 2025, or
    (2) The data classes expressed in the standards in Sec.  170.213 
(which should be in their English (i.e., non-coded) representation if 
they associate with a vocabulary/code set), and in accordance with 
Sec.  170.205(a)(4) and (a)(6), and paragraphs (e)(1)(i)(A)(3)(i) 
through (iii) of this section.
* * * * *
    (B) * * *
    (1) Patients (and their authorized representatives) must be able to 
use technology to download an ambulatory summary or inpatient summary 
(as applicable to the health IT setting for which certification is 
requested) in the following formats:
    (i) Human readable format; and
    (ii) The format specified in accordance with the standard specified 
in Sec.  170.205(a)(4) and (5) for the time period up to and including 
December 31, 2025, or Sec.  170.205(a)(4) and (6), and following the 
CCD document template.
    (2) When downloaded according to the standard specified in Sec.  
170.205(a)(4) through (6) following the CCD document template, the 
ambulatory summary or inpatient summary must include, at a minimum, the 
following data (which, for the human readable version, should be in 
their English representation if they associate with a vocabulary/code 
set):
* * * * *
    (iii) Request for restrictions. 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 Sec.  170.213. Conformance with this paragraph is required 
by January 1, 2026.
* * * * *
    (f) * * *
    (1) * * *
    (i) * * *
    (B) At a minimum, the version of the standard specified in Sec.  
170.207(e)(1) for historical vaccines.
    (C) At a minimum, the version of the standard specified in Sec.  
170.207(e)(2) for administered vaccines.
    (3) * * *
    (ii) At a minimum, the versions of the standards specified in Sec.  
170.207(a)(1) and (c)(1).
    (4) * * *
    (ii) At a minimum, the versions of the standards specified in Sec.  
170.207(a)(1) and (c)(1).
    (5) Transmission to public health agencies--electronic case 
reporting. Enable a user to create a case report for electronic 
transmission meeting the requirements described in paragraphs (f)(5)(i) 
of this section for the time period up to and including December 31, 
2025; or the requirements described in paragraph (f)(5)(ii) of this 
section.
    (i) Functional electronic case reporting. A Health IT Module must 
enable a user to create a case report for electronic transmission in 
accordance with the following:
    (A) Consume and maintain a table of trigger codes to determine 
which encounters may be reportable.
    (B) Match a patient visit or encounter to the trigger code based on 
the parameters of the trigger code table.
    (C) Case report creation. Create a case report for electronic 
transmission:
    (1) Based on a matched trigger from paragraph (f)(5)(i)(B).
    (2) That includes, at a minimum:
    (i) The data classes expressed in the standards in Sec.  170.213.
    (ii) Encounter diagnoses formatted according to at least one of the 
standards specified in Sec.  170.207(i) or Sec.  170.207(a)(1).
    (iii) The provider's name, office contact information, and reason 
for visit.
    (iv) An identifier representing the row and version of the trigger 
table that triggered the case report.
    (ii) Standards-based electronic case reporting. A Health IT Module 
must enable a user to create a case report for electronic transmission 
in accordance with the following:
    (A) Consume and process case reporting trigger codes and identify a 
reportable patient visit or encounter based on a match from the 
Reportable Conditions Trigger Code value set in Sec.  170.205(t)(4).
    (B) Create a case report consistent with at least one of the 
following standards:
    (1) The eICR profile of the HL7 FHIR eCR IG in Sec.  170.205(t)(1); 
or
    (2) The HL7 CDA eICR IG in Sec.  170.205(t)(2).
    (C) Receive, consume, and process a case report response that is 
formatted to either the reportability response profile of the HL7 FHIR 
eCR IG in Sec.  170.205(t)(1) or the HL7 CDA RR IG in Sec.  
170.205(t)(3) as determined by the standard used in (f)(5)(ii)(B) of 
this section.
    (D) Transmit a case report electronically to a system capable of 
receiving a case report.
* * * * *
    (g) * * *
    (3) Safety-enhanced design. User-centered design processes must be 
applied to each capability technology includes that is specified in the 
following certification criteria: paragraphs (a)(1) through (5), (9) 
until the criterion's expiration date, and (14), and (b)(2), (3), and 
(11) of this section.
* * * * *
    (6) * * *
    (i) * * *
    (A) The data classes expressed in the standards in Sec.  170.213 in 
accordance with Sec.  170.205(a)(4) and (a)(5) and paragraphs 
(g)(6)(i)(C)(1) through (4) of this section for the time period up to 
and including December 31, 2025; or
    (B) The data classes expressed in the standards in Sec.  170.213, 
and in accordance with Sec.  170.205(a)(4) and (6) and paragraphs 
(g)(6)(i)(C)(1) through (3) of this section.
* * * * *
    (9) * * *
    (i) * * *
    (A) * * *
    (1) Respond to requests for patient data (based on an ID or other 
token) for all of the data classes expressed in the

[[Page 1433]]

standards in Sec.  170.213 at one time and return such data (according 
to the specified standards, where applicable) in a summary record 
formatted in accordance with Sec.  170.205(a)(4) and (5) following the 
CCD document template, and as specified in paragraphs 
(g)(9)(i)(A)(3)(i) through (iv) of this section for the time period up 
to and including December 31, 2025; or
    (2) Respond to requests for patient data (based on an ID or other 
token) for all of the data classes expressed in the standards in Sec.  
170.213 at one time and return such data (according to the specified 
standards, where applicable) in a summary record formatted in 
accordance with Sec.  170.205(a)(4) and (6) following the CCD document 
template, and as specified in paragraphs (g)(9)(i)(A)(3)(i) through 
(iv) of this section.
* * * * *
    (10) * * *
    (i) * * *
    (A) Respond to requests for a single patient's data according to 
the standards and implementation specifications adopted in 170.215(a) 
and in Sec.  170.215(b)(1), including the mandatory capabilities 
described in ``US Core Server CapabilityStatement,'' for each of the 
data included in the standards adopted in Sec.  170.213. All data 
elements indicated as ``mandatory'' and ``must support'' by the 
standards and implementation specifications must be supported.
    (B) Respond to requests for multiple patients' data as a group 
according to the standards and implementation specifications adopted in 
Sec.  170.215(a), (b)(1), and (d), for each of the data included in the 
standards adopted in Sec.  170.213. All data elements indicated as 
``mandatory'' and ``must support'' by the standards and implementation 
specifications must be supported.
    (ii) * * *
    (A) Respond to search requests for a single patient's data 
consistent with the search criteria included in the implementation 
specifications adopted in Sec.  170.215(b)(1), specifically the 
mandatory capabilities described in ``US Core Server 
CapabilityStatement.''
    (B) Respond to search requests for multiple patients' data 
consistent with the search criteria included in the implementation 
specification adopted in Sec.  170.215(d).
* * * * *
    (iv) * * *
    (A) Establish a secure and trusted connection with an application 
that requests data for patient and user scopes in accordance with the 
implementation specifications adopted in Sec.  170.215(b)(1) and (c).
    (B) Establish a secure and trusted connection with an application 
that requests data for system scopes in accordance with the 
implementation specification adopted in Sec.  170.215(d).
* * * * *
    (v) * * *
    (A) * * *
    (1) * * *
    (i) Authentication and authorization must occur during the process 
of granting access to patient data in accordance with the 
implementation specification adopted in Sec.  170.215(c) and standard 
adopted in Sec.  170.215(e).
    (ii) 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 Sec.  170.215(c).
* * * * *
    (B) Authentication and authorization for system scopes. 
Authentication and authorization must occur during the process of 
granting an application access to patient data in accordance with the 
``SMART Backend Services: Authorization Guide'' section of the 
implementation specification adopted in Sec.  170.215(d) and the 
application must be issued a valid access token.
    (2) * * *
    (i) Access must be granted to patient data in accordance with the 
implementation specification adopted in Sec.  170.215(c) without 
requiring re-authorization and re-authentication when a valid refresh 
token is supplied by the application.
    (ii) 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 Sec.  170.215(c).
* * * * *
    (vi) Patient authorization revocation. 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.
    (vii) Token introspection. A Health IT Module's authorization 
server must be able to receive and validate tokens it has issued in 
accordance with an implementation specification in Sec.  170.215(c).
* * * * *

0
10. Amend Sec.  170.402 by adding paragraphs (a)(5), and (b)(3) and (4) 
to read as follows:


Sec.  170.402   Assurances.

    (a) * * *
    (5) A health IT developer must not inhibit its customer's timely 
access to interoperable health IT certified under the Program.
    (b) * * *
    (3)(i) Update. A health IT developer must update a Health IT 
Module, once certified to a certification criterion adopted in Sec.  
170.315, to all applicable revised certification criteria, including 
the most recently adopted capabilities and standards included in the 
revised certification criterion.
    (ii) Provide. A health IT developer must provide all Health IT 
Modules certified to a revised certification criterion, including the 
most recently adopted capabilities and standards included in the 
revised certification criterion, to its customers of such certified 
health IT.
    (iii) Timeliness. A health IT developer must complete the actions 
specified in paragraphs (b)(3)(i) and (ii) of this section:
    (A) Consistent with the timeframes specified in part 170; or
    (B) If the developer obtains new customers of health IT certified 
to the revised criterion after the effective date of the final rule 
adopting the revised criterion or criteria, then the health IT 
developer must provide the health IT certified to the revised criterion 
to such customers within whichever of the following timeframes that 
expires last:
    (1) The timeframe provided in paragraph (b)(3)(iii)(A) of this 
section; or
    (2) No 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.
    (4) For developers of Health IT Modules certified to Sec.  
170.315(b)(11), starting January 1, 2025, and on an ongoing basis 
thereafter, review and update as necessary source attribute information 
in Sec.  170.315(b)(11)(iv)(A) and (B), intervention risk management 
practices described in Sec.  170.315(b)(11)(vi), and summary 
information provided through Sec.  170.523(f)(1)(xxi).

0
11. Amend Sec.  170.404 by revising paragraph (b)(2) to read as 
follows:


Sec.  170.404  Application programming interfaces.

* * * * *
    (b) * * *
    (2) Service base URL publication. For all Health IT Modules 
certified to Sec.  170.315(g)(10), a Certified API Developer must 
publish, at no charge, the service base URLs and related organization 
details that can be used by patients to access their electronic health

[[Page 1434]]

information, by December 31, 2024. This includes all customers 
regardless of whether the Health IT Modules certified to Sec.  
170.315(g)(10) are centrally managed by the Certified API Developer or 
locally deployed by an API Information Source. These service base URLs 
and organization details must conform to the following:
    (i) Service base URLs must be publicly published in Endpoint 
resource format according to the standard adopted in Sec.  170.215(a).
    (ii) Organization details for each service base URL must be 
publicly published in Organization resource format according to the 
standard adopted in Sec.  170.215(a). Each Organization resource must 
contain:
    (A) A reference, in the Organization.endpoint element, to the 
Endpoint resources containing service base URLs managed by this 
organization.
    (B) The organization's name, location, and facility identifier.
    (iii) Endpoint and Organization resources must be:
    (A) Collected into a Bundle resource formatted according to the 
standard adopted in Sec.  170.215(a) for publication; and
    (B) Reviewed quarterly and, as necessary, updated.
* * * * *

0
12. Amend Sec.  170.405 by:
0
a. Revising paragraphs (a) and (b)(2)(ii); and
0
b. Removing and reserving paragraphs (b)(3) through (7) and (b)(10).
    The revisions read as follows:


Sec.  170.405   Real world testing.

    (a) Condition of Certification requirement. A health IT developer 
with one or more Health IT Module(s) certified to any one or more of 
the ONC Certification Criteria for Health IT in Sec.  170.315(b), 
(c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must 
successfully test the real world use of those Health IT Module(s) for 
interoperability (as defined in 42 U.S.C. 300jj(9) and Sec.  170.102) 
in the type of setting in which such Health IT Module(s) would be/is 
marketed.
    (b) * * *
    (2) * * *
    (ii) For real world testing activities conducted during the 
immediately preceding calendar year, a health IT developer must submit 
to its ONC-ACB an annual real world testing results report addressing 
each of its certified Health IT Modules that include certification 
criteria referenced in paragraph (a) of this section by a date 
determined by the ONC-ACB that enables the ONC-ACB to publish a 
publicly available hyperlink to the results report on CHPL no later 
than March 15 of each calendar year, beginning in 2023. For certified 
Health IT Modules included in paragraph (a) of this section that are 
updated using Inherited Certified Status after August 31 of the year in 
which the plan is submitted, a health IT developer must include the 
newer version of the certified Health IT Module(s) in its annual real 
world testing results report. The real world testing results must 
report the following for each of the certification criteria identified 
in paragraph (a) of this section that are included in the Health IT 
Module's scope of certification:
* * * * *

0
13. Add Sec.  170.407 to read as follows:


Sec.  170.407  Insights Condition and Maintenance of Certification.

    (a) Condition of Certification. (1) Measure responses. A health IT 
developer must submit (to the independent entity designated by the 
Secretary) for each reporting period pursuant to paragraph (b) of this 
section:
    (i) Responses for the measures specified in this section, which 
must include:
    (A) Data aggregated at the product level (across versions);
    (B) Documentation related to the data sources and methodology used 
to generate measures; and
    (C) Percentage of total customers (e.g., hospital sites, individual 
clinician users) represented in provided data; or
    (ii) A response (attestation) that it does not:
    (A) Meet the minimum reporting qualifications requirement in 
paragraph (a)(2) of this section; or
    (B) Have health IT certified to the certification criteria 
specified in each measure in paragraphs (a)(3)(i) through (vii) of this 
section; or
    (C) Have any users using the certified health IT specified in each 
measure in paragraphs (a)(3)(i) through (vii) of this section during 
the reporting period.
    (2) Minimum reporting qualifications requirement. At least 50 
hospital sites or 500 individual clinician users across the developer's 
certified health IT.
    (3) Measures. (i) Individuals' access to electronic health 
information through certified health IT. If a health IT developer has a 
Health IT Module certified to Sec.  170.315(e)(1) or (g)(10) or both, 
then the health IT developer must submit responses for the number of 
unique individuals who access electronic health information (EHI) 
overall and by different methods of access through certified health IT.
    (ii) Consolidated clinical document architecture (C-CDA) problems, 
medications, and allergies reconciliation and incorporation through 
certified health IT. If a health IT developer has a Health IT Module 
certified to Sec.  170.315(b)(2), then the health IT developer must 
submit responses for:
    (A) Encounters;
    (B) Unique patients with an encounter;
    (C) C-CDA documents obtained (unique and overall); and
    (D) C-CDA documents reconciled and incorporated both through manual 
and automated processes.
    (iii) Applications supported through certified health IT. If a 
health IT developer has a Health IT Module certified to Sec.  
170.315(g)(10), then the health IT developer must submit responses on 
how their certified health IT is supporting the application ecosystem, 
by providing the following information for applications that are 
connected to their certified health IT including:
    (A) Application Name(s);
    (B) Application Developer Name(s);
    (C) Intended Purpose(s) of Application;
    (D) Intended Application User(s); and
    (E) Application Status.
    (iv) Use of FHIR in apps through certified health IT. (i) If a 
health IT developer has a Health IT Module certified to Sec.  
170.315(g)(10), then the health IT developer must submit responses on 
the number of requests made to distinct certified health IT deployments 
that returned FHIR resources, number of distinct of certified health IT 
deployments active at any time, the number of distinct deployments 
active at any time that returned FHIR resources in response to API 
calls from apps connected to certified health IT, including stratifying 
responses by the following:
    (A) User type;
    (B) FHIR resource; and
    (C) US Core Implementation Guide version.
    (v) Use of FHIR bulk data access through certified health IT. (i) 
If a health IT developer has a Health IT Module certified to Sec.  
170.315(g)(10), then the health IT developer must submit responses for 
the total number of FHIR bulk data access requests completed through 
the certified health IT, and the number of distinct deployments of the 
certified health IT active at any time overall, and by whether at least 
one bulk data download request was completed.
    (vi) Immunization administrations electronically submitted to 
immunization information systems

[[Page 1435]]

through certified health IT. (i) If a health IT developer has a Health 
IT Module certified to Sec.  170.315(f)(1), then the health IT 
developer must submit responses for the use of certified health IT to 
electronically send immunizations administered to immunization 
information systems (IIS), including stratifying responses based on the 
following subgroups:
    (A) IIS; and
    (B) Age group.
    (vii) Immunization history and forecasts through certified health 
IT. (i) If a health IT developer has a Health IT Module certified to 
Sec.  170.315(f)(1), then the health IT developer must submit responses 
for the use of certified health IT to query immunization history and 
forecast information from immunization information systems (IIS), 
including stratifying responses based on the following subgroup:
    (A) IIS.
    (B) [Reserved]
    (b) Maintenance of Certification. (1) A health IT developer must 
provide responses to the Insights Condition of Certification specified 
in paragraph (a) of this section annually for any Health IT Module that 
has or has had an active certification at any time under the ONC Health 
IT Certification Program during the prior six months:
    (i) A health IT developer must provide responses for measures 
specified in:
    (A) Paragraphs (a)(3)(i), (iii), (iv)(A) and (B), and (vi) of this 
section beginning July 2027;
    (B) Paragraphs (a)(3)(ii)(A) through (C), (iv)(C), (v), (vi)(A) and 
(B), and (vii) of this section beginning July 2028; and
    (C) Paragraph (a)(3)(ii)(D), (vii)(A) of this section beginning 
July 2029.
    (2) [Reserved]

0
14. Amend Sec.  170.523 by:
0
a. Revising paragraph (f)(1) introductory text and adding paragraph 
(f)(1)(xxi);
0
b. Revising paragraphs (g)(1), (k)(1)(i) and (ii); and
0
c. Adding paragraph (u).
    The revisions and addition read as follows:


Sec.  170.523  Principles of proper conduct for ONC-ACBs.

* * * * *
    (f) * * *
    (1) For the ONC Certification Criteria for Health IT:
* * * * *
    (xxi) Where applicable, summary information of the intervention 
risk management practices listed in Sec.  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.
* * * * *
    (g) * * *
    (1) Retain all records related to the certification of Health IT 
Modules to the ONC Certification Criteria for Health IT beginning with 
the codification of those certification criteria in the Code of Federal 
Regulations through a minimum of 3 years after the end of calendar year 
that included the effective date of the removal of those certification 
criteria from the Code of Federal Regulations; and
* * * * *
    (k) * * *
    (1) * * *
    (i) The disclaimer ``This Health IT Module is compliant with the 
ONC Certification Criteria for Health IT and has been certified by an 
ONC-ACB in accordance with the applicable certification criteria 
adopted by the Secretary of Health and Human Services. This 
certification does not represent an endorsement by the U.S. Department 
of Health and Human Services.''
    (ii) For a Health IT Module certified to the ONC Certification 
Criteria for Health IT, the information specified by paragraphs 
(f)(1)(i), (vi) through (viii), (xv), and (xvi) of this section as 
applicable for the specific Health IT Module.
* * * * *
    (u) Insights. Confirm that developers of certified health IT submit 
responses for Insights Conditions and Maintenance of Certification 
requirements in accordance with Sec.  170.407.

0
15. Amend Sec.  170.524 by revising paragraph (f)(1) to read as 
follows:


Sec.  170.524  Principles of proper conduct for ONC-ATLs.

* * * * *
    (f) * * *
    (1) Retain all records related to the testing of Health IT Modules 
to the ONC Certification Criteria for Health IT beginning with the 
codification of those certification criteria in the Code of Federal 
Regulations through a minimum of three years after the end of calendar 
year that included the effective date of the removal of those 
certification criteria from the Code of Federal Regulations; and
* * * * *

0
16. Amend Sec.  170.550 by revising paragraphs (g) introductory text 
and (m) introductory text to read as follows:


Sec.  170.550  Health IT Module certification.

* * * * *
    (g) Health IT Module dependent criteria. When certifying a Health 
IT Module to the ONC Certification Criteria for Health IT, an ONC-ACB 
must certify the Health IT Module in accordance with the certification 
criteria at:
* * * * *
    (m) Time-limited certification and certification status for certain 
ONC Certification Criteria for Health IT. An ONC-ACB may only issue a 
certification to a Health IT Module and permit continued certified 
status for:
* * * * *

PART 171--INFORMATION BLOCKING

0
17. The authority citation for part 171 continues to read as follows:

    Authority:  42 U.S.C. 300jj-52; 5 U.S.C. 552.


0
18. Amend Sec.  171.102 by
0
a. Adding, in alphabetical order, the definition of ``Business 
associate'';
0
b. Revising the definition of ``Health IT developer of certified health 
IT''; and
0
c. Adding, in alphabetical order, the definition of ``Offer health 
information technology or offer health IT''.
    The additions and revision read as follows:


Sec.  171.102  Definitions

* * * * *
    Business associate is defined as it is in 45 CFR 160.103.
* * * * *
    Health IT developer of certified health IT means an individual or 
entity, other than a health care provider that self-develops health IT 
that is not offered to others, that develops or offers health 
information technology (as that term is defined in 42 U.S.C. 300jj(5)), 
and which has, at the time it engages in a practice that is the subject 
of an information blocking claim, one or more Health IT Modules 
certified under a program for the voluntary certification of health 
information technology that is kept or recognized by the National 
Coordinator pursuant to 42 U.S.C. 300jj-11(c)(5) (ONC Health IT 
Certification Program).
* * * * *
    Offer health information technology or offer health IT 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) for 
deployment by or for other individual(s) or entity(ies) under any 
arrangement

[[Page 1436]]

except an arrangement consistent with subparagraph (3)(iii), below. 
Activities and arrangements described in subparagraphs (1) through (3) 
are considered to be excluded from what it means to offer health IT.
    (1) Donation and subsidized supply arrangements are not considered 
offerings when 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, 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.
    (2) Implementation and use activities conducted by an individual or 
entity as follows:
    (i) Issuing user accounts or login credentials to the individual's 
or entity's employees in the course of their employment or contractors 
within the scope of their contract in order for such employees or 
contractors to: use, operate, implement, configure, test, maintain, 
update or upgrade, or to give or receive training on, the individual's 
or entity's health IT system(s) or specific application(s) within such 
system(s).
    (ii) Implementing, operating, or otherwise making available 
production instances of application programming interface (API) 
technology that supports access, exchange, and use of electronic health 
information that the individual or entity has in its possession, 
custody, control, or ability to query or transmit from or across a 
health information network or health information exchange.
    (iii) Implementing, operating, and making available production 
instances of online portals for patients, clinicians or other health 
care providers, or public health entities to access, exchange, and use 
electronic health information that the individual or entity has in its 
possession, custody, control, or ability to query or transmit from or 
across a health information network or health information exchange.
    (iv) Issuing login credentials or user accounts for the 
individual's or entity's production, development, or testing 
environments to public health authorities, or such authorities' 
employees or contractors, as a means of accomplishing or facilitating 
access, exchange, and use of electronic health information for public 
health purposes including but not limited to syndromic surveillance.
    (v) Issuing login credentials or user accounts for independent 
healthcare professionals who furnish services in a healthcare facility 
to use the facility's electronic health record or other health IT 
system(s) in: furnishing, documenting, and accurately billing for care 
furnished in the facility; 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).
    (3) Consulting and legal services arrangements as follows:
    (i) Legal services furnished by outside counsel--when furnishing 
legal services to a client in any matter or matters pertaining to the 
client's seeking, assessing, selecting, or resolving disputes over 
contracts or other arrangements by which the client obtains use of 
certified health IT. Outside counsel also does not offer health IT when 
facilitating limited access or use of a client's health IT by 
independent expert witnesses engaged by the outside counsel, opposing 
parties' counsel and experts, and special masters and court personnel, 
as appropriate to legal discovery.
    (ii) Health IT consultant assistance with selection, 
implementation, and use of health IT --furnished to a health IT 
customer or user to help the customer do (or to do on behalf of a 
customer) 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:
    (A) Define the business needs of the customer or user or evaluate 
health IT product(s) against such business needs, or both;
    (B) Negotiate for the purchase, lease, license, or other 
arrangement under which the health IT product(s) will be used; or
    (C) Oversee or carry out configuration, implementation, or 
operation of health IT product(s).
    (iii) Comprehensive and predominantly non-health IT administrative 
or operations management services--when an individual or entity 
furnishes a health care provider with administrative or operational 
management consultant services and the consultant acts as the agent of 
the provider or otherwise acts on behalf of the provider in dealings 
with one or more health IT developer(s) or vendor(s), or managing the 
day-to-day operations and administrative duties for the health IT, or 
both. 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.
* * * * *

0
19. Revise Sec.  171.103 to read as follows:


Sec.  171.103   Information blocking.

    (a) Information blocking means a practice that except as required 
by law or covered by an exception set forth in subparts B, C, or D of 
this part, is likely to interfere with access, exchange, or use of 
electronic health information; and
    (b) If conducted by:
    (1) A health IT developer of certified health IT, health 
information network or health information exchange, such developer, 
network or exchange knows, or should know, that such practice is likely 
to interfere with access, exchange, or use of electronic health 
information; or
    (2) A health care provider, such provider knows that such practice 
is unreasonable and is likely to interfere with access, exchange, or 
use of electronic health information.

0
20. Amend Sec.  171.204 by revising paragraphs (a)(1) and (3) and 
adding paragraphs (a)(4) and (5) to read as follows:


Sec.  171.204  Infeasibility exception--When will an actor's practice 
of not fulfilling a request to access, exchange, or use electronic 
health information due to the infeasibility of the request not be 
considered information blocking?

* * * * *
    (a) * * *
    (1) Uncontrollable events. The actor cannot fulfill the request for 
access, exchange, or use of electronic health information because 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 that in fact negatively 
impacts the actor's ability to fulfill the request.
* * * * *
    (3) Third party seeking modification use. The request is to enable 
use of EHI in order to modify EHI provided that the request for such 
use is not from a health care provider requesting such use from an 
actor that is its business associate.
    (4) Manner exception exhausted. The actor is unable to fulfill a 
request for access, exchange, or use of electronic health information 
because paragraphs (a)(4)(i), (ii), and (iii) of this section are all 
true; and the actor complied with paragraph (a)(4)(iv) of this section.

[[Page 1437]]

    (i) The actor could not reach agreement with a requestor in 
accordance with Sec.  171.301(a) or was technically unable to fulfill a 
request for electronic health information in the manner requested.
    (ii) The actor offered at least two alternative manners in 
accordance with Sec.  171.301(b), one of which must use either 
technology certified to standard(s) adopted in part 170 (Sec.  
171.301(b)(1)(i)) or published content and transport standards 
consistent with Sec.  171.301(b)(1)(ii).
    (iii) 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 
requester.
    (iv) In determining whether a requestor is similarly situated under 
paragraph (a)(4)(iii), an actor shall not discriminate based on:
    (A) Whether the requestor is an individual as defined in Sec.  
171.202(a)(2)
    (B) The health care provider type and size; and
    (C) Whether the requestor is a competitor of the actor or whether 
providing such access, exchange, or use, would facilitate competition 
with the actor.
    (5) Infeasible under the circumstances. (i) The actor demonstrates, 
prior to responding to the request pursuant to paragraph (b) of this 
section, through a contemporaneous written record or other 
documentation, its consistent and non-discriminatory consideration of 
the following factors that led to its determination that complying with 
the request would be infeasible under the circumstances:
    (A) The type of electronic health information and the purposes for 
which it may be needed;
    (B) The cost to the actor of complying with the request in the 
manner requested;
    (C) The financial and technical resources available to the actor;
    (D) 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;
    (E) Whether the actor owns or has control over a predominant 
technology, platform, health information exchange, or health 
information network through which electronic health information is 
accessed or exchanged; and
    (F) Why the actor was unable to provide access, exchange, or use of 
electronic health information consistent with the exception in Sec.  
171.301.
    (ii) In determining whether the circumstances were infeasible under 
paragraph (a)(3)(i) of this section, it shall not be considered whether 
the manner requested would have:
    (A) Facilitated competition with the actor; or
    (B) Prevented the actor from charging a fee or resulted in a 
reduced fee.
* * * * *

0
21. Revise Sec.  171.301 to read as follows:


Sec.  171.301   Manner exception--When will an actor's practice of 
limiting the manner in which it fulfills a request to access, exchange, 
or use electronic health information not be considered information 
blocking?

    An actor's practice of limiting the manner in which it fulfills a 
request to access, exchange, or use electronic health information will 
not be considered information blocking when the practice follows the 
conditions of this section.
    (a) Manner requested. (1) An actor must fulfill a request for 
electronic health information 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 in the manner 
requested.
    (2) If an actor fulfills a request for electronic health 
information in any manner requested:
    (i) Any fees charged by the actor in relation to fulfilling the 
request are not required to satisfy the exception in Sec.  171.302; and
    (ii) Any license of interoperability elements granted by the actor 
in relation to fulfilling the request is not required to satisfy the 
exception in Sec.  171.303.
    (b) Alternative manner. If an actor does not fulfill a request for 
electronic health information 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 in the manner 
requested, the actor must fulfill the request in an alternative manner, 
as follows:
    (1) The actor must fulfill the request without unnecessary delay in 
the following order of priority, starting with paragraph (b)(1)(i) of 
this section and only proceeding to the next consecutive paragraph if 
the actor is technically unable to fulfill the request in the manner 
identified in a paragraph.
    (i) Using technology certified to standard(s) adopted in part 170 
that is specified by the requestor.
    (ii) Using content and transport standards specified by the 
requestor and published by:
    (A) The Federal Government; or
    (B) A standards developing organization accredited by the American 
National Standards Institute.
    (iii) Using an alternative machine-readable format, including the 
means to interpret the electronic health information, agreed upon with 
the requestor.
    (2) Any fees charged by the actor in relation to fulfilling the 
request are required to satisfy the exception in Sec.  171.302.
    (3) Any license of interoperability elements granted by the actor 
in relation to fulfilling the request is required to satisfy the 
exception in Sec.  171.303.

0
22. Add Subpart D, consisting of Sec. Sec.  171.400 through 171.403 to 
read as follows:

Subpart D--Exceptions That Involve Practices Related to Actors' 
Participation in The Trusted Exchange Framework and Common 
Agreement (TEFCA<SUP>SM</SUP>)

Sec.
171.400 Availability and effect of exceptions.
171.401 [Reserved]
171.402 [Reserved]
171.403 TEFCA manner exception.

    Authority:  42 U.S.C. 300jj-52; 5 U.S.C. 552.


Sec.  171.400  Availability and effect of exceptions.

    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.


Sec.  171.401  [Reserved].


Sec.  171.402   [Reserved].


Sec.  171.403  --TEFCA manner exception--When will an actor's practice 
of limiting the manner in which it fulfills a request to access, 
exchange, or use electronic health information to only via TEFCA not be 
considered information blocking?

    An actor's practice of limiting the manner in which it fulfills a 
request for access, exchange, or use of electronic health information 
to only via TEFCA will not be considered information blocking when the 
practice follows the conditions specified in paragraphs (a) through (d) 
of this section.
    (a) Mutually part of TEFCA. The actor and requestor are both part 
of TEFCA.
    (b) Requestor capability. The requestor is capable of such access,

[[Page 1438]]

exchange, or use of the requested electronic health information from 
the actor via TEFCA.
    (c) Limitation. The request for access, exchange, or use of EHI is 
not via the standards adopted in 45 CFR 170.215, including version(s) 
of those standards approved pursuant to 45 CFR 170.405(b)(8).
    (d) Fees and licensing. (1) Any fees charged by the actor in 
relation to fulfilling the request are required to satisfy the 
exception in Sec.  171.302; and
    (2) Any license of interoperability elements granted by the actor 
in relation to fulfilling the request is required to satisfy the 
exception in Sec.  171.303.

Xavier Becerra,
Secretary, Department of Health and Human Services.
[FR Doc. 2023-28857 Filed 1-2-24; 4:15 pm]
 BILLING CODE 4150-45-P


</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>