Proposed Rule2023-07229
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
April 18, 2023
Issuing agencies
Health and Human Services Department
Abstract
This proposed rule would 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 information technology (health IT) developers under the ONC Health IT Certification Program (Program). This proposed rule would also make 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. This proposed rule would establish a new baseline version of the United States Core Data for Interoperability (USCDI). Additionally, this proposed rule would provide 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 proposed rule would also update the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs.
Full Text
<html>
<head>
<title>Federal Register, Volume 88 Issue 74 (Tuesday, April 18, 2023)</title>
</head>
<body><pre>
[Federal Register Volume 88, Number 74 (Tuesday, April 18, 2023)]
[Proposed Rules]
[Pages 23746-23917]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2023-07229]
[[Page 23745]]
Vol. 88
Tuesday,
No. 74
April 18, 2023
Part II
Department of Health and Human Services
-----------------------------------------------------------------------
45 CFR Parts 170 and 171
Health Data, Technology, and Interoperability: Certification Program
Updates, Algorithm Transparency, and Information Sharing; Proposed Rule
Federal Register / Vol. 88 , No. 74 / Tuesday, April 18, 2023 /
Proposed Rules
[[Page 23746]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 170 and 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: Proposed rule.
-----------------------------------------------------------------------
SUMMARY: This proposed rule would 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 information technology (health IT) developers
under the ONC Health IT Certification Program (Program). This proposed
rule would also make 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. This proposed rule would establish a new
baseline version of the United States Core Data for Interoperability
(USCDI). Additionally, this proposed rule would provide 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 proposed rule would also update the
Program in additional ways to advance interoperability, enhance health
IT certification, and reduce burden and costs.
DATES: To be assured consideration, written or electronic comments must
be received at one of the addresses provided below, no later than 5
p.m. on June 20, 2023.
ADDRESSES: You may submit comments, identified by RIN 0955-AA03, by any
of the following methods (please do not submit duplicate comments).
Because of staff and resource limitations, we cannot accept comments by
facsimile (FAX) transmission.
<bullet> Federal eRulemaking Portal: Follow the instructions for
submitting comments. Attachments should be in Microsoft Word, Microsoft
Excel, or Adobe PDF; however, we prefer Microsoft Word. <a href="http://www.regulations.gov">http://www.regulations.gov</a>.
<bullet> Regular, Express, or Overnight Mail: Department of Health
and Human Services, Office of the National Coordinator for Health
Information Technology, Attention: Health Data, Technology, and
Interoperability: Certification Program Updates, Algorithm
Transparency, and Information Sharing Proposed Rule, Mary E. Switzer
Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201.
Please submit one original and two copies.
<bullet> Hand Delivery or Courier: Office of the National
Coordinator for Health Information Technology, Attention: Health Data,
Technology, and Interoperability: Certification Program Updates,
Algorithm Transparency, and Information Sharing Proposed Rule, Mary E.
Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC
20201. Please submit one original and two copies. (Because access to
the interior of the Mary E. Switzer Building is not readily available
to persons without federal government identification, commenters are
encouraged to leave their comments in the mail drop slots located in
the main lobby of the building.)
Enhancing the Public Comment Experience: To facilitate public
comment on this proposed rule, a copy will be made available in
Microsoft Word format on ONC's website (<a href="http://www.healthit.gov">http://www.healthit.gov</a>). We
believe this version will make it easier for commenters to access and
copy portions of the proposed rule for use in their individual
comments. Additionally, a separate document (``public comment
template'') will also be made available on ONC's website (<a href="http://www.healthit.gov">http://www.healthit.gov</a>) for the public to use in providing comments on the
proposed rule. This document is meant to provide the public with a
simple and organized way to submit comments on proposals and respond to
specific questions posed in the preamble of the proposed rule. While
use of this document is entirely voluntary, we encourage commenters to
consider using the document in lieu of unstructured comments, or to use
it as an addendum to narrative cover pages. We believe that use of the
document may facilitate our review and understanding of the comments
received. The public comment template will be available shortly after
the proposed rule publishes in the Federal Register. This short delay
will permit the appropriate citation in the public comment template to
pages of the published version of the proposed rule.
Inspection of Public Comments: All comments received before the
close of the comment period will be available for public inspection,
including any personally identifiable or confidential business
information that is included in a comment. Please do not include
anything in your comment submission that you do not wish to share with
the general public. Such information includes, but is not limited to,
the following: a person's social security number; date of birth;
driver's license number; state identification number or foreign country
equivalent; passport number; financial account number; credit or debit
card number; any personal health information; or any business
information that could be considered proprietary. We will post all
comments that are received before the close of the comment period at
<a href="http://www.regulations.gov">http://www.regulations.gov</a>.
Docket: For access to the docket to read background documents or
comments received, go to <a href="http://www.regulations.gov">http://www.regulations.gov</a> or the Department
of Health and Human Services, Office of the National Coordinator for
Health Information Technology, Mary E. Switzer Building, Mail Stop:
7033A, 330 C Street SW, Washington, DC 20201 (call ahead to the contact
listed below to arrange for inspection).
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
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 Standard
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)
[[Page 23747]]
x. Patient Requested Restrictions Certification Criterion
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
III. ONC Health IT Certification Program Updates
A. ``The ONC Certification Criteria for Health IT'' and
Discontinuing Year Themed ``Editions''
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 Standard
(USCDI) v3
a. Background
b. Certification Criteria That Reference USCDI
c. 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
a. Background
b. Standards Landscape for Case Reporting
c. Proposed Updates to Case Reporting in Sec. 170.315(f)(5)
d. Proposed Adoption of Standards for Electronic Case Reporting
e. Proposal for Reporting
5. Decision Support Interventions and Predictive Models
a. Background
b. Summary of Proposals
c. Proposed Requirements for Decision Support Interventions
(DSI) Certification Criterion
d. Proposed Updates to Real World Testing Condition for CDS
Criterion
6. Synchronized Clocks Standard
a. Background
b. Justification
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 Requested Restrictions Certification Criterion
a. Patient Right To Request a Restriction New Criterion--Primary
Proposal
b. Alignment With Adopted Standards--Alternate Proposals and
Request for Information
c. Alignment With Applicable Law--Request for Information
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--Proposed Measures
3. Insights Condition and Maintenance of Certification
Requirements
4. Insights Condition and Maintenance of Certification's Process
for Reporting
G. Requests for Information
1. Laboratory Data Interoperability Request for Information
a. Background
b. Request for Information
2. Request for Information on Pharmacy Interoperability
Functionality Within the ONC Health IT Certification Program
Including Real-Time Prescription Benefit Capabilities
a. Background
b. Request for Information
c. Real-Time Prescription Benefit Certification Criterion
d. Health IT Ecosystem for Pharmacy Interoperability
3. FHIR Standard
a. FHIR Subscriptions Request for Information
b. Clinical Decision Support Hooks Request for Information
c. FHIR Standard for Scheduling Request for Information
d. SMART Health Links Request for Information
IV. Information Blocking Enhancements
A. Defined Terms
1. Offer Health Information Technology or Offer Health IT
a. Exclusion of Certain Funding Subsidy Arrangements From Offer
Definition
b. Implementation and Use Activities That Are Not an Offering
c. Consulting and Legal Services Exclusion From Offer Definition
2. Health IT Developer of Certified Health IT: Self-Developer
Health Care Providers
3. Information Blocking Definition
B. Exceptions
1. Infeasibility
a. Infeasibility Exception--Uncontrollable Events Condition
b. Third Party Seeking Modification Use
c. Manner Exception Exhausted
2. Manner Exception--TEFCA Reasonable and Necessary Activities
a. Background
b. TEFCA Condition for the ``Manner'' Exception
C. 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. Response to Comments
VII. Collection of Information Requirements
A. Independent Entity
B. Health IT Developers
C. ONC-ACBs
VIII. Regulatory Impact Statement
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 Secretary of Health and Human Services has delegated
responsibilities to ONC for the implementation of 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 identifying
reasonable and necessary activities that do not constitute information
blocking.\1\ ONC is responsible for implementation of 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, among other things: 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, among other goals; and requirements to keep or recognize a
[[Page 23748]]
program or programs for the voluntary certification of health
information technology. This proposed rule would fulfill statutory
requirements; provide transparency; advance equity, innovation, and
interoperability; and support the access, exchange, and use of
electronic health information (EHI). Transparency regarding healthcare
information and activities--as well as the interoperability and
electronic exchange of health information--are all in the best interest
of the patient and are central to the efforts of the Department of
Health and Human Services to enhance and protect the health and well-
being of all Americans.
---------------------------------------------------------------------------
\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>.
---------------------------------------------------------------------------
In addition to fulfilling the HITECH Act's and Cures Act's
requirements described above and advancing interoperability, the
proposed rule would contribute to fulfilling Executive Orders (E.O.)
13994, 13985, 14036, 14058, and 14091. 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) have
enabled critical steps to making data available across the healthcare
system. The proposed update in this proposed rule to adopt the United
States Core Data for Interoperability Standard Version 3 (USCDI v3)
would promote the establishment and use of interoperable data sets of
EHI for interoperable health data exchange. As discussed in section
III.C.1, USCDI v3 would facilitate the gathering, sharing, and
publication of data for use in public health and emergency response
(e.g., the COVID-19 pandemic) by capturing and promoting the sharing of
key data elements related to public health. The proposed updates to
Application Programming Interfaces (APIs) Conditions and Maintenance of
Certification requirements, as discussed in section III.C.7, would
continue ONC's efforts to develop and standardize APIs and would help
individuals and other authorized health care providers, including those
engaged in public health, to securely access EHI through the broader
adoption of standardized APIs.<SUP>2 3</SUP> Additionally, the proposed
rule would adopt consensus-based, industry-developed health IT
standards for certified Health IT Modules to support electronic case
reporting. As discussed in section III.C.4, this would, among other
benefits, facilitate faster and more efficient disease tracking and
case management. It also would provide more timely and complete data
than manual or non-standardized reporting. In addition to proposing new
standards to support public health initiatives, we also request comment
and seek input from the public in section III.G regarding health IT
standards that could be adopted within the Program to strengthen and
advance laboratory interoperability.
---------------------------------------------------------------------------
\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 committed to advancing health equity, and this proposed 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 any policies and programs that serve as barriers to equal
opportunity.'' As noted above, we propose to adopt USCDI v3. If
finalized, the adoption of USCDI v3 would update the USCDI standard to
include data elements such as sexual orientation and social
determinants of health, as discussed in sections III.C.1 and III.C.8 of
this proposed rule. Expanding the data elements included in USCDI would
increase the amount and type of data available to be used and exchanged
through certified health IT. These proposed updates could help capture
more accurate and complete patient characteristics that are reflective
of patient diversity and 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 would
also support 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>.
---------------------------------------------------------------------------
As discussed in section III.C.1.c, the proposal to adopt USCDI v3
also supports the concept of ``health equity by design,'' where health
equity considerations are identified and incorporated from the
beginning and throughout the technology design, build, and
implementation process, and health equity strategies, tactics, and
patterns are guiding principles for developers, enforced by technical
architecture, and built into the technology at every layer. If the
proposal to adopt USCDI v3 is finalized, certified health IT products
and capabilities should be designed with a foundational approach to
promote equity. As a result, by their very design, certified health IT
and the workflows around them should support equity and efforts to
reduce disparities.
E.O. 14091 of Feb. 16, 2023, builds upon previous equity-related
E.O.s, including E.O. 13985. Section 1 of E.O. 14091 requires the
Federal Government to ``promote equity in science and root out bias in
the design and use of new technologies, such as artificial
intelligence.'' Section 8 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.''
This proposed rule would revise the existing clinical decision
support (CDS) certification criterion by proposing a ``Decision Support
Interventions'' (DSIs) certification criterion to keep pace with
[[Page 23749]]
advances in software that developers of certified health IT enable or
interface with to aid decision-making in healthcare. As discussed in
section III.C.5, this criterion would also advance health equity by
design by making it known to users of certified Health IT Modules
certified to the criterion whether demographic, social determinants of
health assessment data are used in DSIs. Finally, these proposals
would: (1) establish a definition for algorithm-based, ``predictive''
DSIs; (2) require certified Health IT Modules certified to the
criterion that enable or interface with predictive DSIs to enable users
to review information about additional source attributes relevant to
health equity, among other purposes, (3) require developers of
certified Health IT Modules certified to the criterion to employ or
engage in intervention risk management practices for all predictive
DSIs that the developers' certified Health IT Modules enable or
interface; and (4) make summary information regarding these practices
available publicly.
Together, these proposed requirements should improve transparency,
promote trustworthiness, and incentivize the development and wider use
of fair, appropriate, valid, effective, and safe predictive DSIs to aid
decision-making. The resulting information transparency would enable
users, including health care providers, to scrutinize these
technologies and would increase public trust and confidence in these
technologies. The resulting information transparency could expand the
use of these technologies in safer, more appropriate, and more
equitable ways. This transparency would also inform wider discussions
across industry and academia regarding how to evaluate and communicate
performance related to predictive decision support interventions.
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).\6\ This proposed rule would
foster 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 would be 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 to 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 and more choices in their health care providers. This is
similar to how APIs have impacted other sectors of the economy, such as
travel, banking, and commerce.
---------------------------------------------------------------------------
\6\ 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 proposed rule would
provide 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 (84 FR
7508) and Final (85 FR 25790 through 25791) Rules, we discussed how the
information blocking provisions provide a comprehensive response to the
issues identified by empirical and economic research that 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.\7\
We explained that the information blocking provision of the Public
Health Service Act (PHSA) itself expressly addresses practices that
impede innovation and advancements in EHI access, exchange, and use,
including care delivery enabled by health IT (section 3022(a)(2)(C)(ii)
of the PHSA). Actors subject to the information blocking provisions
may, among other practices, attempt to exploit their control over
interoperability elements to create barriers to entry for competing
technologies and services that offer greater value for health IT
customers and users, provide new or improved capabilities, and enable
more robust access, exchange, and use of electronic health information
(EHI) (85 FR 25820).\8\ Information blocking may also harm competition
not just 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 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 providers vulnerable to
acquisition or inducement into arrangements that enhance the market
power of incumbent providers to the detriment of consumers and
purchasers of healthcare services (85 FR 25820). The implementation of
the new information blocking provisions proposed in section IV of this
proposed rule would 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 electronic health information.
---------------------------------------------------------------------------
\7\ 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).
\8\ 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 and
effective delivery of services with a focus on the experience of
individuals, health IT developers, and health care providers.\9\ As
required by section 4002 of the Cures Act and included in the ONC Cures
Act Final Rule (85 FR 25717), we
[[Page 23750]]
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 proposed rule would implement the EHR Reporting Program
Condition and Maintenance of Certification requirement outlined in the
Cures Act by establishing a new Insights Condition and Maintenance of
Certification (``Insights Condition'') within Program. As discussed in
section III.F, the implementation of the Insights Condition would
provide transparent reporting to address information gaps in the health
IT marketplace and provide insights on the use of specific certified
health IT functionalities. The implementation of this new Condition and
Maintenance of Certification requirement would allow ONC to gain
understanding of the use of health IT and would provide ONC with
information about consumers' experience with certified health IT.
---------------------------------------------------------------------------
\9\ 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>.
---------------------------------------------------------------------------
We also strive to improve federal agency coordination. ONC works
with the Centers for Medicare & Medicaid Services (CMS) to ensure that
our own certification timelines complement timelines for CMS programs
that reference ONC regulations, such as the Medicare Promoting
Interoperability Program and the Promoting Interoperability performance
category of the Merit-based Incentive Payment System (MIPS). In the
interest of clarity and cohesion among HHS components, we have proposed
to align 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''
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. ONC first introduced the
concept of an ``edition'' of ONC health IT certification criteria in
2012. In 2012, we stated that we would refer to the certification
criteria adopted in Sec. Sec. 170.302, 170.304, and 170.306
collectively as the ``2011 Edition EHR certification criteria'' and
that the certification criteria adopted in Sec. 170.314 would be
referred to as the ``2014 Edition EHR certification criteria'' (77 FR
13836). In 2015, we issued a 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,'' (2015 Edition Final Rule) and
adopted the ``2015 Edition Health IT Certification Criteria'' (80 FR
62602). We codified the 2015 Edition certification criteria in Sec.
170.315 to set them apart from other editions of certification criteria
(80 FR 62608). In 2020, we published the ONC Cures Act Final Rule (85
FR 25642) and adopted updates to the 2015 Edition. These updates
included new certification criteria, standards, and requirements, as
well as incremental revisions to existing 2015 Edition certification
criteria to better enable interoperability and the access, exchange,
and use of electronic health information (85 FR 25664-65). Because we
did not adopt a wholesale new edition of certification criteria in a
different CFR section, we retained the overall 2015 Edition title for
the changes included in the ONC Cures Act Final Rule and made specific
timebound compliance changes within certification criteria.
Subsequent to publication of the ONC Cures Act Final Rule through
public meetings and correspondence, we heard that the continued use and
reference to the 2015 Edition inaccurately implied an age and
outdatedness to the certification criteria we had adopted. More
importantly, we heard significant positive feedback that the
incremental approach to updates is generally beneficial as a long-term
approach. Specifically, we heard 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
certified Health IT Module certification criteria 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 the specific development needs.
For these reasons, we no longer believe that it is helpful or
necessary to maintain an ``edition'' naming convention or to adopt
entirely new editions of certification criteria to encapsulate updates
over time. Instead, we believe there should be a single set of
certification criteria, which will be updated in an incremental fashion
in closer alignment to standards development cycles and regular health
IT development timelines. Therefore, in section III.A, we propose to
rename all 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'' would create more stability for
the Program and for federal partners who reference the Program, as well
as make it easier for developers of certified health IT to maintain
their product certificates over time. This proposal to remove
``editions'' from the Program would also help users of certified health
IT identify which certification criteria are necessary for their
participation in other HHS programs, such as Medicare Promoting
Interoperability Program and the Promoting Interoperability performance
category of the MIPS. For example, users would only need to know that
their Health IT Module is certified by ONC in accordance with the ONC
Certification Criteria for Health IT for successful participation in
MIPS, as compared to the current state where they must also know if the
Health IT Module complies with the 2014 Edition Certification Criteria,
the 2015 Edition Certification Criteria, or the 2015 Edition Cures
Update Certification Criteria.
In addition, we believe that this approach will have the benefit of
reducing administrative burden for health IT developers with Health IT
Modules certified through the Program. Previously, duplicative
references to certification criteria across different year themed
editions created administrative burden on developers as they had the
effect of requiring health IT 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 proposal, unchanged certification criteria would
no longer be duplicated as separate criteria under multiple editions.
b. New and Revised Standards and Certification Criteria
i. The United States Core Data for Interoperability Standard Version 3
(USCDI v3)
In the ONC Cures Act Final Rule, ONC adopted the United States Core
Data for Interoperability (USCDI) as a standard to replace the Common
Clinical Data Set (CCDS) in several ONC
[[Page 23751]]
certification criteria (85 FR 25670). We adopted USCDI Version 1 (USCDI
v1) as a standard in Sec. 170.213 and incorporated it by reference in
Sec. 170.299. The new USCDI v1 standard established a set of data
classes and constituent data elements required to support
interoperability nationwide. USCDI v1 is a required part of certain
certification criteria updates that were made to the existing 2015
Edition Health IT Certification Criteria in the ONC's Cures Act Final
Rule. These changes constitute the ``2015 Edition Cures Update.''
ONC also indicated in the ONC Cures Act Final Rule that we intended
to establish and follow a predictable, transparent, and collaborative
process to expand future versions of the USCDI, including providing the
public with the opportunity to comment on the USCDI's expansion (85 FR
25670). ONC established a process, including creating the ONC New Data
Element and Class (ONDEC) submission system,\10\ which provides the
public with the opportunity to submit new data elements to be
considered for inclusion in future versions of USCDI. Following this
established process, ONC published USCDI Version 2 (USCDI v2) in July
2021 \11\ and finalized and released USCDI Version 3 (USCDI v3) in July
2022.\12\ Both USCDI v2 and USCDI v3 contain new data elements and data
classes beyond what was included in USCDI v1. USCDI v3 contains all
data elements and classes added in USCDI v2.
---------------------------------------------------------------------------
\10\ ONC. (2020, July 27). USCDI ONDEC. Retrieved March 16,
2023, from <a href="https://www.healthit.gov/isa/ONDEC">https://www.healthit.gov/isa/ONDEC</a>).
\11\ ONC. (2021, July 2). United States Core Data for
Interoperability (USCDI). Interoperability Standards Advisory (ISA).
Retrieved March 16, 2023, from <a href="https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v2">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v2</a>.
\12\ United States Core Data for Interoperability (USCDI),''
Interoperability Standards Advisory (ISA) (ONC, July 5, 2022),
<a href="https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v3">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v3</a>.
---------------------------------------------------------------------------
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. To advance interoperability, in section III.C.1, ONC
proposes to add the newly released USCDI v3 in Sec. 170.213(b). We
propose that USCDI v1 would remain in regulation and now be codified in
Sec. 170.213(a) and we propose to add USCDI v3 to Sec. 170.213 (to be
codified as Sec. 170.213(b)). We also propose to incorporate by
reference USCDI v3 in Sec. 170.299 as of the effective date of the
final rule. In addition, we propose that the USCDI v1 (July 2020
Errata) in the USCDI standard in Sec. 170.213(a) will expire on
January 1, 2025. Under this proposal, both versions would be referenced
as applicable in the USCDI standard in Sec. 170.213 for the time
period up to and including December 31, 2024.
ii. C-CDA Companion Guide Updates
In section III.C.2, we propose to adopt the HL7[supreg] CDA[supreg]
R2 Implementation Guide: C-CDA Templates for Clinical Notes STU
Companion Guide, Release 3--US Realm (C-CDA Companion Guide R3) in
Sec. 170.205(a)(6). The C-CDA Companion Guide R3 provides supplemental
guidance and additional technical clarification for specifying data in
the C-CDA Release 2.1, including data specified in USCDI v2. However,
it is our understanding that HL7 is working on updating the C-CDA
Companion Guide for USCDI v3. If the updated C-CDA Companion Guide
Release 4 (R4) is published before the date of publication of the final
rule, it is our intention to consider adopting the updated Companion
Guide that provides guidance and clarifications for specifying data in
USCDI v3.
iii. ``Minimum Standards'' Code Sets Updates
In the 2015 Edition Final Rule, we established a policy of adopting
newer versions of ``minimum standards'' code sets that update
frequently (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). 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.
Because these code sets are updated frequently, we will consider
whether it may be more appropriate to adopt a version of a minimum
standards code set issued after publication of this proposed rule but
before publication of a final rule. In section III.C.3, we propose to
adopt newer versions 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 updating the minimum standards code sets listed
above, we propose to update some of the 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 also propose to change the heading of Sec. 170.207(o) from
``sexual orientation and gender identity'' to ``sexual orientation and
gender information'' to acknowledge that Sec. 170.207(o) may include
standard code sets to support other gender related data items.
iv. Electronic Case Reporting
In section III.C.4 of this proposed rule, we propose to revise 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 are proposed to
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 and
parameters. 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
In section III.C.5 of this proposed rule, we propose the
certification criterion, ``decision support interventions (DSI)'' in
Sec. 170.315(b)(11). The DSI criterion is a revised certification
criterion as it serves as both an iterative and replacement criterion
for the ``clinical decision support (CDS)'' criterion in Sec.
170.315(a)(9). This criterion would reflect an array of contemporary
functionalities, data elements, and software applications, including
the use of predictive models or algorithms, that certified Health IT
Module(s) enable or interface with to aid decision-making in
healthcare.
[[Page 23752]]
We propose to adopt a new definition for ``predictive decision
support intervention,'' in Sec. 170.102, and we propose that
developers of certified health IT with Health IT Module(s) certified to
the criterion we propose in Sec. 170.315(b)(11) that enable or
interface with predictive DSIs would be subject to requirements to
provide transparency of predictive DSIs. Specifically, we propose that
Health IT Modules that enable or interface with predictive DSIs enable
a user to review predictive DSI ``source attribute'' information
through the Health IT Module. We also propose that developers of
certified health IT with Health IT Modules that enable or interface
with predictive DSIs employ or engage in ``intervention risk
management'' practices. We also propose that summary information
regarding these intervention risk management practices be made
available via a publicly accessible hyperlink. Together, our proposals
for predictive DSI-specific source attributes and intervention risk
management practices information are intended to provide appropriate
information to help guide medical decisions at the time and place of
care, consistent with 42 U.S.C. 300jj-11(b)(4).
We propose that Health IT Modules certified to Sec. 170.315(b)(11)
enable users to provide feedback regarding DSI information displayed
through the Health IT Module, and that such Health IT Modules make
available such feedback data for export in a computable format.
We propose that developers of certified health IT with Health IT
Modules certified to Sec. 170.315(b)(11) comply with these new
requirements by December 31, 2024. For the intervening time between
finalization of this proposed rule and December 31, 2024, we propose to
add Sec. 170.315(a)(9) to the list of applicable certification
criteria for the real-world testing Condition and Maintenance of
Certification requirement in Sec. 170.405(a), thus requiring
developers of certified health IT with Health IT Module(s) certified to
Sec. 170.315(a)(9) or Sec. 170.315(b)(11) to participate in real
world testing plan and results submission.
Finally, we propose to update the Base EHR definition in Sec.
170.102 to include an option of either the existing ``clinical decision
support (CDS)'' version of the criterion in Sec. 170.315(a)(9) or the
revised ``decision support interventions'' criterion in Sec.
170.315(b)(11) for the period up to and including December 31, 2024,
and to include only ``decision support interventions'' in Sec.
170.315(b)(11) on and after January 1, 2025. We discuss in section
III.C.5.d of this preamble proposals that would constitute changes to
the CDS criterion, as the new DSI criterion. We describe how much of
the structure and requirements are duplicated across these criteria and
reflect the capabilities included in the CDS criterion with which
Program participants have years of familiarity and can find, for
comparison purposes, in Sec. 170.315(a)(9).
vi. Synchronized Clocks Standard
We propose in section III.C.6 to remove the current named
specification for clock synchronization, which is Network Time Protocol
(NTP v4 of RFC 5905), in Sec. 170.210(g), based on public feedback and
reflective of contemporary norms within the industry. Additionally, we
propose to keep the requirement for any network time protocol (NTP)
standard to be present, though any NTP standard could be used.
vii. Standardized API for Patient and Population Services
We propose in section III.C.7 to revise the ``standardized API for
patient and population services'' certification criterion in Sec.
170.315(g)(10) in several ways. We propose to require a certified
Health IT Module's authorization server to issue a refresh token
according to the implementation specification adopted in Sec.
170.215(c). The token should be valid for a period of no less than
three months and will apply to all applications using the
``confidential app'' profile for both first time and subsequent
connections.
We also propose to adopt the FHIR US Core Implementation Guide STU
version 5.0.1 in Sec. 170.215(b)(1)(ii). Based on the annual US Core
release cycle, we believe US Core IG v6.0.0 will be published before
ONC issues a final rule.\13\ Therefore, it is our intent to consider
adopting the updated US Core IG v6.0.0 that supports the data elements
and data classes in USCDI v3 since we propose to adopt USCDI v3 in this
rule. Health IT systems that adopt this version of the US Core IG can
provide the latest consensus-based capabilities for providing access to
USCDI data classes and elements using a FHIR API.
---------------------------------------------------------------------------
\13\ <a href="http://hl7.org/fhir/us/core/history.html">http://hl7.org/fhir/us/core/history.html</a>.
---------------------------------------------------------------------------
Additionally, we propose to amend the API Condition and Maintenance
of Certification requirements by adding the requirement that Certified
API Developers with patient-facing apps must publish their service base
URLs for all customers, regardless of whether the certified Health IT
Modules are centrally managed by the Certified API Developer or locally
deployed by an API Information Source, according to a specified format.
We also propose to revise the requirement in Sec.
170.315(g)(10)(vi) to specify that Health IT Modules presented for
certification that allow short-lived access tokens to expire, in lieu
of immediate access token revocation, must have such access tokens
expire within one hour of the request. This revised requirement would
align with industry standard practice for short-lived access tokens,
would provide clarity and consistent expectations that developers
revoke access or expire access privileges within one hour of a request,
and would offer patients an assurance that an application's access to
their data would be revoked or expired within one hour of a request.
We propose to adopt the Substitutable Medical Applications,
Reusable Technologies (SMART) Application Launch Framework
Implementation Guide Release 2.0.0 (SMART v2 Guide) in Sec.
170.215(c)(2), which would replace SMART v1 Guide as the standard in
Sec. 170.215(a)(3) (proposed in this rule as Sec. 170.215(c)(1)). The
SMART v2 Guide iterates 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. We
propose that the availability of the SMART v1 Guide to be adopted as a
standard in the Program would expire on January 1, 2025. After this
time, the SMART v2 Guide would 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)
In section III.C.1 of this proposed rule, we introduce proposals to
change certain data elements in USCDI, namely Sex (Assigned at Birth),
Sexual Orientation, and Gender Identity, that are also data elements in
Sec. 170.315(a)(5). We propose these changes to reflect public
feedback that the standards and terms used to represent these data
elements needed to be updated. Therefore, to ensure consistency, in
section III.C.8 of this preamble, we propose to change the name of the
certification criterion in Sec. 170.315(a)(5) from ``demographics'' to
``patient demographics and observations.'' Additionally, in order to
ensure consistent capture of these data elements across health IT, we
propose in section III.C.8 to carry these changes
[[Page 23753]]
into their respective data elements in Sec. 170.315(a)(5).
We propose to replace the specific codes sets 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 (SNOMED CT[supreg]) code set, as referenced in the standard
proposed in Sec. 170.207(o)(3). We propose that the adoption of the
code sets referenced in Sec. 170.207(n)(1) would expire on January 1,
2026, and we also propose that health IT developers can continue to use
the specific codes in the current terminology standard until December
31, 2025, in order to provide adequate time for health IT systems to
transition to the updated terminology standards.
As also discussed in section III.C.1 of this proposed rule, we have
taken note of efforts to develop clinically relevant ways of
identifying a patient's sex based on observations, to be used by a
patient's clinician when considering or evaluating diagnostic or
therapeutic services in areas such as radiology, laboratory, and
genetic testing. The concept ``Sex For Clinical Use'' (SFCU) is seen as
a valuable tool in addressing these concerns and therefore important
for clinical capture. We also propose to add SFCU as a new data element
in Sec. 170.315(a)(5)(i)(F). Additionally, we propose to add new data
elements ``Name to Use'' in Sec. 170.315(a)(5)(i)(G) and ``Pronouns''
in Sec. 170.315(a)(5)(i)(H), 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 propose in section III.C.9 to update the ``transitions of care''
certification criterion (Sec. 170.315(b)(1)) to align it with changes
proposed in Sec. 170.213, including the proposed adoption of USCDI v3
in Sec. 170.213(b)). This change would ensure that Health IT Modules
certified to Sec. 170.315(b)(1) are capable of accessing, exchanging,
and using USCDI data elements referenced in Sec. 170.213.
x. Patient Requested Restrictions Certification Criterion
We believe 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. The Health Insurance Portability and Accountability Act
(HIPAA) \14\ Privacy Rule \15\ provides individuals with several legal,
enforceable rights intended to empower them to be more active
participants in managing their health information. We make several
proposals in support of the HIPAA Privacy Rule's individuals' ``right
to request a restriction'' on certain uses and disclosures of their PHI
(see also 45 CFR 154.522(a)). We propose to adopt a new certification
criterion, revise a certification criterion, and propose modifications
for Health IT Modules certified to specific criteria under the Privacy
and Security certification Framework.
---------------------------------------------------------------------------
\14\ Public Law 104-191,110 Stat. 1936 (August 21, 1996),
codified at 42 U.S.C. 1320d-1320d8.
\15\ 45 CFR part 160 and subparts A and E of part 164.
---------------------------------------------------------------------------
We propose a new certification criterion in Sec. 170.315(d)(14),
an addition to ONC's Privacy and Security Certification Framework under
the Program in Sec. 170.550(h), and a revision to an existing
criterion in Sec. 170.315(e)(1) to support additional tools for
implementing patient requested information privacy restrictions.
xi. Requirement for Health IT Developers To Update Their Previously
Certified Health IT
We propose to make explicit in the introductory text in Sec.
170.315 that health IT developers voluntarily participating in the
Program must update their certified Health IT Modules 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 propose in section III.C.11 that
health IT developers with health IT certified to any of the
certification criteria in Sec. 170.315 would need to update their
previously certified Health IT Modules to be compliant with any revised
certification criterion adopted in Sec. 170.315, including any new
standards adopted in 45 CFR part 170 subpart B and capabilities
included in the revised certification criterion. We further propose
that health IT developers would also need to provide the updated heath
IT to customers of the previously certified health IT according to the
timelines established for that criterion and any applicable standards.
2. Assurances Condition and Maintenance of Certification Requirements
We propose in section III.D to establish additional Assurances
Condition and Maintenance of Certification requirements. We propose 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 propose two accompanying Maintenance of Certification
requirements. We propose 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 also propose 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.
Additionally, we propose separate ``timely access'' or ``timeliness''
requirements for each of the two proposed Maintenance of Certification
requirements above dictating by when a Health IT Module must be updated
to revised certification criteria and by when a Health IT Module
certified to a revised certification criterion must be provided to the
health IT developer's 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).\16\ 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.
---------------------------------------------------------------------------
\16\ ONC, Applicability Of Inherited Certified Status And Gap
Certification (2016). <a href="https://www.healthit.gov/sites/default/files/policy/public_applicability_of_gap_certification_and_inherited_certified_status.pdf">https://www.healthit.gov/sites/default/files/policy/public_applicability_of_gap_certification_and_inherited_certified_status.pdf</a>.
---------------------------------------------------------------------------
In order to ensure that all developers continue to test the real
world use of their technology as required, we propose in section III.E
to eliminate this anomaly by requiring health IT developers to include
in their real world
[[Page 23754]]
testing results report the newer version of those certified Health IT
Module(s) that are updated using Inherited Certified Status after
August 31 of the year in which the plan is submitted. 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 Electronic Health Record (EHR) Reporting Program to
provide transparent 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 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 Electronic Health Record Reporting Program
established with respect to all certified technology offered by such
developer. For clarity purposes, we intend to 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 proposed 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.''
We propose in section III.F to adopt nine reporting measures for
developers of certified health IT that focus initially on the
interoperability category, emphasizing four areas of interoperability:
individuals' access to electronic health information, public health
information exchange, clinical care information exchange, and standards
adoption and conformance. Through this first set of proposed measures,
ONC intends 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 also propose in section III.F to implement the Insights
Condition and Maintenance of Certification requirements in Sec.
170.407 in two phases, where some of the measures will be required to
be reported earlier than others. For each proposed measure, we have
included information on the rationale for proposing the measure, the
proposed numerators and denominators, and other key topics. Overall,
the intent of the Insights Condition is to provide transparent
reporting, address information gaps in the health IT marketplace, and
provide insights on the use of health IT.
5. Information Blocking Enhancements
We propose in section IV.A to define what it means to ``offer
health information technology'' or ``offer health IT'' for purposes of
the information blocking regulations in 45 CFR part 171. This
definition of what it means to offer health IT would, as proposed,
narrow the applicability of the health IT developer of certified health
IT definition. While the definition of offer health IT proposed at 45
CFR 171.102 would generally continue to include holding out for sale,
selling, or otherwise supplying certified health IT to others on
commercial or other terms, it would carve out by explicit exclusion the
provision of funding for obtaining or maintaining certified health IT.
The proposed definition would also explicitly codify that we do not
interpret health care providers or other health IT users to offer
health IT when they engage in certain activities customary and common
amongst both health care providers that purchase certified health IT
from a commercial developer or reseller and health care providers that
self-develop certified health IT. Activities we propose to codify as
explicitly excluded from the definition of what it means to offer
health IT include implementing APIs or portals for clinician or patient
access as well as the issuance of login credentials allowing licensed
healthcare professionals who are in independent practice to use a
hospital or other healthcare facility's EHR to furnish and document
care to patients in the hospital or other healthcare facility. We also
include a proposal to potentially exclude from what it means to offer
health IT the inclusion of health IT in a package of items, supplies,
facilities, and services that a management consultant handles for a
clinician practice or other health care provider in a comprehensive
(``turn key'') package of services for administrative or operational
management of the clinician practice or other health care provider (see
section IV.A.1.c, below). Finally, we seek comment on the proposed
definition of offer health IT and whether we should consider additional
exclusions.
We also propose in section IV.A to modify the health IT developer
of certified health IT definition so that it is clear that health care
providers who self-develop certified health IT would continue to be
excluded from this definition if they supply their self-developed
certified health IT to others under arrangements excluded from the
definition of what it means to offer health IT. This would treat self-
developer health care providers who supply use of their self-developed
certified health IT to others under arrangements, or in the course of
activities, excluded from the proposed offer health IT definition in
the same way that we treat health care providers who supply commercial
developers' certified health IT under arrangements, or in the course of
activities, excluded from the offer health IT definition.
We propose in section IV.A to revise the text of Sec. 171.103, the
information blocking definition, to remove paragraph (b) (see Sec.
171.103(b)). Paragraph (b) established the period of time during which
electronic health information (EHI) for purposes of the information
blocking definition (Sec. 171.103) was limited to a subset of
electronic health information (EHI) that was identified by the data
elements represented in the USCDI standard adopted in 171.213. The end
date of that period of time, October 5, 2022, has passed. 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
and thus paragraph (b) of Sec. 171.103 is no longer needed.
We note that we do not propose to change the scope of EHI for
purposes of the information blocking definition, only to update the CFR
text to remove the paragraph specific to the period of time now passed.
Similarly, because we included the same time period in reference to the
scope of electronic health information in two paragraphs of the Content
and Manner exception (Sec. 171.301(a)(1) and (2)), we propose to
revise Sec. 171.301 to remove from the regulatory text the existing
Sec. 171.301(a)(1) and (2) as no longer necessary.
We propose in section IV.B to revise the Infeasibility Exception
codified in 45 CFR 171.204(a) by adding two new conditions and by
revising one existing condition to further clarify when an actor's
practice of not fulfilling a request for access, exchange, or use of
EHI meets the condition. First, we propose to revise the
``uncontrollable events'' condition in Sec. 171.204(a)(1) to further
[[Page 23755]]
clarify when an actor's practice meets the uncontrollable events
condition. Second, we propose to add two new conditions to be codified
as subparagraphs (a)(3) and (a)(4), and to therefore renumber the
``infeasible under the circumstances'' condition currently codified in
Sec. 171.204(a)(3) as (a)(5).
The first new infeasibility condition would 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 its business associate. The
second new infeasibility condition would apply where an actor has
exhausted the manner exception in Sec. 171.301, including offering all
alternative manners in accordance with Sec. 171.301(b), and the actor
does not currently provide a substantial number of individuals or
entities similarly situated to the requestor with the same requested
access, exchange, or use of the requested EHI.
We also seek comment on ways health IT can support EHI segmentation
for access, exchange, and use of EHI; and particularly how the Program,
through the certification of health IT to certain functionalities and/
or standards, can support EHI segmentation for access, exchange, and
use, including to assist health care providers with sharing EHI
consistent with patient preferences and all laws applicable to the
creation, use, and sharing of EHI.
Additionally, in section IV.B, we propose to add a Trusted Exchange
Framework and Common Agreement (TEFCA) condition to the proposed
revised and renamed Manner Exception, proposed to be codified in 45 CFR
171.301. This proposal aligns with a foundational policy construct
underpinning the Manner Exception in that it facilitates an actor
reaching agreeable terms with a requestor to fulfill an EHI request and
acknowledges that certain agreements have been reached between these
parties for the access, exchange, and use of EHI.
C. Costs and Benefits
E.O. 12866 on Regulatory Planning and Review and E.O.13563 on
Improving Regulation and Regulatory Review 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). 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 $100 million or more in any 1
year, or adversely and materially affecting a sector of the economy,
productivity, competition, jobs, the environment, public health or
safety, or State, local 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 novel legal
or policy issues arising out of legal mandates, the President's
priorities, or the principles set forth in the Executive Order. A
regulatory impact analysis (RIA) must be prepared for major rules with
significant effects as per section 3(f)(1)) ($100 million or more in
any one year). OMB has determined that this proposed rule is a
significant rule as the potential costs associated with this proposed
rule could be greater than $100 million per year. Accordingly, we have
prepared an RIA that to the best of our ability presents the costs and
benefits of this proposed rule. We have estimated the potential
monetary costs and benefits of this proposed 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 35.
We note that we have rounded all estimates to the nearest dollar
and that all estimates are expressed in 2021 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 2021 National Occupational Employment and Wage Estimates reported
by the U.S. Bureau of Labor Statistics.\17\ We also note that estimates
presented in the following ``Employee Assumptions and Hourly Wage,''
``Quantifying the Estimated Number of Health IT Developers and
Products,'' and ``Number of End Users that Might Be Impacted by ONC's
Proposed Regulations'' sections are used throughout this RIA.
---------------------------------------------------------------------------
\17\ 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 proposed rule for
the first year after it is finalized (including one-time costs), based
on the cost estimates outlined above and throughout this RIA, would
result in $742 million. The total undiscounted perpetual cost over a
10-year period for this proposed rule (starting in year three), based
on the cost estimates outlined above, would result in $712 million. We
estimate the total costs to health IT developers to be $742 million and
estimate the government (ONC) costs to be between $62,000 to $124,000.
We estimate the total annual benefit for this proposed rule, based
on the benefit estimates outlined above, would be on average $1.0
billion. We estimate the total undiscounted perpetual annual net
benefit for this proposed rule (starting in year three), based on the
estimates outlined above, would be $326 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 PDP sponsors of prescription drug plans 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
[[Page 23756]]
requirements for an RTBT is that it is capable of integrating 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 ONC Health IT Certification Program (Program). Specifically, the
law amends the definition of a ``qualified electronic health record''
(qualified EHR) in section 3000(13) of the PHSA to require that a
qualified EHR must include (or be capable of including) an RTBT.
1. Standards, Implementation Specifications, and Certification Criteria
The HITECH Act established two Federal advisory committees, the
Health IT Policy Committee (HITPC) and the Health IT Standards
Committee (HITSC). Each was responsible for advising the National
Coordinator for Health Information Technology (National Coordinator) on
different aspects of standards, implementation specifications, and
certification criteria.
Section 4003(e) of the Cures Act amended sections 3002 and 3003 of
the PHSA by replacing, in an amended section 3002, the HITPC and HITSC
with one committee named the Health Information Technology Advisory
Committee (Health IT Advisory Committee or HITAC). Section 3002(a) of
the PHSA, as added by the Cures Act, establishes that the HITAC
recommends to the National Coordinator policies and standards,
implementation specifications, and certification criteria, relating to
the implementation of a health information technology infrastructure,
nationally and locally, that advances the electronic access, exchange,
and use of health information. Further described in section 3002(b)(1)
of the PHSA, this includes recommending to the National Coordinator a
policy framework to advance interoperable health information technology
infrastructure, updating recommendations to the policy framework, and
making new recommendations, as appropriate. Section 3002(b)(2)(A) of
the PHSA specifies that in general, the HITAC shall recommend to the
National Coordinator for purposes of adoption under section 3004,
standards, implementation specifications, and certification criteria
and an order of priority for the development, harmonization, and
recognition of such standards, specifications, and certification
criteria. Like the process previously required of the former HITPC and
HITSC, section 3002(b)(5) of the PHSA requires the HITAC to develop a
schedule, updated annually, for the assessment of policy
recommendations, which the Secretary publishes in the Federal Register.
Section 3004 of the PHSA establishes a process for the adoption of
health IT standards, implementation specifications, and certification
criteria and authorizes the Secretary to adopt such standards,
implementation specifications, and certification criteria. As specified
in section 3004(a)(1), the Secretary is required, in consultation with
representatives of other relevant federal agencies, to jointly review
standards, implementation specifications, and certification criteria
endorsed by the National Coordinator under section 3001(c) and
subsequently determine whether to propose the adoption of such
standards, implementation specifications, or certification criteria.
Section 3004(a)(3) requires the Secretary to publish all such
determinations in the Federal Register.
Section 3004(b)(3) of the PHSA, titled, Subsequent Standards
Activity, provides that the Secretary shall adopt additional standards,
implementation specifications, and certification criteria as necessary
and consistent with the schedule published by the HITAC. We consider
this provision in the broader context of the HITECH Act and Cures Act
to grant the Secretary the authority and discretion to adopt standards,
implementation specifications, and certification criteria that have
been recommended by the HITAC and endorsed by the National Coordinator,
as well as other appropriate and necessary health IT standards,
implementation specifications, and certification criteria.
2. Health IT Certification Program(s)
Section 3001(c)(5) of the PHSA provides the National Coordinator
with the authority to establish a certification program or programs for
the voluntary certification of health IT. Section 3001(c)(5)(A)
specifies that the National Coordinator, in consultation with the
Director of the National Institute of Standards and Technology (NIST),
shall keep or recognize a program or programs for the voluntary
certification of health IT that is in compliance with applicable
certification criteria adopted under section 3004 of the PHSA. The
certification program(s) must also include, as appropriate, testing of
the technology in accordance with section 13201(b) of the HITECH Act.
Section 13201(b) of the HITECH Act requires that, with respect to the
development of standards and implementation specifications, the
Director of NIST shall support the establishment of a conformance
testing infrastructure, including the development of technical test
beds. Section 13201(b) also indicates that the development of this
conformance testing infrastructure may include a program to accredit
independent, non-federal laboratories to perform testing.
Section 4003(b) of the Cures Act added section 3001(c)(9)(B)(i) to
the PHSA, which requires the National Coordinator ``to convene
appropriate public and private stakeholders'' with the goal of
developing or supporting a Trusted Exchange Framework and a Common
Agreement (collectively, TEFCA) 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; application programing
interfaces (APIs); real world testing; attestations regarding certain
conditions and maintenance of certification requirements; and
submission of reporting criteria under the EHR Reporting Program in
accordance with section 3009A(b) of the PHSA.
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
[[Page 23757]]
Health Record Technology'' (75 FR 2014), which adopted an initial set
of standards, implementation specifications, and certification
criteria. On March 10, 2010, the Secretary issued a proposed rule,
``Proposed Establishment of Certification Programs for Health
Information Technology'' (75 FR 11328), that proposed both temporary
and permanent certification programs for the purposes of testing and
certifying health IT. A final rule establishing the temporary
certification program was published on June 24, 2010, ``Establishment
of the Temporary Certification Program for Health Information
Technology'' (75 FR 36158), and a final rule establishing the permanent
certification program was published on January 7, 2011, ``Establishment
of the Permanent Certification Program for Health Information
Technology'' (76 FR 1262).
We have engaged in multiple rulemakings to update standards,
implementation specifications, certification criteria, and the
certification program, a history of which can be found in the October
16, 2015, final rule ``2015 Edition Health Information (Health IT)
Certification Criteria, 2015 Edition Base Electronic Health Record
(EHR) Definition, and ONC Health IT Certification Program
Modifications'' (80 FR 62602) (2015 Edition Final Rule). The history
can be found at 80 FR 62606. A 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 referred to as the Promoting
Interoperability (PI) Programs) when the 2015 Edition is required for
use under these and other programs referencing the CEHRT definition.
The final rule also adopted a proposal to change the Program's name to
the ``ONC Health IT Certification Program'' from the ONC HIT
Certification Program, modified the 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 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 final rule also set forth processes for us to
authorize and oversee accredited testing laboratories under the
Program. In addition, it included provisions for expanded public
availability of certified health IT surveillance results.
On March 4, 2019, the Secretary published a proposed rule titled,
``21st Century Cures Act: Interoperability, Information Blocking, and
the ONC Health IT Certification Program'' (84 FR 7424) (ONC Cures Act
Proposed Rule). The 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).
This 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 final rule also implemented certain parts of the Cures
Act to support patients' access to their EHI, and the implementation of
information blocking policies that support patient electronic access.
Additionally, the final rule modified the 2015 Edition health IT
certification criteria and Program in other ways to advance
interoperability, enhance health IT certification, and reduce burden
and costs, as well as improving patient and health care provider access
to EHI and promoting competition. On November 4, 2020, the Secretary
published an interim final rule with comment period titled,
``Information Blocking and the ONC Health IT Certification Program:
Extension of Compliance Dates and Timeframes in Response to the COVID-
19 Public Health Emergency'' (85 FR 70064) (Cures Act Interim Final
Rule). The interim final rule extended certain compliance dates and
timeframes adopted in the ONC Cures Act Final Rule to offer the
healthcare system additional flexibilities in furnishing services to
combat the COVID-19 pandemic, including extending the applicability
date for information blocking provisions to April 5, 2021.
On 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.
III. ONC Health IT Certification Program Updates
A. ``The ONC Certification Criteria for Health IT '' and Discontinuing
Year Themed ``Editions''
ONC first introduced the concept of an ``edition'' of ONC health IT
certification criteria in 2012. In March 2012, in the 2014 Edition
Proposed
[[Page 23758]]
Rule,\18\ to make a clear distinction between the certification
criteria finalized in the 2010 ONC ``Health Information Technology:
Initial Set of Standards, Implementation Specifications, and
Certification Criteria for Electronic Health Record Technology''
interim final rule (75 FR 20132047) and adopted in Sec. Sec. 170.302,
170.304, and 170.306 (to support ``Stage 1 meaningful use criteria'')
and the certification criteria proposed for adoption in Sec. 170.314
(to support ``Stage 2 meaningful use criteria'') (77 FR 13832), we
discussed that we would use an ``edition'' naming approach for the sets
of certification criteria subsequently adopted by the Secretary (77 FR
13836). We stated that we would refer to the certification criteria
adopted in Sec. Sec. 170.302, 170.304, and 170.306 collectively as the
``2011 Edition EHR certification criteria'' and that the certification
criteria adopted in Sec. 170.314 would be referred to as the ``2014
Edition EHR certification criteria'' (77 FR 13836). We finalized this
approach and adopted a ``2014 Edition'' in a September 2012 final rule
(77 FR 54163) (the 2014 Edition Final Rule). Overall, we created the
concept of certification criteria ``editions'' with the expectation
that it would make it easier for developers of certified health IT and
health care providers to quickly determine the certification criteria
to which their health IT would need to be certified to remain in
compliance with CMS program requirements regarding the use of certified
EHR technology (CEHRT) (77 FR 54167).
---------------------------------------------------------------------------
\18\ Health Information Technology: Standards, Implementation
Specifications, and Certification Criteria for Electronic Health
Record Technology, 2014 Edition; Revisions to the Permanent
Certification Program for Health Information Technology (77 FR
13832).
---------------------------------------------------------------------------
We coined the ``2011 Edition'' and ``2014 Edition'' because the
edition's name was designed to coincide with the first year in which
compliance with that edition of certification criteria was required for
use under the Medicare and Medicaid EHR Incentive Programs (79 FR
54431). We thought this approach would simplify communications related
to the certification criteria editions and enable clear compliance
statements like ``an EP needs to be using 2014 Edition CEHRT when they
demonstrate meaningful use . . . in CY 2014'' (79 FR 54431). This
approach resulted for many people in a direct, and limited in scope,
link between certification criteria editions and ``meaningful use''
even though these certification criteria were already being referenced
by other HHS programs (e.g., the CMS and HHS Office of the Inspector
General (OIG) final rules to modify the Physician Self-Referral Law
exception and Anti-kickback Statute safe harbor for certain EHR
donations (78 FR 78751) and (78 FR 79202), respectively).\19\
---------------------------------------------------------------------------
\19\ The CMS final rule is titled ``Medicare Program;
Physicians' Referrals to Health Care Entities with Which They Have
Financial Relationships: Exception for Certain Electronic Health
Records Arrangements'' (78 FR 78751). The OIG final rule is titled
``Medicare and State Health Care Programs: Fraud and Abuse;
Electronic Health Records Safe Harbor Under the Anti-Kickback
Statute'' (78 FR 79201).
---------------------------------------------------------------------------
In September 2014, we issued a final rule to update the 2014
Edition with ``2014 Edition Release 2'' certification criteria and to
remove the 2011 Edition from the Code of Federal Regulations (CFR)
starting in 2015 (79 FR 54430). At that time, EHR technology certified
to the 2011 Edition had become outmoded, no longer met the CEHRT
definition, and no longer supported an acceptable level of
interoperability (79 FR 54447). Further, as referenced by OIG and CMS
in the rulemakings completed by those agencies around donations of EHR
items and services, we had planned to retire old or no longer
applicable certification criteria editions ((78 FR 79205) and (78 FR
78754), respectively). During this same time period, we jointly issued
with CMS a final rule (79 FR 52910) that allowed for continued use of
2011 Edition CEHRT in combination with 2014 Edition CEHRT within 2014,
which allowed for certain providers to meet meaningful use requirements
with EHRs certified to the 2011 or the 2014 Edition criteria, or a
combination of both editions, for an EHR Reporting Period in 2014.\20\
The rule also extended Stage 2 through 2016, meaning that providers who
first attested to meaningful use in 2011 or 2012 would remain in Stage
2 for an additional year (79 FR 52926). These actions further
demonstrated that linking a certification criteria edition's year to
any other program's compliance date had drawbacks and could ultimately
confuse the original intent of the edition's year selection. This
experience also highlighted unintended negative impacts stemming from
this approach of packaging all ONC certification criteria into discrete
editions, even where those editions might have overlapping criteria.
Specifically, the editions approach had two major negative impacts
relating to how updates were implemented: (1) it required all
developers and providers to update their systems by a specific date,
and (2) it required all developers and providers to update their
systems to all edition criteria even where criteria may overlap or only
have minor revisions between editions.
---------------------------------------------------------------------------
\20\ The CMS final rule is titled ``Medicare and Medicaid
Programs; Modifications to the Medicare and Medicaid Electronic
Health Record (EHR) Incentive Program for 2014 and Other Changes to
the EHR Incentive Program; and Health Information Technology:
Revisions to the Certified EHR Technology Definition and EHR
Certification Changes Related to Standards'' (79 FR 52909).
---------------------------------------------------------------------------
Accordingly, we set out to establish a simpler approach that could
be used for future certification criteria editions. First, we
intentionally adopted an overlapping transition period from any one
edition to a subsequent edition (e.g., the 2014 Edition to the
subsequent edition). Second, we modified our approach to name the
edition for the year in which the final rule was published, and
subsequent rulemakings that include additional criteria or alternatives
to previously adopted certification criteria would be added to the most
current edition of certification criteria (79 FR 54431). To further
clarify, we stated that a rulemaking that does not adopt an edition of
certification criteria would be referred to as ``[current edition year]
Release #X'' (79 FR 54431). We intended this approach to provide the
public with predictable naming expectations for future editions and to
support ONC's broader interests to have the Program be generally
accessible to other programs designed to use certified health IT,
either within or outside government. Developers of certified health IT
and health care providers that sought to leverage the Program would
then be able to choose which edition of certification criteria (or
subset of criteria within an edition) was most relevant and appropriate
for their program needs for the time their program requirements would
be applicable (79 FR 54431).
Following this approach, in 2015, ONC issued a 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,'' (2015 Edition
Final Rule) and adopted the ``2015 Edition Health IT Certification
Criteria'' (80 FR 62602). We codified the 2015 Edition certification
criteria in Sec. 170.315 to set them apart from other editions of
certification criteria (80 FR 62608). Importantly, the program
compliance requirements for certain health care providers to use 2015
Edition certified health IT was ultimately set by CMS to start in 2019
(83 FR 41144).\21\
---------------------------------------------------------------------------
\21\ The CMS final rule is titled ``Medicare Program; Hospital
Inpatient Prospective Payment Systems for Acute Care Hospitals and
the Long-Term Care Hospital Prospective Payment System and Policy
Changes and Fiscal Year 2019 Rates; Quality Reporting Requirements
for Specific Providers; Medicare and Medicaid Electronic Health
Record (EHR) Incentive Programs (Promoting Interoperability
Programs) Requirements for Eligible Hospitals, Critical Access
Hospitals, and Eligible Professionals; Medicare Cost Reporting
Requirements; and Physician Certification and Recertification of
Claims'' (83 FR 41144).
---------------------------------------------------------------------------
[[Page 23759]]
Four years later, as part of implementation of the 21st Century
Cures Act, we issued the 21st Century Cures Act: Interoperability,
Information Blocking, and the ONC Health IT Certification Program
Proposed Rule (84 FR 7424) to update to the 2015 Edition, mindful that
2015 Edition certified health IT was just being implemented. In 2020,
we published the ONC Cures Act Final Rule (85 FR 25642) and adopted
updates to the 2015 Edition. These updates included new certification
criteria, standards, and requirements, as well as incremental revisions
to existing 2015 Edition certification criteria to better enable
interoperability and the access, exchange, and use of EHI (85 FR 25664-
65). Because we did not adopt a new edition of certification criteria
in a different CFR section, we retained the overall 2015 Edition title
for the changes included in the ONC Cures Act Final Rule and made
specific timebound compliance changes within certification criteria.
In the final rule, we stated that we considered a variety of
factors when we determined to update the 2015 Edition rather than adopt
a new ``edition.'' First, we reviewed the scope of each proposed update
and the cumulative scope of the proposals overall for health IT
developers and sought to identify whether it would be more appropriate
to require health IT developers participating in the Program to
implement updates to Health IT Modules certified to the 2015 Edition or
to test and certify health IT products to an entirely new edition of
certification criteria. Second, we considered the impact that either
approach would have on health care providers, including how such
updated Health IT Modules or products certified to a new edition would
be implemented by providers participating in CMS programs. We also
noted that historically, with a new edition of certification criteria,
health IT developers have packaged Health IT Modules certified to new,
revised, and unchanged criteria into a wholly new certified product. We
observed that historical data indicated that these complete updates to
the edition were particularly challenging for both health IT developers
seeking certification and for health care providers as they establish
deadlines for a significant number of health IT developers to support
and implement new products for a significant number of health care
providers simultaneously. As a result, the burden of updating the
technology is compounded for both health IT developers and health care
providers (85 FR 25665).
Our intent with this approach was 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 the ONC Cures Act Final
Rule, we stated our belief that this approach should also include
development timelines based on the updates required for each criterion
and a transition period allowing for multiple standards to be used for
a reasonable period of time. We noted our belief that, as a whole, 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 their
customers (85 FR 25665). Commenters noted this approach would provide
stability and that an incremental approach best serves the health care
provider and health IT developer community (85 FR 25664).
However, in response to public comment related to how we
communicate and avoid public confusion (85 FR 25666), we distinguished
the ``original'' 2015 Edition certification criteria from the new and
revised 2015 Edition certification criteria by referring to the updates
we adopted as the 2015 Edition ``Cures Update'' certification criteria.
Subsequent to publication of the final rule, through public meetings
and correspondence, we have been informed that the continued use and
reference to the 2015 Edition inaccurately implied an age and
outdatedness to the certification criteria we had adopted. More
importantly, 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 the specific development needs.
For these reasons, we no longer believe that it is helpful or
necessary to maintain an ``edition'' naming convention and to adopt
entirely new editions of certification criteria to encapsulate updates
over time. Instead, 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. We therefore propose to rename 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'' 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. 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 on
developers, as they had the effect of requiring health IT 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 proposal,
unchanged certification criteria would no longer be duplicated as
separate criteria under multiple editions. Accordingly, we propose 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 proposed
revised regulation text, below). We welcome public comment on this
proposal.
In the 2014 Edition Final Rule we defined the terms ``new,''
``revised,'' and ``unchanged'' to both describe the differences between
the 2014 Edition certification criteria and the 2011 Edition
certification criteria, as well as establish what certification
criteria in the 2014 Edition were eligible for gap certification \22\
(see 77 FR 54171, 54202,
[[Page 23760]]
and 54248). Beginning with the 2015 Edition, ``Complete EHR''
certifications were no longer issued (see also 79 FR 54443 through
54445) and, as part of our effort to make the Program more open and
accessible to other healthcare and practice settings, we also defined
these terms for the purpose of a gap certification analysis as follows:
---------------------------------------------------------------------------
\22\ Gap certification means the certification of a previously
certified Health IT Module(s) to:
(1) All applicable new and/or revised certification criteria
adopted by the Secretary at subpart C of this part based on test
results issued by a NVLAP-accredited testing laboratory under the
ONC Health IT Certification Program or an ONC-ATL; and
(2) All other applicable certification criteria adopted by the
Secretary at subpart C of this part based on the test results used
to previously certify the Complete EHR or Health IT Module(s) under
the ONC Health IT Certification Program (Sec. 170.502).
---------------------------------------------------------------------------
<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 of the included capabilities (80 FR 62608).
We propose that these same concepts 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 now propose 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 functions or 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.
By way of example, proposed provisions (1) and (2) were met in
Sec. 170.315(b)(3) in the ONC Cures Act Final Rule (85 FR 25683)
because we modified this criterion to include new functions or
capabilities in Sec. 170.315(b)(3)(ii)(A)(7) through (9) that did not
exist in Sec. 170.315(b)(3). Also, in Sec. 170.315(b)(3), in the ONC
Cures Act Final Rule we added cross-references to the NCPDP SCRIPT
standard version 2017071 in Sec. 170.315(b)(3)(ii)(A) and
(b)(3)(ii)(B), which did not exist in Sec. 170.315(b)(3). An example
of proposed provision (3) can be found in the ONC Cures Act Final Rule
in Sec. 170.315(b)(6) ``Data export'' being replaced by Sec.
170.315(b)(10) ``Electronic Health Information export'' (85 FR 25699).
If finalized as proposed there would not be an ``edition'' to
differentiate between such revisions to existing criteria; instead,
such criteria would be considered ``revised'' until a subsequent
rulemaking where no further revision to the criterion renders them
``unchanged.''
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 when setting expiration dates or applicable
timelines related to standards and certification criteria. Through the
development of educational resources, such as fact sheets \23\ and
resource guides,\24\ 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 this
proposed rule, we propose 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 is no longer applicable and by establishing a date by when a
new or revised certification criterion or standard version is adopted.
For example, if finalized as proposed, a user and the public would know
that a Health IT Module certified to ``revised'' Sec. 170.315(b)(1)
would support USCDI v3 (Sec. 170.213(b)) after January 1, 2025,
because we state that USCDI v1 expires on January 1, 2025, in Sec.
170.213(a).
---------------------------------------------------------------------------
\23\ 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>.
\24\ See API Resource Guide: <a href="https://onc-healthit.github.io/api-resource-guide/">https://onc-healthit.github.io/api-resource-guide/</a>.
---------------------------------------------------------------------------
We propose the following revised standards and implementation
specifications: Sec. 170.205(a); Sec. Sec. 170.207(a), (c), (d), (e),
(f), (m), (n), (o), (p), (r), and (s); Sec. 170.210(g); Sec. 170.213;
Sec. 170.215(b), and Sec. 170.215(c). We propose new standards and
implementation specifications in Sec. 170.205(t) and Sec. 170.205(o).
Table 1 below includes the proposed new and revised certification
criteria described in this rule.
Table 1--List of Proposed Health IT Certification Criteria
------------------------------------------------------------------------
------------------------------------------------------------------------
New Certification Criterion
------------------------------------------------------------------------
Sec. 170.315(d)(14)........ Privacy and security--Patient Requested
Restrictions.
------------------------------------------------------------------------
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)
(to be recategorized as ``Care
Coordination Sec. 170.315(b)(11)'').
Sec. 170.315(b)(1)......... Care Coordination--Transitions of care.
Sec. 170.315(b)(2)......... Care Coordination--Clinical information
reconciliation and incorporation.
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)(6)......... Care Coordination--Data export.
[[Page 23761]]
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.
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.
------------------------------------------------------------------------
When we published the 2015 Edition Final Rule, ONC released
educational resources to inform the public. Educational and
communication resources included charts on the 2015 Edition
certification criteria, reader-friendly fact sheets on specific topics
like addressing health disparities and patient engagement, the
Companion Certification Guides, and a new ``2015 Edition Standards
Hub'' to help interested parties quickly crosswalk and identify
standards referenced by 2015 Edition certification criteria. While our
proposal may have the near-term effect of requiring ONC to revise
existing communications materials, as well as conforming regulatory
updates and updates to materials by other agencies such as CMS that
reference the 2015 Edition, we believe the overall benefit of having a
single ONC branded set of certification criteria outweighs the burdens
that result administratively, as well as for developers of certified
health IT and their customers, from rolling out a new ``edition.''
Moreover, starting with the ONC Cures Act Final Rule, we developed a
new approach for conformance requirement changes within certification
criteria that, when applied in conjunction with this proposed approach,
can also reduce administrative and regulatory burden and help to ensure
the updates to criteria are clearly defined to support both a
transition period and a predictable development timeline aligned to the
scope of the specific update. In the ONC Cures Act Final Rule, we did
not create a new CFR section as we had done previously but instead
updated the existing CFR section, Sec. 170.315. The new approach was
designed to make it clear for health IT developers, as well as ONC-
Authorized Testing Labs (ONC-ATLs) and ONC-ACBs, how long certain
capabilities and standards remain available for the purposes of
certification. We also implemented new Maintenance of Certification
requirements as a result of the Cures Act to give health IT developers
specific deadlines relative to complying with updated technical
requirements, while still allowing developers to continue supporting
technology certified to the prior version of certification criteria or
standards for use by their customers.
Building upon this approach, in this proposed rule, we also propose
modifications to our approach for setting applicability or
implementation timelines for both our certification criteria and the
standards adopted in 45 CFR part 170. This approach includes
establishing the dates by which an existing version of a certification
criterion is no longer applicable because a new or revised version of
that criterion is adopted. In addition, we have proposed to establish
applicable timelines, including expiration dates, for the adoption of
standards when a new or revised version of the standard is adopted for
the same purpose. This proposed approach would support the ongoing
establishment of clear timelines associated with the specific criterion
or standard in alignment with the development and update cycle for that
specific criterion or standard--again supporting an incremental and
flexible approach.
In addition, we believe this approach would facilitate ease of
reference for federal, state, local or tribal programs seeking to align
their program requirements to the standards and implementation
specifications available in certified health IT. These programs may not
require use of the entirety of the Base EHR, or they may not even
require the use of certified health IT, but they may still seek to
align to a specific certification criterion or a specific standard
where applicable to their program goals and consistent with their
applicable authorities. Furthermore, as we move away from the use of
editions to define updated timelines, we believe it is important to
continue to provide clarity on existing Program requirements and to
ensure that customers are provided with timely technology updates. We
therefore propose to incorporate the applicable timelines and
expiration dates for functional and standards updates within each
individual criterion or standard. In section III.C.11 of this proposed
rule, we propose to make explicit in the introductory text in Sec.
170.315 that health IT developers voluntarily participating in the
Program must update their certified Health IT Modules and provide that
updated certified health IT to customers in accordance with the
timelines defined for each criterion and standard if they intend to
maintain certification of the Health IT Module. (For ease of reference
and reading, we use ``developer of certified health IT'' in this
proposed rule to reference developers who voluntarily participate in
the Program). We believe this approach will also help to advance
interoperability. Under this proposal, a developer of certified health
IT would not be required to provide technology updates for
certification criteria or standards to a user who declined such
updates. However, we note that if such an update is not provided, and
the Health IT Module was previously certified to a criterion or
criteria that now make it subject to a ``revised'' criterion or
criteria, the Health IT Module would no longer be certified under the
Program, in the same manner that previously removed or expired
``editions'' are no longer certified under the Program.
We direct readers to section III.C.11 of this proposed rule for
further discussion of the requirements for health IT developers
voluntarily participating in the Program related to health IT
certification updates.
In the ONC Cures Act Final Rule, we revised the Principles of
Proper Conduct for ONC-ACBs and ONC-ATLs by revising 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
[[Page 23762]]
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). Because in this proposed rule we
propose to maintain a single set of ``ONC Certification Criteria for
Health IT'' and not an edition, we propose to revise Sec. 170.523 and
Sec. 170.524. We propose 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 retain 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.
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 \25\ require the use of, wherever practical,
technical standards that are developed or adopted by voluntary
consensus standards bodies to carry out policy objectives or
activities, with certain exceptions. The NTTAA and OMB Circular A-119
provide exceptions to electing only standards developed or adopted by
voluntary consensus bodies, namely when doing so would be inconsistent
with applicable law or otherwise impractical. Agencies have the
discretion to decline the use of existing voluntary consensus standards
if it is determined that such standards are inconsistent with
applicable law or otherwise impractical, and instead use a government-
unique standard or other standard. In addition to the consideration of
voluntary consensus standards, the OMB Circular A-119 recognizes the
contributions of standardization activities that take place outside of
the voluntary consensus standards process. Therefore, in instances
where use of voluntary consensus standards would be inconsistent with
applicable law or otherwise impracticable, other standards should be
considered that meet the agency's regulatory, procurement or program
needs, deliver favorable technical and economic outcomes, and are
widely utilized in the marketplace. In this proposed rule, we use
voluntary consensus standards except for:
---------------------------------------------------------------------------
\25\ <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>.
---------------------------------------------------------------------------
<bullet> The United States Core Data for Interoperability (USCDI),
October 2022 Errata, Version 3 (v3) standard. We propose to adopt USCDI
v3 (October 2022 Errata) in Sec. 170.213. This standard 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 we propose to adopt 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 proposed rule including establishing a baseline set of
data that can be commonly 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.
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/or implementation
specifications in any subsequent final rule, the entire standard or
implementation specification document is deemed published in the
Federal Register when incorporated by reference therein with the
approval of the Director of the Federal Register. Once published,
compliance with the standard and implementation specification includes
the entire document unless we specify otherwise. For example, if we
adopted the HL7[supreg] FHIR US Core Implementation Guide 5.0.1
proposed in this proposed rule (see section III.C.7.b), health IT
certified to certification criteria referencing this IG would need to
demonstrate compliance with all mandatory elements and requirements of
the IG. If an element of the IG is optional or permissive in any way,
it would remain that way for testing and certification unless we
specified otherwise in regulation. In such cases, the regulatory text
would 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(a)). 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 propose to adopt
and subsequently incorporate by reference in the Code of Federal
Regulations. To note, we also provide relevant information about these
standards and implementation specifications throughout the relevant
sections of the proposed rule.
C. New and Revised Standards and Certification Criteria
1. The United States Core Data for Interoperability Standard (USCDI) v3
a. Background
The United States Core Data for Interoperability (USCDI) is a
standardized set of health data classes and constituent data elements
for nationwide, interoperable health information exchange.\26\ In the
ONC Cures Act Final Rule, ONC established USCDI as a standard to
replace the Common Clinical Data Set (CCDS) in several ONC
certification criteria (85 FR 25670). ONC adopted USCDI Version 1
(USCDI v1) in Sec. 170.213 and incorporated it by reference in Sec.
170.299.\27\ In an interim final rule with comment period published by
ONC on November 4, 2020, ``Information Blocking and the ONC Health IT
Certification Program: Extension of Compliance Dates and Timeframes in
Response to the COVID-19 Public Health Emergency,'' ONC adopted and
incorporated by reference the updated standard USCDI v1 (July 2020
Errata) (85 FR 70073).
---------------------------------------------------------------------------
\26\ <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>.
\27\ <a href="https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170#p-170.213">https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170#p-170.213</a>.
---------------------------------------------------------------------------
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 certain certification criteria in the 2015 Edition
Cures Update. These certification criteria include transitions of care;
clinical information reconciliation and incorporation; view, download,
and
[[Page 23763]]
transmit to 3rd party; transmission to public health agencies--
electronic case reporting; consolidated CDA creation performance;
application access--all data request, and standardized API for patient
and population services (adopted in Sec. 170.315(b)(1), (b)(2),
(e)(1), (f)(5), (g)(6), (g)(9), and (g)(10) respectively). USCDI is
also referenced by HHS programs and the healthcare community to align
interoperability requirements and national priorities for health IT and
healthcare standards broadly across industry initiatives. Additionally,
at a minimum, entities that sign the Common Agreement are required to
exchange all available data elements from USCDI v1.\28\ USCDI is
composed of data classes which aggregate data elements by common
themes. Data elements are the granular level at which a piece of data
is defined for exchange within the USCDI standard. For example,
``Laboratory'' is a data class, and within that data class there is
``Values/Results'' which is a data element. 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\ Trusted Exchange Framework and Common Agreement Qualified
Health Information Network (QHIN) Technical Framework (QTF). Version
1.0. January 2022. <a href="https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf">https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf</a>.
---------------------------------------------------------------------------
ONC 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 health IT
developers would be able to use the Standards Version Advancement
Process (SVAP) to voluntarily implement and use a newer, National
Coordinator-approved version of USCDI in the future without waiting for
ONC to propose and adopt via rulemaking an updated version of the USCDI
(85 FR 25669). ONC, therefore, established a process for expanding
USCDI based on public input and submissions of new data elements and
classes.\29\ To enable these submissions, ONC created the ONC New Data
Element and Class (ONDEC) submission system, which provides the public
with the opportunity to submit new data elements for consideration for
inclusion in future versions of USCDI.\30\ ONC accepts submissions for
new USCDI data elements in ONDEC on an ongoing basis, with a September
cutoff each year for submissions to be considered for the next version
of USCDI. ONC evaluates these submissions and assigns ``levels'' based
on technical maturity, implementation feasibility, overall breadth of
impact on potential users, and any known challenges to use of these
data. Level 2 elements are those ONC deems the most mature and ready
for consideration for future versions, followed by Level 1 elements as
less mature, and Comment Level elements as the least mature. After the
submission cutoff, ONC selects from Level 2 elements. ONC then
publishes a draft of the next version of USCDI and accepts public
feedback on the draft.\31\ This feedback informs the version of USCDI
released in July each year. In this way, the standard can continue to
evolve in an incremental and predictable manner, even though ONC might
not propose to adopt each new version in the Code of Federal
Regulations.
---------------------------------------------------------------------------
\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>.
\31\ <a href="https://www.healthit.gov/buzz-blog/interoperability/opportunity-trifecta-isa-svap-and-draft-uscdi-version-3-feedback-period-now-open">https://www.healthit.gov/buzz-blog/interoperability/opportunity-trifecta-isa-svap-and-draft-uscdi-version-3-feedback-period-now-open</a>.
---------------------------------------------------------------------------
ONC has received several hundred submissions through ONDEC
recommending new and updated data classes and data elements during each
annual update cycle. In July 2021, ONC published USCDI Version 2 (USCDI
v2),\32\ and this version was later added to the SVAP Approved
Standards for 2022.\33\ SVAP allows health IT developers to voluntarily
update their products to USCDI v2 without waiting for rulemaking to
update the version of USCDI listed in the regulations (85 FR 25669). At
the time of release of USCDI v2, ONC also announced additional criteria
on which new and existing submissions would be evaluated and selected
for USCDI v3 and future versions. These criteria included the ability
of the data elements to promote health equity, address the needs of
underserved communities, and enable public health data
interoperability.\34\ In January 2022, ONC released Draft USCDI v3 and
provided for a three-month public feedback period.\35\ After reviewing
and incorporating public feedback, ONC finalized and released USCDI v3
in July 2022.
---------------------------------------------------------------------------
\32\ <a href="https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v2">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v2</a>.
\33\ <a href="https://www.healthit.gov/sites/default/files/page/2022-06/SVAP_Approved_Standards_2022.pdf">https://www.healthit.gov/sites/default/files/page/2022-06/SVAP_Approved_Standards_2022.pdf</a>.
\34\ <a href="https://www.healthit.gov/buzz-blog/interoperability/opportunity-trifecta-isa-svap-and-draft-uscdi-version-3-feedback-period-now-open">https://www.healthit.gov/buzz-blog/interoperability/opportunity-trifecta-isa-svap-and-draft-uscdi-version-3-feedback-period-now-open</a>.
\35\ <a href="https://www.healthit.gov/sites/default/files/page/2022-01/Standards_Bulletin_2022-1.pdf">https://www.healthit.gov/sites/default/files/page/2022-01/Standards_Bulletin_2022-1.pdf</a>.
---------------------------------------------------------------------------
We propose to update the USCDI standard in Sec. 170.213 by adding
the newly released USCDI v3 and by establishing a January 1, 2025,
expiration date for USCDI v1 (July 2020 Errata) for purposes of the
Program. We propose to add USCDI v3 in Sec. 170.213(b) and incorporate
it by reference in Sec. 170.299. Specifically, USCDI v3 in this
proposed rule refers to the USCDI v3 (October 2022 Errata). We propose
to codify the existing reference to USCDI v1 (July 2020 Errata) in
Sec. 170.213(a). We propose that as of January 1, 2025, any Health IT
Modules seeking certification for criteria referencing Sec. 170.213
would need to be capable of exchanging the data classes and data
elements that comprise USCDI v3.
b. Certification Criteria That Reference USCDI
The USCDI standard is currently cross-referenced, via cross-
reference to Sec. 170.213, in certain certification criteria. A Health
IT Module could currently be certified to any of these criteria by
ensuring that it complies with either the USCDI v1 or USCDI v2
standards, since USCDI v2 is approved for SVAP. Should we adopt our
proposal to add the USCDI v3 in Sec. 170.213, Health IT Modules
certified to these criteria that cross-reference Sec. 170.213 could
also be certified by meeting the USCDI v3 standard. Through December
31, 2024, we propose that a Health IT Module certified to criteria that
cross-reference Sec. 170.213 may be certified by complying with (1)
USCDI v1; (2) USCDI v2 under SVAP; and (3) USCDI v3. We propose to
allow only USCDI v3 after this date for the criteria that cross-
reference Sec. 170.213. 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 note that Sec. 170.315(f)(5) also currently references Sec.
170.213. However, as discussed later in this preamble, we propose to
rely on specific
[[Page 23764]]
IGs for this criterion, rather than reference Sec. 170.213. As such,
we do not propose to require Health IT Modules certified to Sec.
170.315(f)(5)(iii) to certify using either USCDI v1 or USCDI v3 through
December 31, 2024, and only USCDI v3 after December 31, 2024.
As noted previously, a developer of certified health IT would not
be required to provide technology updates for certified criteria or
standards to a user who declined such updates. However, we note that if
such an update is not provided, even if the version of the Health IT
Module in use still operates, that version would no longer be
considered certified. This means that it may no longer meet the
requirements of HHS programs requiring the use of certified health IT.
We propose to add introductory text to Sec. 170.213 noting that
the Secretary adopts the following standards as the standards available
for the purpose of representing electronic health information, and we
also propose 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 propose 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 propose 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). 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 the final rule, it is our intent to consider adopting
the updated versions that support USCDI v3.
We clarify that under this proposal, for the time period up to and
including December 31, 2024, USCDI v1 would remain applicable as the
minimum version of the USCDI required for certification criteria that
reference Sec. 170.213. This means that upon the effective date of a
rule finalizing this proposal, for the identified certification
criteria that reference Sec. 170.213, the following would apply as
available versions of USCDI for certification and compliance:
<bullet> USCDI v1 (2020 Errata) for the time period up to and
including December 31, 2024 (the adoption of the standard expires on
January 1, 2025),
<bullet> USCDI v3.
We refer to the term ``expires'' in standards throughout this
proposed rule, and it would mean that the Secretary no longer
recognizes the standard in the Code of Federal Regulations and its use
for purposes of the Program is no longer available.
USCDI v2 would remain available via SVAP for developers of
certified health IT who want to voluntarily update their Health IT
Modules, or for developers of certified health IT who want to certify
to applicable criteria in addition to or instead of USCDI v1 up to and
including December 31, 2024.
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 propose 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 have instead proposed to
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 are not removing the reference to CCDS in that section.
c. USCDI Standard--Data Classes and Elements Added Since USCDI v1
ONC proposes to update the USCDI standard in Sec. 170.213 by
proposing a January 1, 2025 expiration date for USCDI v1 (July 2020
Errata) and by adding the newly released USCDI v3 (October 2022
Errata). ONC proposes to incorporate USCDI v3 by reference in Sec.
170.299. USCDI v3 includes all data elements defined in USCDI v1 and
USCDI v2, and includes additional data elements added in USCDI v3.
Adopting USCDI v3 would provide more comprehensive health data for
providers and patients accessing and exchanging electronic health
information. USCDI v3 includes Sexual Orientation, Gender Identity,
Functional Status, Disability Status, Mental/Cognitive Status, and
Social Determinants of Health data elements including: SDOH Assessment,
SDOH Goals, SDOH Interventions, and SDOH Problems/Health Concerns.
Access, exchange, and use of these data elements can support more
informed care for patients. These data elements are described in more
detail below.
While the SVAP process provides an opportunity for health IT
developers to voluntarily update their certified products to newer
versions of USCDI, setting a new USCDI v3 floor for all certified
health IT that includes Health IT Modules certified to certification
criteria that reference Sec. 170.213 would enable a more consistent
adoption of an expanded baseline set of data, realizing the benefits
described above. We propose to add USCDI v3 to Sec. 170.213 in
addition to USCDI v1 (July 2020 Errata). Because USCDI v1 (July 2020
Errata) may be used for the time period up to and including December
31, 2024, we propose to amend Sec. 170.213 to include paragraph (a)
that will note that the USCDI v1 (July 2020 Errata) standard will
expire on January 1, 2025, and paragraph (b) that will note the
addition of USCDI v3.
Below, we describe the data classes and data elements in USCDI v3
that are not included in USCDI v1. We also describe any data classes or
data elements that were changed through the USCDI update processes when
comparing USCDI v3 to USCDI v1. For the overall structure and
organization of the USCDI standard, including USCDI v3, we urge the
public to consult <a href="http://www.healthIT.gov/USCDI">www.healthIT.gov/USCDI</a>. All the following data
classes and data elements were added to USCDI based on submissions
through the ONDEC system and ONC's determination that they represented
significant additions to core interoperable health data and met the
prioritization criteria previously set forth in this process. We
propose each of these data classes or data elements to be included in
the USCDI standard in Sec. 170.213 and to be incorporated by reference
in Sec. 170.299 as part of our proposal to adopt USCDI v3.
i. Social Determinants of Health (SDOH)
SDOH \36\ 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.\37\ In the 2015 Edition, ONC adopted a
certification criterion to enable users of Health IT Modules(s) that
certified to that criterion with the functionality to electronically
capture,
[[Page 23765]]
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 were 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.\38\ ONC supports the use of technology to improve the
standardized capture of a set of health data classes to support the
healthcare industry's need to electronically capture the underlying
data they need or want to collect for healthcare.
---------------------------------------------------------------------------
\36\ 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>.
\37\ <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>.
\38\ <a href="https://www.federalregister.gov/d/2015-25597/p-406">https://www.federalregister.gov/d/2015-25597/p-406</a>.
---------------------------------------------------------------------------
SDOH data are often categorized into domains based on the type of
circumstances they are intended to represent, such as food or housing
insecurity. However, many of these circumstances overlap, and there are
continuing efforts aiming to capture additional areas of focus such as
broadband access or environmental risk factors.
USCDI v3 includes four SDOH data elements that represent specific
aspects of SDOH data related to the use or purpose of the SDOH data
rather than based on the domain. In this way, the data elements can
emphasize the use case aspect of the data and expand to additional
domains over time. These data elements are new for USCDI v3 as compared
to USCDI v1. However, because each of these aspects is closely related
to data elements that exist in USCDI data classes, these new data
elements were organized into the applicable existing data classes.
------------------------------------------------------------------------
Existing USCDI Data Class New Data Element
------------------------------------------------------------------------
Assessment and Plan of SDOH Assessment--related to the
Treatment. conditions in which people live, learn,
work and play.
Goals........................ SDOH Goals--related to expected outcomes
for interventions addressing the
conditions in which people live, learn,
work and play.
Procedures................... SDOH Interventions--related to addressing
the conditions in which people live,
learn, work and play.
Problems..................... SDOH Problems/Health Concerns--related to
the conditions experienced by a person
that impact how they live, learn, work
and play. (e.g., transportation
insecurity, food insecurity).
------------------------------------------------------------------------
ii. Care Team Member
In USCDI v1, the Care Team Member data class had one data element
to capture all aspects about a care team member. ONC received
submissions recommending the addition of more granular data elements
that provide greater detail around a patient's health care provider and
other members of the care team. USCDI v3 includes five Care Team Member
data elements: Name, Identifier, Role, Location, and Telecom.
iii. Clinical Notes
For the data element Discharge Summary Note in the Clinical Notes
data class, we specified additional requirements in USCDI v3 including
admission and discharge dates and locations, discharge instructions,
and reason(s) for hospitalization, which are also required elements in
the Transitions of Care certification criterion (Sec. 170.315(b)(1)).
iv. Clinical Tests
USCDI v3 includes a data class for Clinical Tests, which has two
data elements, Clinical Test and Clinical Test Result/Report. This is a
new data class as compared to USCDI v1. These elements will enable the
capture and exchange of non-imaging and non-laboratory tests. Some
examples include electrocardiogram (ECG), visual acuity exam, macular
(ophthalmic) exam, or graded exercise testing (GXT). These tests are
routinely performed on patients and result in structured or
unstructured (narrative) findings that facilitate the diagnosis and
management of a patient's condition(s).
v. Diagnostics Imaging
USCDI v3 includes the Diagnostic Imaging data class and its two
elements: Diagnostic Imaging Test and Diagnostic Imaging Report. This
is a new data class as compared to USCDI v1. These data elements added
a critical missing capability of health IT to capture and exchange
structured and unstructured imaging test and report data for a patient.
vi. Encounter Information
USCDI v3 includes the Encounter Information data class, which
includes five data elements: Encounter Type, Encounter Diagnosis,
Encounter Time, Encounter Location, and Encounter Disposition. This is
a new data class as compared to USCDI v1.
vii. Health Insurance Information
USCDI v3 includes the Health Insurance Information data class,
which provides an opportunity for health IT to capture and exchange key
elements of healthcare insurance coverage. This information can be
useful for patient matching and record linkage, coverage determination,
prior authorization, price transparency, claims and reimbursement
efficiencies, and identifying disparities related to insurance
coverage. This is a new data class as compared to USCDI v1. This data
class includes seven data elements: Coverage Status, Coverage Type,
Relationship to Subscriber, Member Identifier, Subscriber Identifier,
Group Identifier, and Payer Identifier.
viii. Health Status Assessments
USCDI v3 includes a data class called Health Status Assessments,
which contains four new data elements: Disability Status, Mental/
Cognitive Status, Functional Status, and Pregnancy Status. This is a
new data class as compared to USCDI v1. In USCDI v3, the Health Status
Assessments data class also includes two data elements that have been
recategorized, Health Concerns and Smoking Status, which were
previously part of different data classes in USCDI. The Health Status
Assessments data class provides a broader context for these data
elements. The ability to capture and exchange data that represent the
assessment performed and the assessment component results helps health
care providers address inequities by being able to readily identify and
address a patient's conditions characterized with these data.
ix. Laboratory
USCDI v3 includes Specimen Type and Result Status data elements,
which
[[Page 23766]]
have been added to the USCDI Laboratory data class to address public
health reporting priorities. These new data elements are key components
of laboratory reports and can help with ongoing public health needs,
including Covid-19, MPox and future public health emergencies, to
ultimately improve patient care.
x. Medications
USCDI v3 includes Dose, Dose Units of Measure, Indication, and Fill
Status data elements, which have been added to the USCDI Medications
data class in response to public feedback and because these data
elements are necessary for certain CMS reporting programs and are also
critical to certain ONC certification criteria (including the
electronic prescribing certification criterion at Sec. 170.315(b)(3)).
xi. Patient Demographics/Information
Based on submissions and comments during the USCDI update processes
described above, ONC changed or added data elements in the Patient
Demographics/Information data class.
USCDI v3 includes data elements Sexual Orientation and Gender
Identity, which have been added to the USCDI Patient Demographics/
Information data class. Previously, ONC adopted standards for Sexual
Orientation in the demographics criterion in Sec. 170.315(a)(5)(i)(D)
and for Gender Identity in the demographics criterion in Sec.
170.315(a)(5)(i)(E). These criteria include requirements to code Sexual
Orientation and Gender Identity according to the adopted SNOMED
CT[supreg] codes and HL7 Version 3 Standard, Value Sets for
AdministrativeGender and NullFlavor as referenced Sec. 170.207(o)(1)
and Sec. 170.207(o)(2), respectively.
These codes reflect an attempt to exchange data regarding Sexual
Orientation and Gender Identity in a consistent manner. Public feedback
has, however, indicated that the required SNOMED CT[supreg] codes do
not appropriately and accurately capture all applicable sexual
orientations or gender identities. We also understand that the existing
standards reference specific codes from the HL7 Version 3 Standard,
Value Set for NullFlavor, which are primarily used by health IT
developers to indicate when there is not information available to
represent Sexual Orientation or Gender Identity. The HL7 Gender Harmony
Project has developed an informative document \39\ that includes codes
for Gender Identity such as ``Nonbinary'' that are not present in
adopted values sets (Sec. 170.207(o)(2)). Additionally,
representatives of the healthcare community and patient advocates have
indicated a desire to expand the codes for Sexual Orientation and
Gender Identity in the future to reflect the need to be more inclusive
and to aid in identifying and addressing health disparities.
---------------------------------------------------------------------------
\39\ <a href="https://confluence.hl7.org/download/attachments/81017270/HL7_GENDER_R1_INFORM_2021AUG.pdf?version=1&modificationDate=1639425849713&api=v2">https://confluence.hl7.org/download/attachments/81017270/HL7_GENDER_R1_INFORM_2021AUG.pdf?version=1&modificationDate=1639425849713&api=v2</a>.
---------------------------------------------------------------------------
Accordingly, we propose to remove the requirement to use specific
codes for representing Sexual Orientation and Gender Identity and have
removed the codes as applicable vocabulary standards from USCDI v3.
Rather, to continue to promote interoperability while also providing
health care providers with flexibility to better support clinical care,
certified health IT with Health IT Modules certified to criteria that
reference Sec. 170.213 would be required to be capable of representing
Sexual Orientation and Gender Identity in SNOMED CT[supreg] when such
information is exchanged as part of USCDI. We believe that it is best
to let the health IT community develop the list of appropriate values
for Sexual Orientation and Gender Identity, whether through
implementation specifications or developing additional codes in SNOMED
CT[supreg].
We received strong support from commenters in response to our
request during the Draft USCDI v3 public feedback period that the USCDI
term Sex (Assigned at Birth) was too limiting for the industry. In
subsequent exploration and analysis, we learned that this element is
represented in different ways in a number of jurisdictions, so the
meaning is unclear.
There was support to align the term in USCDI with the term Recorded
Sex or Gender as part of the Gender Harmony Project. We understand that
the term Recorded Sex or Gender is a more expansive term that defines
the value of patient's sex recorded in administrative or legal
documents, and indeed Sex (Assigned at Birth) could be considered as a
specific type or recorded value with the identifier being assigned at
birth. However, in order to be least disruptive to the industry, while
at the same time, acknowledging the shortcomings of our current term,
we have recharacterized the USCDI data element Sex (Assigned at Birth)
to Sex. We note that this is presently a change in the name of the
element and will have no immediate impact on health IT developers of
certified health IT, which will continue to exchange the value of
patient's sex they have been historically exchanging using USCDI.
However, we anticipate this change to support future enhancements to
improve precision in the meaning through work done by health IT
developers of certified health IT.
USCDI v3 does not require the use of certain specific codes for
representing Sex. As discussed previously, we propose to remove the
requirement in Sec. 170.315(a)(5)(i)(C) and Sec.
170.315(b)(1)(iii)(G)(3) to code Sex according to the adopted value
sets of HL7 Version 3 Value Sets for AdministrativeGender and
NullFlavor as referenced in the value sets in Sec. 170.207(n)(1). We
propose instead to permit coding according to either the adopted value
sets of HL7 Version 3 Value Sets for AdministrativeGender and
NullFlavor as referenced in the value sets in Sec. 170.207(n)(1) until
December 31, 2025, or in accordance with the standard in proposed Sec.
170.207(n)(2). These codes reflect an attempt to exchange Sex in a
consistent manner. Our analysis has, however, indicated that the value
sets do not appropriately and accurately capture all applicable values
for Sex. Interested parties have indicated a desire to expand the codes
for Sex in the future to be more inclusive and to aid in efforts to
address health disparities. Accordingly, we no longer require the use
of specific code sets for representing Sex and have removed the codes
from USCDI v3. Rather, to continue to promote interoperability while
also granting providers with flexibility to better support clinical
care, certified health IT with Health IT Modules certified to criteria
that reference Sec. 170.213 would be required to be capable of
representing Sex in SNOMED CT when such information is exchanged as
part of USCDI. We have similarly proposed to adopt the same changes for
relevant certification criteria that reference these standards (see
sections III.C.8 and III.C.9).
Finally, we have taken note of the substantial effort in this area
to develop a clinically meaningful way for identifying a patient's sex
from observable information (e.g., Clinical Observation, Radiology
report, Laboratory report, genetic testing data) that may be suitable
for clinical care, including the development of a new data element Sex
for Clinical Use, which we may consider including in future standards
adoption. We welcome public comment on this concept and approach. In
addition, as noted in our proposals to the Patient Demographics and
Observations certification criterion in Sec. 170.315(a)(5), we have
proposed to adopt the same changes for relevant certification criteria
that reference these
[[Page 23767]]
standards (see sections III.C.8 and III.C.9).
ONC also sought feedback on the value of adoption of an applicable
vocabulary standard for patient addresses.\40\ USCDI v1 required
Current Address and Previous Address as discrete data elements, but
there are no existing standards available for healthcare use cases.
Through a collaboration between ONC and the standards development
community, a new standard, the Unified Specification for Address in
Health Care (US@),\41\ emerged and was released in 2022. After
receiving broad support from the public, ONC has incorporated the
Project US@Technical Specification version 1 as the applicable standard
for Current Address and Previous Address in USCDI v3.
---------------------------------------------------------------------------
\40\ <a href="https://www.healthit.gov/sites/default/files/page/2022-01/Standards_Bulletin_2022-1.pdf#page=5">https://www.healthit.gov/sites/default/files/page/2022-01/Standards_Bulletin_2022-1.pdf#page=5</a>.
\41\ <a href="https://oncprojectracking.healthit.gov/wiki/pages/viewpage.action?pageId=180486153">https://oncprojectracking.healthit.gov/wiki/pages/viewpage.action?pageId=180486153</a>.
---------------------------------------------------------------------------
USCDI v3 includes six data elements added to the prior USCDI
Patient Demographics/Information data class: Related Person's Name,
Related Person's Relationship, Date of Death, Occupation, Occupation
Industry, and Tribal Affiliation. Related Person's Name and Related
Person's Relationship enable linkages between maternal and child
records as well as identifying and linking other related persons, such
as custodians and guardians. Date of Death supports patient matching,
adverse event, public health, and vital records reporting. Occupation
and Occupation Industry data elements were added to support public
health, and to capture military service. Finally, Tribal Affiliation is
captured by the Indian Health Service (IHS), an agency within the
Department of Health and Human Services, to aid in the determination of
eligibility for IHS services, care-coordination with non-tribal medical
facilities, and identification of disparities in healthcare in and
across American Indian and Alaska Native populations.
xii. Problems
As discussed in sub-section i of this section, USCDI v3 includes
the SDOH Problems/Health Concerns data element added to the prior USCDI
Problems data class. In addition, USCDI v3 includes Date of Diagnosis
and Date of Resolution data elements added to the prior USCDI Problems
data class to include timing elements for recorded and maintained
problem lists within electronic health records.
xiii. Procedures
USCDI v3 includes the Reason for Referral data element added to the
prior USCDI Procedures data class. This data element is already part of
the Program requirements for the transitions of care certification
criterion (Sec. 170.315(b)(1)(iii)(E)) in the ambulatory setting and
is broadly implemented in health IT. As discussed in sub-section i of
this section, the USCDI v3 also includes the SDOH Interventions data
element added to the prior USCDI Procedures data class.
xiv. Updated Versions of Vocabulary Standard Code Sets
In the 2015 Edition Final Rule, we established a policy for minimum
standards code sets that update frequently throughout a calendar year
at 80 FR 62612, and we have listed several standards as minimum
standards code sets in 45 CFR part 170 subpart B. As with all adopted
minimum standards code sets, health IT can be certified to newer
versions of the adopted baseline version minimum standards code sets
for purposes of certification, unless the Secretary specifically
prohibits the use of a newer version (see Sec. 170.555 and 77 FR
54268). In USCDI v3, we included the most recent versions of the
minimum standards code sets.
2. C-CDA Companion Guide Updates
We propose to adopt the HL7[supreg] CDA[supreg] R2 Implementation
Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release
3--US Realm in Sec. 170.205(a)(6) (``C-CDA Companion Guide R3''). The
C-CDA Companion Guide R3 provides supplemental guidance and additional
technical clarification for specifying data in the C-CDA Release 2.1
for USCDI v2. However, it is our understanding that HL7 is working on
updating the C-CDA R2.1 Companion Guide (Release 4) for USCDI v3. If
the C-CDA Companion Guide Release 4 (R4) is published before the date
of publication of the final rule, it is our intention to consider
adopting the updated Companion Guide R4 that provides guidance and
clarifications for specifying data in USCDI v3 since we propose to
adopt USCDI v3 as the baseline in this proposed rule.
As mentioned above, HL7[supreg] has been updating the C-CDA
Companion Guide to accommodate the new data classes and elements in
each USCDI version. To allow developers to voluntarily update to USCDI
v2, ONC included the C-CDA Companion Guide R3 in the SVAP Approved
Standards List for 2022. ONC released the SVAP Approved Standards List
for 2022 in June 2022. We anticipate that the C-CDA Companion Guide R4
would support updates included in proposed USCDI v3. We note that the
adoption of the C-CDA Companion Guide R4 would align with our goal to
increase the use of consistently implemented standards among health IT
developers and improve interoperability. We propose to adopt the C-CDA
Companion Guide R3 as a standard in Sec. 170.205(a)(6) and incorporate
it by reference in Sec. 170.299. As stated above, if the C-CDA
Companion Guide R4 is available at the time of publication of the final
rule, we intend to consider adopting the C-CDA Companion Guide R4,
which would support the updates included in proposed USCDI v3.
Consistent with our proposals in sections III.A and III.C.11, we
propose to revise Sec. 170.205(a)(5) to add that the adoption of the
standard in Sec. 170.205(a)(5) expires on January 1, 2025. Developers
of certified health IT with Health IT Modules certified to criteria
that reference Sec. 170.205(a)(5) would have to update those Health IT
Modules to Sec. 170.205(a)(6) and provide them to customers by January
1, 2025. We clarify that under this proposal, for the time period up to
and including December 31, 2024, HL7 CDA[supreg] R2 Implementation
Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release
2 would remain applicable as the minimum version required in the
Program. This means that upon the effective date of a final rule, for
the identified certification criteria, the following would apply as the
minimum version for C-CDA for certification and compliance:
<bullet> HL7 CDA[supreg] R2 Implementation Guide: C-CDA Templates
for Clinical Notes R2.1 Companion Guide, Release 2 (incorporated by
reference in Sec. 170.299) for the time period up to and including
December 31, 2024,
<bullet> HL7 CDA[supreg] R2 IG: C-CDA Templates for Clinical Notes
R2.1 Companion Guide, Release 3.
Further, we propose that Health IT Modules certified to the
certification criteria below would need to update to the HL7
CDA[supreg] R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion
Guide, Release 3 in Sec. 170.205(a)(6) by January 1, 2025:
<bullet> ``transitions of care'' (Sec. 170.315(b)(1)(iii)(A));
<bullet> ``clinical information reconciliation and incorporation''
(Sec. 170.315(b)(2)(i), (ii), and (iv));
<bullet> ``care plan'' (Sec. 170.315(b)(9)(ii));
<bullet> ``view, download, and transmit to 3rd party'' (Sec.
170.315(e)(1)(i)(A) and (B));
[[Page 23768]]
<bullet> ``consolidated CDA creation performance'' (Sec.
170.315(g)(6)(i)); and
<bullet> ``application access--all data request'' (Sec.
170.315(g)(9)(i)).
For the purposes of meeting that compliance timeline, we expect
health IT developers to update their certified health IT without new
mandatory testing and notify their ONC-ACB on the date at which they
have reached compliance. Developers would also need to factor these
updates into their next real world testing plan.
3. ``Minimum Standards'' Code Sets Updates
We established a policy in the 2015 Edition Final Rule for minimum
standards code sets that update frequently (80 FR 62612). In prior
rulemaking, we discussed the benefits of adopting newer versions of
minimum standards code sets, including the improved interoperability
and implementation of health IT with minimal additional burden (77 FR
54170). When determining whether to propose newer versions of minimum
standards code sets, we consider the impact on interoperability and
whether a newer version would require substantive effort for developers
of certified health IT to implement. If adopted, newer versions of
minimum standards code sets would serve as the baseline for
certification and developers of certified health IT would be able to
use newer versions of these adopted standards on a voluntary basis. We
reiterate that while minimum standard code sets update frequently,
perhaps several times in a single year, these updates are confined to
concepts within the code system, not substantive changes to the
standards themselves. We propose to adopt the following versions of the
minimum standards codes sets listed below.
<bullet> Sec. 170.207(a)--Problems
We propose to remove and reserve Sec. 170.207(a)(3), IHTSDO SNOMED
CT[supreg] International Release July 2012 and US Extension to SNOMED
CT[supreg] March 2012 Release. We propose to revise Sec.
170.207(a)(1), which is currently reserved, to reference SNOMED CT US
Edition March 2022 and incorporate it by reference in Sec. 170.299.
<bullet> Sec. 170.207(c)--Laboratory Tests
We propose to remove and reserve Sec. 170.207(c)(2), Logical
Observation Identifiers Names and Codes (LOINC[supreg]) Database
version 2.40. We propose to revise Sec. 170.207(c)(1), which is
currently reserved, to reference LOINC Database version 2.72, February
16, 2022, and incorporate it by reference in Sec. 170.299.
<bullet> Sec. 170.207(d)--Medications
We propose to revise Sec. 170.207(d)(1), which is currently
reserved, to reference RxNorm July 5, 2022, Full Monthly Release and
incorporate it by reference in Sec. 170.299. We propose to reference
the code sets specified in 45 CFR 162.1002(c)(1) which include
International Classification of Diseases, 10th Revision, Clinical
Modification (ICD-10-CM); International Classification of Diseases,
10th Revision, Procedure Coding System (ICD-10-PCS) (including The
Official ICD-10-PCS Guidelines for Coding and Reporting); National Drug
Codes (NDC); the combination of Health Care Financing Administration
Common Procedure Coding System (HCPCS), as maintained and distributed
by HHS, and Current Procedural Terminology, Fourth Edition (CPT-4), as
maintained and distributed by the American Medical Association, for
physician services and other healthcare services; Health Care Financing
Administration Common Procedure Coding System (HCPCS) as maintained and
distributed by HHS, for all other substances, equipment, supplies, or
other items used in healthcare services; and Code on Dental Procedures
and Nomenclature, in Sec. 170.207(d)(4).
<bullet> Sec. 170.207(e)--Immunizations
We propose to revise Sec. 170.207(e)(1), which is currently
reserved, to reference CVX--VaccinesAdministered, June 15, 2022, and
incorporate it by reference in Sec. 170.299. We also propose to revise
Sec. 170.207(e)(2), which is currently reserved, to reference NDC--
Vaccine NDC Linker, updates through July 19, 2022, and incorporate it
by reference in Sec. 170.299.
<bullet> Sec. 170.207(f)--Race and ethnicity
We propose to add Sec. 170.207(f)(3) to reference CDC Race and
Ethnicity Code Set Version 1.2 (July 2021) and incorporate it by
reference in Sec. 170.299.
<bullet> Sec. 170.207(m)--Numerical references
We propose to revise Sec. 170.207(m)(2), which is currently
reserved, to reference the Unified Code of Units of Measure (UCUM),
Revision 2.1, November 21, 2017, and incorporate it by reference in
Sec. 170.299.
<bullet> Sec. 170.207(n)--Sex
As described in this proposed rule in sections III.C.1 and III.C.8,
we propose to revise Sec. 170.207(n)(2), which is currently reserved,
to reference the version of SNOMED CT[supreg] codes specified in Sec.
170.207(a)(1). We also propose to add Sec. 170.207(n)(3) to reference
the version of LOINC[supreg] codes specified in Sec. 170.207(c)(1).
<bullet> Sec. 170.207(o)--Sexual orientation and gender
information
We propose to change the heading of Sec. 170.207(o) from ``sexual
orientation and gender identity'' to ``sexual orientation and gender
information'' to acknowledge that Sec. 170.207(o) may include standard
code sets to support other gender related data items. Additionally, as
described in this proposed rule in sections III.C.1 and III.C.8, we
propose to add Sec. 170.207(o)(3) to reference the version of SNOMED
CT[supreg] codes specified in Sec. 170.207(a)(1) and to add Sec.
170.207(o)(4) to reference the version of LOINC[supreg] codes specified
in Sec. 170.207(c)(1) for Pronouns.
<bullet> Sec. 170.207(p)--Social, psychological, and behavioral
data
We propose to revise Sec. 170.207(p)(1) through (8) to reference
the version of LOINC[supreg] codes specified in proposed Sec.
170.207(c)(1) instead of Sec. 170.207(c)(3). We propose to revise
Sec. 170.207(p)(4), (5) and (7) and (8) to reference the version of
the Unified Code of Units of Measure in proposed Sec. 170.207(m)(2),
instead of Sec. 170.207(m)(1). We also propose to revise Sec.
170.207(p)(6) to include a reference to the version of the Unified Code
of Units of Measure in proposed Sec. 170.207(m)(2).
<bullet> Sec. 170.207(r)--Provider type
We propose to revise Sec. 170.207(r)(2), which is currently
reserved, to reference Crosswalk: Medicare Provider/Supplier to
Healthcare Provider Taxonomy, October 29, 2021, and incorporate it by
reference in Sec. 170.299.
<bullet> Sec. 170.207(s)--Patient insurance
We propose to revise Sec. 170.207(s)(2), which is currently
reserved, to reference Public Health Data Standards Consortium Source
of Payment Typology Code Set Version 9.2 (December 2020) and
incorporate it by reference in Sec. 170.299.
In addition to updating the minimum standards code sets listed
above, we propose to update the certification criteria that reference
those minimum standards. We propose to update some of the certification
criteria that reference Sec. 170.207(a) Problems, by replacing the
reference to Sec. 170.207(a)(4) in those criteria that reference it
with a reference to the new proposed Sec. 170.207(a)(1). These
criteria include Sec. 170.315(a)(12), (b)(1)(iii)(B)(2),
(b)(6)(ii)(B)(2), (c)(4)(iii)(I), and (f)(4)(ii). We also propose to
update Sec. 170.315(f)(3)(ii) by replacing the reference to Sec.
170.207(a)(3) with a reference to the new proposed Sec. 170.207(a)(1).
We propose to update the certification criteria that reference Sec.
170.207(c) Laboratory Tests by replacing the references to
[[Page 23769]]
Sec. 170.207(c)(2) and (c)(3) in those criteria with a reference to
the new proposed Sec. 170.207(c)(1). These criteria include Sec.
170.315(f)(3)(ii) and (f)(4)(ii).
We propose to update two certification criteria that reference
Sec. 170.207(e) Immunizations. We propose to update the certification
criterion Sec. 170.315(f)(1)(i)(B), which references Sec.
170.207(e)(3), to instead reference the new proposed Sec.
170.207(e)(1). We also propose to update the certification criterion
Sec. 170.315(f)(1)(i)(C), which references Sec. 170.207(e)(4), by
replacing the reference to Sec. 170.207(e)(4) in that criterion with a
reference to the new proposed Sec. 170.207(e)(2).
We propose to update several certification criteria that reference
Sec. 170.207(f) Race and Ethnicity. We propose to update certification
criteria that reference Sec. 170.207(f)(2) to instead reference the
new proposed Sec. 170.207(f)(3). These criteria include Sec.
170.315(a)(5)(i)(A)(1) and (2) and Sec. 170.315(c)(4)(iii)(H).
As described in sections III.C.1 and III.C.8 of this proposed rule,
we propose to update criteria that reference Sec. 170.207(n) Sex by
updating criteria that reference Sec. 170.207(n)(1) to reference the
new proposed Sec. 170.207(n)(2). More specifically, we propose to
update Sec. 170.315(a)(5)(i)(C) to reference Sec. 170.207(n)(1) for
the time period up to and including December 31, 2025, or to reference
Sec. 170.207(n)(2). We also propose to update Sec.
170.315(c)(4)(iii)(G) to reference Sec. 170.207(n)(2) and to update
Sec. 170.315(b)(1)(iii)(G)(3) to reference the standards adopted in
Sec. 170.213.
Additionally, as described in sections III.C.1 and III.C.8 of this
proposed rule, we propose to update the criteria that reference Sec.
170.207(o) Sexual orientation and gender information (as we propose to
rename the criterion) by updating criteria that reference Sec.
170.207(o)(1) and (2). We propose to replace the reference to Sec.
170.207(o)(1) in Sec. 170.315(a)(5)(i)(D) with a reference to the new
proposed Sec. 170.207(o)(3) and propose to replace the reference to
Sec. 170.207(o)(2) in Sec. 170.315(a)(5)(i)(E) with a reference to
the new proposed Sec. 170.207(o)(3). More specifically, we propose to
update Sec. 170.315(a)(5)(i)(D) to reference Sec. 170.207(o)(1) for
the time period up to and including December 31, 2025, or to reference
Sec. 170.207(o)(3). We propose to update Sec. 170.315(a)(5)(i)(E) to
reference Sec. 170.207(o)(2) for the time period up to and including
December 31, 2025, or to reference Sec. 170.207(o)(3).
We also propose to update Sec. 170.315(c)(4)(iii)(C), which
references Sec. 170.207(r) Provider Type. Specifically, we propose to
replace the reference to Sec. 170.207(r)(1) in that criterion with a
reference to the new proposed Sec. 170.207(r)(2). We also propose to
update Sec. 170.315(c)(4)(iii)(E), which references Sec. 170.207(s)
Patient insurance. Specifically, we propose to replace the reference to
Sec. 170.207(s)(1) in that criterion with a reference to the new
proposed Sec. 170.207(s)(2).
4. Electronic Case Reporting
a. Background
Case reporting serves as early notification to Public Health
Agencies (PHAs) for potential disease outbreaks and includes
information that enables PHAs to start contact tracing and other
prevention measures. Case reports include critical clinical information
that is not included in syndromic surveillance or laboratory reporting
and can help illuminate the impact of comorbidities, treatments, and
variable access to care. Every state has laws requiring providers to
submit case reports of specific reportable diseases and conditions.
Electronic case reporting is the automated, real-time, bidirectional
exchange of case report information between EHRs and PHAs.\42\
Electronic case reporting uses standard codes to trigger the transfer
of relevant clinical data to PHAs for case investigation and follow-up,
including data on demographics, comorbidities, immunizations,
medications, occupation, and other treatments. Most states do not
require electronic submission of case reports; rather, case reporting
often occurs through outdated manual methods (e.g., fax, email, or
phone) which results in delays, underreporting, and incomplete or
inaccurate case data.<SUP>43 44</SUP> This manual case reporting also
imposes burdens on health care providers, taking staff time away from
patients to submit case reports and comply with state reporting
requirements.
---------------------------------------------------------------------------
\42\ Centers for Disease Control & Prevention (CDC). Electronic
Case Reporting Fact Sheet. Available at: <a href="https://www.cdc.gov/ecr/docs/eCR-Fact-Sheet-508.pdf">https://www.cdc.gov/ecr/docs/eCR-Fact-Sheet-508.pdf</a>.
\43\ ONC. Interoperability Standards Advisory. Case Reporting to
Public Health: <a href="https://www.healthit.gov/isa/case-reporting-public-health-agencies">https://www.healthit.gov/isa/case-reporting-public-health-agencies</a>.
\44\ Ashley Antonelli and Joseph Leonard. CMS is mandating new
electronic case reporting requirements. Here's how providers can
prepare. Advisory Board. <a href="https://www.advisory.com/blog/2021/12/electronic-case-reporting">https://www.advisory.com/blog/2021/12/electronic-case-reporting</a>.
---------------------------------------------------------------------------
ONC established initial content exchange standards in 45 CFR
170.205(g)(1) and (g)(2) to support a version of HL7[supreg] v2 for
``electronic submission to public health agencies for surveillance or
reporting'' in the 2010 ``Health Information Technology: Initial Set of
Standards, Implementation Specifications, and Certification Criteria
for Electronic Health Record Technology'' Interim Final Rule (75 FR
2033). These standards were not specific to electronic case reporting;
rather they supported the more generic submission of information to
PHAs. The ``transmission to public health agencies--electronic case
reporting'' certification criterion in Sec. 170.315(f)(5) was later
adopted in the 2015 Edition Final Rule to ``support the electronic
transmission of case reporting information to public health agencies''
as part of the CMS EHR Incentive Programs (80 FR 62667).
In the ONC 2015 Edition Proposed Rule (80 FR 16804), we requested
comment on whether to adopt a standardized method for electronic case
reporting, including potentially adopting the ``IHE Quality, Research,
and Public Health Technical Framework Supplement, Structured Data
Capture, Trial Implementation (September 5, 2014) standard'' and the
``HL7 FHIR Implementation Guide: SDC DSTU that would be balloted in
mid-2015 in place of, or together with, the IHE Quality, Research, and
Public Health Technical Framework Supplement'' (80 FR 16855). In
response to comments, we did not adopt a standard for this criterion in
the 2015 Edition Final Rule, but instead outlined functional
requirements that Health IT Modules would need to support for
certification to the electronic case reporting criterion. These
functional requirements included a requirement that a Health IT Module
support the ability to ``(1) consume and maintain a table of trigger
codes to determine which encounters should initiate an initial case
report being sent to public health to determine reportability; and (2)
when a trigger is matched, create an initial case report that includes
specific data (Common Clinical Data Set; encounter diagnoses; provider
name, office contact information, and reason for visit, and an
identifier representing the row and version of the trigger table that
triggered the case report)'' (80 FR 62667). In addition to establishing
these functional requirements in the 2015 Edition Final Rule, we also
described additional functionalities that would help support electronic
case reporting to public health but did not adopt them as requirements
for the ONC Health IT Certification Program (80 FR 62667); these
functional requirements included: ``(3) receive and display additional
information, such as a ``notice of reportability'' and data fields to
be
[[Page 23770]]
completed; and (4) submit a completed form.''
ONC described some of the context for standards development and the
future for electronic case reporting. We stated ``[a]s standards evolve
. . . the future might include a FHIR-based approach. Therefore, we
believe this overall initial certification approach establishes
necessary flexibility within the ONC Health IT Certification Program
related to electronic case reporting in that as technical approaches
evolve to accomplish electronic case reporting they can be certified.
In the future, we may be able to consider a specific standard for
certification through rulemaking'' (80 FR 62667).
In 2017, ONC established self-declaration as the demonstration
method for electronic case reporting.\45\ In the ONC Cures Act Final
Rule (85 FR 25642), electronic case reporting was included as part of
the Real World Testing Condition and Maintenance of Certification
requirements (codified in 45 CFR 170.405), which require health IT
developers with Health IT Modules certified to criteria specified in
Sec. 170.405(a) to ``successfully test the real world use of those
Health IT Module(s) for interoperability (as defined in 42
U.S.C.300jj(9) and Sec. 170.102) in the type of setting in which such
Health IT Module(s) would be/is marketed'' (85 FR 25948). Health IT
developers with Health IT Modules certified to applicable criteria have
the flexibility to establish their own Real World Testing plan and
submit results based on measures they develop. However, it is expected
that developers use Real World Testing plans and results to demonstrate
ongoing conformance to standards and functionality required as part of
the Program, per 45 CFR 170.405(b)(2)(i).
---------------------------------------------------------------------------
\45\ <a href="https://www.healthit.gov/test-method/transmission-public-health-agencies-electronic-case-reporting">https://www.healthit.gov/test-method/transmission-public-health-agencies-electronic-case-reporting</a>.
---------------------------------------------------------------------------
We also modified Sec. 170.315(f)(5)(iii)(B) in the ONC Cures Act
Final Rule to require Health IT Modules to support creation of
electronic case reports based on (1) the data classes expressed in the
standards in Sec. 170.213, or (2) the Common Clinical Data Set (CCDS)
until December 31, 2022 (85 FR 25667). This was proposed as part of a
Program-wide effort to transition Health IT Modules certified to
certification criteria that referenced the CCDS to instead support the
USCDI v1 (85 FR 25670). ONC subsequently clarified that while either
the CCDS or the USCDI v1 data set needed to be supported, ``a health IT
developer must attest to their product's ability to support the
referenced standard(s) in Sec. 170.315(f)(5)(iii)(B)(1) or (2).
However, individual PHAs may require a subset of this data for
reporting.'' \46\
---------------------------------------------------------------------------
\46\ For further information see: Sec. 170.315(f)(5)
Certification Companion Guide available here: <a href="https://www.healthit.gov/test-method/transmission-public-health-agencies-electronic-case-reporting">https://www.healthit.gov/test-method/transmission-public-health-agencies-electronic-case-reporting</a>.
---------------------------------------------------------------------------
b. Standards Landscape for Case Reporting
Since ONC adopted 45 CFR 170.315(f)(5) as a functional requirement
for Health IT Modules in the 2015 Edition, standards development
organizations (SDOs), public health, and interested parties within the
healthcare industry have balloted several standards related to
electronic case reporting. The standards were produced and developed
through a collaborative effort among many partners, including CDC, the
Council of State and Territorial Epidemiologists (CSTE), the
Association of State and Territorial Health Officials (ASTHO), the
Association of Public Health Laboratories (APHL), electronic health
record (EHR) developers, and the Health Level Seven (HL7) Public Health
(PH) Work Group.\47\ These standards pertain to both HL7[supreg] FHIR
and HL7[supreg] CDA and include multiple Implementation Guides (IGs).
---------------------------------------------------------------------------
\47\ See work group membership at: <a href="https://confluence.hl7.org/display/PHWG/Public+Health+Work+Group">https://confluence.hl7.org/display/PHWG/Public+Health+Work+Group</a>.
---------------------------------------------------------------------------
Recognizing advancement of standards development in this area, ONC
analyzed the currently balloted standards for potential inclusion in
the existing 45 CFR 170.315(f)(5) criterion. ONC examined the following
standards for potential inclusion as a part of this criterion:
<bullet> HL7 FHIR[supreg] Implementation Guide: Electronic Case
Reporting (eCR)--US Realm STU2 (HL7 FHIR eCR IG): <SUP>48</SUP> The HL7
FHIR eCR IG contains multiple FHIR profiles that correspond to the HL7
CDA eICR and the HL7 CDA Reportability Response standards. This IG also
includes profiles for electronic Reporting and Surveillance
Distribution (eRSD) that enables the electronic distribution of trigger
codes and reporting guidance and parameters from public health to
clinical care.
---------------------------------------------------------------------------
\48\ <a href="http://build.fhir.org/ig/HL7/case-reporting/index.html">http://build.fhir.org/ig/HL7/case-reporting/index.html</a>.
---------------------------------------------------------------------------
[cir] HL7 FHIR Electronic Initial Case Report (eICR) transaction
and profile: <SUP>49</SUP> The HL7 FHIR eCR IG specifies a standardized
method for the communication of an eICR to a PHA using the HL7[supreg]
FHIR standard. The eICR profiles are intended to contain the data
elements necessary to initiate a public health investigation or other
appropriate public health action based on a potentially reportable case
identified by a healthcare organization.
---------------------------------------------------------------------------
\49\ <a href="http://build.fhir.org/ig/HL7/case-reporting/electronic_initial_case_report_eicr_transaction_and_profiles.html">http://build.fhir.org/ig/HL7/case-reporting/electronic_initial_case_report_eicr_transaction_and_profiles.html</a>.
---------------------------------------------------------------------------
[cir] HL7 FHIR Reportability Response (RR) transaction and profile:
<SUP>50</SUP> The HL7 FHIR eCR IG also describes a standardized method
for a PHA to communicate a RR to a healthcare organization that
initiated an eICR. The RR profiles can include determination of
reportability information, contact information for the involved PHAs,
requests for case investigation supplemental data that may not have
been recorded in the process of care, condition-specific information
from public health, and an acknowledgment that a report has been
successfully conveyed. The IG notes that there may be several different
intermediaries involved in the transmission of RR messages including
Health Information Exchanges and Health Data Networks.
---------------------------------------------------------------------------
\50\ <a href="http://build.fhir.org/ig/HL7/case-reporting/reportability_response_rr_transaction_and_profiles.html">http://build.fhir.org/ig/HL7/case-reporting/reportability_response_rr_transaction_and_profiles.html</a>.
---------------------------------------------------------------------------
<bullet> HL7 FHIR Electronic Reporting and Surveillance
Distribution (eRSD) transaction and profiles: <SUP>51</SUP> The HL7
FHIR eRSD profiles support the distribution of reporting guidance and
trigger code value sets from PHAs to healthcare organizations. The eRSD
profiles are specified in the HL7 FHIR eCR IG but are intended to be
used by health IT that supports either CDA or FHIR-based approaches to
electronic case reporting.\52\ The eRSD profiles include an ``eRSD
Specification Library,'' which is composed of a constrained HL7 FHIR
PlanDefinition resource and the Trigger Value Set Library, and an
``eRSD Supplemental Library,'' which is composed of a RuleFilters
library and a Supplemental Value Set library. These can be contained
and transacted via a HL7 FHIR Bundle. The eRSD Specification Library,
which can optionally be used in combination with the eRSD Supplemental
Library, supports the distribution of reporting guidance and
parameters, trigger code value sets, and more complex reporting ru
[…truncated; see source link]Indexed from Federal Register on April 18, 2023.
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.