Rule2023-28857
Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
January 9, 2024
Effective
February 8, 2024
Issuing agencies
Health and Human Services Department
Abstract
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.
Full Text
<html>
<head>
<title>Federal Register, Volume 89 Issue 6 (Tuesday, January 9, 2024)</title>
</head>
<body><pre>
[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 [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[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, <a href="http://HealthIT.gov">HealthIT.gov</a>, 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: <a href="https://www.healthit.gov/topic/information-blocking/">https://www.healthit.gov/topic/information-blocking/</a>.
---------------------------------------------------------------------------
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 <a href="https://onc-healthit.github.io/api-resource-guide/">https://onc-healthit.github.io/api-resource-guide/</a>.
\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, <a href="https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government">https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government</a>.
\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, <a href="https://www.federalregister.gov/documents/2023/02/22/2023-03779/further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal">https://www.federalregister.gov/documents/2023/02/22/2023-03779/further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal</a>.
---------------------------------------------------------------------------
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\ <a href="http://HealthIT.gov">HealthIT.gov</a>: Embracing Health Equity by Design. <a href="https://www.healthit.gov/buzz-blog/health-it/embracing-health-equity-by-design">https://www.healthit.gov/buzz-blog/health-it/embracing-health-equity-by-design</a>.
---------------------------------------------------------------------------
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. <a href="https://www.federalregister.gov/documents/2023/11/01/2023-24283/safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence">https://www.federalregister.gov/documents/2023/11/01/2023-24283/safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence</a>.
---------------------------------------------------------------------------
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). <a href="https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-access-Memo.pdf">https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-access-Memo.pdf</a>.
---------------------------------------------------------------------------
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, <a href="https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy">https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy</a>.
---------------------------------------------------------------------------
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 <a href="http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930">http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930</a>; 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 <a href="http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-exchange-yaraghi">http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-exchange-yaraghi</a>;
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 <a href="http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930">http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930</a>.
---------------------------------------------------------------------------
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, <a href="https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government">https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government</a>.
---------------------------------------------------------------------------
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: <a href="https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf">https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf</a>.
---------------------------------------------------------------------------
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\ <a href="https://www.archives.gov/files/federal-register/executive-orders/pdf/12866.pdf">https://www.archives.gov/files/federal-register/executive-orders/pdf/12866.pdf</a>.
\21\ <a href="https://obamawhitehouse.archives.gov/the-press-office/2011/01/18/executive-order-13563-improving-regulation-and-regulatory-review">https://obamawhitehouse.archives.gov/the-press-office/2011/01/18/executive-order-13563-improving-regulation-and-regulatory-review</a>.
\22\ <a href="https://www.whitehouse.gov/briefing-room/presidential-actions/2023/04/06/executive-order-on-modernizing-regulatory-review/">https://www.whitehouse.gov/briefing-room/presidential-actions/2023/04/06/executive-order-on-modernizing-regulatory-review/</a>.
---------------------------------------------------------------------------
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. <a href="https://www.bls.gov/oes/current/oes_nat.htm">https://www.bls.gov/oes/current/oes_nat.htm</a>.
---------------------------------------------------------------------------
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: <a href="https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf">https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf</a>.
\25\ See API Resource Guide: <a href="https://onc-healthit.github.io/api-resource-guide/">https://onc-healthit.github.io/api-resource-guide/</a>.
---------------------------------------------------------------------------
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\ <a href="https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf">https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf</a>.
---------------------------------------------------------------------------
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
<a href="http://www.healthIT.gov/uscdi">www.healthIT.gov/uscdi</a>.
---------------------------------------------------------------------------
\28\ <a href="https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi</a>.
---------------------------------------------------------------------------
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\ <a href="https://www.healthit.gov/buzz-blog/interoperability/uscdi-onc-new-data-element-and-class-submission-system-now-available">https://www.healthit.gov/buzz-blog/interoperability/uscdi-onc-new-data-element-and-class-submission-system-now-available</a>.
\30\ <a href="https://www.healthit.gov/isa/ONDEC">https://www.healthit.gov/isa/ONDEC</a>.
---------------------------------------------------------------------------
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\ <a href="https://www.healthit.gov/sites/default/files/2023-07/2023_SVAP_Fact_Sheet.pdf">https://www.healthit.gov/sites/default/files/2023-07/2023_SVAP_Fact_Sheet.pdf</a>.
---------------------------------------------------------------------------
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\ <a href="https://www.healthit.gov/sites/default/files/page/2023-07/Standards_Bulletin_2023-2.pdf">https://www.healthit.gov/sites/default/files/page/2023-07/Standards_Bulletin_2023-2.pdf</a>.
\33\ <a href="https://www.healthit.gov/topic/standards-version-advancement-process-svap">https://www.healthit.gov/topic/standards-version-advancement-process-svap</a>.
---------------------------------------------------------------------------
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\ <a href="https://site.healthit.gov/sandbox-ccda/ccda-validator">https://site.healthit.gov/sandbox-ccda/ccda-validator</a>.
\35\ <a href="https://inferno.healthit.gov/">https://inferno.healthit.gov/</a>.
\36\ <a href="https://www.healthit.gov/sites/default/files/page/2023-04/LEAP%20FY2023%20SEN_508.pdf">https://www.healthit.gov/sites/default/files/page/2023-04/LEAP%20FY2023%20SEN_508.pdf</a>.
---------------------------------------------------------------------------
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 <a href="https://www.federalregister.gov/documents/2022/12/13/2022-26479/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability">https://www.federalregister.gov/documents/2022/12/13/2022-26479/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability</a>.
---------------------------------------------------------------------------
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: <a href="https://www.healthit.gov/uscdi">https://www.healthit.gov/uscdi</a>.
---------------------------------------------------------------------------
\38\ <a href="https://www.healthit.gov/topic/certification-ehrs/certification-health-it">https://www.healthit.gov/topic/certification-ehrs/certification-health-it</a>.
---------------------------------------------------------------------------
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 <a href="https://www.healthit.gov/isa/sites/isa/files/2022-10/USCDI-Version-3-October-2022-Errata-Final.pdf">https://www.healthit.gov/isa/sites/isa/files/2022-10/USCDI-Version-3-October-2022-Errata-Final.pdf</a> 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 <a href="https://www.healthit.gov/uscdi">https://www.healthit.gov/uscdi</a>, 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 <a href="http://www.healthIT.gov/uscdi">www.healthIT.gov/uscdi</a>. 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, <a href="https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf">https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf</a>.
\40\ <a href="https://www.healthit.gov/topic/health-it-health-care-settings/social-determinants-health">https://www.healthit.gov/topic/health-it-health-care-settings/social-determinants-health</a>.
---------------------------------------------------------------------------
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\ <a href="http://hl7.org/fhir/us/sdoh-clinicalcare/STU2/">http://hl7.org/fhir/us/sdoh-clinicalcare/STU2/</a>.
---------------------------------------------------------------------------
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., <a href="https://www.healthit.gov/topic/patient-access-health-records/patient-access-health-records">https://www.healthit.gov/topic/patient-access-health-records/patient-access-health-records</a>.
---------------------------------------------------------------------------
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\ <a href="https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf">https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf</a>.
---------------------------------------------------------------------------
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 d
[…truncated; see source link]Indexed from Federal Register on January 9, 2024.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.