[Federal Register Volume 90, Number 245 (Monday, December 29, 2025)]
[Proposed Rules]
[Pages 60970-61034]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2025-23896]
[[Page 60969]]
Vol. 90
Monday,
No. 245
December 29, 2025
Part III
Department of Health and Human Services
-----------------------------------------------------------------------
Office of the Secretary
-----------------------------------------------------------------------
45 CFR Parts 170 and 171
Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory
Actions To Unleash Prosperity; Proposed Rule
Federal Register / Vol. 90 , No. 245 / Monday, December 29, 2025 /
Proposed Rules
[[Page 60970]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 170 and 171
RIN 0955-AA09
Health Data, Technology, and Interoperability: ASTP/ONC
Deregulatory Actions To Unleash Prosperity
AGENCY: Assistant Secretary for Technology Policy (ASTP)/Office of the
National Coordinator for Health Information Technology (ONC)
(collectively, ASTP/ONC), Department of Health and Human Services
(HHS).
ACTION: Proposed rule.
-----------------------------------------------------------------------
SUMMARY: This proposed rule focuses on deregulatory actions identified
in HHS regulations regarding Health information technology standards,
implementation specifications, and certification criteria and
certification programs for health information technology, and
information blocking. This proposed rule seeks to reduce burden, offer
flexibility to both developers and providers, and support innovation
through the removal and revisions of certain certification criteria and
regulatory provisions. This proposed rule also seeks to address
reported misuse and abuse of information blocking definitions and
exceptions.
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. Eastern Time on February 27, 2026.
ADDRESSES: You may submit comments, identified by RIN 0955-AA09, 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.
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. http://www.regulations.gov.
Regular, Express, or Overnight Mail: Department of Health
and Human Services, Assistant Secretary for Technology Policy/Office of
the National Coordinator for Health Information Technology, Attention:
Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory
Actions to Unleash Prosperity Proposed Rule, Mary E. Switzer Building,
Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit
one original and two copies.
Hand Delivery or Courier: Assistant Secretary for
Technology Policy/Office of the National Coordinator for Health
Information Technology, Attention: Health Data, Technology, and
Interoperability: ASTP/ONC Deregulatory Actions to Unleash Prosperity
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.)
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
http://www.regulations.gov.
Docket: For access to the docket to read background documents,
comments received, or the plain-language summary of the proposed rule
of not more than 100 words in length required by the Providing
Accountability Through Transparency Act of 2023, go to http://www.regulations.gov or the Department of Health and Human Services,
Assistant Secretary for Technology Policy/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,
Assistant Secretary for Technology Policy/Office of the National
Coordinator for Health Information Technology, 202-690-7151.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Executive Summary
A. Purpose of Deregulatory Action
1. Administration Deregulatory Priorities
2. ASTP/ONC Implementation
a. Certification Program and Information Blocking
b. America's FHIR-Forward Future
B. Summary of Major Provisions
1. Health Information Technology Standards, Implementation
Specifications, and Certification Criteria and Certification
Programs for Health Information Technology (Part 170)
a. Certification Criteria for Health Information Technology
b. Standards and Implementation Specifications for Health
Information Technology
c. Terms and Definitions
d. Conditions and Maintenance of Certification Requirements for
Health IT Developers
e. ONC Health IT Certification Program Administrative
Requirements
2. Information Blocking (Part 171)
C. Severability
D. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation Specifications, and Certification
Criteria
2. Health IT Certification Program
B. Regulatory History
III. Health Information Technology Standards, Implementation
Specifications, and Certification Criteria and Certification
Programs for Health Information Technology (Part 170)
A. Certification Criteria for Health Information Technology
1. Clinical Certification Criteria
a. Patient Demographics
b. Clinical Decision Support
c. Family Health History
d. Implantable Device List
2. Care Coordination Certification Criteria
a. Transitions of Care
b. Clinical Information Reconciliation and Incorporation
c. Security Tags--Summary of Care
d. Care Plan
e. Decision Support Interventions
3. Clinical Quality Measures Certification Criteria
a. Clinical Quality Measures--Report
b. Clinical Quality Measures--Filter
4. Privacy and Security Certification Criteria
5. Patient Engagement Certification Criteria
a. View, Download, and Transmit to a 3rd Party
b. Patient Health Information Capture
6. Public Health Certification Criteria
a. Transmission to Cancer Registries
b. Transmission to Public Health Agencies--Electronic Case
Reporting
c. Transmission to Public Health Agencies--Antimicrobial Use and
Resistance Reporting
d. Transmission to Public Health Agencies--Health Care Surveys
[[Page 60971]]
7. Design and Performance Certification Criteria
a. Automated Numerator Recording
b. Automated Measure Calculation
c. Safety Enhanced Design
d. Quality Management System
e. Accessibility-centered Design
f. Consolidated CDA Creation Performance
g. Application Access--Patient Selection
h. Application Access--All Data Request
8. Transport Methods and Other Protocols Certification Criteria
a. Direct Project
b. Direct Project, Edge Protocol, and XDR/XDM
B. Standards and Implementation Specifications for Health
Information Technology
1. United States Core Data for Interoperability Version 3.1
Update (USCDI v3.1)
a. National Technology Transfer and Advancement Act
b. ``Reasonably Available'' to Interested Parties
2. Standards and Implementation Specifications
C. Terms and Definitions
1. Base EHR
2. Common Clinical Data Set
3. Global Unique Device Identification Database and Production
Identifier
D. Conditions and Maintenance of Certification Requirements for
Health IT Developers
1. Assurances
2. Application Programming Interfaces
3. Real World Testing
4. Attestations
5. Insights
E. ONC Health IT Certification Program Administrative
Requirements
1. Principles of Proper Conduct for ONC-ACBs
2. Health IT Module Certification
3. Certification to Newer Versions of Certain Standards
4. Effect of Revocation on the Certifications Issued to Health
IT Module(s)
IV. Information Blocking (Part 171)
A. ``Access'' and ``Use'' Definitions
B. Infeasibility Exception Revisions
1. Third Party Seeking Modification Use Condition
2. Manner Exception Exhausted Condition
C. Manner Exception
D. Removal of Subpart D Exception and Other Provisions Specific
to TEFCA
V. Incorporation by Reference
VI. Response to Comments
VII. Collection of Information Requirements
A. ONC-ACBs
B. Health IT Developers
VIII. Regulatory Impact Analysis
A. Statement of Need
B. Overall Impact
1. Regulatory Planning and Review Analysis
a. Costs and Benefits
b. Accounting Statement and Table
C. Regulatory Flexibility Act
D. Executive Order 13132--Federalism
E. Unfunded Mandates Reform Act of 1995
I. Executive Summary
A. Purpose of Deregulatory Action
1. Administration Deregulatory Priorities
On January 31, 2025, President Trump issued Executive Order (E.O.)
14192 ``Unleashing Prosperity Through Deregulation,'' \1\ which states
that it is the policy of the Administration to significantly reduce the
private expenditures required to comply with Federal regulations to
secure America's economic prosperity and national security and the
highest possible quality of life for each citizen. ASTP/ONC is issuing
this proposed rule in an effort to streamline and reduce administrative
burdens on health care providers, health information technology (IT)
developers, and the health IT community overall. This proposed rule
would also improve patient and health care provider access to
electronic health information (EHI) and promote health IT and health
care market competition with proposals to revise the information
blocking regulations.
---------------------------------------------------------------------------
\1\ https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation.
---------------------------------------------------------------------------
In order to implement the President's deregulatory initiatives, and
to better promote the health and well-being of the American people, HHS
intends to dramatically expand its deregulatory efforts. An important
component of Making America Healthy Again is making sure that health
care providers and caretakers can focus on preventing and treating
chronic diseases. By proposing to remove duplicative and unnecessary
requirements of the ONC Health IT Certification Program (Certification
Program), we will support providers in caring for their patients.
Developers of certified health IT will have more time to support
providers' specific technological needs. Providers may also have more
health IT choices to meet their needs through increased competition in
the certified health IT market that may come from reduced barriers to
entry for the certification of health IT. Further, proposed revisions
to the information blocking regulations would support health care
providers in using innovative third-party software with their EHRs as
well as their access, exchange, and use of patients' EHI.
2. ASTP/ONC Implementation
a. Certification Program and Information Blocking
Since the inception of the Certification Program, ASTP/ONC has
aimed to implement and administer the Certification Program in the
least burdensome manner that supports an administration's policy goals.
Throughout the years, we have worked to improve the Certification
Program with a focus on ways to reduce burden, offer flexibility to
both developers and providers, and support innovation. Over the past 15
years, we have established a set of regulatory requirements that have
provided a foundation for our voluntary Certification Program. As we
look to the future, there is an opportunity to review the existing
requirements and make updates as needed. Through both formal notice and
comment rulemaking and informal engagements, we have received
suggestions on how to update the Certification Program to meet current
market needs. This proposed rule proposes deregulatory actions that:
take into consideration these suggestions; account for the current and
future state of technology; reduce burden by eliminating redundant
requirements; and promote innovation for health IT developers,
providers, and other interested parties. We have also evaluated the
information blocking regulations and propose the removal of one
exception, removal and revisions of conditions of other exceptions, and
revisions of definitions to better promote EHI access, exchange, and
use. Together, these efforts directly align with Administration goals
as outlined in E.O. 14192 (Unleashing Prosperity through Deregulation)
\2\ and E.O. 14267 (Reducing Anti-Competitive Regulatory Barriers).\3\
---------------------------------------------------------------------------
\2\ https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation.
\3\ https://www.federalregister.gov/documents/2025/04/15/2025-06463/reducing-anti-competitive-regulatory-barriers.
---------------------------------------------------------------------------
b. America's FHIR-Forward Future
Background
In 2012, Health Level Seven (HL7[supreg]) first published for
industry feedback what is now called the Fast Healthcare
Interoperability Resources (FHIR[supreg]) \4\ standard. FHIR aimed to
build on prior HL7 work, including well-established messaging and
document standards (e.g., HL7 Version 2, Clinical Document Architecture
(CDA)). It also sought to improve developer usability and ease of
implementation by leveraging internet[hyphen]scale tooling common to
modern web services. Rooted in a RESTful architectural style,\5\ FHIR
organizes data into granular ``resources'' (e.g., Patient, Observation,
[[Page 60972]]
MedicationRequest) that can be created, read, updated, or deleted
through standard HTTP operations and expressed in formats such as JSON.
FHIR was designed to help reduce implementer variation, allow for
widespread web security conventions to be layered in (e.g., OAuth 2.0,
OpenID Connect, and TLS), and facilitate more incremental adoption
through modularity.
---------------------------------------------------------------------------
\4\ https://hl7.org/fhir/summary.html.
\5\ https://ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf.
---------------------------------------------------------------------------
Since FHIR Draft Standard for Trial Use (DSTU) 1 was officially
published in September 2014, HL7 has iteratively advanced FHIR through
a comprehensive ballot process that combines industry pilots,
Connectathons, and formal community review. In 2015, ONC released the
``2015 Edition Health Information Technology (Health IT) Certification
Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition,
and ONC Health IT Certification Program Modifications'' Final Rule
(2015 Edition Final Rule) (80 FR 62602), which among other
requirements, adopted non-standards-based, functional application
programming interface (API) certification criteria (45 CFR
170.315(g)(7), (8), and (9)). The adoption of these certification
criteria combined with the data elements specified in the ``common
clinical data set'' (CCDS) helped catalyze the industry to focus on
developing a consistent implementation guide for FHIR-based API
deployment in the United States (US). This industry-led effort resulted
in the ``Argonaut Data Query Implementation Guide'' based on FHIR DSTU
2, which became commonly deployed in production and used as the basis
to build early versions of patient access applications with the
potential for nationwide scale.\6\
---------------------------------------------------------------------------
\6\ See https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019; and also https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/.
---------------------------------------------------------------------------
In parallel to this wave of standards development and industry
implementation, API-focused interoperability policy also advanced. The
21st Century Cures Act (Cures Act) (Pub. L. 114-255) was signed into
law at the end of 2016 and ASTP/ONC subsequently engaged in rulemaking
to implement its provisions. This included, among other new policies,
the adoption of a FHIR-based API certification criterion (45 CFR
170.315(g)(10)) and the establishment of an API Condition of
Certification, which focused on the publication of APIs that would
allow EHI ``to be accessed, exchanged, and used without special effort
. . . including providing access to all data elements of a patient's
electronic health record . . .''. On May 1, 2020, ONC published the
``21st Century Cures Act: Interoperability, Information Blocking, and
the ONC Health IT Certification Program'' Final Rule (Cures Act Final
Rule) (85 FR 25642), which adopted a suite of FHIR-based requirements
in the Certification Program. This final rule required support for
HL7's FHIR US Core Implementation Guide (IG) (based on FHIR Release 4
and consistent with United States Core Data for Interoperability
(USCDI) v1 data elements), FHIR Bulk Data Access Implementation Guide,
and HL7[supreg] SMART Application Launch Framework Implementation
Guide. We stated that developers of certified health IT certified to
the applicable criteria were required to upgrade certified health IT to
these FHIR API standards and provide them to their customers by no
later than May 2, 2022, in the Cures Act Final Rule (85 FR 25948). We
then extended the compliance date to December 31, 2022, in the
``Information Blocking and the ONC Health IT Certification Program:
Extension of Compliance Dates and Timeframes in Response to the COVID-
19 Public Health Emergency Interim'' Final Rule (85 FR 70072).
In the years since the Cures Act Final Rule, ASTP/ONC and industry
established an iterative, annual cycle whereby a new USCDI version is
released that then helps inform further data element constraints for a
new version of the FHIR-based US Core IG. This predictable, consistent,
and collaborative approach has been transformative for standards
development and FHIR-based policy making. It has also positioned the US
as a world leader in FHIR adoption and use. Other federal agencies,
such as the Centers for Medicare & Medicaid Services (CMS), Centers for
Disease Control and Prevention (CDC), Food and Drug Administration
(FDA), Health Resources and Services Administration (HRSA), and
National Institutes of Health (NIH) have also pursued FHIR-oriented
regulatory policy and program implementations based on this foundation.
Resetting the Certification Program for a FHIR-Enabled Future
America's interoperability arc in health care has bent decisively
toward FHIR-based APIs. An open, interoperable health data ecosystem
invites entrepreneurship, drives innovation, and cements American
leadership and competitiveness in the expanding digital health
marketplace. As discussed in this deregulatory proposed rule, we
propose to aggressively reduce and remove long-standing functionality-
oriented and non-FHIR-based certification criteria from the
Certification Program. While this approach would directly and rapidly
reduce compliance burdens for health IT developers that participate in
the Certification Program, more broadly, it enables ASTP/ONC to reset
the Certification Program's regulatory scope and establish a new
foundation on which to build FHIR-based API requirements in the future.
This would allow more creative artificial intelligence (AI)-enabled
interoperability solutions that combine FHIR with newer standards to
emerge, such as Model Context Protocol (MCP) which ``standardizes how
applications provide context to Large Language Models (LLMs)'',\7\ and
further embrace the Cures Act's reference to ``. . . successor
technology or standards . . .'' in the API Condition of
Certification.\8\
---------------------------------------------------------------------------
\7\ https://modelcontextprotocol.io/introduction.
\8\ 42 U.S.C. 300jj-11(c)(5)(D)(iv).
---------------------------------------------------------------------------
While FHIR provides the potential for better, faster, and more
consistent ways to address emerging market needs and policy
imperatives, more work is needed for certain use cases. We intend to
continue to fully engage industry and our federal partners, such as
CMS, to rapidly advance FHIR specifications for regulatory readiness.
We also intend to sharpen the Certification Program's future focus to
prioritize FHIR-based APIs that: (1) enhance automation and API
performance; (2) move beyond read-only interactions; and (3) expand the
scope of data available to support clinical efficiency, patient-
centered care, and timely reporting (e.g., public health, quality,
government programs) use cases.
The transition to a FHIR-based API ecosystem is a strategic
imperative and an investment in the US's interoperability future. To
execute this vision, it will require a collective commitment from
policymakers, software developers, clinicians, payers, and patients
alike. Together, we can build interoperable solutions that meet today's
challenges and anticipate tomorrow's opportunities.
In this proposed rule, our proposals remove or revise certain
certification criteria that are consistent with our drive toward and
our support for the FHIR standard, as discussed above. The push toward
universal adoption of FHIR is not just important for secure,
streamlined data access, it is a critical step toward modernizing our
health care system with the ultimate goal of Making America Healthy
Again.
[[Page 60973]]
B. Summary of Major Provisions
1. Health Information Technology Standards, Implementation
Specifications, and Certification Criteria and Certification Programs
for Health Information Technology (Part 170)
a. Certification Criteria for Health Information Technology
We have identified certification criteria for proposed removal or
revision. The removal or revision of the identified certification
criteria would reduce burden and costs for health IT developers and
clinicians, for reasons including but not limited to, eliminating the
need to design and meet specific certification functionalities;
prepare, test, and certify health IT in certain instances; and maintain
conformance to certification requirements. We do not anticipate that
the proposed removals or revisions would alter behavior across product
implementations by health IT developers for the capabilities that have
thus far been included as part of certification criteria in the
Certification Program. We have observed over time that certification is
likely no longer a primary factor driving improvements or compliance in
particular areas, such as with respect to privacy and security.
Generally, at the time of certification, developers have (in some cases
for over a decade) consistently demonstrated for many certification
criteria that their certified health IT can perform required
functionalities in a conformant manner.\9\ Throughout this proposed
rule, we have included proposed revisions and removals of certification
criteria that, among other factors, we believe are no longer necessary
to advance interoperability and no longer provide a strong market
driver for initial adoption and implementation of the certified
functionalities.
---------------------------------------------------------------------------
\9\ https://chpl.healthit.gov/.
---------------------------------------------------------------------------
In total, out of the 60 certification criteria that are currently
in effect, we propose to remove 34 and revise seven. Of the revised
criteria, one of the proposed revisions would reduce the scope of the
``decision support interventions'' certification criterion to fully
remove the artificial intelligence (AI) ``model card'' requirements. We
intend to retain and make no changes to 19 certification criteria,
which include new and revised certification criteria that were adopted
in the Health Data, Technology, and Interoperability: Electronic Prior
Authorization and Real-Time Prescription Benefit (HTI-4) Final Rule (90
FR 37130). This final rule was published as a part of the ``Medicare
Program; Hospital Inpatient Prospective Payment Systems for Acute Care
Hospitals (IPPS) and the Long-Term Care Hospital Prospective Payment
System and Policy Changes and Fiscal Year (FY) 2026 Rates; Changes to
the FY 2025 IPPS Rates Due to Court Decision; Requirements for Quality
Programs; and Other Policy Changes; Health Data, Technology, and
Interoperability: Electronic Prescribing, Real-Time Prescription
Benefit and Electronic Prior Authorization'' (FY2026 IPPS/LTCH PPS)
Final Rule, which was published by CMS on August 4, 2025 (90 FR 36536).
b. Standards and Implementation Specifications for Health Information
Technology
In some instances where we propose to remove or revise a certain
certification criterion, we also propose to remove the standard(s) that
is referenced by the certification criterion. In some cases, we propose
to remove standards consistent with a certification criterion
transition period until January 1, 2027. In very limited circumstances,
we retain a standard referenced in a certification criterion proposed
for removal for purposes of health IT interoperability alignment.\10\
We also propose to remove standards that are outdated and no longer
referenced in the Certification Program. Lastly, we propose to adopt
USCDI v3.1 in Sec. 170.213.
---------------------------------------------------------------------------
\10\ Section 13111 and 13112 of the HITECH Act requires health
IT systems and products to utilize standards adopted under section
3004 of the PHSA in specified circumstances. The HHS Health IT
Alignment Program, led by ASTP/ONC builds upon the HITECH to advance
interoperability across HHS investments. See https://www.healthit.gov/topic/hhs-health-it-alignment-program.
---------------------------------------------------------------------------
c. Terms and Definitions
Because of the proposed removal of certain certification criteria
as discussed above, we propose to make conforming edits to the terms
and definitions in Sec. 170.102. We propose to revise the definition
of ``Base EHR'' to remove references to criteria that we have proposed
to remove from the Code of Federal Regulations (CFR). We also propose
to remove the definitions of ``Common Clinical Data Set,'' ``Global
Unique Device Identification Database (GUDID),'' and ``Production
Identifier'' because these terms are no longer referenced in 45 CFR
part 170.
d. Conditions and Maintenance of Certification Requirements for Health
IT Developers
We propose to make conforming edits for several Conditions and
Maintenance of Certification requirements, including the ``Assurances''
(Sec. 170.402), ``Application Programming Interfaces'' (Sec.
170.404), and ``Attestations'' (Sec. 170.406) Conditions and
Maintenance of Certification requirements. In addition to conforming
edits, we also propose to descope the ``Real World Testing'' Condition
and Maintenance of Certification requirements (Sec. 170.405) with
deregulatory actions related to real world testing plans, results, and
the use of the standards version advancement process (SVAP). These
proposals are consistent with the enforcement discretion notice we
issued on June 30, 2025.\11\ Lastly, we propose to remove and descope
measures associated with the ``Insights'' Condition and Maintenance of
Certification requirements (Sec. 170.407), consistent with the
enforcement discretion we issued on April 29, 2025,\12\ to limit
reporting requirements only to the ``use of FHIR in apps through
certified health IT'' measure.
---------------------------------------------------------------------------
\11\ https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement.
\12\ https://www.healthit.gov/topic/insights-condition-and-maintenance-certification-enforcement-discretion-notice.
---------------------------------------------------------------------------
e. ONC Health IT Certification Program Administrative Requirements
We propose to make conforming edits, to remove references to
certification criteria that we propose to remove in this proposed rule,
in subpart E of 45 CFR part 170. Specifically, in Sec. Sec. 170.523,
170.550, 170.555, and 170.570.
2. Information Blocking (Part 171)
We propose to revise the Sec. 171.102 ``access'' and ``use''
definitions to emphasize that the definitions include automated means
of access, exchange, or use of EHI--including, without limitation,
autonomous AI systems. As an alternative proposal, we propose, in
addition to updating the ``access'' and ``use'' definitions, to revise
the ``exchange'' definition in a similar manner.
We propose to remove the third party seeking modification use
condition from the Infeasibility Exception (Sec. 171.204(a)(3)). This
condition is susceptible to misuse by actors withholding EHI to
unnecessarily inhibit access, exchange, and use of EHI by third parties
that patients and health care providers want. Where any requested
access, exchange, or use of EHI poses concerns such as specific threats
to the confidentiality, integrity, or availability of the EHI involved,
this condition is unnecessary. Activities reasonable and necessary to
address
[[Page 60974]]
those concerns are covered by other exceptions.
We propose to revise or, in the alternative, remove the manner
exception exhausted condition (Sec. 171.204(a)(4)) from the
Infeasibility Exception. Similar to the third party seeking
modification use condition (Sec. 171.204(a)(3)), we believe this
condition as currently codified is susceptible to misuse by actors
holding EHI to unnecessarily inhibit access, exchange, and use of EHI.
The revisions we propose to the manner exception exhausted condition
(Sec. 171.204(a)(4)) would narrow its application to better align with
our intent for this condition and reduce the risk of an actor misusing
it. In the alternative, we propose to remove the entire condition to
address our concerns.
We propose to revise the Manner Exception's manner requested
condition (Sec. 171.301(a)) to ensure that it is clear that the Manner
Exception cannot be met with contracts that are not market rate, are
contracts of adhesion, or are contracts containing unconscionable
terms.
We propose to remove subpart D from 45 CFR part 171, which includes
the Trusted Exchange Framework and Common Agreement\TM\ (TEFCA\TM\)
Manner Exception (Sec. 171.403) and associated definitions. Based on
TEFCA's continued implementation, maturation, and public comments
received--including those received in response to the CMS-ASTP/ONC
Request for Information; Health Technology Ecosystem (90 FR 21034)
(CMS-ASTP/ONC RFI)--we believe the removal of the TEFCA Manner
Exception (Sec. 171.403) is appropriate.
C. Severability
It is our intent that if any provision of this rule were, if or
when finalized, held to be invalid or unenforceable facially, or as
applied to any person, plaintiff, or stayed pending further judicial or
agency action, such provision shall be severable from other provisions
of this rule, and from rules and regulations currently in effect, and
not affect the remainder of this rule. It is also our intent that,
unless such provision shall be held to be utterly invalid or
unenforceable, it be construed to give the provision maximum effect
permitted by law including in the application of the provision to other
persons not similarly situated or to other, dissimilar circumstances
from those where the provision may be held to be invalid or
unenforceable.
In this rule, we propose provisions that are intended to and will
operate independently of each other, even if multiple of them serve the
same or similar general purpose(s) or policy goal(s). Where a provision
is necessarily dependent on another, the context generally makes that
clear (such as by cross-reference to a particular standard,
requirement, condition, or pre-requisite). Where a provision that is
dependent on one that is stayed or held invalid or unenforceable (as
described in the preceding paragraph) is included in a subparagraph,
paragraph, or section within part 170 or 171 of 45 CFR, we intend that
other provisions of such subparagraph(s), paragraph(s), or section(s)
that operate independently of said provision would remain in effect.
For example, if any proposed revision of any section or paragraph
of part 170, if finalized, were stayed or held utterly invalid or
unenforceable, we would intend for all other finalized revisions in
part 170 that do not depend upon the stayed or invalidated revision to
remain in full effect. To illustrate, if a removal of a certification
criterion were to be finalized and then held to be entirely invalid or
unenforceable, any corresponding removal of a cross-reference to that
provision would depend on that revision and would be affected by the
holding of invalidity or unenforceability. But in direct contrast, any
revision to any other certification criterion or other Certification
Program requirement or provision codified in part 170 that is not made
based specifically on the removal of the certification criterion for
which removal was held invalid or unenforceable, is intended to remain
in full effect even if both revisions were proposed in this same
proposed rule and were to be finalized in a single final rule.
To provide another example, if we were to finalize the proposed
removal of paragraph (a)(3) from Sec. 171.204 (the Infeasibility
Exception), and the removal of this paragraph was stayed or held
facially invalid or unenforceable in whole or in part, we would intend
for other finalized revisions in part 171, including without limitation
the proposed revision or, in the alternative, removal of paragraph
(a)(4) from Sec. 171.204 (the Infeasibility Exception) to continue in
effect. Each of the conditions (subparagraphs) within Sec. 171.204(a)
is designed to stand independent of any and every other subparagraph in
Sec. 171.204(a). Moreover, each information blocking exception is
intended and designed to stand independent of any and every other
exception unless any specific provision of an exception might
explicitly reference another exception. Likewise, any dependency on
cross-referenced provision(s) is intended to be limited to the exact
provision, or function of such provision, that relies upon the cross-
reference. For example, paragraph (a)(4) in Sec. 171.204 cross-
references subparagraphs (1)(i) and (1)(ii) in Sec. 171.301(b) (the
Manner Exception's alternative manner condition). If either Sec.
171.301(b)(1)(i) or (ii) were to be held facially invalid or
unenforceable, paragraph (a)(4) in Sec. 171.204 as currently codified
is intended to remain in effect, including with respect to its cross-
references to Sec. 171.301(b) as a whole and to whichever of the
cross-referenced paragraphs ((i) or (ii)) in Sec. 171.301(b)(1) was
not held facially invalid or unenforceable.
If any revision to any provision of part 170 or 171 (such as the
removal or revision of a specific condition within one information
blocking exception in part 171 or a revision to a certification
criterion in part 170) were stayed or held to be invalid or
unenforceable as applied to any person, plaintiff, or circumstance, it
is our intent that such provision--and any section or paragraph of part
171 or 170 that may reference such provision--be construed to give the
provision maximum effect permitted by law including in the application
of the provision to other persons not similarly situated or to other,
dissimilar circumstances from those where the provision may be held to
be invalid or unenforceable.
D. Costs and Benefits
The Regulatory Impact Analysis (RIA) includes an updated analysis
of the costs and benefits associated with the proposals in this
proposed rule. The proposed deregulatory actions provide substantial
relief for developers of certified health IT and significant cost
savings realized from the revision and removal of certain Certification
Program requirements. The cost savings have been estimated using the
best available data and modeled on the costs estimated and finalized in
prior ASTP/ONC rulemakings. The proposed deregulatory actions reduce
the effort of developers of certified health IT to meet ongoing
Certification Program requirements and reduce entry barriers for new
Certification Program participants. The proposed actions, importantly,
return effort back to developers of certified health IT to innovate
with their technology, improve interoperability and third-party
integration, and focus on the needs of their customers. We do not
expect costs to be associated with these deregulatory proposals. We
expect the proposed deregulatory actions to result in significant
benefits for health IT developers, providers, ONC-Authorized
Certification Bodies (ONC-
[[Page 60975]]
ACBs), ONC-Authorized Testing Laboratories (ONC-ATLs), and ASTP/ONC.
Generally, these benefits are in the form of cost and time savings and
reductions in administrative burden to comply with Certification
Program requirements. The proposed actions reduce the scope and breadth
of Certification Program requirements.
The analysis included in this proposed rule indicates that the
proposed updates to the Certification Program would result in $0 in
implementation costs on developers of certified health IT. However, we
do estimate some costs for reviewers who review this proposed rule. We
estimate those costs to be $284,132 in total for an estimated 644
reviewers, which include developers and medical associations. We do not
quantify benefits for this proposed rule and instead rely on our
calculation of cost savings to developers of certified health IT to
quantify in dollars the time and effort developers would have expended
had these requirements remained in effect in perpetuity. In total, this
proposed rulemaking would result in a present value of cost savings of
$1.53 billion in 2024 dollars and discounted at a rate of 7%, beginning
in 2027 and in perpetuity.
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 health care quality,
safety, and efficiency through the promotion of health IT and
electronic health information (EHI) exchange.
The 21st Century Cures Act (Pub. L. 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.
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 in 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
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 in 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. Overall, 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. The HITECH Act also indicates that the development
of this conformance testing infrastructure may include a program to
accredit independent, non-federal laboratories to perform testing.
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 Certification
Program. Specifically, the health IT developers or entities with
technology certified under the Certification Program must, in order to
maintain such certification status, adhere to certain conditions and
[[Page 60976]]
maintenance of certification requirements concerning information
blocking; assurances regarding appropriate exchange, access, and use of
electronic health information; communications regarding health IT;
APIs; real world testing; attestations regarding certain conditions and
maintenance of certification requirements; and submission of reporting
criteria under the EHR Reporting Program in accordance with section
3009A(b) of the PHSA.
B. Regulatory History
The Secretary issued an interim final rule with request for
comments on January 13, 2010, ``Health Information Technology: Initial
Set of Standards, Implementation Specifications, and Certification
Criteria for Electronic Health Record Technology'' (the ``S&CC January
2010 Interim Final Rule'') (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).
After consideration of the comments received on the S&CC January
2010 Interim Final Rule, a final rule was issued to complete the
adoption of the initial set of standards, implementation
specifications, and certification criteria and realign them with the
final objectives and measures established for the EHR Incentive
Programs Stage 1, titled ``Health Information Technology: Initial Set
of Standards, Implementation Specifications, and Certification Criteria
for Electronic Health Record Technology'' (75 FR 44590, July 28, 2010)
(2011 Edition Final Rule). The 2011 Edition Final Rule also established
the first version of the certified electronic health record technology
(CEHRT) definition. Subsequent to the 2011 Edition Final Rule, on
October 13, 2010, we issued an interim final rule ``Health Information
Technology: Revisions to Initial Set of Standards, Implementation
Specifications, and Certification Criteria for Electronic Health Record
Technology'' with a request for comment to remove certain
implementation specifications related to public health surveillance
that had been previously adopted in the 2011 Edition Final Rule (75 FR
62686).
The standards, implementation specifications, and certification
criteria adopted by the Secretary in the 2011 Edition Final Rule
established the capabilities that CEHRT must include in order to, at a
minimum, support the achievement of EHR Incentive Programs Stage 1 by
eligible professionals (EPs), eligible hospitals, and critical access
hospitals (CAHs) under the ``Medicare and Medicaid Programs; Electronic
Health Record Incentive Program'' final rule (75 FR 44314, July 28,
2010) (EHR Incentive Programs Stage 1 Final Rule).
On March 7, 2012, the Secretary issued a proposed rule with request
for comments titled ``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) (2014 Edition Proposed Rule), which proposed new and revised
standards, implementation specifications, and certification criteria.
After consideration of the comments received on the 2014 Edition
Proposed Rule, a final rule titled ``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 54163) (2014 Edition Final Rule) was issued on September 4, 2012, to
adopt the 2014 Edition set of standards, implementation specifications,
and certification criteria and realign them with the final objectives
and measures established for the EHR Incentive Programs Stage 2, as
well as Stage 1 revisions. The 2014 Edition Final Rule adopted a
proposal to change the Permanent Certification Program's name to the
``ONC HIT Certification Program,'' revised the process for permitting
the use of newer versions of ``minimum standard'' code sets, modified
the certification processes ONC-ACBs need to follow for certifying EHR
Modules in a manner that provides clear implementation direction and
compliance with the new certification criteria, and eliminated the
certification requirement that every EHR Module be certified to the
``privacy and security'' certification criteria.
The standards, implementation specifications, and certification
criteria adopted by the Secretary in the 2014 Edition Final Rule
established the capabilities that CEHRT must include in order to, at a
minimum, support the achievement of the EHR Incentive Programs Stage 2
by EPs, eligible hospitals, and CAHs under the ``Medicare and Medicaid
Programs; Electronic Health Record Incentive Program--Stage 2'' final
rule (77 FR 53968, September 4, 2012) (EHR Incentive Programs Stage 2
Final Rule).
On December 7, 2012, an interim final rule with a request for
comment, titled ``Health Information Technology: Revisions to the 2014
Edition Electronic Health Record Certification Criteria; and Medicare
and Medicaid Programs; Revisions to the Electronic Health Record
Incentive Program'' (77 FR 72985), was jointly issued and published by
ONC and CMS to update certain standards that had been previously
adopted in the 2014 Edition Final Rule. The interim final rule also
revised the EHR Incentive Programs by adding an alternative measure for
the Stage 2 objective for hospitals to provide structured electronic
laboratory results to ambulatory providers, corrected the regulation
text for the measures associated with the objective for hospitals to
provide patients the ability to view online, download, and transmit
information about a hospital admission, and made the case number
threshold exemption policy for clinical quality measure (CQM) reporting
applicable for eligible hospitals and CAHs beginning with FY 2013. In
addition, the interim final rule provided notice of CMS's intent to
issue technical corrections to the electronic specifications for CQMs
released on October 25, 2012. On September 4, 2014, a final rule
``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 52910) was
published adopting these proposals.
On November 4, 2013, the Secretary published an interim final rule
with a request for comment titled ``2014 Edition Electronic Health
Record Certification Criteria: Revision to the Definition of `Common
Meaningful Use (MU) Data Set' '' (78 FR 65884) to make a minor revision
to the Common MU Data Set definition. This revision was intended to
allow more flexibility with respect to the representation of dental
[[Page 60977]]
procedures data for EHR technology testing and certification.
On February 26, 2014, the Secretary published a proposed rule
titled ``Voluntary 2015 Edition Electronic Health Record (EHR)
Certification Criteria; Interoperability Updates and Regulatory
Improvements'' (79 FR 10880) (``Voluntary Edition Proposed Rule''). The
proposed rule proposed a voluntary edition of certification criteria
that was designed to enhance interoperability, promote innovation, and
incorporate ``bug fixes'' to improve upon the 2014 Edition. The
Voluntary Edition Proposed Rule also included proposals that focused on
improving regulatory clarity, simplifying the certification of EHR
Modules that are designed for purposes other than meeting requirements
of the EHR Incentive Programs, and discontinuing the use of the
Complete EHR definition. A correction notice was published for the
Voluntary Edition Proposed Rule on March 19, 2014, entitled ``Voluntary
2015 Edition Electronic Health Record (EHR) Certification Criteria;
Interoperability Updates and Regulatory Improvements; Correction'' (79
FR 15282). This correction notice corrected the preamble text and gap
certification table for four certification criteria that were omitted
from the list of certification criteria eligible for gap certification
for the 2015 Edition EHR certification criteria. On September 11, 2014,
a final rule was published titled ``2014 Edition Release 2 Electronic
Health Record (EHR) Certification Criteria and the ONC HIT
Certification Program; Regulatory Flexibilities, Improvements, and
Enhanced Health Information Exchange'' (79 FR 54430) (2014 Edition
Release 2 Final Rule). The final rule adopted a small subset of the
original proposals in the Voluntary Edition Proposed Rule as optional
and revised 2014 Edition EHR certification criteria that provide
flexibility, clarity, and enhance health information exchange. It also
finalized administrative proposals (i.e., removal of regulatory text
from the CFR) and proposals for the ONC HIT Certification Program that
provide improvements. We issued the 2014 Edition Release 2 Final Rule
to complete the rulemaking for the Voluntary Edition Proposed Rule. The
2014 Edition Release 2 Final Rule discontinued the ``Complete EHR''
certification concept beginning with the proposed 2015 Edition, adopted
an updated standard (ISO/IEC 17065) for the accreditation of ONC-ACBs,
and adopted the ``ONC Certified HIT'' certification and design mark for
required use by ONC-ACBs under the Certification Program.
On May 23, 2014, CMS and ONC jointly published a proposed rule
titled ``Medicare and Medicaid Programs; Modifications to the Medicare
and Medicaid Electronic Health Record Incentive Programs for 2014; and
Health Information Technology: Revisions to the Certified EHR
Technology Definition'' (79 FR 29732). The proposed rule proposed to
update the EHR Incentive Programs Stage 2 and Stage 3 participation
timeline. It proposed to revise the CEHRT definition to permit the use
of EHR technology certified to the 2011 Edition to meet the CEHRT
definition for FY/CY 2014. It also proposed to allow EPs, eligible
hospitals, and CAHs that could not fully implement EHR technology
certified to the 2014 Edition for an EHR reporting period in 2014 due
to delays in the availability of such technology to continue to use EHR
technology certified to the 2011 Edition or a combination of EHR
technology certified to the 2011 Edition and 2014 Edition for the EHR
reporting periods in CY 2014 and FY 2014. On September 4, 2014, a final
rule 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'' (CEHRT
Flexibility Final Rule) was published (79 FR 52910) adopting these
proposals.
On March 30, 2015, the Secretary published a proposed rule titled
``2015 Edition Health Information Technology (Health IT) Certification
Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition,
and ONC Health IT Certification Program Modifications'' (80 FR 16804)
(2015 Edition Proposed Rule). The 2015 Edition Proposed Rule proposed
revisions to the Certification Program with a revised edition of
certification criteria that was designed to enhance interoperability.
On October 16, 2015, the Secretary published a final rule titled
``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 2015 Edition Final Rule established a new
edition of certification criteria (2015 Edition) and a new 2015 Edition
Base EHR definition. CMS subsequently established the 2015 Edition Base
EHR definition as encompassing the minimum capabilities and the related
minimum standards and implementation specifications that CEHRT would
need to include to support the achievement of ``meaningful use'' by
eligible clinicians, eligible hospitals, and CAHs under the Medicare
and Medicaid EHR Incentive Programs (the predecessors to the Medicare
Promoting Interoperability Program and the Promoting Interoperability
performance category under the Merit-based Incentive Payment System
(MIPS)). The final rule also adopted a proposal to change the
Certification Program's name to the ``ONC Health IT Certification
Program'' from the ONC HIT Certification Program, modified the
Certification 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-
ACBs. A final rule making corrections and clarifications was published
for the 2015 Edition Final Rule (80 FR 76868) on December 11, 2015, to
correct preamble and regulatory text errors and clarify requirements of
the CCDS, the 2015 Edition privacy and security certification
framework, and the mandatory disclosures for health IT developers.
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 Certification Program,
including provisions related to our role in the Certification Program.
The EOA Final Rule created a regulatory framework for our direct review
of health IT certified under the Certification Program, including, when
necessary, requiring the correction of non-conformities found in health
IT certified under the Certification 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 Certification
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
[[Page 60978]]
7424) (Cures Act Proposed Rule). The proposed rule proposed to
implement certain provisions of the 21st Century Cures Act (Cures Act)
that would advance interoperability and support the access, exchange,
and use of electronic health information.
On May 1, 2020, the Cures Act Final Rule was published in the
Federal Register (85 FR 25642). The final rule implemented certain
provisions of the Cures Act, including Conditions and Maintenance of
Certification requirements for 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 electronic health information
(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
Certification Program in other ways to advance interoperability,
enhance health IT certification, and reduce burden and costs, as well
as to improve patient and health care provider access to EHI and
promote 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 Cures Act Final Rule to offer the health care 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 April 18, 2023, the Secretary published a proposed rule titled
``Health Data, Technology, and Interoperability: Certification Program
Updates, Algorithm Transparency, and Information Sharing'' (88 FR
23746) (HTI-1 Proposed Rule). The HTI-1 Proposed Rule proposed to
implement the EHR Reporting Program provision of the Cures Act by
establishing new Conditions and Maintenance of Certification
requirements for health IT developers under the Certification Program.
The HTI-1 Proposed Rule also proposed several updates to certification
criteria and implementation specifications recognized by the
Certification Program, including revised certification criteria for:
``clinical decision support,'' ``patient demographics and
observations,'' and ``electronic case reporting.'' The HTI-1 Proposed
Rule also proposed to establish a new baseline version of the USCDI.
Additionally, the HTI-1 Proposed Rule also proposed enhancements to
support information sharing under the information blocking regulations.
On January 9, 2024, the Secretary issued the ``Health Data,
Technology, and Interoperability: Certification Program Updates,
Algorithm Transparency, and Information Sharing'' final rule (HTI-1
Final Rule), which implemented the EHR Reporting Program provision of
the 21st Century Cures Act and established new Conditions and
Maintenance of Certification requirements for health IT developers
under the Certification Program (89 FR 1192). The HTI-1 Final Rule also
made several updates to certification criteria and standards recognized
by the Certification Program. The Certification Program updates
included revised certification criteria for ``decision support
interventions'' (DSIs), ``patient demographics and observations,'' and
``electronic case reporting,'' as well as adopted a new baseline
version of the USCDI standard, USCDI Version 3 (v3). Additionally, the
HTI-1 Final Rule provided enhancements to support information sharing
under the information blocking regulations. Through these provisions,
we sought to advance interoperability, improve algorithm transparency,
and support the access, exchange, and use of EHI. The HTI-1 Final Rule
also updated numerous technical standards in the Certification Program
to advance interoperability, enhance health IT certification, and
reduce burden and costs for health IT developers and users of health
IT.
On August 5, 2024, the Secretary published a proposed rule titled
``Health Data, Technology, and Interoperability: Patient Engagement,
Information Sharing, and Public Health Interoperability'' (89 FR 63498)
(HTI-2 Proposed Rule). The HTI-2 Proposed Rule sought to advance
interoperability, improve transparency, and support the access,
exchange, and use of EHI through proposals for: standards adoption;
adoption of certification criteria to advance public health data
exchange; expanded uses of certified APIs, such as for electronic prior
authorization, patient access, care management, and care coordination;
and information sharing under the information blocking regulations.
Additionally, the HTI-2 Proposed Rule proposed to establish a new
baseline version of the USCDI standard and proposed to update the
Certification Program to enhance interoperability and optimize
certification processes to reduce burden and costs. The HTI-2 Proposed
Rule also proposed to implement certain provisions related to TEFCA,
which would support the reliability, privacy, security, and trust
within TEFCA.
On December 16, 2024, the Secretary issued the ``Health Data,
Technology, and Interoperability: Trusted Exchange Framework and Common
Agreement (TEFCA)'' final rule (89 FR 101772) (HTI-2 Final Rule) which
implemented advancements to interoperability, improved transparency,
and supported the access, exchange, and use of electronic health
information. The HTI-2 Final Rule codified definitions of certain TEFCA
terms in Sec. 171.401 of the information blocking regulations and
finalized the 45 CFR part 172 TEFCA provisions.
On December 17, 2024, the Secretary issued the ``Health Data,
Technology, and Interoperability: Protecting Care Access'' final rule
(89 FR 102512) (HTI-3 Final Rule). The HTI-3 Final Rule finalized
certain proposals from the HTI-2 Proposed Rule to support the access,
exchange, and use of EHI. The final rule amended the information
blocking regulations to revise two existing information blocking
exceptions and established an additional reasonable and necessary
activity that does not constitute information blocking referred to as
the Protecting Care Access Exception.
On July 31, 2025, ASTP/ONC finalized the ``Health Data, Technology,
and Interoperability: Electronic Prescribing, Real-Time Prescription
Benefit and Electronic Prior Authorization'' final rule (90 FR 37130)
(HTI-4 Final Rule), as a part of the FY2026 IPPS/LTCH PPS Final Rule,
published by CMS on August 4, 2025 (90 FR 36536). The HTI-4 Final Rule
finalized a limited subset of the proposals in the HTI-2 Proposed Rule
(89 FR 63498) and focused on improving care delivery and reducing
administrative burden through the exchange of clinical and
administrative information. The HTI-4 Final Rule updated the ONC Health
IT Certification Program to add several new certification criteria that
advance health care providers' ability to engage in electronic
prescribing, real-time prescription benefit checks, and electronic
prior authorization.
[[Page 60979]]
III. Health Information Technology Standards, Implementation
Specifications, and Certification Criteria and Certification Programs
for Health Information Technology (Part 170)
Reading This Proposed Rule
In this preamble, we present our proposals in an order that begins
with the certification criteria we propose to remove and subsequently
the standards, definitions, and other related Certification Program
provisions proposed for removal or revision. This approach should make
it easier for readers to follow our proposed Certification Program
removals, in part, due to the natural cascading effects of proposing to
remove or revise a certification criterion. For example, we propose to
remove the ``application access--all data request'' certification
criterion in 45 CFR 170.315(g)(9), the referenced HL7 CDA R2
Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion
guide, Release 2-US Realm, October 2019 (45 CFR 170.205(a)(5)), and the
``application access--all data request'' certification criterion from
the Base EHR definition. In some cases, we propose to remove a standard
consistent with a certification criterion transition period until
January 1, 2027. In very limited circumstances, we retain a standard
that is cross-referenced in a certification criterion that we propose
to remove. We do this because the standard is cross-referenced in
another criterion and/or supports health IT interoperability alignment.
For example, although we propose to remove the ``transport methods and
other protocols'' certification criteria in Sec. 170.315(h), we
propose to retain the Direct Project transport standard adopted in
Sec. 170.202(a)(2) because we believe keeping the primary Direct
Project standard would acknowledge the current utilization of the
Direct standard, while removing the certification criteria in Sec.
170.315(h) recognizes the ongoing technological advancements related to
transport, including movement toward FHIR-based standards, and would
encourage and provide space for further innovation and market
competition in this area. We also propose to remove the certification
criteria in Sec. 170.315(h) from the ``Base EHR'' definition.
Additionally, we solely propose to remove standards when they are no
longer referenced by existing certification criteria. Further, as noted
above, we propose to remove certain Conditions and Maintenance of
Certification requirements and other Certification Program
requirements.
RFI Feedback
Recently, the Office of Management and Budget (OMB), the
Department, and CMS-ASTP/ONC issued requests for information (RFIs)
related to deregulation. We reviewed comments related to ASTP/ONC. In
response to the CMS-ASTP/ONC Request for Information; Health Technology
Ecosystem (90 FR 21034) (CMS-ASTP/ONC RFI), commenters expressed a
strong desire to modernize the Certification Program to be more
modular, API-focused, and less centered on specific EHR
functionalities. Commenters recommended simplifying the process,
reducing costs, and expanding certification requirements to ensure
payers and other health IT systems adhere to the same interoperability
standards. There was an overwhelming demand to strengthen, expand, and
mandate the use of FHIR-based APIs. Commenters strongly advocated for
retiring outdated, less efficient standards to reduce complexity. A
central theme from commenters was the need for regulatory modernization
to reduce administrative and financial burdens on providers and
technology developers. Commenters also expressed concern that existing
certification requirements are often too rigid, costly, and not aligned
with emerging care models like value-based care or specialized
technologies such as AI and remote monitoring. A commenter that
responded to the HHS RFI expressed concerns with the Real World Testing
and Insights Conditions of Certification, stating that the requirements
are overly burdensome and offer limited value to providers or patients.
The commenter also recommended retiring low-value certification
criteria requirements that add complexity without improving care. A
commenter that responded to the OMB RFI suggested that revisions could
be made to the Conditions and Maintenance of Certification requirements
that focus on streamlined and meaningful oversight without placing
undue demands on developers, especially where those demands offer
limited direct benefit to health care provider customers or their
patients. The commenter also suggested the removal of ``non-
interoperability-focused, redundant, or valueless'' criteria and focus
on promoting standardized and scalable interoperability. ASTP/ONC
addresses a number of these comments in the proposals below,
specifically the suggestions to remove non-interoperability-focused and
redundant certification criteria. Commenters were strongly supportive
of our focus on FHIR-based standards. Some commenters, however,
included suggestions related to new regulatory actions. These
suggestions are out of scope for this proposed deregulatory rule, but
we may consider the suggestions for a future rulemaking.
A. Certification Criteria for Health Information Technology
In this proposed rule we have identified certification criteria for
removal or revision. For some of the criteria below, we justify
removing the certification criteria because they have been ``widely
adopted'' or ``widely implemented.'' To determine if the certification
criterion is ``widely adopted'' or ``widely implemented,'' we
considered whether and for how long the certification criterion has
been included in the Base EHR definition in Sec. 170.102, or the
Certified Electronic Health Record Technology (CEHRT) definitions
established by CMS in 42 CFR 495.4 and 414.1305. The CEHRT definitions
incorporate the Base EHR definition and may also incorporate
certification criteria necessary to report applicable objectives and
measures under the Medicare Promoting Interoperability (PI) Program or
the Promoting Interoperability performance category in the Merit-based
Incentive Payment System (MIPS), certification criteria determined
applicable for an Alternative Payment Model (APM), and other
certification criteria as specified. To participate in the Promoting
Interoperability Program and the MIPS Promoting Interoperability
performance category, eligible hospitals, CAHs, and eligible clinicians
must use CEHRT as specified by the applicable definition. In addition,
CEHRT is required for the purposes of determinations under 42 CFR
414.1415 and 414.1420 regarding Advanced APM status. ASTP/ONC tracks
and publishes data on the adoption and use of health IT, including
CEHRT, by US hospitals and office-based physicians. Our most recent
survey data from 2021 shows that 96 percent of hospitals and 78 percent
of physicians reported having a certified EHR.\13\ As discussed in more
detail below, we provide this analysis and consider certain
certification criteria as ``widely adopted'' or ``widely implemented''
because they are included in the Base EHR or CEHRT definitions and
adopted by 96 and 78 percent of hospitals and physicians, respectively.
Our proposals to remove or
[[Page 60980]]
revise certain certification criteria are also consistent with our
drive toward and our support for the FHIR standard as mentioned above
in section I.A and are responsive to comments we received on the
recently issued RFIs. We explain our proposals in detail in their
respective sections of the preamble and have provided a table (see
Table 1) for a list of all proposed certification criteria removals and
revisions.
---------------------------------------------------------------------------
\13\ https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.
Table 1--Proposed Removals or Revisions of Certification Criteria
----------------------------------------------------------------------------------------------------------------
Certification criteria Reference Remove/revise Timing
----------------------------------------------------------------------------------------------------------------
Patient demographics and Sec. 170.315(a)(5).. Revise...................... Effective date of
observations. final rule.
Clinical decision support.......... Sec. 170.315(a)(9).. Remove...................... Effective date of
final rule.
Family health history.............. Sec. 170.315(a)(12). Remove...................... Effective January 1,
2027.
Implantable device list............ Sec. 170.315(a)(14). Remove...................... Effective date of
final rule.
Transitions of care................ Sec. 170.315(b)(1).. Revise...................... Effective January 1,
2027.
Clinical information reconciliation Sec. 170.315(b)(2).. Remove...................... Effective January 1,
and incorporation. 2027.
Security tags--summary of care-- Sec. 170.315(b)(7).. Remove...................... Effective date of
send. final rule.
Security tags--summary of care-- Sec. 170.315(b)(8).. Remove...................... Effective date of
receive. final rule.
Care plan.......................... Sec. 170.315(b)(9).. Remove...................... Effective date of
final rule.
Decision support interventions..... Sec. 170.315(b)(11). Revise...................... Effective date of
final rule.
Clinical quality measures--report.. Sec. 170.315(c)(3).. Revise...................... Effective date of
final rule.
Clinical quality measures--filter.. Sec. 170.315(c)(4).. Remove...................... Effective January 1,
2027.
Authentication, access control, Sec. 170.315(d)(1).. Remove...................... Effective date of
authorization. final rule.
Auditable events and tamper- Sec. 170.315(d)(2).. Remove...................... Effective date of
resistance. final rule.
Audit report(s).................... Sec. 170.315(d)(3).. Remove...................... Effective date of
final rule.
Amendments......................... Sec. 170.315(d)(4).. Remove...................... Effective date of
final rule.
Automatic access time-out.......... Sec. 170.315(d)(5).. Remove...................... Effective date of
final rule.
Emergency access................... Sec. 170.315(d)(6).. Remove...................... Effective date of
final rule.
End-user device encryption......... Sec. 170.315(d)(7).. Remove...................... Effective date of
final rule.
Integrity.......................... Sec. 170.315(d)(8).. Remove...................... Effective date of
final rule.
Trusted connection................. Sec. 170.315(d)(9).. Remove...................... Effective date of
final rule.
Auditing actions on health Sec. 170.315(d)(10). Remove...................... Effective date of
information. final rule.
Accounting of disclosures.......... Sec. 170.315(d)(11). Remove...................... Effective date of
final rule.
Encrypt authentication credentials. Sec. 170.315(d)(12). Remove...................... Effective date of
final rule.
Multi-factor authentication........ Sec. 170.315(d)(13). Remove...................... Effective date of
final rule.
View, download, and transmit to 3rd Sec. 170.315(e)(1).. Revise...................... Effective data of
party. final rule.
Patient health information capture. Sec. 170.315(e)(3).. Remove...................... Effective January 1,
2027.
Transmission to cancer registries.. Sec. 170.315(f)(4).. Remove...................... Effective January 1,
2027.
Transmission to public health Sec. 170.315(f)(5).. Revise...................... Effective date of
agencies--electronic case final rule.
reporting.
Transmission to public health Sec. 170.315(f)(6).. Revise...................... Effective date of
agencies--antimicrobial use and final rule.
resistance reporting.
Transmission to public health Sec. 170.315(f)(7).. Remove...................... Effective January 1,
agencies--health care surveys. 2027.
Automated numerator recording...... Sec. 170.315(g)(1).. Remove...................... Effective January 1,
2027.
Automated measure calculation...... Sec. 170.315(g)(2).. Remove...................... Effective January 1,
2027.
Safety-enhanced design............. Sec. 170.315(g)(3).. Remove...................... Effective date of
final rule.
Quality management system.......... Sec. 170.315(g)(4).. Remove...................... Effective date of
final rule.
Accessibility-centered design...... Sec. 170.315(g)(5).. Remove...................... Effective date of
final rule.
Consolidated CDA creation Sec. 170.315(g)(6).. Remove...................... Effective date of
performance. final rule.
Application access--patient Sec. 170.315(g)(7).. Remove...................... Effective January 1,
selection. 2027.
Application access--all data Sec. 170.315(g)(9).. Remove...................... Effective January 1,
request. 2027.
Direct Project..................... Sec. 170.315(h)(1).. Remove...................... Effective date of
final rule.
Direct Project, Edge Protocol, and Sec. 170.315(h)(2).. Remove...................... Effective date of
XDR/XDM. final rule.
----------------------------------------------------------------------------------------------------------------
1. Clinical Certification Criteria
a. Patient Demographics
In the 2014 Edition Final Rule, we included ``demographics'' in the
Base EHR definition in Sec. 170.102 (77 FR 54265). We noted that
including demographics in the Base EHR definition aligns with the
statutory ``Qualified EHR'' definition and is intended to facilitate
the recording, capture, and access to a patient's demographic data. In
the 2015 Edition Final Rule (80 FR 62602), we added the requirement to
record, capture, and access a patient's sex, sexual orientation, and
gender identity for Health IT Modules certified to the demographics'
certification criterion (Sec. 170.315(a)(5)) (80 FR 62747). The 2015
Edition Final Rule also defined a required set of standardized
terminology to represent each of these data elements (80 FR 62618
through 62620).
In the HTI-1 Final Rule (89 FR 1428), we adopted USCDI v3, which
includes data elements for Sex, Sexual Orientation, and Gender
Identity. To ensure consistent capture of these data elements across
health IT, we made updates to the data elements in Sec. 170.315(a)(5)
to incorporate the newly adopted data elements in USCDI v3.
Specifically, these same data elements were adopted as ``sex'' (Sec.
170.315(a)(5)(i)(C)), ``sexual orientation'' (Sec.
170.315(a)(5)(i)(D)), and ``gender identity'' (Sec.
170.315(a)(5)(i)(E)). To ensure consistency with our adoption of USCDI
v3, we finalized the name change of the certification criterion in
Sec. 170.315(a)(5) from ``demographics'' to ``patient demographics and
observations'' due to the inclusion of data elements based on clinical
observations.
Additionally, in the HTI-1 Final Rule, we finalized the replacement
of the specific concepts referenced in Sec. 170.315(a)(5)(i)(D) and
(E), sexual orientation and gender identity, respectively, with the
SNOMED Clinical Terms U.S. Edition (SNOMED CT[supreg]) U.S. Edition
code set, as referenced in the standard in Sec. 170.207(o)(3). In
[[Page 60981]]
Sec. 170.315(a)(5)(C), sex, we finalized adoption that a Health IT
Module enable sex to be recorded in accordance with the standard
specified in Sec. 170.207(n)(1) for the period up to and including
December 31, 2025; or Sec. 170.207(n)(2). The standards specified in
Sec. 170.207(n)(1) (sex) require that birth sex must be coded in
accordance with HL7[supreg] Version 3 Standard, Value Sets for
AdministrativeGender and NullFlavor, up until the adoption of this
standard expires January 1, 2026, attributed as follows: (i) Male. M;
(ii) Female. F; (iii) Unknown. NullFlavor UNK. The code sets referenced
in Sec. 170.207(n)(1), as cross-referenced in Sec.
170.315(a)(5)(i)(C), would expire on January 1, 2026, but we also
stated that health IT developers could continue to use the specific
codes referenced in Sec. 170.207(n)(1) through December 31, 2025, to
provide adequate time for Health IT Modules certified to the relevant
certification criteria to transition to the updated terminology
standards. Lastly, we finalized the addition of ``sex parameter for
clinical use'' as a new data element in Sec. 170.315(a)(5)(i)(F),
``name to use'' in Sec. 170.315(a)(5)(i)(G), and ``pronouns'' in Sec.
170.315(a)(5)(i)(H).
After publication of the HTI-1 Final Rule and our adoption of the
revisions in Sec. 170.315(a)(5), we began exercising enforcement
discretion and issued certification guidance for the Certification
Program regarding Health IT Module conformance with certain data
elements in the patient demographics and observations certification
criterion.\14\ In our enforcement discretion notice, we explained that
Sec. 170.550 requires an ONC-ACB, when certifying Health IT Modules,
to certify in accordance with the applicable certification criteria
adopted in regulation. Under this enforcement discretion and
certification guidance, we noted that ASTP/ONC will not take any
enforcement action under Sec. 170.565 against an ONC-ACB based on non-
compliance with Sec. 170.550 for certifying a Health IT Module that is
presented for certification to the patient demographics and
observations certification criterion (Sec. 170.315(a)(5)) where the
Health IT Module does not demonstrate conformance with any or all of
the following data and observations in paragraph (a)(5)(i): sex
parameter for clinical use, sexual orientation, gender identity, name
to use, and pronouns; or does not demonstrate conformance with any or
all of data and observations in Sec. 170.315(a)(5)(i)(D) through (H).
We also stated that ASTP/ONC will not take action against Health IT
Modules certifying or currently certified to the patient demographics
and observations certification criterion in Sec. 170.315(a)(5) that
only demonstrate, for conformance with paragraph (a)(5)(i)(C) (sex),
that it can record sex in accordance with either the standard specified
in Sec. 170.207(n)(1) for the period up to and including December 31,
2025, or the SNOMED CT[supreg] U.S. Edition codes found in the standard
specified in Sec. 170.207(n)(2): 248152002 Female (finding) and
248153007 Male (finding).\15\ We noted that we would not exercise our
direct review authority under Sec. 170.580 for any non-conformity,
potential or actual, that arises solely from a Health IT Module not
demonstrating the capabilities specified in our enforcement discretion
notice. We stated that the enforcement discretion and certification
guidance will remain in effect for 12 months from the date of the
notice or until the Department completes a regulatory action to revise
the applicable regulations, whichever comes first.
---------------------------------------------------------------------------
\14\ USCDI v3 Data Elements Enforcement Discretion [verbar]
https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion-notice.
\15\ https://www.healthit.gov/test-method/patient-demographics-and-observations.
---------------------------------------------------------------------------
We have reviewed the requirements in Sec. 170.315(a)(5)(i) and
have determined that removal of certain requirements in Sec.
170.315(a)(5)(i) would result in burden reduction for health IT
developers and cost savings associated with the (1) enforcement
discretion and (2) ongoing maintenance costs affected by the proposed
updates to the certification criterion. Accordingly, for these reasons
and reasons discussed below, we propose the following revisions to
Sec. 170.315(a)(5)(i).
We propose to revise Sec. 170.315(a)(5)(i)(C) to remove the
reference to the standard in Sec. 170.207(n)(1) (HL7 Administrative
Gender and NullFlavor). As discussed above, in the HTI-1 Final Rule, we
finalized that the adoption of the code sets referenced in Sec.
170.207(n)(1) will expire on January 1, 2026. Beginning January 1,
2026, a Health IT Module certified to Sec. 170.315(a)(5) is required
to demonstrate, for conformance with paragraph (a)(5)(i)(C), that it
can record sex in accordance with the SNOMED CT[supreg] U.S. Edition
codes found in the standard specified in Sec. 170.207(n)(2). Given the
timing of publication of this proposed rule, the reference to Sec.
170.207(n)(1) in Sec. 170.315(a)(5)(i)(C) is outdated and no longer
relevant. Therefore, we propose to remove the cross-reference to Sec.
170.207(n)(1) in Sec. 170.315(a)(5)(i)(C) because retaining the
reference may cause confusion for interested parties. Our proposed
revision would keep the cross-reference to Sec. 170.207(n)(2) in Sec.
170.315(a)(5)(i)(C). We propose that to demonstrate conformance with
Sec. 170.315(a)(5), a Health IT Module would only need to demonstrate
that it can record sex in accordance with either the 248152002 Female
(finding) or 248153007 Male (finding) SNOMED CT[supreg] U.S. Edition
codes found in the standard specified in Sec. 170.207(n)(2). A Health
IT Module would not need to demonstrate that it can record sex with any
other code found in SNOMED CT[supreg] U.S. Edition.
We have reviewed and evaluated the data elements in Sec.
170.315(a)(5)(i)(D) through (H) for consistency with our overall
deregulatory approach, and we have determined that it is no longer
necessary to include the paragraphs specified in Sec.
170.315(a)(5)(i)(D) through (H) (i.e., patient observations data) as
part of the Certification Program. As part of this evaluation, we
considered the general statutory requirement of the Qualified EHR
definition (further implemented with the ``Base EHR'' definition in
Sec. 170.102) to capture patient demographics, which neither
identifies demographic data elements nor requires certain demographic
elements to be included in the definition. The removal of these
elements would reduce burden by narrowing how many data elements are
required for purposes of certification to the criterion and for meeting
the Base EHR definition. This would produce cost savings for developers
regulated under the Certification Program. Health IT developers would
no longer need to support these data elements as part of the voluntary
certification process including not only for initial certification but
also for ongoing maintenance requirements over time. In this regard, we
invite readers to review section VIII (Regulatory Impact Analysis) for
a detailed discussion of our estimated impacts and cost savings
associated with our proposed revisions in Sec. 170.315(a)(5)(i). In
addition, the observational data elements proposed for removal do not
support the meeting of specific measures under the Medicare Promoting
Interoperability Program and the MIPS Promoting Interoperability
performance category, and therefore, are not essential for inclusion in
certified health IT that is used to meet the CEHRT definitions and
support meeting measures under those programs. Lastly, we note that the
proposed removal of the data elements in Sec. 170.315(a)(5)(i)(D)
through (H) aligns with our proposal
[[Page 60982]]
related to the removal of data elements from USCDI v3 and reflected in
proposed USCDI v3.1 (see section III.B.1).
We propose a conforming name change of the certification criterion
from ``patient demographics and observations'' to ``patient
demographics.'' This revision is not a substantive change to
certification requirements, but would return the certification
criterion's naming convention to as it was prior to the HTI-1 Final
Rule, as well as acknowledge that the data described in Sec.
170.315(a)(5) is understood to be demographic information. We note that
our proposed revisions are limited to Sec. 170.315(a)(5)(i), and we do
not propose to revise the ``inpatient setting only'' requirements in
Sec. 170.315(a)(5)(ii). We welcome comments on these proposals.
b. Clinical Decision Support
We propose to remove the ``clinical decision support'' (CDS)
certification criterion and reserve Sec. 170.315(a)(9).
In 2012, we established a new set of requirements for Health IT
Modules to support CDS. These requirements included capabilities to
support evidence-based CDS based on a defined set of data elements; CDS
configuration for both inpatient and ambulatory settings; and the
display of source attribute or bibliographic citation of CDS (77 FR
54212). In the 2015 Edition Final Rule, we finalized an updated CDS
certification criterion in Sec. 170.315(a)(9) (80 FR 62622). In the
HTI-1 Proposed Rule, we noted our belief that the continued evolution
of decision support software, especially as it relates to AI or machine
learning-driven Predictive DSIs, necessitates new requirements for the
Certification Program's CDS certification criterion (88 FR 23781).
In the HTI-1 Final Rule, we finalized an expiration date of January
1, 2025, for the CDS certification criterion in Sec. 170.315(a)(9) and
incorporate certain policies with modifications in the ``decision
support intervention'' certification criterion in Sec. 170.315(b)(11)
(89 FR 1237). We finalized a conforming expiration date for the CDS
certification criterion in the Base EHR definition in Sec. 170.102. We
noted that no action is required for developers relating to the
expiration of Sec. 170.315(a)(9) in the Base EHR. However, we also
noted that developers with Health IT Modules certified to Sec.
170.315(a)(9) wishing to maintain certification to the Base EHR
definition, needed to update to the DSI certification criterion in
Sec. 170.315(b)(11) by December 31, 2024.
As of January 1, 2025, the CDS certification criterion in Sec.
170.315(a)(9) is no longer available in the Certification Program.
Therefore, we propose to remove and reserve Sec. 170.315(a)(9). This
proposal would be effective upon the effective date of a subsequent
final rule. We welcome feedback on this proposal.
c. Family Health History
We propose to remove the ``family health history'' certification
criterion and reserve Sec. 170.315(a)(12). Health IT Modules certified
to Sec. 170.315(a)(12) must enable a user to record, change, and
access a patient's family health history in accordance with the
familial concepts or expressions included in, at a minimum, the version
of the standard in Sec. 170.207(a)(1) (SNOMED CT[supreg], U.S.
Edition, March 2022 Release). This certification criterion is not
included in the Base EHR definition but is included in the CEHRT
definitions established by CMS for the Medicare Promoting
Interoperability Program (42 CFR 495.4) and the MIPS Promoting
Interoperability performance category (42 CFR 414.1305).
We adopted the family health history certification criterion in the
2015 Edition Final Rule as a revised iteration of the 2014 Edition
family health history certification criterion adopted in Sec.
170.314(a)(13) (80 FR 62624). In the 2014 Edition Proposed Rule, we
proposed the first iteration of the family health history certification
criterion to align with a Meaningful Use Stage 2 proposal (77 FR
13838). We solicited comment on whether we should adopt the HL7
Pedigree standard and/or the Systematized Nomenclature of Medicine--
Clinical Terms (SNOMED CT[supreg] U.S. Edition) terms for familial
conditions. We also sought comment on a tool produced by the HHS Office
of the Surgeon General for capturing family health histories. In the
2014 Edition Final Rule, we finalized a certification criterion that
required, at a minimum, that health IT must enable a user to record,
change, and access information about a patient's first degree relative
within the said patient's record (see also 77 FR 54174). We also
finalized that health IT certified to Sec. 170.314(a)(13) could meet
this certification criterion by either being able to capture a
patient's family health history in SNOMED CT[supreg] U.S. Edition or in
the HL7 Pedigree standard. We noted that because the use of SNOMED
CT[supreg] U.S. Edition was required for meeting several other
certification criteria, it would not be a challenge to meet the
certification criterion. In the 2015 Edition Proposed Rule, we proposed
two separate certification criteria for family health history--one
based on functionality according to the SNOMED CT[supreg] U.S. Edition
standard and one based on functionality according to the HL7 Pedigree
standard (80 FR 16822 through 16823). However, we only adopted the
family health history certification criterion (Sec. 170.315(a)(12))
based on SNOMED CT[supreg] U.S. Edition, stating that the functionality
should be available to providers for more comprehensive patient care
(80 FR 62624).
In light of our overall deregulatory approach, we have determined
that we should remove the family health history certification criterion
in Sec. 170.315(a)(12). The functionality of this certification
criterion has been part of the Certification Program and associated
with the Medicare Promoting Interoperability Program and the MIPS
Promoting Interoperability performance category (including prior
iterations such as the EHR Incentives Programs and the CEHRT
definitions) for over 12 years. As such, the functionality is embedded
in certified health IT and has been widely adopted by hospitals and
physicians due to participation in those programs.\16\ Further, similar
to what we stated when we adopted the certification criterion, the
ability to code to SNOMED[supreg] CT U.S. Edition (including the entire
adopted version) is required to meet many of the remaining
certification criteria, including those referencing the USCDI v3 and
those criteria that would include the proposed USCDI v3.1 standard.\17\
These certification criteria included criteria that are in the Base EHR
definition and not proposed for removal in this proposed rule.
Therefore, we expect that many developers of certified health IT will
still conform to the SNOMED CT[supreg] U.S. Edition and the
functionality to code family health history with SNOMED CT[supreg] U.S.
Edition will remain in certified health IT adopted by hospitals and
physicians. Moreover, USCDI v6 includes a new Family Health History
data element.\18\ We note that health IT developers can use the SVAP to
voluntarily implement and become certified using the most recent
National Coordinator-approved version of USCDI without waiting for
ASTP/ONC to require that newer version via rulemaking (85 FR 25669).
While USCDI v6 has not been adopted in regulation at
[[Page 60983]]
this time, our expectations, as with every prior version of USCDI, are
that USCDI v6 would go through the SVAP approval process and be
approved for SVAP certification in 2026.
---------------------------------------------------------------------------
\16\ https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.
\17\ We discuss USCDI v3.1 in section III.B.1.
\18\ https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6.
---------------------------------------------------------------------------
As noted above, the family health history certification criterion
in Sec. 170.315(a)(12) is included in the CEHRT definitions.
Therefore, to provide sufficient time for CMS to update the CEHRT
definitions to remove reference to the certification criterion, we
propose a January 1, 2027, effective date for the removal of this
certification criterion. We welcome comments on these proposals.
d. Implantable Device List
We propose to remove and reserve the ``implantable device list''
certification criterion in Sec. 170.315(a)(14). The implantable device
list certification criterion requires Health IT Modules certified to
Sec. 170.315(a)(14) to exchange, record, and allow a user to access a
list of Unique Device Identifiers (UDIs) associated with a patient's
implantable devices. There is no adopted standard or implementation
guide associated with this functionality. However, the implantable
device list certification criterion is included in the Base EHR
definition, and we propose a conforming revision in Sec. 170.102 to
remove Sec. 170.315(a)(14) from the Base EHR definition (please see
section III.C.1 of this proposed rule).
In the 2015 Edition Final Rule, we adopted Sec. 170.315(a)(14)
with the purpose of establishing a baseline functionality to support
the exchange and use of UDIs in certified health IT (80 FR 62748). We
explained that the need to exchange and have access to this information
wherever patients seek care is broadly relevant to all clinical users
of health IT, regardless of setting or specialty, so that they may know
what devices their patients are using (or have used) and thereby
prevent device-related adverse events and deliver safe and effective
care (80 FR 62625 through 62627). We also stated that this need is most
acute for implantable devices, which by their nature are difficult to
detect and identify in the absence of reliable clinical documentation.
We acknowledged the challenges of fully implementing UDIs in health
IT in the 2015 Edition Final Rule, yet believed our adoption of the
certification criterion, as well as including the certification
criterion in the 2015 Base EHR definition and a UDI data element in the
2015 CCDS definition, were important steps to support electronic
exchange and use of UDIs (80 FR 62625 through 62626). In responding to
comments on the 2015 Edition Proposed Rule, we recognized that fully
implementing UDIs in health IT will take time and require addressing a
number of challenges, so we adopted a certification criterion that
focused narrowly on baseline health IT capabilities that developers
could feasibly implement. We stated that these capabilities would
provide the foundation for broader adoption and more advanced
capabilities and use cases. This approach minimized the potential
burden while maximizing the impact of this certification criterion for
all stakeholders.
We have reviewed the implantable device list certification
criterion in Sec. 170.315(a)(14) and, as explained below, have
determined that we have achieved our policy goals associated with the
exchange and use of UDIs. In consideration of this outcome and our
overall regulatory goals to reduce burden and offer flexibility to both
health IT developers and health care providers, we propose to remove
the implantable device list certification criterion and reserve Sec.
170.315(a)(14).
First, we have achieved our stated policy goal of broad adoption of
Sec. 170.315(a)(14). As we explained in prior rulemakings, we believe
in a foundational approach as the first step to broader adoption of
health IT capabilities (80 FR 16824, 80 FR 62626). We added the
implantable device list certification criterion to the 2015 Edition
Base EHR definition in the 2015 Edition Final Rule. The Base EHR
definition (2015 Edition and subsequent versions) is part of the CEHRT
definitions under the Medicare Promoting Interoperability Program and
the MIPS Promoting Interoperability performance category.\19\ As such,
health care providers participating in these programs are required to
adopt health IT certified to the implantable device list certification
criterion. As discussed earlier in this preamble, survey data indicates
widespread adoption by hospitals and physicians of certified health IT
products meeting the Base EHR definition, which includes Health IT
Modules certified to the implantable device list certification
criterion.\20\ The widespread adoption of the implantable device list
functionality is now well-established in health IT products, and we do
not believe that removing the certification criterion from the
Certification Program will result in health IT developers removing the
functionality from their products, which would likely be both a costly
endeavor and counter to the interests of their customers (i.e.,
hospitals and physicians).
---------------------------------------------------------------------------
\19\ 42 CFR 495.4 and 42 CFR 414.130.
\20\ https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.
---------------------------------------------------------------------------
Second, our proposed removal of the implantable device list
certification criterion would reduce burden and costs. We have
historically, where feasible and appropriate, taken measures to reduce
burden within the Certification Program and make the Certification
Program more effective, flexible, and streamlined. We believe our
proposal to remove the implantable device list certification criterion
would result in reduced burden, increased flexibility, and cost
savings. Developers of certified heath IT would have the flexibility to
implement those functionalities supporting the exchange and use of UDIs
that best meet the needs of their clients without additional regulatory
burden, which could also lead to innovations in these and related
functionalities.
Third, support for UDIs within certified health IT is incorporated
into other Certification Program elements besides the implantable
device list certification criterion. For example, UDIs are a required
data element in USCDI v3, and the proposed USCDI v3.1 standard, as the
``Unique Device Identifier(s) for a patient's implantable device(s)''
data element. We believe retaining a functional data capture
certification criterion that requires the same information as the USCDI
v3 standard supports (as part of key criteria enabling health
information exchange) would be duplicative and unnecessary (we refer
readers to section III.B.1 of this proposed rule for a discussion on
the proposed USCDI v3.1).
We also note that in USCDI v6, published in July 2025, we adopted a
significantly modified definition of the UDI data element to include
non-implantable devices.\21\ Health IT developers can use SVAP to
voluntarily implement and become certified using the most recent
National Coordinator-approved version of USCDI without waiting for ONC
to require that newer version via rulemaking (85 FR 25669). While USCDI
v6 has not been adopted in regulation at this time, our expectations,
as with every prior version of USCDI, are that USCDI v6 would go
through the SVAP approval process and be approved for SVAP
certification in 2026.
---------------------------------------------------------------------------
\21\ https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6.
---------------------------------------------------------------------------
Therefore, we believe that some health IT developers may choose to
voluntarily update relevant certified Health IT Modules to utilize
USCDI v6
[[Page 60984]]
with the modified definition of the UDI data element. Such actions
would provide for new data exchange capabilities to expand beyond the
baseline functionality in Sec. 170.315(a)(14). This proposal, if
finalized, would be effective as of the effective date of a subsequent
final rule. We welcome comments on this proposal.
2. Care Coordination Certification Criteria
a. Transitions of Care
We propose to revise the ``transitions of care'' certification
criterion in Sec. 170.315(b)(1) to simplify its requirements, with an
effective date of January 1, 2027. We propose to reduce the scope of
the criterion to focus on enabling the receipt of a Consolidated CDA
(C-CDA) document as a way to position this criterion for a future
evolution to receipt of FHIR-formatted data. The transitions of care
criterion supports the structured transition of care summaries and
referral summaries that help ensure continuity and care coordination as
patients move between providers. In the 2014 Edition Final Rule, we
finalized adoption of the C-CDA standard for this criterion because it
accommodated formatting of a summary care record that included all of
the data elements that CMS proposed be available for inclusion in a
summary care record (77 FR 54217). We also stressed that an EHR
technology's ability to incorporate data for medications, medication
allergies, and problems in structured form from a C-CDA document was
the minimum necessary to meet this certification criterion and
encouraged EHR technology developers to go beyond this minimum (77 FR
54219). Additionally, in the 2014 Edition Final Rule we included Sec.
170.315(b)(1) in the Base EHR definition (77 FR 54265).
In the Cures Act Final Rule, we updated the transitions of care
criterion's data requirements to include USCDI v1 (85 FR 25667), and in
the HTI-1 Final Rule we updated the data requirements to include USCDI
v3 (89 FR 1298). We note that the certification criterion in Sec.
170.315(b)(1) is currently associated with several measures under the
Health Information Exchange Objective of the Medicare Promoting
Interoperability Program and the MIPS Promoting Interoperability
performance category. Specifically, the certification criterion in
Sec. 170.315(b)(1) is specified as required for the Support Electronic
Referral Loops by Sending Health Information and Support Electronic
Referral Loops by Receiving and Reconciling Health Information measures
and specified as an example of a criterion that may be used to support
the actions of the Health Information Exchange (HIE) Bi-directional
Exchange and Enabling Exchange under TEFCA measures.\22\
---------------------------------------------------------------------------
\22\ See the ``Medicare and Medicaid Programs; CY 2026 Payment
Policies Under the Physician Fee Schedule and Other Changes to Part
B Payment and Coverage Policies; Medicare Shared Savings Program
Requirements; and Medicare Prescription Drug Inflation Rebate
Program'' (CY 2026 PFS) Proposed Rule (90 FR 32352) Table 62,
available at https://www.federalregister.gov/d/2025-13271/p-3055andtheFY2026IPPS/LTCH PPS Final Rule (90 FR 36536) Table X.F.-05
available at https://www.federalregister.gov/d/2025-14681/p-4161.
---------------------------------------------------------------------------
We have reviewed and evaluated the transitions of care
certification criterion in Sec. 170.315(b)(1) in order to identify
ways to reduce burden while still supporting our policy goals. As we
noted in the S&CC January 2010 Interim Final Rule, we take an iterative
approach to addressing the interoperability of health IT and consider
factors such as maturity, market prevalence, and complexity of
implementation to inform our adoption of standards and certification
criteria (75 FR 2020). Our approach then and now is intended to be
``pragmatic, but forward looking'' and involves sustainable and
incremental steps to harmonize current and future standards, as well as
phase out standards and certification criteria when needed (75 FR
2021).
Several industry trends have led us to propose revising this
certification criterion. First, FHIR supports the functionalities of a
contemporary web-based architecture, using technologies such as RESTful
APIs, JSON, and XML, making the standard more approachable to software
developers and enabling easier integration with web-based and mobile
applications than the C-CDA standard. Second, FHIR is a more granular
data standard, enabling exchange of more discrete data concepts rather
than entire documents. C-CDA is a document-centric standard that does
not support retrieval of information at the data element level, which
can lead to information overload during transitions of care. Finally,
we believe that FHIR supports easier scalability to support real-time
data exchange, which will support a broader ecosystem of health IT
tools than C-CDA. Various capabilities, such as CDS Hooks,
Subscriptions, and SMART Health Links, support new interoperability
paradigms that are much more difficult to do using C-CDA. These trends
notwithstanding, we remain cognizant that the C-CDA standard is widely
adopted, and we anticipate its continued use over the near-term,
especially for transitions of care among health care delivery settings,
such as in-patient and long-term and post-acute care.
In detail, we propose to revise the transitions of care
certification criterion in Sec. 170.315(b)(1) as of January 1, 2027.
We propose to remove the requirements in Sec. 170.315(b)(1)(i) ``send
and receive via edge protocol'' and in Sec. 170.315(b)(1)(iii)
``create'' and to simplify the requirements in Sec. 170.315(b)(1)(ii)
``validate and display'' to focus on the ability to receive and
validate C-CDA documents. We propose to remove the requirements in
Sec. 170.315(b)(1)(ii)(B) and (C). We also propose to move the
requirements in Sec. 170.315(b)(1)(ii)(A) ``validate C-CDA
conformance--system performance'' to Sec. 170.315(b)(1)(i) and to
rename Sec. 170.315(b)(1) to read ``transitions of care--receive and
validate.'' Additionally, in Sec. 170.315(b)(1)(ii)(A) we propose to
remove the references to Sec. 170.205(a)(3) and to replace the
references to Sec. 170.205(a)(5), which expires on January 1, 2026,
with references to Sec. 170.205(a)(6). We welcome feedback on these
proposals.
b. Clinical Information Reconciliation and Incorporation
We propose to remove the ``clinical information reconciliation and
incorporation'' certification criterion in Sec. 170.315(b)(2) with an
effective date of January 1, 2027, and to reserve that section. The
clinical information reconciliation and incorporation (CIRI)
certification criterion allows health care providers to reconcile and
incorporate patient health information sent from external sources to
maintain a more accurate and up-to-date patient record. The CIRI
certification criterion is not currently included in the Base EHR
definition; however, the criterion is required for the Support
Electronic Referral Loops by Receiving and Reconciling Health
Information measure and specified as an example of a criterion that may
be used to support the actions of the HIE Bi-Directional Exchange and
Enabling Exchange under TEFCA measures in the Medicare Promoting
Interoperability Program and the MIPS Promoting Interoperability
performance category.\23\
---------------------------------------------------------------------------
\23\ See the CY 2026 PFS Proposed Rule Table 62, available at
https://www.federalregister.gov/d/2025-13271/p-3055andtheFY2026IPPS/LTCH PPS Final Rule Table X.F.-05 available at https://www.federalregister.gov/d/2025-14681/p-4161.
---------------------------------------------------------------------------
Our requirements for CIRI in the Certification Program were first
established in the S&CC January 2010 Interim Final Rule to enable a
user to
[[Page 60985]]
electronically complete medication reconciliation of two or more
medication lists (75 FR 2046). In the 2011 Edition Final Rule, we
revised the certification criterion to require that Certified EHR
Technology be capable of providing a user with the ability to
electronically compare two or more medication lists (75 FR 44613). We
expanded these requirements in the 2014 Edition Final Rule to require
clinical information reconciliation for problems, medications, and
medication allergies (77 FR 54289). In the 2014 Edition Release 2 Final
Rule, we added incorporation requirements and adopted the updated CIRI
certification criterion as an optional 2014 Edition certification
criterion in Sec. 170.314(b)(9) (79 FR 54438). In the 2015 Edition
Final Rule, we finalized a revised 2015 Edition CIRI certification
criterion in Sec. 170.315(b)(2) (80 FR 62749), and we updated the
related C-CDA standards for the certification criterion in Sec.
170.315(b)(2) in both the Cures Act Final Rule (85 FR 25677) and the
HTI-1 Final Rule (89 FR 1224).
We have reviewed and evaluated the CIRI certification criterion in
Sec. 170.315(b)(2), seeking to identify ways to reduce burden while
still supporting our policy goals. As we have stressed in prior
rulemaking, we take an incremental approach to improving health IT
interoperability and performance, relying on factors such as market
prevalence and industry readiness to harmonize current and future
standards and phase out standards and certification criteria as needed
(75 FR 2020). Our review of industry adoption of the CIRI certification
criterion indicates widespread adoption. Review also indicates that its
capabilities are widely implemented and used in health IT at this time
and thus not likely to go away as supported capabilities by developers
of certified health IT solely on the basis of removal of the criterion
from the Certification Program \24\ (see section III.A for a discussion
on ``widely adopted'' and ``widely implemented''). We also have seen
indications that removing the certification criterion from the
Certification Program could spur greater development and innovation in
this area. In conversations with developers and implementers, we have
seen technology that innovates on CIRI, providing functionality beyond
Certification Program requirements that supports direct incorporation
of information received from trusted sources.
---------------------------------------------------------------------------
\24\ Real World Testing results (accessible via https://chpl.healthit.gov/) for 2024 from three large EHR developers with
significant market share in the United States attest to routine
clinician use of Clinical Information Reconciliation and
Incorporation (Sec. 170.315(b)(2)): Epic customers reconciled 66
million medications, 7 million allergies, and 40 million problems
out of 135 million transition of care CCDs received; Oracle Health
clinicians added ~491 k and rejected 2.69 million external
medications per month, evidencing active review; and MEDITECH's
Expanse product processed 17 million CCD Retrieve Document Set
exchanges with a 99.67% success rate. Given that Epic, Oracle
(Cerner), and MEDITECH together provide the majority of EHR systems
used in the U.S., these findings indicate that CIRI capabilities are
broadly adopted and meaningfully used in clinical care.
---------------------------------------------------------------------------
We have concluded that removing the CIRI certification criterion in
Sec. 170.315(b)(2) would reduce burden for health IT developers, such
as testing and other burden associated with certification to this
criterion, while still allowing ASTP/ONC to achieve our policy goals of
supporting interoperability and access to quality EHI at the point of
care. Additionally, we believe that removing this C-CDA-based
certification criterion from the Certification Program would encourage
movement toward FHIR-based standards which can further spur innovation
and development in this area, improving interoperability and patient
care. Because the certification criterion in Sec. 170.315(b)(2) is a
requirement for Promoting Interoperability measures, we believe a
transition date for removal is needed. We propose a January 1, 2027,
effective date for the removal of the CIRI certification criterion in
Sec. 170.315(b)(2). We welcome feedback on these proposals.
c. Security Tags--Summary of Care
We propose to remove the ``security tags--summary of care--send''
certification criterion in Sec. 170.315(b)(7) and the ``security
tags--summary of care--receive'' certification criterion in Sec.
170.315(b)(8) and reserve those sections. Together, these certification
criteria support the application and persistence of security labels for
document-based exchange. The security tags--summary of care--send
certification criterion in Sec. 170.315(b)(7) enables a user to create
a summary record that is tagged as restricted and subject to
restrictions on re-disclosure, while the security tags--summary of
care--receive certification criterion in Sec. 170.315(b)(8) enables a
user to receive a summary record that is tagged as restricted and
subject to restrictions on re-disclosure. These criteria are not
currently included in the Base EHR definition.
The certification criteria in Sec. 170.315(b)(7) and (b)(8) were
originally adopted in the 2015 Edition Final Rule as ``data
segmentation for privacy'' (DS4P) certification criteria and only
required security tagging of C-CDA documents at the document level (80
FR 62646 and 62647). In the Cures Act Final Rule, we updated the
requirements to support security tagging of C-CDA documents at the
document, section, and entry levels (85 FR 25646).
We have reviewed the security tags--summary of care--send
certification criterion in Sec. 170.315(b)(7) and the security tags--
summary of care--receive certification criterion in Sec.
170.315(b)(8), evaluating how to reduce burden while still addressing
policy priorities to support privacy protections in information
exchange. As we have stated previously in this proposed rule, we
consider factors such as market prevalence and the uptake in
implementation of criteria by developers of health IT when making
revisions to Certification Program certification criteria. Currently,
35 unique Health IT Modules are certified to the criterion in Sec.
170.315(b)(7), and 36 unique Health IT Modules are certified to the
criterion in Sec. 170.315(b)(8), out of a total of 707 active and non-
suspended certifications listed on the Certified Health IT Product List
(CHPL), a comprehensive listing of all certified health IT successfully
tested and certified under the Certification Program.\25\ We believe
that in this case the low number of Health IT Modules certified to
these criteria indicate that the criteria may not be of sufficient
value to health IT developers to warrant continued inclusion in the
Certification Program. Additionally, as the industry moves toward
greater use of FHIR-based standards, the removal of these C-CDA-based
criteria in the Certification Program would help spur further
innovation and advancement in this area.
---------------------------------------------------------------------------
\25\ https://chpl.healthit.gov/ search conducted June 2025.
---------------------------------------------------------------------------
We have concluded that removing the certification criteria in Sec.
170.315(b)(7) and (8) would reduce burden for health IT developers and
health care providers while still supporting our policy goals to
support privacy protections in information exchange. We propose to
remove the security tags--summary of care--send certification criterion
in Sec. 170.315(b)(7) and the security tags--summary of care--receive
certification criterion in Sec. 170.315(b)(8) as of the effective date
of a final rule. We welcome feedback on these proposals.
d. Care Plan
We propose to remove the ``care plan'' certification criterion in
Sec. 170.315(b)(9) and reserve that section. This criterion
[[Page 60986]]
helps improve coordination of care by providing a structured format for
documenting patient information such as goals, health concerns, health
status evaluations, and interventions. The criterion is not currently
included in the Base EHR definition. The certification criterion in
Sec. 170.315(b)(9) was first adopted in the 2015 Edition Final Rule
and required a Health IT Module to enable a user to record, change,
access, create, and receive care plan information in accordance with
the C-CDA Release 2.1 standard in Sec. 170.205(a)(4) (80 FR 62648). We
updated the criterion in the Cures Act Final Rule to also require the
HL7 CDA[supreg] R2 Implementation Guide: C-CDA Templates for Clinical
Notes R2.1 Companion Guide, Release 2 standard in Sec. 170.205(a)(5)
(85 FR 25943). In the HTI-1 Final Rule, we updated the criterion to
require the HL7 CDA[supreg] R2 Implementation Guide: C-CDA Templates
for Clinical Notes R2.1 Companion Guide, Release 2 standard in Sec.
170.205(a)(5) for the time period up to and including December 31,
2025, or the C-CDA Companion Guide Release 4.1 standard in Sec.
170.205(a)(6) (89 FR 1224).
We have evaluated the care plan certification criterion in Sec.
170.315(b)(9) with a goal of reducing burden on health IT developers
and health care providers while still achieving our policy priorities.
Currently, 54 unique Health IT Modules are certified to the criterion
in Sec. 170.315(b)(9) out of a total of 707 active and non-suspended
certifications listed on the CHPL. We believe this may indicate low
interest by health IT developers in certifying to this criterion.\26\
As discussed previously in this proposed rule, the industry is moving
away from C-CDA-based standards to the use of FHIR-based standards that
offer greater flexibility and potential for innovation. ASTP/ONC
recently highlighted the development of FHIR-based care plan IGs,
including the Multiple Chronic Condition eCare Plan and the Electronic
Long Term Services & Support Care Plan IGs, in a January 2025 standards
bulletin.\27\ Additionally, input from industry has indicated that the
care plan document type is less frequently adopted than other C-CDA
document types, and where it is utilized, health IT developers are not
likely to cease supporting the functionality if the criterion is
removed from the Certification Program.
---------------------------------------------------------------------------
\26\ https://chpl.healthit.gov/ search conducted June 2025.
\27\ https://www.healthit.gov/topic/standardsbulletin_25-1.
---------------------------------------------------------------------------
We have concluded that removing the certification criterion in
Sec. 170.315(b)(9) would reduce burden for health IT developers and
health care providers while still supporting our goals. Additionally,
as discussed previously, moving away from C-CDA-based requirements in
the Certification Program would help promote greater innovation and
advancement in this area. We propose to remove the care plan
certification criterion in Sec. 170.315(b)(9) as of the effective date
of a final rule. We welcome feedback on these proposals.
e. Decision Support Interventions
We propose to revise the ``decision support interventions'' (DSI)
certification criterion in Sec. 170.315(b)(11). The DSI certification
criterion ensures that users can leverage health IT for clinical
decision-making by supporting their selection of both evidence-based
and predictive DSIs and enabling users' access to transparent
information on DSI performance and quality. In the HTI-1 Final Rule, we
adopted the DSI certification criterion in Sec. 170.315(b)(11) as both
an update and replacement criterion for the CDS certification criterion
in Sec. 170.315(a)(9) (89 FR 1236). We also added Sec. 170.315(b)(11)
to the Base EHR definition in the HTI-1 Final Rule (89 FR 1197). When
we finalized the DSI certification criterion in the HTI-1 Final Rule,
we cited E.O. 14091 on Further Advancing Racial Equity and Support for
Underserved Communities Through the Federal Government (February 16,
2023), which addressed bias in AI, and E.O. 14110 on Safe, Secure, and
Trustworthy Development and Use of Artificial Intelligence (October 30,
2023), which addressed the risks of AI (89 FR 1232). These EOs were
revoked in E.O. 14148 on Initial Rescissions of Harmful Executive
Orders and Actions (January 20, 2025).
We have reviewed and evaluated the DSI certification criterion in
Sec. 170.315(b)(11), focusing on ways to reduce burden while still
supporting our policy priorities. As we have noted previously in this
proposed rule and in prior rulemakings, we consider factors such as
standards maturity, market adoption, and complexity of implementation
when adopting, revising, or phasing out standards and certification
criteria (75 FR 2020). Currently, the requirements in Sec.
170.315(b)(11) reference data expressed in the USCDI standards in Sec.
170.213. We have received feedback from developers of certified health
IT that requiring support of predictive DSIs that use any data element
in one of the USCDI standards in Sec. 170.213 has proven burdensome
and costly to implement, with questionable value. While many USCDI data
elements are routinely used in decision support and would be important
inputs to predictive DSI, other USCDI data elements, such as phone
number and phone number type data elements, are not likely to be used
as inputs.
We propose to revise the DSI certification criterion in Sec.
170.315(b)(11) as detailed below as of the effective date of a
subsequent final rule. We propose to remove the requirement in Sec.
170.315(b)(11)(ii)(B) to enable interventions when a patient's
medications, allergies and intolerance, and problems are incorporated
from a transition of care or referral summary received and pursuant to
paragraph Sec. 170.315(b)(2)(iii)(D). As described above in section
III.A.2.b, we propose to remove Sec. 170.315(b)(2), which is a C-CDA-
based criterion, from the Certification Program completely as of
January 1, 2027. Thus, we propose to remove the requirement in Sec.
170.315(b)(11)(ii)(B), which references Sec. 170.315(b)(2), as well.
We also propose to redesignate the certification criterion currently in
Sec. 170.315(b)(11)(ii)(C) as Sec. 170.315(b)(11)(ii)(B).
We propose to remove the parenthetical reference in Sec.
170.315(b)(11)(iii) to ``drug-drug and drug-allergy contraindication
checking'' upon the effective date of a final rule. We have retained
the ``drug-drug, drug-allergy interaction checks for CPOE''
certification criterion in Sec. 170.315(a)(4), and in order to
simplify overall Certification Program requirements, we do not believe
it is necessary to reference this capability as part of decision
support functionality in Sec. 170.315(b)(11)(iii). We note that this
reference was initially included as part of the revisions made to the
Certification Program's decision support certification criterion (then
referenced in Sec. 170.314(a)(8)) in 2012 (see 77 FR 54215). Since
this time, the Certification Program has taken deliberate actions to
support a more modular marketplace for health IT (see 84 FR 7428, 89 FR
63567 through 63568, and 90 FR 37158). Removal of this specified
capability within Sec. 170.315(b)(11) to support drug-drug and drug-
allergy contraindication checking furthers this goal of modularity
without precluding support for such interaction checks, due to the
retention of requirements in Sec. 170.315(b)(11)(iii)(A)(2) and (3)
regarding enabling evidence-based DSIs that include ``Medications'' and
[[Page 60987]]
``Allergies and Intolerances,'' respectively, as data types.
Additionally, we propose to revise the requirements in Sec.
170.315(b)(11)(iii)(B), which currently relate to enabling predictive
DSIs that use any data expressed in the standards in Sec. 170.213, to
limit the application of the certification criterion to just data
expressed in Sec. 170.315(b)(11)(iii)(A) as well as data expressed in
the Clinical Notes and the Assessment and Plan of Treatment data
classes in the standards in Sec. 170.213. While we originally wanted
to apply the requirements of this certification criterion to any data
expressed in the standards in Sec. 170.213 in order to reflect our
focus on the USCDI and the variety of data for which DSIs may be
enabled, we believe a number of USCDI data elements are not likely to
be used as inputs, as mentioned above. We believe that revising the
requirements to focus on fewer data elements would significantly reduce
burden for health IT developers without diminishing users' ability to
select (i.e., activate) a wide variety of predictive DSIs that use
remaining USCDI data elements as inputs.
Finally, we propose to remove the requirements in Sec.
170.315(b)(11)(iv) and (v) regarding source attribute support, access,
and modification and in Sec. 170.315(b)(11)(vi) regarding intervention
risk management for predictive DSIs. In addition to reducing burden,
removal of these requirements would comply with E.O. 14179 on Removing
Barriers to American Leadership in Artificial Intelligence (January 23,
2025). E.O. 14179 calls for the review of regulations and other actions
taken pursuant to revoked E.O. 14110, and any actions taken that are
inconsistent with the policy set forth in E.O. 14179 to ``sustain and
enhance America's global AI dominance in order to promote human
flourishing, economic competitiveness, and national security'' \28\
shall be suspended, revised, or rescinded as appropriate and consistent
with applicable law.\29\ Despite proposing source attribute information
transparency and intervention risk management more than six months
prior to issuance of E.O. 14110,\30\ we note that many of our
fundamental assumptions and objectives were aligned with the stated
goals of E.O. 14110 to advance ``safe, secure, and trustworthy
development and use of artificial intelligence.''
---------------------------------------------------------------------------
\28\ https://www.federalregister.gov/d/2025-02172/p-3.
\29\ Federal Register: Removing Barriers to American Leadership
in Artificial Intelligence (90 FR 8741).
\30\ https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and.
---------------------------------------------------------------------------
Additionally, we note several factors supporting the proposal to
modify the DSI certification criterion. First, developers of certified
health IT have reported that during care delivery, most clinical users
lack the time or technical background to engage with source attribute
information for either evidence-based DSIs or predictive DSIs supplied
by the developer of certified health IT.\31\ Despite having access to
source attribute information since the beginning of 2025, when Health
IT Modules certified to Sec. 170.315(b)(11) began to be first
deployed, we have no publicly available evidence indicating that a
single doctor, nurse, or administrator has accessed, recorded, or
modified a single source attribute. Further, we have no publicly
available evidence that transparency requirements in Sec.
170.315(b)(11) have led to positive impacts on patient care, such as
removing deficient or untested algorithms, or testing a deployed
algorithm on local data. We believe that the underlying assumption that
source attribute information would be valuable to health care delivery
organizations and health care professionals when deciding whether to
implement or use a DSI (as stated in the HTI-1 Final Rule) \32\ was
incorrect.
---------------------------------------------------------------------------
\31\ See letter to Acting Assistant Secretary for Technology
Policy, Acting National Coordinator for Health Information
Technology Posnack, April 16, 20215: https://www.ehra.org/sites/ehra.org/files/EHR%20Association%20Letter%20to%20ASTP-ONC%20-%20Certification%20Program%20Deregulatory%20Suggestions.pdf#page=7.
\32\ See 88 FR 23780 at https://www.federalregister.gov/d/2023-07229/p-547.
---------------------------------------------------------------------------
Second, transparency regarding how a predictive or generative AI
application was designed, developed, tested, evaluated, and should be
used may not have the savings and benefits we anticipated. As described
in the regulatory impact analysis (RIA) to the HTI-1 Final Rule, we
estimated considerable benefits from this policy (89 FR 1411), noting
that transparency into AI applications would result in health care
delivery organizations selecting and using more accurate AI
applications. We quantified associated benefits for two illustrative
cases, sepsis detection and ambulatory care sensitive admissions (89 FR
1412 through 1414), estimating that our policies would result in a 10-
year savings of up to $3 billion for the sepsis use case through
increased application of more sensitive predictive models for this
condition. We have not encountered supporting evidence or published
research indicating that source attribute transparency requirements in
Sec. 170.315(b)(11)(iv) have improved health care delivery
organizations' evaluation and effective use of AI. We understand that
the benefits articulated in the HTI-1 Final Rule impact analysis are
not being realized.
Third, developers of certified health IT have reported an
inconsistent approach to oversight of other parties producing similar,
health-based AI systems.\33\ They note that ``[t]he current model of
imposing rigorous requirements [(i.e., algorithmic transparency and
risk management)] on certified health IT but not the many other tech
companies working in this space is simply unacceptable and needs to be
remedied.'' \34\ While we attempted to encourage more consistent and
ubiquitous transparency requirements across similar applications in our
April 2023 proposals for predictive DSI in the HTI-1 Proposed Rule (88
FR 23782), and have worked with federal partners on alignment with
similar policy objectives since finalization of the HTI-1 Final Rule in
January 2024,35 36 we acknowledge that our authorities have
limitations that inhibit our collective efforts to treat similar
technologies similarly under a single Department-wide policy.
---------------------------------------------------------------------------
\33\ https://www.ehra.org/sites/ehra.org/files/EHR%20Association%20Letter%20to%20ASTP-ONC%20-%20Certification%20Program%20Deregulatory%20Suggestions.pdf#page=7.
\34\ Ibid.
\35\ See 89 FR 1264 for discussion of alignment with FDA
policies.
\36\ See 89 FR 37643 for discussion of alignment with OCR
policies.
---------------------------------------------------------------------------
Finally, in order to promote innovation of AI in health care, we
propose to remove transparency and risk management requirements
established in the HTI-1 Final Rule. Additionally, we have heard from
health IT developers that the requirements are burdensome and
detrimental to such innovation and growth, which is the opposite of our
stated policy intent to optimize the ubiquitous use of high-quality AI
in health care.
For these and the aforementioned reasons, we propose to remove all
requirements related to source attributes in Sec. 170.315(b)(11)(iv),
their access in Sec. 170.315(b)(11)(v)(A), and their modification in
Sec. 170.315(b)(11)(v)(B), as well as requirements to manage risks
related to the development and deployment of predictive DSIs supplied
by health IT developers as part of their product in Sec.
170.315(b)(11)(vi). We welcome comments on these proposals.
[[Page 60988]]
3. Clinical Quality Measures Certification Criteria
a. Clinical Quality Measures--Report
We propose to revise the ``clinical quality measures--report''
certification criterion in Sec. 170.315(c)(3) as of the effective date
of a final rule. We propose to remove the requirement in Sec.
170.315(c)(3)(ii), as this provision may no longer be used to support
certification to the criterion. In the Cures Act Interim Final Rule, we
revised Sec. 170.315(c)(3) to include a corrected compliance
transition timeline for the criterion in Sec. 170.315(c)(3)(ii), which
specified the use of standards in Sec. 170.205(h)(2) and in Sec.
170.205(k)(1) and (2), for the period before December 31, 2022 (85 FR
70075, 70083). We propose to remove paragraph Sec. 170.315(c)(3)(ii)
because that transition time period has elapsed. We also propose to
move the requirements in Sec. 170.315(c)(3)(i) to Sec. 170.315(c)(3),
thus removing all subparagraphs and including all criterion
requirements in the main paragraph for Sec. 170.315(c)(3). We welcome
comments on our proposal.
b. Clinical Quality Measures--Filter
We propose to remove the ``clinical quality measures--filter''
certification criterion in Sec. 170.315(c)(4) with an effective date
of January 1, 2027. This certification criterion assesses whether a
Health IT Module can filter quality data based on a set of standardized
data elements for electronic clinical quality measures (eCQM)
calculated using certified health IT.
In the Voluntary Edition Proposed Rule, we proposed a new
certification criterion in Sec. 170.315(c)(4) that would require
health IT to record structured data allowing CQM results to be grouped
by patient characteristics (79 FR 10903 and 10904).\37\ We proposed
this capability to support eCQM reporting by group practice or
accountable care organization (ACO). We also proposed capturing patient
characteristics that support identification of health disparities, that
help providers identify gaps in quality, and that support delivery of
specialized care to needful patient subgroups. We did not adopt this
certification criterion in the 2014 Edition Release 2 Final Rule as we
received comments recommending refinement of the use cases and
performance of more analysis on which data elements are being captured
in standardized ways (79 FR 54462).
---------------------------------------------------------------------------
\37\ Practice site and address; Tax Identification Number (TIN),
National Provider Identifier (NPI), and TIN/NPI combination;
diagnosis; primary and secondary health insurance, including
identification of Medicare and Medicaid dual eligible; demographics
including age, sex, preferred language, education level, and
socioeconomic status.
---------------------------------------------------------------------------
In the 2015 Edition Proposed Rule (80 FR 16844) we proposed to add
Sec. 170.315(c)(4) as a new certification criterion for CQM filtering
based on the rationale that health IT should support an organization's
ability to filter individual and aggregate eCQM results in ways that
support administrative reporting, identification of health disparities,
and identification of gaps in care.
In the 2015 Edition Final Rule, we adopted the ``CQMs--filter''
certification criterion in Sec. 170.315(c)(4), along with three other
CQM certification criteria: ``CQMs--record and export'' (Sec.
170.315(c)(1)), ``CQMs--import and calculate'' (Sec. 170.315(c)(2)),
and ``CQMs--report'' (Sec. 170.315(c)(3)) (80 FR 62649 through 62655).
Together, these four criteria were adopted to support providers'
quality improvement activities and to support reporting to programs
such as the EHR Incentive Programs, Quality Payment Program, and
Comprehensive Primary Care plus initiative.
The 2015 Edition Final Rule adopted Sec. 170.315(c)(4) as a new
2015 Edition certification criterion that supports the capability of a
clinician to filter eCQM results using data captured for quality
improvement and quality reporting purposes. We finalized that Health IT
Modules certified to Sec. 170.315(c)(4) must be able to: record data
and filter CQM results at both patient and aggregate levels; filter by
any combination of the data elements established as part of the
criterion with associated vocabulary standards; create a data file of
the filtered data in accordance with the QRDA Category I and Category
III standards; and display the filtered data in a human readable
format.
This certification criterion is not included in the Base EHR
definition in Sec. 170.102 but is included in the CEHRT definition for
MIPS in 42 CFR 414.1305 as an optional criterion. While we recognize
the value of this functionality, we propose to remove this criterion
for multiple reasons. We reviewed and evaluated existing regulations to
identify deregulatory actions that would reduce administrative burden,
and the private expenditures required for compliance with federal
regulations. We have identified that the administrative costs of
certification for the CQMs--filter certification criterion are no
longer offset by the benefits of advancing the specific functionality
supported by the criterion. Further, we do not believe that quality
measure filtering functionality would be removed from health IT systems
because of our proposal to remove this criterion.
Quality reporting programs, such as those required by states and
CMS programs, require broader supplemental data and capabilities beyond
what we currently require for certification. In addition, health IT
developers have widely implemented technology solutions that expand
beyond the baseline requirements of the certification criterion (see
section III.A for a discussion on ``widely implemented''). Through
listening sessions with a wide range of health care provider types and
sites of service, public correspondence, and CHPL data, we understand
that the use of the CQMs--filter certified functionality is fairly low
relative to the other certification criteria that support clinical
quality measure capabilities. According to CHPL data, as of August
2025, there are 340 active Health IT Modules certified to Sec.
170.315(c)(1), (2), or (3), but only 71 active Health IT Modules
certified to Sec. 170.315(c)(4). Among the feedback we have received,
health care providers participating in CMS alternative payment models,
as well as health IT developers supporting quality initiatives, have
reported that they have different options to filter eCQM results,
including using customized systems and/or the support of third parties
to support innovative, specialty-specific quality measurement and
reporting tailored to their particular needs. We therefore believe the
value of maintaining this certification criterion is minimal as health
IT developer time and resources would be better spent on quality data
system modernization efforts leveraging FHIR-based APIs for quality
data exchange.
We therefore propose to remove the certification criterion in Sec.
170.315(c)(4) as of January 1, 2027.
4. Privacy and Security Certification Criteria
We propose to remove all the privacy and security certification
criteria in Sec. 170.315(d) and the associated Privacy and Security
Certification Framework under Sec. 170.550(h) as of the effective date
of a subsequent final rule.
We first adopted a version of the privacy and security
certification criteria currently found in Sec. 170.315(d) (and
associated standards) in the 2011 Edition through an interim final rule
(75 FR 2033 through 2035). These certification criteria originated from
HIT Policy Committee and HIT Standards Committee recommendations. The
[[Page 60989]]
criteria generally focused on basic technical capabilities that could
be included in the development of Health IT Modules that would be
certified. We used the Health Insurance Portability and Accountability
Act of 1996 (HIPAA) Security Rule (45 CFR 164 parts 160 and 164,
subparts A and C) as the starting point for the Certification Program's
privacy and security certification criteria, with the intent of
ensuring that Certified EHR Technology (now referred to as ``certified
health IT'') included at least one capability to assist a HIPAA covered
entity with complying with HIPAA Security Rule requirements. The
initial criteria also included a certification criterion (``accounting
of disclosures'') to support entities regulated under HIPAA that must
provide an accounting of disclosures of protected health information
\38\ made in certain circumstances.\39\ We noted, however, that the
interim final rule strictly focused on the capabilities of Certified
EHR Technology and did not change existing HIPAA Privacy Rule or
Security Rule requirements, guarantee compliance with those
requirements, or absolve an eligible professional, eligible hospital or
other health care provider from having to comply with any applicable
provision of the HIPAA Privacy or Security Rules. In addition, we
stated that, while the capabilities provided by Certified EHR
Technology may assist an eligible professional, eligible hospital in
improving their technical safeguards, the use of Certified EHR
Technology alone does not equate to compliance with the HIPAA Privacy
or Security Rules. We stated that the capabilities provided by
Certified EHR Technology do not in any way affect the analysis that an
entity regulated by HIPAA is required to perform by 45 CFR 164.306(b)
and (d) (75 FR 2035).
---------------------------------------------------------------------------
\38\ 45 CFR 160.103 (definition of ``protected health
information'').
\39\ 42 U.S.C. 17935(c), sec. 13405(c) of the American Recovery
and Reinvestment Act of 2009, Public Law 111-5, 123 Stat. 265 (Feb.
17, 2009); 45 CFR 164.528.
---------------------------------------------------------------------------
With the 2014 Edition, we included the privacy and security
certification criteria in the Base EHR definition in an attempt to
provide both developers and health care providers more flexibility in
meeting Certification Program requirements, while still providing
health care providers with basic technical options that could support
compliance with parts of the HIPAA Privacy and Security Rules (77 FR
54265). Based on recommendations from the HIT Standards Committee, we
established a third privacy and security certification approach under
Sec. 170.550(h) for the new 2015 Edition so that each certification
criterion also had a set of separate privacy and security certification
criteria attributed to them that were applicable to the criterion's
functionality (80 FR 62705 through 62707). In doing so, we established
the current Privacy and Security Certification Framework, which has
been in place for the past 10 years. Under this framework, health IT
developers have two options for meeting requirements: build the
capabilities themselves natively into their certified health IT; or
provide system documentation to demonstrate that the certified health
IT could integrate (via service interfaces) with required privacy and
security capabilities (80 FR 62707).
We have come to the conclusion that, despite the Certification
Program providing various certification flexibilities and approaches to
accommodate the privacy and security certification criteria (i.e.,
different approaches for the 2011, 2014 and 2015 Editions), the costs
and burden of these Certification Program requirements far exceed their
intended purpose and benefits.
First, we have found that health IT developers have changed their
development processes to build in privacy and security capabilities to
meet these certification requirements rather than attempting to
demonstrate that their technology could interface with other health IT
that provides these capabilities. This has led to negative experiences
for health care providers who have sought to use a best-of-breed, non-
certified security technology to work across their deployed enterprise
(e.g., a third-party audit log).
Second, as certified health IT (which is generally EHR-focused
technology) is often implemented in enterprise-wide settings (e.g.,
group practices, large health care systems, multi-provider cloud-
supported services), such certified health IT cannot in isolation, or
independently, provide the necessary privacy and security capabilities
for HIPAA Security Rule compliance across all relevant technologies of
the enterprise-wide setting.
Third, while certified health IT has always been ``linked'' to the
Medicare Promoting Interoperability Program and the MIPS Promoting
Interoperability performance category, those programs have not required
participating health care providers to use or implement the privacy and
security capabilities included in certified health IT for purposes of
meeting the security risk analysis measure. Rather, the health care
providers must ``have'' such certified health IT. As such and as
discussed in more detail below, health care providers participating in
the Medicare Promoting Interoperability Program or the MIPS Promoting
Interoperability performance category are required to adopt certified
capabilities that they may not use because, for example, they may
prefer a non-certified security health IT product to meet their overall
security needs under relevant HIPAA Security Rule requirements.
Fourth, many stakeholders have overinterpreted the Certification
Program's limited scope and policy purpose with respect to health IT
security and instead assumed that the Certification Program assessed
discrete specific security capabilities at significant depths, such as
when and how the capabilities are implemented in health care provider
or system settings. For example, stakeholders have expressed incorrect
expectations of certified health IT and developers, such as
expectations that the Certification Program required health IT
developers of certified health IT to implement and conduct penetration
testing of certified health IT or ensure that certified authentication
and authorization capabilities protect against known or unknown
vulnerabilities. In contrast, and to allow for significant scalable
deployment flexibility, certified heath IT must only, for example,
demonstrate support for basic authentication and role-based access
control.
Finally, there remains a disconnect between health IT certified to
the privacy and security certification criteria under the Certification
Program and the implementation and compliance responsibilities of most
purchasers and users of certified health IT with the HIPAA Privacy and
Security Rule requirements. This disconnect has led to the introduction
of unnecessary regulatory burden and duplication, as well as
unwarranted opportunity costs for innovation. As we noted above and in
our rulemakings related to the privacy and security certification
criteria, the adoption of health IT certified to the privacy and
security certification criteria does not guarantee compliance with the
HIPAA Privacy and Security Rule requirements. Further, the adoption of
health IT certified to the privacy and security certification criteria
does not serve as an affirmative defense, has not been identified as a
mitigating factor in assessing HIPAA civil money penalties, and does
not exempt a HIPAA-regulated entity from having to comply with any
applicable provision of the HIPAA Privacy or Security Rules. These
facts alone have created unnecessary burden for health care providers
that adopt
[[Page 60990]]
certified health IT and health IT developers of certified health IT
that also meet the definition of a covered entity or business
associate, respectively, and are subject to the HIPAA Privacy and
Security Rules.\40\ In fact, we have heard from stakeholders both
arguing that our certification requirements go beyond the HIPAA
Security Rule requirements (75 FR 44619, 80 FR 62707) or do not go far
enough in meeting HIPAA Privacy Rule and Security Rule requirements (80
FR 62691, 62706). As such, our Certification Program requirements are
diverting financial resources and efforts from innovative, agile, and
comprehensive solutions that can address the threats faced by health
care providers and meet their regulatory obligations under the HIPAA
Privacy and Security Rules. By removing the privacy and security
certification requirements under the Certification Program, we will
provide health IT developers with the flexibility to innovate in this
area and to develop new solutions to address the needs of their
customers. Such an approach should also spur competition and give
health care providers, including small practices, the opportunity to
choose the best privacy and security technologies that fit their needs
at the best price versus being forced to accept those capabilities
included in certified health IT that may not fit their health
information privacy and security needs for various reasons.
---------------------------------------------------------------------------
\40\ 45 CFR 160.103 (definitions of ``covered entity'' and
``business associate'').
---------------------------------------------------------------------------
We will continue to collaborate with our colleagues in HHS to
promote privacy and security and to strengthen the nation's critical
health care infrastructure. Equally, we are not completely foregoing
the adoption of privacy and security capabilities within the
Certification Program. Instead, going forward, we intend to prioritize
the adoption of privacy and security capabilities that are fit for
purpose, use case specific, and deliver much needed technical
consistency in the market when paired with specific conformance
requirements. For example, as we pursue more API-focused certification
criteria, if the standards and implementation guides adopted for them
do not specify or leave optional specific security requirements, we may
look to add further constraints (e.g., multi-factor authentication
support). But in all cases, we intend to make security capability
conformance a built-in part of a certification criterion's conformance
and not the separate and stand-alone conformance assessment that it is
today. With this planned approach in mind, we also request comment on
an alternative proposal as discussed below.
In lieu of removing, on the effective date of a subsequent final
rule, all of the privacy and security certification criteria in Sec.
170.315(d) and the associated Privacy and Security Certification
Framework under Sec. 170.550(h), we would retain the ``auditable
events and tamper resistance'' (Sec. 170.315(d)(2)), ``audit
report(s)'' (Sec. 170.315(d)(2)), and ``auditing actions on health
information'' (Sec. 170.315(d)(10)) certification criteria and
associated Privacy and Security Certification Framework certification
requirements. These certification criteria and included functionality
may serve to help identify fraud and abuse. The functionality may also
support health care provider compliance obligations and investigations
by relevant entities, including both civil and criminal matters at the
federal and state levels. Identifying and addressing fraud and abuse
increases confidence in the nation's health care system, reduces
inappropriate and wasteful spending, and protects taxpayer dollars when
it comes to government spending on health care.
We welcome feedback on these proposals.
5. Patient Engagement Certification Criteria
a. View, Download, and Transmit to a 3rd Party
We propose to revise the ``view, download, and transmit to 3rd
party'' (VDT) certification criterion in three ways as described below.
These proposed revisions, if finalized, would be effective as of the
effective date of a subsequent final rule.
We first included the Web Content Accessibility Guidelines (WCAG
2.0) standard as a requirement of the view, download, and transmit to
3rd party (VDT) certification criterion (Sec. 170.315(e)(1)) in the
2014 Edition. Specifically, the VDT certification criterion viewing
capability required conformance to WCAG Level A (77 FR 54179). This
provided an accessibility baseline for health IT certified to the
criterion. With the 2015 Edition, we proposed compliance with WCAG
Level AA (as we did for the 2014 Edition) but finalized a policy that
gave developers the option of demonstrating conformance with either
Level A or Level AA to meet the certification requirements (80 FR
62660).
We now propose to remove the WCAG conformance requirement from the
certification criterion (found in Sec. 170.315(e)(1)(i)). As noted
above, the WCAG baseline certification standard of Level A was adopted
with the 2014 Edition in 2012 and has been part of the VDT
certification criterion since that time. The functionality is now
sufficiently widespread among certified health IT and health care
providers who adopt such technology. This is true because the VDT
certification criterion has been part of the CEHRT definitions and
specifically supports the patient access measure under the Medicare
Promoting Interoperability Program and MIPS Promoting Interoperability
performance category since the 2014 Edition. By removing the WCAG
certification requirement, health IT developers of health IT currently
certified to Sec. 170.315(e)(1) will have the opportunity to consider
other innovative ways to provide patients with the viewing
functionality. To this point, commenters noted in response to the 2014
Edition WCAG proposals that most patients want functions and content
provided in a more visually appealing manner than the WCAG standard
allows. Further, as we noted in the 2011 Edition Interim Final Rule and
again in response to comments on the 2011 Edition Interim Final Rule,
in providing patients with access to their online health information,
the accessibility requirements of the Americans with Disabilities Act
of 1990 and Section 504 of the Rehabilitation Act of 1973 still apply
to entities covered by these federal civil rights laws (75 FR 2036, 75
FR 44643). In addition, Section 1557 of the Patient Protection and
Affordable Care Act (Affordable Care Act) prohibits covered entities
from subjecting individuals to certain forms of discrimination,
including on the grounds prohibited by Section 504 of the
Rehabilitation Act, in any health program or activity.\41\ Health IT
developers and other health programs or activities who receive Federal
financial assistance under the Certification Program or other federal
programs likely qualify as covered entities \42\ under Section 1557 and
would be required to comply with applicable accessibility requirements.
Under Section 504 of the Rehabilitation Act, recipients of financial
assistance from HHS must conform to certain accessibility requirements,
including but not limited to using the WCAG 2.1
[[Page 60991]]
AA success criteria for web content and mobile applications, as
detailed in 45 CFR 84.82 through 84.89. Additionally, under Section 508
of the Rehabilitation Act (Pub. L. 93-112; Sep. 26, 1973), HHS must
ensure the information and communication technology it develops,
procures, maintains, or uses, allows comparable access and use for
people with disabilities, including by conforming to the success
criteria of WCAG 2.0 AA. See 29 U.S.C. 794d; 36 CFR part 1194. As such,
we expect health IT developers will continue to meet these requirements
and provide the necessary accessibility within their products certified
to the VDT certification criterion.
---------------------------------------------------------------------------
\41\ https://www.ecfr.gov/current/title-45/part-92#p-92.4(Health%20program%20or%20activity).
\42\ https://www.ecfr.gov/current/title-45/part-92#p-92.4(Covered%20entity).
---------------------------------------------------------------------------
We also propose to remove the VDT requirement in Sec.
170.315(e)(1)(ii)(A)(2) to conform with any Network Time Protocol (NTP)
standard for purposes of ``date and time each action occurred'' under
the activity log. In the HTI-1 Final Rule, we revised the requirement
from conformance with the Network Time Protocol v4 of the RFC 5905
standard to compliance with any Network Time Protocol standard (89 FR
1283; Sec. 170.210(g)). As a result, health IT could be certified by
demonstrating that it could use any NTP to synchronize clocks for time
accuracy. However, we have received feedback over the years from
developers stating that the requirement should not be part of
certification because the functionality was not native to the EHR
technology (rather part of the operating system within which the EHR
technology runs) and was unnecessary for certification because EHRs use
of underlying operating system clocks is commonplace (88 FR 23811).
Consistent with our overall goal to reduce regulatory burden, we agree
that there is currently little value, and unnecessary burden, in
maintaining the conformance requirement as part of certification. We do
not expect that developers will stop using NTP with their certified
health IT. Rather, we expect that developers will continue to use NTPs,
such as Microsoft's MS-SNTP, due to ongoing evolution in the industry.
We propose to remove and reserve Sec. 170.315(e)(1)(i)(A)(1)
because the requirement has an expiration date of December 31, 2025,
which expires by the time a subsequent final rule will be issued.
Additionally, we similarly propose to revise Sec.
170.315(e)(1)(i)(B)(1) and (2) to remove references to Sec.
170.205(a)(5) because the standard codified in this paragraph also has
an expiration date of December 31, 2025. Finally, we propose to provide
a heading for the paragraph at Sec. 170.315(e)(1)(i), which would be
``general.'' This would align the paragraph with similar level
paragraphs that have headings (Sec. 170.315(e)(1)(ii) and (iii)) and
would be compliant with the Office of the Federal Register Drafting
Handbook.
We welcome comments on these proposals.
b. Patient Health Information Capture
We propose to remove the ``patient health information capture''
certification criterion in Sec. 170.315(e)(3) with an effective date
of January 1, 2027, and to reserve that section. The patient health
information capture certification criterion allows health care
providers to incorporate unstructured patient generated health data or
data from a non-clinical setting into a patient record. The criterion
is not currently included in the Base EHR definition; however, the
criterion is included in CEHRT definitions established by CMS for the
Medicare Promoting Interoperability Program (42 CFR 495.4) and the MIPS
Promoting Interoperability performance category (42 CFR 414.1305).
The patient health information capture certification criterion was
first adopted in the 2015 Edition Health IT Certification Criteria,
2015 Edition Base Electronic Health Record (EHR) Definition, and ONC
Health IT Certification Program Modifications Final Rule (80 FR 62602).
The criterion replaced the Sec. 170.314(a)(17) advance directives and
applied to various patient health information documents (80 FR 62661).
In the 2015 Edition Final Rule, we stated that a Health IT Module would
need to enable a user to: (1) identify (e.g., label health information
documents as advance directives and birth plans), record (capture and
store) and access (ability to examine or review) patient health
information documents; (2) reference and link to patient health
information documents; and (3) record and access information directly
and electronically shared by a patient. This criterion was specifically
included in the CEHRTdefinition to ensure, at a minimum, providers
participating in the EHR Incentive Programs (now the Medicare Promoting
Interoperability Program and the MIPS Promoting Interoperability
performance category) had this capability.
The intent of the criterion is to establish at least one means for
accepting patient health information directly and electronically from
patients in the most flexible manner possible (80 FR 62662). The
criterion did not define the types of health information that could be
accepted as we believed it should be as broad as possible and could be
documents or health information from devices or applications. The
devices and applications could include home health or personal health
monitoring devices, fitness and nutrition applications, or a variety of
other devices and applications. In addition, patient health information
could be accepted directly and electronically through a patient portal,
an API, or even email (80 FR 62662). As adopted, we anticipated health
IT developers would develop innovative and efficient ways to meet this
criterion and simultaneously support providers accepting health
information from patients.
We have reviewed and evaluated the patient health information
capture certification criterion in Sec. 170.315(e)(3), seeking to
identify ways to reduce burden while still supporting our policy goals.
As we have stressed in prior rulemaking, we take an incremental
approach to improving health IT interoperability and performance,
relying on factors such as market prevalence and industry readiness to
harmonize current and future standards and phase out standards and
certification criteria as needed (75 FR 2021). Our review of industry
adoption of the patient health information capture certification
criterion has found that the capabilities described in the criterion
are widely implemented (as discussed above in section III.A) and used
in health IT at this time, suggesting that these capabilities will
remain in health IT products even if the corresponding criterion is
removed from the Certification Program. We also have seen indications
that removing the criterion from the Certification Program could spur
greater development and innovation in this area.
We have concluded that removing the patient health information
capture certification criterion in Sec. 170.315(e)(3) on January 1,
2027, would reduce administrative burden as well as burden for health
IT developers of certified health IT and health care providers while
still allowing us to achieve our policy goals. There are other
certification criteria that support patient engagement, such as the
2015 Edition view, download, and transmit to 3rd party and ``API''
certification criteria. We have seen developers integrate the
functionality in the patient health information capture certification
criterion as part of other patient engagement features, such as patient
portals. With these considerations in mind, we believe removing this
criterion from the Certification Program will help reduce burden and
costs, while also spurring further innovations
[[Page 60992]]
in patient engagement. Because the certification criterion in Sec.
170.315(e)(3) is a requirement for CEHRT definitions established by
CMS, we believe a transition date is needed. Therefore, we propose to
remove the patient health information capture certification criterion
in Sec. 170.315(e)(3) effective January 1, 2027. We welcome feedback
on this proposal.
6. Public Health Certification Criteria
a. Transmission to Cancer Registries
We propose to remove the ``transmission to cancer registries''
certification criterion in Sec. 170.315(f)(4) with an effective date
of January 1, 2027, and reserve that section. This criterion assesses
whether a Health IT Module can properly create and format cancer case
information for electronic transmission according to a CDA-based
implementation specification for reporting to public health agencies.
In the 2014 Edition Final Rule, we expanded the public health-related
standards and certification criteria to include a criterion for
transmission to cancer registries in Sec. 170.314(f)(6) that we
designated as optional for Complete EHR certification (77 FR 54195). We
stated that we proposed this criterion to support a new meaningful use
objective and measure for reporting cancer cases to cancer registries
(77 FR 54194). In the 2015 Edition Final Rule, we finalized a revised
transmission to cancer registries criterion in Sec. 170.315(f)(4)
which was no longer labeled as optional and required updated standards
(80 FR 62666), and in the HTI-1 Final Rule we further updated the
associated vocabulary standards (89 FR 1208). The standards currently
referenced in the criterion include the Health Level 7 (HL7[supreg])
Implementation Guide for CDA[supreg] Release 2: Reporting to Public
Health Cancer Registries from Ambulatory Healthcare Providers, Release
1, DSTU Release 1.1, April 2015 in Sec. 170.205(i)(2), the SNOMED
CT[supreg], U.S. Edition, March 2022 Release in Sec. 170.207(a)(1),
and the Logical Observation Identifiers Names and Codes (LOINC[supreg])
Database Version 2.72, February 16, 2022 in Sec. 170.207(c)(1). In the
Meaningful Use Stage 3 Final Rule, the transmission to cancer
registries certification criterion was identified as one of the
criteria that eligible professionals could utilize to report the Public
Health Registry measure in the EHR Incentive Programs (80 FR 62882).
Subsequently, CMS stated that this criterion could be used to report on
the Public Health Registry measure that was included in the MIPS
Advancing Care Information performance category (later renamed the MIPS
Promoting Interoperability performance category) (81 FR 77236).
Currently, MIPS eligible clinicians that report on the Public Health
Registry measure may earn optional bonus points for submitting this
data.\43\
---------------------------------------------------------------------------
\43\ See the CY 2026 PFS Proposed Rule Table 60, available at
https://www.federalregister.gov/d/2025-13271/page-32744.
---------------------------------------------------------------------------
We have reviewed and evaluated the transmission to cancer
registries certification criterion in Sec. 170.315(f)(4), seeking to
identify ways to reduce burden while still supporting our policy goals.
We recognize trends within the industry that support removal of this
criterion. Of note, there is specific work being done to move cancer
registry reporting from CDA to FHIR through the Helios FHIR Accelerator
and updates to the Central Cancer Registry Reporting IG in support of
more efficient tumor abstract completion and supportive harmonization
and standardization of data elements through USCDI+ Cancer.\44\ Given
the movement toward these promising modernization efforts that rely on
FHIR rather than CDA, we anticipate health IT developers will find
maintaining CDA development support to be both duplicative and a
significant burden.
---------------------------------------------------------------------------
\44\ https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/index.html.
---------------------------------------------------------------------------
We believe that removing the certification criterion in Sec.
170.315(f)(4) would reduce burden and encourage the ongoing evolution
in cancer registry reporting by offering health IT developers space to
move toward FHIR standards and modern reporting solutions, further
encouraging innovation. We propose a January 1, 2027, effective date
for the removal of the transmission to cancer registries certification
criterion in Sec. 170.315(f)(4). We welcome feedback on these
proposals.
b. Transmission to Public Health Agencies--Electronic Case Reporting
We propose to revise the ``transmission to public health agencies--
electronic case reporting'' (eCR) certification criterion in Sec.
170.315(f)(5). This criterion enables a user to create case reports
that can be transmitted electronically to public health agencies. In
the 2015 Edition Final Rule, we included a new certification criterion
in Sec. 170.315(f)(5) with functional requirements to support the
electronic transmission of case reporting information to public health
agencies (80 FR 62667). When we originally proposed this criterion, we
highlighted several goals, including linking EHR data with other data
in a structured way in order to improve quality, safety, population
health, and research, as well as making case reporting from providers
to public health agencies more efficient (80 FR 16855). In the 2015
Edition Final Rule, we noted commenter concerns with the proposed
standards and recommendations that case reporting continue as a public
health reporting option for the EHR Incentive Programs, but without a
requirement to use a particular standard (80 FR 62667). We further
noted ongoing advancements in FHIR standards and stated that in order
to permit flexibility and accommodate evolution, we would not finalize
a required standard (80 FR 62667).
In the HTI-1 Final Rule, we finalized a policy to require support
for either a FHIR or CDA standard in order to provide technical design
flexibility while still supporting the existing CDA-based landscape,
and we established a transition period from functional requirements to
standards-based requirements (89 FR 1227). Specifically, we finalized
requirements in Sec. 170.315(f)(5)(ii) to create case reports
consistent with either the HL7 FHIR eCR IG in Sec. 170.205(t)(1) or
the HL7 CDA eICR IG in Sec. 170.205(t)(2), and to receive, consume,
and process a case report response formatted to either the HL7 FHIR eCR
IG in Sec. 170.205(t)(1) or the HL7 CDA RR IG in Sec. 170.205(t)(3)
(89 FR 1227). We stated that we would continue monitoring the
development of standards for case reporting, and that as FHIR-based
standards advanced we intended to transition solely to a FHIR-based
approach for case reporting in future rulemaking (89 FR 1227). We also
stated in the HTI-1 Final Rule, in response to comments that technology
used by public health agencies may not be able to accept incoming FHIR-
based reports, that we understood commenters' ``concerns related to
performance, scalability, and maintenance, and will monitor standards
development and implementation to inform future rulemaking'' (89 FR
1229).
Consistent with E.O. 14192, ASTP/ONC published the ``Electronic
Case Reporting Certification Criterion Enforcement Discretion Notice''
on July 31, 2025.\45\ The enforcement discretion notice stated that for
calendar year 2025, ASTP/ONC will not exercise its direct review
authority for any non-conformity arising solely from certified health
IT not complying with the standards in Sec. 170.315(f)(5) as long as
the health IT
[[Page 60993]]
remains conformant with either Sec. 170.315(f)(5)(i) or with
requirements in Sec. 170.315(f)(5)(ii) as specified in the notice. The
requirements in Sec. 170.315(f)(5)(ii) specified in the enforcement
discretion notice include requirements to: consume and process case
reporting trigger codes and identify a reportable patient visit or
encounter based on a match with a trigger code value set (e.g., table);
create a case report; receive, consume, and process a case report
response; and, transmit a case report electronically to a system
capable of receiving a case report. Additionally, the enforcement
discretion notice stated that for calendar year 2025, ASTP/ONC will not
take any enforcement action against an ONC-ACB for certifying a Health
IT Module that is presented for certification to Sec. 170.315(f)(5)
where the Health IT Module demonstrates and maintains conformance with
Sec. 170.315(f)(5)(i) or the requirements in Sec. 170.315(f)(5)(ii)
as specified above. For calendar year 2026, the enforcement discretion
notice stated that ASTP/ONC will not exercise its direct review
authority for any non-conformity arising solely from certified health
IT not complying with the standards in Sec. 170.315(f)(5)(ii) as long
as the health IT remains conformant with the requirements in Sec.
170.315(f)(5)(ii) as specified above. The enforcement discretion notice
also stated that for calendar year 2026, ASTP/ONC will not take any
enforcement action against an ONC-ACB for certifying a Health IT Module
that is presented for certification to Sec. 170.315(f)(5) where the
Health IT Module demonstrates and maintains conformance to the
requirements in Sec. 170.315(f)(5)(ii) as specified above. The
enforcement discretion notice stated that it remains in effect until
December 31, 2026, or until the Department completes a deregulatory
action to revise Sec. 170.315(f)(5).
---------------------------------------------------------------------------
\45\ https://www.healthit.gov/topic/electronic-case-reporting-certification-criterion-enforcement-discretion-notice.
---------------------------------------------------------------------------
We have reviewed and evaluated the transmission to public health
agencies--electronic case reporting certification criterion in Sec.
170.315(f)(5) with a focus on reducing burden while still supporting
our policy priorities. We understand from developers of certified
health IT that there may be issues with readiness to adopt these
standards as well as concerns regarding the performance, scalability,
or maintenance of these standards. We also note that the Sec.
170.315(f)(5) certification criterion is required to complete the
Electronic Case Reporting measure in the MIPS Promoting
Interoperability performance category and the Medicare Promoting
Interoperability Program.\46\ We note that in the CY 2026 PFS Final
Rule, CMS finalized a policy to suppress the measure for performance
for MIPS eligible clinicians meeting the requirements of the MIPS
Promoting Interoperability performance category for the CY 2025
performance period, and eligible hospitals and CAHs participating in
the Medicare Promoting Interoperability Program for the EHR reporting
period in CY 2025 (90 FR 49892).
---------------------------------------------------------------------------
\46\ See the CY 2026 PFS Proposed Rule Table 62, available at
https://www.federalregister.gov/d/2025-13271/p-3055 and the FY2026
IPPS/LTCH PPS Final Rule Table X.F.-05 available at https://www.federalregister.gov/d/2025-14681/p-4161.
---------------------------------------------------------------------------
We propose to revise the eCR certification criterion to be a
functional requirement in order to reduce burden and allow for industry
innovation. In particular, we propose to rescind the expiration date
for the functional requirements defined in Sec. 170.315(f)(5) as of
the effective date of a subsequent final rule. We propose to revise the
introductory text of the criterion to enable a user to create a case
report for electronic transmission meeting the functional requirements
described in paragraph (f)(5)(i) of this section. Additionally, we
propose to remove the standards-based requirements defined in Sec.
170.315(f)(5)(ii) as of the effective date of a subsequent final rule
and reserve that section. We welcome feedback on these proposals.
c. Transmission to Public Health Agencies--Antimicrobial Use and
Resistance Reporting
We propose to revise the ``transmission to public health agencies--
antimicrobial use and resistance reporting'' certification criterion in
Sec. 170.315(f)(6). This criterion assesses whether Health IT Modules
can create and properly format an antimicrobial use and resistance
report for electronic transmission, following specified sections of a
CDA-based implementation guide. In the 2015 Edition Final Rule, we
expanded the public health-related standards and certification criteria
to include a new criterion for transmission of antimicrobial use and
resistance reporting data to public health registries (80 FR 62668). We
stated in the 2015 Edition Final Rule that the antimicrobial use and
resistance reporting data is only collected by CDC rather than at the
jurisdictional level (80 FR 62668). The transmission to public health
agencies--antimicrobial use and resistance reporting certification
criterion currently references the Health Level 7 (HL7[supreg])
Implementation Guide for CDA[supreg] Release 2--Level 3: Healthcare
Associated Infection (HAI) Reports, Release 1, U.S. Realm, August 2013
standard in Sec. 170.205(r)(1) and only requires conformance to
certain sections of the implementation guide. The Sec. 170.315(f)(6)
certification criterion is required for completing the Antimicrobial
Use Surveillance and Antimicrobial Resistance Surveillance measures in
the Medicare Promoting Interoperability Program for eligible hospitals
and CAHs.\47\
---------------------------------------------------------------------------
\47\ See the FY2026 IPPS/LTCH PPS Final Rule Table X.F.-05
available at https://www.federalregister.gov/d/2025-14681/p-4161.
---------------------------------------------------------------------------
We have reviewed and evaluated the transmission to public health
agencies--antimicrobial use and resistance reporting certification
criterion in Sec. 170.315(f)(6) with a focus on achieving burden
reduction while still supporting our policy goals. We have identified
trends within the industry regarding a shift in reporting approach that
supports revision of this criterion.\48\ As CDC works to move reporting
to FHIR-based standards,\49\ we believe maintaining an outdated CDA-
based standard in the criterion would impose regulatory burden on
health IT developers that are seeking to support FHIR-based approaches
to reporting. We propose to revise the criterion requirements to be
functional only and remove the reference to the standard in Sec.
170.205(r)(1) as of the effective date of a subsequent final rule. This
would reduce administrative and development burden by allowing progress
in line with other use cases, the use of more recent standards, and
modern approaches to reporting. We note that, as with other criteria
that include solely functional requirements, use of a specific standard
would not be required to meet the proposed requirements of the
criterion.
---------------------------------------------------------------------------
\48\ https://stacks.cdc.gov/view/cdc/
118849#:~:text=July%2027%2C%202021,2021%20Export%20RIS%20Citation%20I
nformation.
\49\ For information on CDC's National Healthcare Safety Network
(NHSN) antimicrobial use and resistance reporting options see
https://www.cdc.gov/nhsn/psc/aur/index.html.
---------------------------------------------------------------------------
We believe that revising the certification criterion in Sec.
170.315(f)(6) to functional requirements only would reduce burden and
allow for standards advancement and adoption of FHIR-based reporting to
move more quickly. We welcome feedback on these proposals.
d. Transmission to Public Health Agencies--Health Care Surveys
We propose to remove the ``transmission to public health agencies--
health care surveys''
[[Page 60994]]
certification criterion in Sec. 170.315(f)(7) with an effective date
of January 1, 2027. This criterion supports the transmission of health
care surveys directly to the CDC. In the 2015 Edition Final Rule, we
expanded the public health-related standards and certification criteria
to include a new criterion for transmission of health care surveys to
public health agencies (80 FR 62669). We clarified in the 2015 Edition
Final Rule that the finalized implementation guide for this criterion
is intended for the transmission of survey data for both the National
Ambulatory Medical Care Survey (NAMCS) and the National Hospital
Ambulatory Medical Care Survey (NHAMCS) (80 FR 62668). We also
clarified that templates included in the implementation guide align
with the CDA standard (80 FR 62668). We stated in the 2015 Edition
Final Rule that data covered by this criterion will only be collected
by the CDC rather than at the jurisdictional level (80 FR 62669). The
certification criterion in Sec. 170.315(f)(7) currently references the
Health Level 7 (HL7[supreg]) Implementation Guide for CDA[supreg]
Release 2: National Health Care Surveys (NHCS), Release 1--US Realm,
Draft Standard for Trial Use, December 2014 standard in Sec.
170.205(s)(1). We note that the Sec. 170.315(f)(7) certification
criterion is optional to complete the Public Health Registry measures
in the MIPS Promoting Interoperability performance category and the
Medicare Promoting Interoperability Program.\50\
---------------------------------------------------------------------------
\50\ See the CY 2026 PFS Proposed Rule Table 62, available at
https://www.federalregister.gov/d/2025-13271/p-3055 and the FY2026
IPPS/LTCH PPS Final Rule Table X.F.-05 available at https://www.federalregister.gov/d/2025-14681/p-4161.
---------------------------------------------------------------------------
We have reviewed and evaluated the transmission to public health
agencies--health care surveys certification criterion in Sec.
170.315(f)(7) with a goal of reducing burden while still supporting our
policy priorities. We are also seeking to align with CDC priorities
around data modernization and encouraging the use of FHIR-based
approaches. The removal of this criterion would encourage industry to
modernize and scale their reporting approach alongside CDC's efforts.
We believe that removing the certification criterion in Sec.
170.315(f)(7) would reduce burden while at the same time honor our
policy goals to ensure health IT interoperability and functionality.
Hospitals and clinicians have been actively submitting these surveys
for over a decade and continue to meet the technical requirements set
by CDC, even when these requirements outpace the certification
criteria.\51\ We propose a January 1, 2027, effective date for the
removal of the transmission to public health agencies--health care
surveys criterion in Sec. 170.315(f)(7). We welcome feedback on these
proposals.
---------------------------------------------------------------------------
\51\ See https://build.fhir.org/ig/HL7/fhir-health-care-surveys-reporting-ig/.
---------------------------------------------------------------------------
7. Design and Performance Certification Criteria
a. Automated Numerator Recording
In the 2015 Edition Final Rule (80 FR 62669), we adopted a
certification criterion in Sec. 170.315(g)(1) that requires the
capability to create a report or file that enables a user to review the
patients or actions that would make the patient or action eligible to
be included in the numerator of a percentage-based measure in the MIPS
Promoting Interoperability performance category and the Medicare
Promoting Interoperability Program. We first adopted this capability
for the 2014 edition in Sec. 170.314(g)(1) to complement the
``automated measure calculation'' certification criterion to support
the associated meaningful use objectives in the EHR Incentive Programs.
In the Cures Act Final Rule (85 FR 25708), we updated the references to
the EHR Incentive Programs in the criterion to reflect CMS' updates to
the name of the Programs, which are now the Medicare Promoting
Interoperability Program and the MIPS Promoting Interoperability
performance category.
We propose to remove the ``automated numerator recording''
certification criterion and reserve Sec. 170.315(g)(1). We have
reviewed and evaluated the certification criterion in Sec.
170.315(g)(1), seeking to identify ways to reduce burden while still
supporting our policy goals. Health IT developers that facilitate
customer participation in the Medicare Promoting Interoperability
Program and the MIPS Promoting Interoperability performance category
have been supporting the recording of numerator data associated with
the measures and its previous iterations for many years. CMS
establishes the measures and provides any additional information about
how the numerator should be recorded through rulemaking and subsequent
communications. ASTP/ONC uses the measure specifications established by
CMS to develop testing procedures for health IT developers to certify
their products to the automated numerator recording certification
criterion. Certification of health IT to record the actions of the
numerator has played an important role in ensuring health IT developers
consistently implemented the measures established by CMS. However, we
believe that developers now have significant experience with
implementing CMS requirements, and they will continue to ensure that
the measures are recorded in a fashion that meets CMS requirements to
ensure that their customers can successfully participate in the absence
of additional testing requirements under the ONC Health IT
Certification Program. If our removal of the automated numerator
recording certification criterion is finalized as proposed, we will
work with CMS to ensure relevant guidance and materials for existing
measures is consolidated as part of the informational materials that
CMS maintains regarding measures in the Medicare Promoting
Interoperability Program and MIPS Promoting Interoperability
performance category.
We believe that removing the certification criterion in Sec.
170.315(g)(1) will reduce administrative burden, as well as burden for
health IT developers and health care providers while still allowing us
to achieve our policy goals. Because the certification criterion in
Sec. 170.315(g)(1) is specified in the definitions of CEHRT
established by CMS for the Medicare Promoting Interoperability Program
(42 CFR 495.4) and the MIPS Promoting Interoperability performance
category (42 CFR 414.1305), we believe that a transition date is
needed. Therefore, we propose to remove the automated numerator
recording certification criterion as of January 1, 2027, and reserve
Sec. 170.315(g)(1). We welcome comments on this proposal.
b. Automated Measure Calculation
In the 2015 Edition Final Rule (80 FR 62669 through 62670), we
adopted the ``automated measure calculation'' certification criterion
in Sec. 170.315(g)(2) that requires the capability to record the
numerator and denominator and create a report including the numerator,
denominator, and resulting percentage associated with each applicable
measure in the Medicare Promoting Interoperability Program and the MIPS
Promoting Interoperability performance category. This capability was
first adopted as a 2011 Edition certification criterion to support the
associated meaningful use stage 1 objectives and subsequently adopted
in the 2014 Edition in Sec. 170.314(g)(2) (77 FR 54184). In the Cures
Act Final Rule (85 FR 25708), we updated the references to the EHR
Incentive Programs in the certification criterion to reflect CMS'
updated names for the Medicare Promoting Interoperability Program and
the MIPS Promoting Interoperability
[[Page 60995]]
performance category. In the HTI-2 Final Rule (89 FR 101809), we
inadvertently removed and reserved Sec. 170.315(g)(2) due to an
amendatory instruction drafting error. We corrected this error through
a technical correction in the HTI-4 Final Rule published on August 4,
2025, which was included in the CY26 CMS IPPS/LTCH PPS Final Rule as a
rider (90 FR 37182).
We now propose to remove the ``automated measure calculation''
certification criterion and reserve Sec. 170.315(g)(2) with an
effective date of January 1, 2027. We have reviewed and evaluated the
certification criterion in Sec. 170.315(g)(2), seeking to identify
ways to reduce burden while still supporting our policy goals. As with
the automated numerator recording certification criterion discussed
above, health IT developers that facilitate customer participation in
the Medicare Promoting Interoperability Program and the MIPS Promoting
Interoperability performance category have been supporting the
calculation of measures in the program and its previous iterations for
many years. CMS establishes these measures and provides any additional
information about how the measures should be calculated through
rulemaking and subsequent program communications. ASTP/ONC uses the
measure specifications established by CMS to develop testing procedures
for health IT developers to certify their products to the automated
measure calculation certification criterion. Certification of health IT
for measure calculation has played an important role in ensuring health
IT developers consistently implemented the measures established by CMS.
However, we believe that developers now have significant experience
with implementing CMS requirements, and that they will continue to
ensure that the measures are calculated in a fashion that meets CMS
requirements to ensure that their customers can successfully
participate in the absence of additional testing requirements under the
Certification Program. If our removal of the automated measure
calculation certification criterion is finalized as proposed, we will
work with CMS to ensure relevant guidance and materials for existing
measures is consolidated as part of the informational materials that
CMS maintains regarding measures in the Medicare Promoting
Interoperability Program and MIPS Promoting Interoperability
performance category.
We believe that removing the certification criterion in Sec.
170.315(g)(2) will reduce administrative burden for health IT
developers that support customer participation in the Medicare
Promoting Interoperability Program and MIPS Promoting Interoperability
performance category. Because the certification criterion in Sec.
170.315(g)(2) is specified in the definitions of CEHRT in 42 CFR
414.1305 and 495.4 and currently required for reporting of Promoting
Interoperability measures, we believe that a transition date is needed.
Therefore, we propose to remove and reserve the automated measure
calculation certification criterion in Sec. 170.315(g)(2) as of
January 1, 2027. We welcome comments on this proposal.
c. Safety Enhanced Design
We propose to remove the ``safety-enhanced design'' certification
criterion in Sec. 170.315(g)(3) and the reference to this
certification criterion in Sec. 170.550(g)(1) as of the effective date
of a final rule for this proposed rule. The safety-enhanced design
certification criterion specifies the user-centered design (UCD)
testing that must be applied to certain health IT capabilities
submitted for certification. Certification to this certification
criterion is conditional as its scope and applicability depends on the
other certification criteria for which a Health IT Module is presented
for certification. Section 170.315(g)(3) prescribes specific
requirements for how certified capabilities are designed or made
available to users. For example, during the design and development of
certified health IT, developers are required to apply UCD processes to
the capabilities reference in Sec. 170.315(g)(3). This certification
criterion is not included in the Base EHR definition in Sec. 170.102
or the definition of CEHRT established by CMS in 42 CFR 414.1305 and 42
CFR 495.4.
In the 2014 Edition Proposed Rule (77 FR 13842), we provided an
overview of the International Organization for Standardization's (ISO)
definition of usability and outlined that EHR technology certification
could introduce some improvements that we believed would enhance both
the safety and efficiency of CEHRT. This position mirrored statements
made by interested parties regarding a gap between optimal usability
and the usability offered by some EHR technologies at that time. In
November 2011, the Institute of Medicine (IOM) called on the Secretary
of HHS to specify the quality and risk management process requirements
that health IT vendors must adopt, with a particular focus on human
factors, safety culture, and usability. In the 2014 Edition Proposed
Rule, we proposed to focus on the process of UCD to improve overall
usability. We prioritized eight certification criteria \52\ and
associated capabilities to which the proposed certification criterion
would require UCD to be applied. We chose these eight because we
believed they posed the greatest risk for patient harm, and therefore,
the greatest opportunity for error prevention. We also noted that the
methods for how an EHR technology developer could employ UCD are well
defined in documents and requirements such as ISO 9241-11, ISO 13407,
ISO 16982, and NISTIR 7741. Our proposed approach sought to enable EHR
technology developers to choose their UCD approach and not to prescribe
specific UCD processes that would be required to meet this
certification criterion. We also proposed in the 2014 Edition Proposed
Rule (77 FR 13843), that testing to this certification criterion would
require EHR technology developers to document that their UCD
incorporates all the data elements defined in the Customized Common
Industry Format Template for EHR Usability Testing (NISTIR 7742).\53\
We noted that with respect to demonstrating compliance with this
certification criterion that this information would need to be
available to an ONC-ACB for review. Finally, we indicated that this
documentation would become a component of the publicly available
testing results on which a certification is based.
---------------------------------------------------------------------------
\52\ Sec. 170.314(a)(1) (CPOE); Sec. 170.314(a)(2) (drug-drug,
drug-allergy interaction checks); Sec. 170.314(a)(6) (medication
list); Sec. 170.314(a)(7) (medication allergy list); Sec.
170.314(a)(8) (clinical decision support); Sec. 170.314(a)(16)
(electronic medication administration record); Sec. 170.314(b)(3)
(electronic prescribing); and Sec. 170.314(b)(4) (clinical
information reconciliation).
\53\ http://www.nist.gov/manuscript-publication-search.cfm?pub_id=907312.
---------------------------------------------------------------------------
In the 2014 Edition Final Rule (77 FR 54187 through 54190), we
adopted Sec. 170.314(g)(3) as proposed, specifying that UCD must be
applied to each capability of an EHR technology that is associated with
the eight certification criteria named in the safety-enhanced design
certification criterion. In addition, we finalized that the information
from the NISTIR 7742 was required to be submitted for each of the
criteria specified in the 2014 Edition safety-enhanced design
certification criterion.
In the 2014 Edition Release 2 Final Rule, we revised the safety-
enhanced design certification criterion in to include three CPOE
certification criteria (79 FR 54436) and the clinical information
reconciliation and incorporation (CIRI) certification criterion (79 FR
54439).
In the 2015 Edition Proposed Rule (80 FR 16856), we proposed to
adopt a 2015
[[Page 60996]]
Edition safety-enhanced design certification criterion that reflected
updates to the 2014 Edition safety-enhanced design criterion. We
proposed to include 17 certification criteria (seven of which were new)
in the 2015 Edition safety-enhanced design certification criterion. For
each of the referenced certification criteria and their corresponding
capabilities presented for certification, we proposed to require that
UCD processes must be applied to satisfy the certification criterion.
For the 2015 Edition safety-enhanced design criterion, we further
proposed to add more specificity around requirements for the
information that must be provided to demonstrate compliance with this
certification criterion. For instance, we proposed in Sec.
170.315(g)(3)(ii) that information must be submitted on the specific
UCD processes used. We further proposed in Sec. 170.315(g)(3)(iii)
that a health IT developer must submit information about and findings
of the UCD testing conducted for each of the criteria specified in the
2015 Edition safety-enhanced design certification criterion. We
proposed that this information would become part of the test results
publicly available on CHPL.
In the 2015 Edition Final Rule (80 FR 62670), we adopted the
proposed safety-enhanced design certification criterion with
modifications. Modifications included adopting a reduced list of
criteria for inclusion in the safety-enhanced design certification
criterion \54\ and adopting the requirement that ONC-ACBs certify
Health IT Modules to Sec. 170.315(g)(3) consistent with the
requirements included in the certification criterion.
---------------------------------------------------------------------------
\54\ Sec. 170.315(a)(1) computerized provider order entry--
medications; Sec. 170.315(a)(2) computerized provider order entry--
laboratory; Sec. 170.315(a)(3) computerized provider order entry--
diagnostic imaging; Sec. 170.315(a)(4) drug-drug, drug-allergy
interaction checks; Sec. 170.315(a)(5) demographics; Sec.
170.315(a)(6) problem list; Sec. 170.315(a)(7) medication list;
Sec. 170.315(a)(8) medication allergy list; Sec. 170.315(a)(9)
clinical decision support; Sec. 170.315(a)(14) implantable device
list; Sec. 170.315(b)(2) clinical information reconciliation and
incorporation; and Sec. 170.315(b)(3) electronic prescribing.
---------------------------------------------------------------------------
We anticipate the removal of this criterion would reduce costs and
burden for health IT developers and health care providers. For example,
when pursuing certification, health IT developers must recruit a
minimum of ten participants, conduct the necessary testing, and submit
metrics for each certification criterion, for which they seek
certification, that is refenced within Sec. 170.315(g)(3). We refer
readers to section VIII (Regulatory Impact Analysis) of this proposed
rule for more detailed information on cost estimates of safety-enhanced
design and potential cost savings. In addition to reducing costs and
burden for health IT developers, we anticipate that removing this
certification criterion would allow health IT developers to redirect
time and resources towards more innovative approaches to support and
improve safety-enhanced design in their products. Additionally, we no
longer believe that this certification criterion provides the same
benefit to the regulatory burden profile that it did when first adopted
over ten years ago. In contrast, its presence in the Certification
Program has led to instances where administrative processes to fulfill
its requirements have delayed health IT developers from achieving
product certifications without added improvements in user-centered
design. In short, this certification criterion's impact has diminished
since it was first adopted. Moreover, compared to its burden, we have
seen little use of the transparent reporting associated with this
certification criterion (Sec. 170.523(f)(1)(xix)).
Consistent with E.O. 14192, ``Unleashing Prosperity Through
Deregulation,'' and the reasons we stated above, we believe it is
appropriate to remove this certification criterion. Therefore, we
propose to remove the safety-enhanced design certification criterion in
Sec. 170.315(g)(3) and the reference to this certification criteria in
Sec. 170.550(g)(1) as of the effective date of a subsequent final
rule. We welcome comments on our proposal.
d. Quality Management System
We propose to remove the ``quality management system'' (QMS)
certification criterion in Sec. 170.315(g)(4) and the reference to
this certification criteria in Sec. 170.550(g)(2) as of the effective
date of a final rule for this proposed rule. The QMS certification
criterion states for each capability that a technology includes and for
which that capability's certification is sought, the use of a QMS in
the development, testing, implementation, and maintenance of that
capability must be identified and satisfied in one of the following
ways: either the QMS used is established by the Federal government or a
standards developing organization (SDO) or the QMS used is mapped to
one or more QMS established by the Federal government or SDOs. Per
Sec. 170.550(g), this certification criterion is mandatory for all
certified Health IT Modules.
The 2014 Edition Proposed Rule (77 FR 13842) referenced a report by
the Institute of Medicine (IOM) in which IOM recommended that we
``[establish] quality management principles and processes in health
IT.'' Accordingly, we stated that we were considering including in the
final rule an additional certification criterion that would require an
EHR technology developer to document how their EHR technology
development processes either align with, or deviate from, certain
quality management principles and processes (77 FR 13843).
In the 2014 Edition Final Rule, we adopted a new quality management
system certification criterion in Sec. 170.314(g)(4) that was intended
as a first step to focus on QMS and build on it in an incremental
fashion (77 FR 54191). We finalized that all EHR technology certified
to the 2014 Edition certification criteria would need to be certified
to this certification criterion. In addition, we revised Sec. 170.550
to require that, when certifying EHR Modules to the 2014 Edition EHR
certification criteria, ONC-ACBs must certify EHR Modules to this
certification criterion.
In the 2015 Edition Proposed Rule (80 FR 16858), we proposed a
revised version of the QMS certification criterion in Sec.
170.315(g)(4). We proposed to require the identification of the QMS
used in the development, testing, implementation, and maintenance of
capabilities certified under the Certification Program. We proposed
that for a Health IT Module to be certified, the identified QMS must be
compliant with a quality management system established by the Federal
government or an SDO, or mapped to one or more quality management
systems established by the Federal government or SDOs. In the 2015
Edition Final Rule (80 FR 62672), we adopted the proposed version of
the QMS certification criterion in Sec. 170.315(g)(4). In addition, we
revised Sec. 170.550 to require ONC-ACBs to certify Health IT Modules
to the new criterion in Sec. 170.315(g)(4) when certifying to the 2015
Edition.
When we initially proposed this certification criterion in the 2014
Edition Proposed Rule, we understood that some EHR technology
developers already had quality management principles and processes in
place, but we did not believe, especially considering the IOM
recommendation, that the EHR technology industry consistently followed
such processes. Since the adoption of the QMS certification criterion,
we find that industry and other interested parties now widely employ
quality management principles. As an example,
[[Page 60997]]
an ISO 9001-certified quality management system provides a structured
set of requirements designed to support quality-focused business
operations.\55\ The ISO Survey 2023 \56\ showed that 26,833 ISO 9001
certificates were issued in the U.S., demonstrating widespread adoption
across diverse industries. Given these advances across industry, we
have determined that this certification criterion, and program
requirements that all Health IT Modules be certified to the criterion,
have become duplicative. Therefore, we propose to remove the criterion
in Sec. 170.315(g)(4) and the reference to this certification
criterion in Sec. 170.550(g)(2) as of the effective date of a
subsequent final rule. We welcome comments on our proposal.
---------------------------------------------------------------------------
\55\ https://amtivo.com/us/resources/insights/iso-9001-meaning-requirements-and-beginners-guide/.
\56\ https://www.iso.org/the-iso-survey.html.
---------------------------------------------------------------------------
e. Accessibility-Centered Design
We propose to remove the ``accessibility-centered design'' (ACD)
certification criterion in Sec. 170.315(g)(5) and the reference to
this certification criteria in Sec. 170.550(g)(3) as of the effective
date of a final rule for this proposed rule. This certification
criterion requires that all developers of Health IT Modules identify
and use a health IT accessibility-centered design standard or law in
the development, testing, implementation and maintenance of each
capability for which certification is sought. The removal of this
certification criterion, if finalized, would not exempt health IT
developers and providers from their independent obligations under
applicable federal civil rights laws, including Section 504 of the
Rehabilitation Act, Section 1557 of the Affordable Care Act, and the
Americans with Disabilities Act. The requirements of these civil rights
laws include, but are not limited to, providing individuals with
disabilities equal access to information and appropriate auxiliary aids
and services as provided in the applicable statutes and regulations.
In the 2015 Edition Proposed Rule, we proposed a new accessibility-
centered design certification criterion in Sec. 170.315(g)(8) (80 FR
16861). We proposed that this criterion would require the
identification of user-centered design standard(s) or laws for
accessibility that were applied, or complied with, in the development
of specific capabilities included in a Health IT Module or,
alternatively, the lack of such application or compliance. We proposed
to require that for each capability that a Health IT Module includes,
and for which that capability's certification is sought, the use of a
health IT accessibility-centered design standard or compliance with a
health IT accessibility law in the development, testing,
implementation, and maintenance of that capability must be identified.
We also proposed that the method(s) used to meet this proposed
certification criterion would be reported through the open data CHPL
and we proposed to revise Sec. 170.550 to require ONC-ACBs to certify
all Health IT Modules certified to the 2015 Edition to the
accessibility-centered design certification criterion.
The 2015 Edition Final Rule adopted the accessibility-centered
design (ACD) certification criterion as proposed, moving it to Sec.
170.315(g)(5) (80 FR 62673). Additionally, we finalized in Sec.
170.550 that ONC-ACBs must certify all 2015 Edition Health IT Modules
to the criterion in Sec. 170.315(g)(5).
In the 2015 Edition Proposed Rule we explained that the proposed
certification criterion would serve to increase transparency around the
application of user-centered design standards for accessibility to
health IT and the compliance of health IT with accessibility laws (80
FR 16861). We stated that this transparency would benefit health care
providers, consumers, government entities, and other stakeholders, and
would encourage health IT developers to pursue the application of more
accessibility standards and laws in product development that could lead
to improved usability for health care providers with disabilities and
health care outcomes for patients with disabilities. Since the adoption
of this certification criterion, we find that industry and other
interested parties have readily adopted this application of user-
centered design as an industry standard. For instance, according to
CHPL data, as of August 2025, every single active Certified Health IT
Module (721 total) was certified to Sec. 170.315(g)(5). The proposed
removal of this certification criterion would reduce the effort of
health IT developers to meet ongoing program requirements that
duplicate widely adopted accessibility-centered design practices,
allowing developers to refocus these resources on innovation and
meeting the needs of their clients and end users in other areas.
Therefore, we propose to remove the accessibility-center design
certification criterion in Sec. 170.315(g)(5) and the reference to
this certification criterion in Sec. 170.550(g)(3) as of the effective
date of a final rule for this proposed rule. As stated earlier, the
removal of this certification criterion, if finalized as proposed,
would not exempt health IT developers and providers from their
independent obligations under applicable federal civil rights laws,
including but not limited to, providing individuals with disabilities
equal access to information and appropriate auxiliary aids and
services. We welcome comments on our proposal.
f. Consolidated CDA Creation Performance
We propose to remove the certification criterion in Sec.
170.315(g)(6) and reserve that section. We also propose to remove Sec.
170.550(g)(4) which references the criterion, as described elsewhere in
this proposed rule. The ``Consolidated CDA creation performance''
certification criterion helps to ensure the proper conformance of
Consolidated CDAs (C-CDAs) for transition of care and referral
summaries that are sent to and received from external organizations. In
the 2015 Edition Final Rule, we adopted a new Consolidated CDA creation
performance certification criterion in Sec. 170.315(g)(6) that
assesses a product's C-CDA creation performance if the Health IT Module
is presented for certification with C-CDA creation capabilities within
its scope (80 FR 62674). In the HTI-1 Final Rule, we updated the
associated standards (89 FR 1224).
We have stated elsewhere in this proposed rule that while C-CDA-
based standards are still in use, the industry is shifting toward
adoption of FHIR-based standards, which are designed to enable greater
interoperability and innovation. We believe that maintaining the
current level of support for this and other C-CDA-based criteria,
including putting effort and resources toward testing and
certification, can detract from industry efforts to move toward FHIR-
based solutions. We believe that removing the Consolidated CDA creation
performance certification criterion in Sec. 170.315(g)(6) would
contribute to reducing the effort health IT developers and health care
providers are focusing on C-CDA support and allow for redirection of
efforts toward greater use of FHIR-based standards in health IT. We
propose to remove the Consolidated CDA creation performance
certification criterion in Sec. 170.315(g)(6) as of the effective date
of a subsequent final rule. We welcome feedback on these proposals.
g. Application Access--Patient Selection
In the 2015 Edition Final Rule (80 FR 62602), we adopted the
``application
[[Page 60998]]
access--patient selection'' certification criterion in Sec.
170.315(g)(7) that includes the capability to receive a request with
sufficient information to uniquely identify a patient and return an ID
or other token that can be used by an application to subsequently
execute requests for that patient's data.
We propose to remove the application access--patient selection
criterion and reserve Sec. 170.315(g)(7) as of January 1, 2027. We
have reviewed and evaluated the certification criterion in Sec.
170.315(g)(7), seeking to identify ways to reduce burden while still
supporting our policy goals. We refer readers to section I.A.2.b for
detailed discussion on ``America's FHIR-Forward Future.'' Given our
increased focus on standards-based APIs in the Certification Program,
we believe it is appropriate to remove this functional API criterion at
this time. Specifically, since adoption of the SMART App Launch
Implementation Guide in Sec. 170.215(c) all Health IT Modules
certified to the standardized API for patient and population services
certification criterion in Sec. 170.315(g)(10) must support the
functional requirement described in Sec. 170.315(g)(7)(i) according to
the SMART App Launch Implementation Guide. Further, we are also
proposing elsewhere in this proposed rule to remove a corresponding
certification criterion in Sec. 170.315(g)(9). Should we finalize
removal of the certification criterion in Sec. 170.315(g)(9), the
certification criterion in Sec. 170.315(g)(7) would lose its intended
utility. We believe that reducing compliance burdens for health IT
developers that participate in the Certification Program would foster
industry innovation and encourage the development of more creative
interoperability solutions. We have similarly also removed the
certification criterion in Sec. 170.315(g)(8) via a technical
correction in the HTI-4 Final Rule (90 FR 37182), which was published
in tandem with the FY2026 IPPS/LTCH PPS Final Rule (90 FR 36536). We
had intended to remove Sec. 170.315(g)(8) in the HTI-2 Final Rule, but
mistakenly removed Sec. 170.315(g)(2) instead due to an amendatory
instruction drafting instruction error. We corrected this error in the
HTI-4 Final Rule.
The application access--patient selection certification criterion
is included in the Base EHR definition in Sec. 170.102. The criterion
is also associated with measures under the Provider to Patient Exchange
and Health Information Exchange objectives of the Medicare Promoting
Interoperability Program and the MIPS Promoting Interoperability
performance category. Accordingly, we believe that a transition date is
needed for the removal of this measure, if our proposal is finalized,
that would allow CMS to make appropriate program adjustments.
Therefore, we propose to remove the application access--all data
request certification criterion as of January 1, 2027, and reserve
Sec. 170.315(g)(7).
We believe that removing the certification criterion in Sec.
170.315(g)(7) will reduce administrative burden as well as burden for
health IT developers and health care providers while still allowing us
to achieve our policy goals. We welcome comments on this proposal.
h. Application Access--All Data Request
In the 2015 Edition Final Rule (80 FR 62602), we established the
``application access--all data request'' certification criterion at
Sec. 170.315(g)(9) that requires the capability to respond to requests
for patient data for all of the data classes expressed in the standards
in Sec. 170.213. In the Cures Act Final Rule (85 FR 25642), we revised
Sec. 170.315(g)(9) to add requirements for the USCDI and remove
support for the CCDS by a specified date. In the HTI-1 Final Rule (89
FR 1192), we made revisions to support USCDI v2 and v3 updates and
changes to data classes and constituent data elements for C-CDA and C-
CDA 2.1 Companion Guide.
We propose to remove the application access--all data request
certification criterion in Sec. 170.315(g)(9) as of January 1, 2027.
We have reviewed and evaluated the certification criterion in Sec.
170.315(g)(9), seeking to identify ways to reduce burden for health IT
developers and health care providers while still supporting our policy
goals. As we have stated in the above section on our proposal to remove
Sec. 170.315(g)(7) and in section I.A.2.b of this rule, we are
increasing focus on standards-based APIs, and we believe it is
appropriate to remove this functional API criterion at this time. We
believe the functionality of the criterion has been widely adopted (as
discussed in section III.A) among health IT developers and is not
likely to go away as a supported functionality solely because of
removal from the Certification Program. We also believe that removing
this certification criterion could spur further industry innovation and
support the development of more creative interoperability solutions.
We believe that removing the certification criterion in Sec.
170.315(g)(9) will reduce administrative burden as well as burden for
health IT developers and health care providers by eliminating the need
for developers of certified health IT to certify to the certification
criterion in Sec. 170.315(g)(9). Because the certification criterion
in Sec. 170.315(g)(9) is associated with measures under the Provider
to Patient Exchange and Health Information Exchange objectives of the
Medicare Promoting Interoperability Program and the MIPS Promoting
Interoperability performance category, we believe that a transition
date is needed.\57\ Therefore, we propose to remove the application
access--all data request certification criterion as of January 1, 2027
and reserve Sec. 170.315(g)(9). We welcome comments on this proposal.
---------------------------------------------------------------------------
\57\ See the CY 2026 PFS Proposed Rule Table 62, available at
https://www.federalregister.gov/d/2025-13271/p-3055 and the FY2026
IPPS/LTCH PPS Final Rule Table X.F.-05 available at https://www.federalregister.gov/d/2025-14681/p-4161.
---------------------------------------------------------------------------
8. Transport Methods and Other Protocols Certification Criteria
a. Direct Project
In the 2015 Edition Final Rule (80 FR 62602), we adopted a revised
certification criterion in Sec. 170.315(h)(1) that includes the
capability to send and receive according to the Applicability Statement
for Secure Health Transport (the primary Direct Project specification).
We previously adopted this capability across different certification
criteria as the 2014 Edition EHR Certification Criteria were maintained
at Sec. 170.314(b)(1), (b)(2), and (h)(1).
We propose to remove the ``transport methods and other protocols--
direct project'' certification criterion in Sec. 170.315(h)(1) as of
the effective date of a final rule. We have reviewed and evaluated the
certification criterion in Sec. 170.315(h)(1), seeking to identify
ways to reduce burden while still supporting our policy goals. We
believe that because this certification criterion was included as part
of the 2014 Base EHR definition, the 2015 Base EHR definition
(subsequently renamed the Base EHR definition), the functionality of
this certification criterion has been widely adopted (as discussed in
section III.A) among health IT developers and is not likely to go away
as a supported functionality solely because of removal from the
Certification Program. We no longer believe there is added benefit to
include conformance testing for this functionality in the Certification
Program as it is widely relied on and supported in the health care
industry and would be incorporated in health IT absent the
certification criterion. We further believe that removing this
certification criterion could spur further
[[Page 60999]]
industry innovation by enabling health IT developers to redirect
investment in certification and testing for this criterion to new
areas.
We believe the removal of this certification criterion will reduce
administrative burden and costs associated with certification for
health IT developers and health care providers by eliminating the need
for developers of certified health IT to certify to the certification
criterion in Sec. 170.315(h)(1) without substantially impacting our
broader policy goals around interoperability and exchange and will
allow for further innovation and development. Therefore, we propose to
remove the transport methods and other protocols--direct project
certification criterion in Sec. 170.315(h)(1) as of the effective date
of a subsequent final rule. We welcome comments on this proposal.
b. Direct Project, Edge Protocol, and XDR/XDM
In the 2015 Edition final rule we adopted a variation of the Sec.
170.315(h)(1) certification criterion in Sec. 170.315(h)(2) to
accommodate implementation differences. This certification criterion
combined three standards conformance requirements (the primary Direct
standard, the edge protocol, and XDR/XDM handling). We propose to
remove the ``transport methods and other protocols--Direct Project,
Edge Protocol, and XDR/XDM'' certification criterion in Sec.
170.315(h)(2) as of the effective date of a subsequent final rule. We
have reviewed and evaluated the certification criterion in Sec.
170.315(h)(2), seeking to identify ways to reduce burden while still
supporting our policy goals. Similar to Sec. 170.315(h)(1), we believe
the functionality of this certification criterion has been widely
adopted (as discussed in section III.A) among health IT developers and
is not likely to go away as a supported functionality solely because of
removal from the Certification Program, since it has been part of the
2014 Edition Base EHR definition, and 2015 Edition Base EHR definition
(renamed the Base EHR definition), and the current criterion has not
substantively changed since it was adopted in the 2015 Edition Final
Rule. We further believe that removing this criterion could spur
further industry innovation in this area by allowing for greater
flexibility and reduced burden and costs from the need to certify to
the certification criterion. Because removing Sec. Sec. 170.315(h)(1)-
(2) would remove all of the certification criteria under Sec.
170.315(h), we propose to remove and reserve Sec. 170.315(h) in its
entirety. We welcome comments on this proposal.
B. Standards and Implementation Specifications for Health Information
Technology
1. United States Core Data for Interoperability Version 3.1 Update
(USCDI v3.1)
The USCDI standard in Sec. 170.213 is a baseline set of data that
can be commonly exchanged across care settings for a wide range of
uses. Certain certification criteria in the Certification Program
currently require the use of one of the versions of the USCDI standard
in Sec. 170.213. We established USCDI as a standard in the Cures Act
Final Rule (85 FR 25670), adopting USCDI Version 1 (USCDI v1) in Sec.
170.213 and incorporating it by reference in Sec. 170.299. USCDI is
also referenced by HHS programs and used by the health care community
to align interoperability requirements and national priorities for
health IT across industry initiatives. For the overall structure and
organization of USCDI, including data classes and data elements, please
see www.healthIT.gov/USCDI.
We published the ``USCDI v3 Data Elements Enforcement Discretion
Notice,'' \58\ on March 21, 2025, which stated that ASTP/ONC is
exercising enforcement discretion, and issued certification guidance
for the Certification Program. Specifically, under this enforcement
discretion notice and certification guidance, we stated that ASTP/ONC
will not take any enforcement action under 45 CFR 170.565 against an
ONC-ACB based on non-compliance with 45 CFR 170.550 for certifying a
Health IT Module that is presented for certification to a certification
criterion or criteria in 45 CFR 170.315 that cross-references USCDI v3,
where the Health IT Module:
---------------------------------------------------------------------------
\58\ https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion.
---------------------------------------------------------------------------
1. Does not demonstrate the capability to categorize data on
individuals based on either or both of the following data elements:
Sexual orientation; and
Gender identity; or
2. Only demonstrates the capability to categorize data on
individuals for the sex data element in accordance with the following
SNOMED CT[supreg] codes:
248152002 [verbar] Female (finding) [verbar]; and
248153007 [verbar] Male (finding) [verbar].
Additionally, under this enforcement discretion notice and
certification guidance, we stated that ASTP/ONC will not take any
enforcement action under 45 CFR 170.565 against an ONC-ACB based on
non-compliance with 45 CFR 170.550 for certifying a Health IT Module
that is presented for certification to the ``patient demographics and
observations'' certification criterion (45 CFR 170.315(a)(5)), where
the Health IT Module:
1. Does not demonstrate conformance with any or all of the
following data and observations in paragraph (a)(5)(i): sex parameter
for clinical use, sexual orientation, gender identity, name to use, and
pronouns; or
2. Does not demonstrate conformance with any or all of the
following paragraphs of (a)(5)(i): (D) (``sexual orientation''), (E)
(``gender identity''), (F) (``sex parameter for clinical use''), (G)
(``name to use''), and (H) (``pronouns''); or
3. Only demonstrates, for conformance with paragraph (a)(5)(i)(C)
(``sex''), that it can record sex in accordance with either the
standard specified in Sec. 170.207(n)(1) for the period up to and
including December 31, 2025, or the following SNOMED CT[supreg] codes
found in the standard specified in Sec. 170.207(n)(2):
248152002 [verbar] Female (finding) [verbar]; and
248153007 [verbar] Male (finding) [verbar].
We stated that ASTP/ONC will not exercise its direct review
authority under 45 CFR 170.580 for any non-conformity, potential or
actual, that arises solely from a Health IT Module not demonstrating
the capabilities specified above or for only demonstrating the limited
specified capabilities above, as applicable, for the relevant
certification criteria requirements.
We also stated that this enforcement discretion notice, and
certification guidance will remain in effect for twelve (12) months
from the date of this notice or until HHS completes a regulatory action
to revise the applicable regulations, whichever comes first.
In June 2025, we published the USCDI v3.1,\59\ which removes or
updates from USCDI v3 the data elements for Sex, Sexual Orientation,
and Gender Identity in the Patient Demographics/Information Data Class.
We propose to adopt USCDI v3.1 in Sec. 170.213(a) and incorporate it
by reference in Sec. 170.299. The removal of data elements from USCDI
v3 reflected in USCDI v3.1 aligns with our other proposals related to
Sec. 170.315(a)(5) (see section III.A.1.a), resulting in burden
reduction for health IT developers and cost savings associated with the
enforcement discretion and ongoing maintenance requirements over time.
In addition,
[[Page 61000]]
these data elements (e.g., sexual orientation and gender identity) do
not support the meeting of specific measures under the Medicare
Promoting Interoperability Program or the MIPS Promoting
Interoperability performance category, and are therefore not essential
for inclusion in certified health IT that is used to meet the CEHRT
definitions and support meeting measures under those programs.
Therefore, we propose to remove USCDI v3 in Sec. 170.213(b) and USCDI
v1 in Sec. 170.213(a) which expires on January 1, 2026. The effect of
these proposals, if finalized in a subsequent final rule, would be that
USCDI v3.1 would be the only version of USCDI in Sec. 170.213. In
other words, all Health IT Modules that cross-reference Sec. 170.213
would need to conform to USCDI v3.1 as of the effective date of a
subsequent final rule. Given that USCDI v3.1 is a reduction, rather
than expansion, of required support for data elements, we do not
anticipate that Health IT Modules that cross-reference Sec. 170.213
would require further development to conform to USCDI v3.1.
---------------------------------------------------------------------------
\59\ See https://www.healthit.gov/isp/sites/isp/files/USCDI-Version-3-1_2025_508.pdf.
---------------------------------------------------------------------------
We welcome comments on our proposals.
a. 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 \60\ 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 this general rule, 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 propose
to use a government-unique standard which is the USCDI v3.1 standard
that we propose to adopt 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).
---------------------------------------------------------------------------
\60\ https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf.
---------------------------------------------------------------------------
We are not aware of any voluntary consensus standard that could
serve as an alternative for the purposes we describe in further detail
throughout this proposed rule, including for establishing a baseline
set of data that can be commonly exchanged across care settings for a
wide range of uses.
b. ``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 CFR (79 FR 66267: 1
CFR 51.5(a)). To comply with these requirements, in section V
(``Incorporation by Reference'') of this preamble, we provide a summary
of, and a uniform resource location (URL) to, the USCDI standard we
propose to adopt and subsequently incorporate by reference in the Code
of Federal Regulations. To note, we also provide relevant information
about the standard throughout the relevant sections of the proposed
rule.
2. Standards and Implementation Specifications
As discussed above, we have proposed to remove or revise certain
certification criteria in the Certification Program in an effort to
reduce burden, offer flexibility to both developers and health care
providers, as well as to support innovation. Included in certain
certification criteria are references to standards. In those instances
where we have proposed to remove the criterion, we also generally
propose to remove the standard that is referenced from the CFR. Where
the certification criterion is not removed as of the effective date of
a final rule but allows time for transition until January 1, 2027, we
generally propose to also remove those referenced standards on January
1, 2027. Only in limited circumstances do we retain a standard that is
referenced in a certification criterion proposed for removal.
We propose to remove the following standards as of the effective
date of a subsequent final rule because they would no longer be
referenced in certification criteria in the CFR: transport standards in
Sec. 170.202(b) through (e); functional standards in Sec. 170.204;
content exchange standards in Sec. 170.205(a)(3) and (5); vocabulary
standards for representing electronic health information in Sec.
170.207(r) and (s); and standards for health information technology to
protect electronic health information created, maintained, and
exchanged in Sec. 170.210. We note that certain standards in Sec.
170.210 may not be removed contingent on whether we finalize the
alternative privacy and security proposal (see section III.A.4). We
also propose to remove the following standards as of the effective date
of a final rule since we propose to revise the associated certification
criterion requirements to no longer reference the given standard: the
content and exchange standard in Sec. 170.205(r)(1), including the
specific document templates in Sec. 170.205(r)(1)(i) through (iii).
We propose to remove content exchange standards and implementation
specifications referenced in certification criteria requirements that
have expired in Sec. 170.205(k)(1) and (2) from the CFR. We propose to
remove API standards that expire on January 1, 2026, in Sec.
170.215(b)(1)(i) and (c)(1), and we also propose to remove and reserve
outdated vocabulary standards in Sec. 170.207(f)(2) and (m)(1).
Where we propose to remove certain certification criteria after a
transition period until January 1, 2027, we also propose to remove
those standards from the CFR effective on January 1, 2027. Standards
referenced in a certification criterion proposed for removal with a
transition date of January 1, 2027, include content exchange standards
in Sec. 170.205(i)(2), (t)(1) through (4), and (s)(1). We also propose
to remove certain vocabulary standards in order to eliminate outdated
standards that are no longer referenced or have expired. Therefore, we
propose to remove vocabulary standards in Sec. 170.207(a)(4), (c)(3),
(e)(3) and (4). We also propose to remove vocabulary standards in Sec.
170.207(d)(1)(ii), (d)(1)(iii), (n)(1) and (3), and (o) from the CFR
and reserve these subsections.
We welcome comments on our proposals. Specifically, we request
comment on whether we should retain any of the standards and
implementation specifications proposed for removal because the standard
or implementation specification should be required for purposes of
health IT
[[Page 61001]]
alignment, for instance, when acquiring, implementing or upgrading
health IT systems and products consistent with sections 13111 and 13112
of the HITECH Act.
In certain instances, we have not proposed to remove a standard
even though we propose to remove the certification criterion where the
standard is referenced. As noted, under section 3004 of the PHSA, we
may adopt standards independently of associated criteria in the
Certification Program. Standards adopted in 45 CFR 170 subpart B may be
referenced by other HHS programs and policies besides the Certification
Program. For example, standards adopted in 45 CFR 170 subpart B,
regardless of whether they are associated with health IT certification
criteria, are also required for use under sections 13111 and 13112 of
the HITECH Act when acquiring, implementing or upgrading health IT
systems and products in certain instances.
We do not propose to remove the standard in Sec. 170.205(o), data
segmentation for privacy, because some developers still rely on these
standards, which allow health care providers to tag health care
documents with privacy metadata. We also do not propose to remove the
Direct Project transport standard in Sec. 170.202(a)(2). We realize
that the Direct Project standards are widely utilized in various use
cases and emphasize that developers may still use these standards even
if they are removed from certification criteria. We welcome comments on
these proposals.
We believe that keeping the primary Direct Project standard in
Sec. 170.202(a)(2) but removing the other related standards and
protocols in Sec. 170.202(b) through (e) from the Certification
Program would acknowledge the current utilization of the Direct Project
standard while recognizing the ongoing technological advancements
related to transport, including movement toward FHIR-based standards,
and would encourage and provide space for further innovation and market
competition in this area. We propose a minor revision to Sec.
170.205(d)(2) to add the full name of the HL7 Messaging Standard
Version 2.5.1 standard. Lastly, we request comments on retaining the
``Applicability Statement for Secure Health Transport'' requirement
found in Sec. 170.315(h)(1)(i).
C. Terms and Definitions
Because of the proposed removal of certain certification criteria
from Sec. 170.315 discussed above, we propose to make conforming edits
to the terms and definitions in Sec. 170.102.
1. Base EHR
We propose to make conforming revisions to the Base EHR definition
in Sec. 170.102 based on our proposals to remove certification
criteria from the CFR that are currently referenced in Sec. 170.102.
The Base EHR definition provides a baseline assurance that certified
health IT has been developed to possess, at a minimum, a key set of
capabilities. We note the Base EHR definition is based on the
``Qualified EHR'' definition in section 3000(13) of the PHSA (77 FR
54262). As we noted recently, we have generally sought to limit the
Base EHR definition to elements required for the Qualified EHR
definition in PHSA section 3000 (90 FR 37145). In section (3)(i) of the
Base EHR definition, we propose to remove references to Sec.
170.315(a)(14), (g)(7) and (9), and (h)(1) and (2). We propose to
remove these certification criteria from the Base EHR definition
because we have proposed to remove those certification criteria from
the CFR. We also propose to move Sec. 170.315(b)(11) to section (3)(i)
of the definition and remove and reserve section (3)(ii) and remove
section (3)(iii) because the transition date has passed. We welcome
feedback on these proposals.
2. Common Clinical Data Set
We finalized in the Cures Act Final Rule that the CCDS would no
longer be applicable for certified Health IT Modules 24 months after
the publication date of the 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). Because Sec.
170.315(b)(6)(ii)(A), which also referenced CCDS, was available for the
period before December 31, 2023, we did not propose to remove the
definition of CCDS in Sec. 170.102 at that time. However, now that the
date of December 31, 2023, has passed and we finalized the removal
Sec. 170.315(b)(6) in the HTI-2 Final Rule (89 FR 101776) and there
are no longer any references to CCDS in 45 CFR part 170, we propose to
remove the term Common Clinical Data Set in Sec. 170.102. We welcome
comments on these proposals.
3. Global Unique Device Identification Database and Production
Identifier
In section III.A.1.d, we propose to remove the ``implantable device
list'' certification criterion in Sec. 170.315(a)(14) and reserve
Sec. 170.315(a)(14). The implantable device list certification
criterion requires Health IT Modules certified to Sec. 170.315(a)(14)
to exchange, record, and allow a user to access a list of Unique Device
Identifiers (UDIs) associated with a patient's implantable devices. The
only references to the Global Unique Device Identification Database and
Production Identifier in 45 CFR part 170 are in Sec. 170.315(a)(14).
Because we propose to remove Sec. 170.315(a)(14), we propose to remove
the definitions of Global Unique Device Identification Database and
Production Identifier in Sec. 170.102 too as the terms would no longer
be referenced in any other section of 45 CFR part 170. We welcome
comments on these proposals.
D. Conditions and Maintenance of Certification Requirements for Health
IT Developers
1. Assurances
Section 3001(c)(5) of the PHSA (42 U.S.C. 300jj-11) (section 4002
of the Cures Act) requires that a health IT developer, as a Condition
of Certification requirement under the Certification Program, provide
assurances to the Secretary that, unless for legitimate purpose(s) as
specified by the Secretary, the developer will not take any action that
constitutes information blocking as defined in section 3022(a) of the
PHSA or any other action that may inhibit the appropriate exchange,
access, and use of EHI. In the Cures Act Final Rule (85 FR 25718), we
implemented this provision through several Conditions of Certification
and accompanying Maintenance of Certification requirements, which are
set forth in Sec. 170.402. Because the transition dates in Sec.
170.402(b)(2)(i) and (ii) have passed, we propose to revise the
Maintenance of Certification requirements in Sec. 170.402(b)(2) to
remove the transition dates and only include that a health IT developer
that must comply with the requirements of Sec. 170.402(a)(4) must
provide all of its customers of certified health IT with the health IT
certified to the certification criterion in Sec. 170.315(b)(10).
We also propose to make additional conforming edits to Sec.
170.402(b). Because we propose to remove the requirements in Sec.
170.315(b)(11)(iv) and (v) regarding source attribute support, access,
and modification and in Sec. 170.315(b)(11)(vi) regarding intervention
risk management for predictive DSIs, we also propose to remove Sec.
170.402(b)(4), which requires
[[Page 61002]]
health IT developers to review and update as necessary source attribute
information and intervention risk management practices. We welcome
feedback on these proposals.
2. Application Programming Interfaces
As a Condition of Certification requirement in section 3001(c)(5)
of the PHSA (42 U.S.C. 300jj-11) (section 4002 of the Cures Act),
health IT developers are required to publish APIs that allow ``health
information from such technology to be accessed, exchanged, and used
without special effort through the use of application programming
interfaces or successor technology or standards, as provided for under
applicable law.'' Section 4002 of the Cures Act also states that a
developer must, through an API, ``provid[e] access to all data elements
of a patient's electronic health record to the extent permissible under
applicable privacy laws.'' The Cures Act Final Rule (85 FR 25642)
captured both the technical functionality and behaviors necessary to
implement the Cures Act API Condition of Certification requirement.
Specifically, we adopted new standards, new implementation
specifications, a new certification criterion, and modified the Base
EHR definition. In addition, we finalized detailed Condition and
Maintenance of Certification requirements for health IT developers of
certified health IT in Sec. 170.404. Because the transition dates in
Sec. 170.404(b)(2), (3), and (4) have passed, we propose to revise the
Maintenance of Certification requirements in Sec. 170.404(b). We
propose to revise Sec. 170.404(b)(2) to remove the date, and we
propose to remove paragraphs (b)(3) and (b)(4) entirely as they are
outdated and, in the case of (b)(4) because it refers to certification
criteria that we are proposing to remove. We also propose to revise
Sec. 170.404(c) to update certification criteria referenced in the
``Certified API technology'' definition. We propose to remove the
reference to ``Sec. 170.315(g)(7) through'' and only keep Sec.
170.315(g)(10) in the ``Certified API technology'' definition because
we are proposing to remove Sec. 170.315(g)(7) through (9). We welcome
feedback on these proposals.
3. Real World Testing
Section 3001(c)(5) of the PHSA (42 U.S.C. 300jj-11) (section 4002
of the Cures Act) requires, as a Condition and Maintenance of
Certification under the Certification Program, that health IT
developers have successfully tested the real world use of the
technology for interoperability in the type of setting in which such
technology would be marketed. Section 4003(a)(2) of the Cures Act
defines interoperability as health information technology that enables
the secure exchange of electronic health information with, and use of
electronic health information from, other health information technology
without special effort on the part of the user; allows for complete
access, exchange, and use of all electronically accessible health
information for authorized use under applicable state or federal law;
and does not constitute information blocking as defined in section
3022(a) of the Cures Act. This definition for interoperability was
codified in 45 CFR 170.102.
In the Cures Act Final Rule, through the Real World Testing
Condition and Maintenance of Certification requirements, we finalized
the implementation of the statute's real world testing requirements in
45 CFR 170.405 for health IT certified to the following certification
criteria:
The ``care coordination'' certification criteria in Sec.
170.315(b);
The ``clinical quality measures'' certification criteria
in Sec. 170.315(c)(1) through (c)(3);
The ``view, download, and transmit to 3rd party''
certification criterion in Sec. 170.315(e)(1);
The ``public health'' certification criteria in Sec.
170.315(f);
The certification criteria related to APIs in Sec.
170.315(g)(7) through (g)(10); and
The ``transport methods and other protocols''
certification criteria in Sec. 170.315(h).
However, in that same final rule we replaced the ``application
access--data category request'' certification criterion (Sec.
170.315(g)(8)) with the ``standardized API for patient and population
services'' certification criterion (Sec. 170.315(g)(10)). The
``application access--data category request'' certification criterion
was only available for certification until December 31, 2022, and we
eventually removed the certification criterion from the CFR (89 FR
101776). In the HTI-4 Final Rule, we finalized six new certification
criteria. We clarified that because Sec. 170.405(a) cross references
Sec. 170.315(b), the new Sec. 170.315(b)(4) ``real-time prescription
benefit'' certification criterion finalized in HTI-4 would be
automatically included within real world testing requirements.
Similarly, we included five API-focused certification criteria: Sec.
170.315(g)(31) ``provider prior authorization API--coverage
requirements discovery''; Sec. 170.315(g)(32) ``provider prior
authorization API--documentation templates and rules''; Sec.
170.315(g)(33) ``provider prior authorization API--prior authorization
support''; Sec. 170.315(j)(20) ``workflow triggers for decision
support interventions--clients''; and Sec. 170.315(j)(21)
``subscriptions--client'' in scope for real world testing. Health IT
certified to the identified real world testing certification criteria
are eligible for the SVAP under Sec. 170.405(b)(8) and (9).
Consistent with the ``Real World Testing Condition and Maintenance
of Certification Requirements Enforcement Discretion Notice'' \61\ we
issued on June 30, 2025, we now propose the following deregulatory
actions: (1) removing the requirement to submit real world testing
plans for all real world testing certification criteria (Sec.
170.405(b)(1)); (2) limiting full real world testing results reporting
(Sec. 170.405(b)(2)) to only Health IT Modules that are certified to
the API certification criteria identified below; and (3) permitting the
use of SVAP for the remaining non-API real world testing certification
criteria with minimal reporting requirements.
---------------------------------------------------------------------------
\61\ https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement.
---------------------------------------------------------------------------
We note that certain certification criteria would be fully removed
from real world testing requirements by virtue of their proposed
removal from the Certification Program. We have included such an
outcome in our proposed revised Real World Testing Condition of
Certification (45 CFR 170.405(a)). If, in a subsequent final rule, we
determine to keep any of the criteria proposed for removal and they are
currently identified in the Real World Testing Condition of
Certification (45 CFR 170.405(a)), they would also remain part of the
Real World Testing Condition of Certification. Examples of such
criteria would be the public health criteria proposed for removal
(``transmission to cancer registries'' (Sec. 170.315(f)(4)) and
``transmission to public health agencies--health care surveys'' (Sec.
170.315(f)(7)).
First, we propose to remove the real world testing plan submission
requirement from the Real World Testing Maintenance of Certification
requirements (Sec. 170.405(b)). Second, we propose to revise the
results reporting requirements under Sec. 170.405(b)(2) to make clear
what health IT developers must include in their real world testing
results reporting. Specifically, developers will be expected to report
on all health IT certified to any of the certification criteria in
Sec. 170.315(g) certification criteria as of January 1 of the year in
which they must complete real world testing. Developers must also
[[Page 61003]]
report on all health IT certified to any of the certification criteria
in Sec. 170.315(g) that undergo updates via Inherited Certified Status
during the real world testing year. This is consistent with current
requirements to conduct a full calendar year of real world testing
(Sec. 170.405(b)(2)(ii)).
We propose to limit real world testing reporting (Sec.
170.405(b)(2)) to API-focused certification criteria which are, at this
time: ``standardized API for patient and population services'' (Sec.
170.315(g)(10)); ``provider prior authorization API--coverage
requirements discovery'' (Sec. 170.315(g)(31)); ``provider prior
authorization API--documentation templates and rules'' (Sec.
170.315(g)(32)); and ``provider prior authorization API--prior
authorization support'' (Sec. 170.315(g)(33)). This approach aligns
with our overall move to focus the Certification Program on APIs (see
discussion in section I.A.2) with a particular focus on FHIR-based
APIs.
SVAP will remain available for all certified health IT subject to
the Real World Testing Condition of Certification and Maintenance of
Certification requirements. For the API-focused certification criteria
identified above, the real world testing SVAP reporting requirements
will not change. However, for health IT certified to the remaining real
world testing certification criteria identified in Sec. 170.405(a),
developers will only need to identify in their real world testing
results their voluntary updates (health IT products, certification
criteria, and standards/implementation specifications) to standards and
implementation specifications that the National Coordinator has
approved through SVAP, which is consistent with current requirements
under 45 CFR 170.405(b)(2)(ii)(C). This approach will allow developers
to continue to voluntarily update to newer versions of standards once
approved by the National Coordinator, which supports advancing
interoperability. For clarity, we have captured this SVAP requirement
separately in proposed 45 CFR 170.405(b)(2)(iv). We also propose a
revision to Sec. 170.405(b)(8) to cross-reference paragraph (a) of
Sec. 170.405 instead of paragraph (b) due to our proposed revisions.
4. Attestations
Section 4002(a) of the Cures Act requires that a health IT
developer, as a Condition and Maintenance of Certification requirement
under the Certification Program, provide to the Secretary an
attestation to the Conditions of Certification required in section
3001(c)(5)(D) of the PHSA. In the Cures Act Final Rule, we adopted
regulation text implementing the Cures Act's ``Attestations'' Condition
of Certification requirement in Sec. 170.406 (85 FR 25781). Under
Sec. 170.406, health IT developers attest twice a year to compliance
with the Conditions and Maintenance of Certification requirements. A
health IT developer of certified health IT must provide the Secretary
an attestation of compliance with Sec. 170.404, the API Conditions and
Maintenance of Certification requirements, according to Sec.
170.406(a)(4). Because we discuss the proposal to remove Sec.
170.315(g)(7) through (9) in section III.A.7 of this proposed rule, we
also propose to remove the reference to Sec. 170.315(g)(7) through (9)
in Sec. 170.406(a)(4). In Sec. 170.406(a)(5), we also propose to
remove the reference to Sec. 170.315(g)(7) through (9). Additionally,
we propose to remove the reference to Sec. 170.315(h) in Sec.
170.406(a)(5) because, as we discussed in section III.A.8, we propose
to remove Sec. 170.315(h)(1) and (2), in effect removing the entirety
of Sec. 170.315(h).
5. Insights
The Cures Act specified requirements in section 4002(c) to
establish an 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. In the HTI-1 Final Rule (89 FR 1311), we
established the EHR Reporting Program as the ``Insights Condition and
Maintenance of Certification'' (also referred to as the ``Insights
Condition'') and finalized in Sec. 170.407 the first set of measures
to reflect the interoperability category required by section
3009A(a)(3)(A)(iii) of the PHSA. The Insights Condition includes seven
measures on which health IT developers under the Certification Program
must annually report consistent with specified timelines. We refer
readers to the HTI-1 Proposed Rule (88 FR 23831) for detailed
background on how we engaged with the health IT community for the
purpose of identifying measures that developers of certified health IT
would be required to report on as a Condition and Maintenance of
Certification under the Certification Program.
Consistent with E.O. 14192, ``Unleashing Prosperity Through
Deregulation,'' \62\ we identified certain regulatory requirements for
which the exercise of enforcement discretion may prevent or mitigate
the accrual of sunk costs by regulated entities. On April 29, 2025, we
published the ``Insights Condition and Maintenance of Certification
Enforcement Discretion Notice,'' \63\ in which we stated we had
exercised the following enforcement discretion:
---------------------------------------------------------------------------
\62\ https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation.
\63\ https://www.healthit.gov/topic/insights-condition-and-maintenance-certification-enforcement-discretion.
---------------------------------------------------------------------------
ASTP/ONC will not exercise its direct review authority
under 45 CFR 170.580 for any non-conformity, potential or actual, that
arises solely from a health IT developer not complying with 45 CFR
170.407(b) except for reporting requirements related to the ``use of
FHIR in apps through certified health IT'' measure (45 CFR
170.407(a)(3)(iv)). Stated another way, ASTP/ONC only expects that
health IT developers will report on the ``use of FHIR in apps through
certified health IT'' measure (Sec. 170.407(a)(3)(iv)(A) and (B)
beginning in July of 2027 and (a)(3)(iv)(C) beginning in July 2028).
ASTP/ONC will not conclude that an ONC-ACB has failed to
adhere to 45 CFR 170.523(u), find a violation of 45 CFR 170.560(a), or
take any enforcement action under 45 CFR 170.565 against an ONC-ACB if
an ONC-ACB confirms that the only measure under 45 CFR 170.407(b) for
which a health IT developer submits responses is the ``use of FHIR in
apps through certified health IT'' measure (45 CFR 170.407(a)(3)(iv)).
We stated that this enforcement discretion will be in effect
beginning on July 1, 2027, and will remain in effect until HHS
completes a deregulatory action to remove or revise 45 CFR 170.407 and
170.523(u). Therefore, in this proposed rule, we propose to remove the
following measures in Sec. 170.407(a)(3):
Sec. 170.407(a)(3)(i), Individuals' access to electronic
health information through certified health IT;
Sec. 170.407(a)(3)(ii), Consolidated clinical document
architecture (C-CDA) problems, medications, and allergies
reconciliation and incorporation through certified health IT;
Sec. 170.407(a)(3)(iii), Applications supported through
certified health IT;
Sec. 170.407(a)(3)(v), Use of FHIR bulk data access
through certified health IT;
Sec. 170.407(a)(3)(vi), Immunization administrations
electronically submitted
[[Page 61004]]
to immunization information systems through certified health IT; and
Sec. 170.407(a)(3)(vii), Immunization history and
forecasts through certified health IT.
Note, given this proposal, we propose to make conforming edits to
the list structure in Sec. 170.407(a)(3) to revise the ``use of FHIR
in apps through certified health IT'' as paragraph (i) instead of (iv).
In addition, we propose to remove corresponding references to the
removed measures in Sec. 170.407(b) as we only expect that health IT
developers would report on the ``use of FHIR in apps through certified
health IT'' measure in the newly designated Sec. 170.407(a)(3)(i),
specifically, paragraphs (a)(3)(i)(A) and (B) beginning July of 2027
and (a)(3)(i)(C) beginning in July 2028. We believe our proposal to
remove the measures listed above reduces cost and burden to the public.
Our proposals ensure that the Insights Condition is aligned with
other proposed policies and changes to the Certification Program that
prioritize exchange using FHIR-based APIs. Among the measures that
related to FHIR-based APIs, the ``use of FHIR in apps through certified
health IT'' provides the most valuable insights related to
implementation and use of FHIR. We welcome comments on these proposals.
In the HTI-1 Final Rule (89 FR 1346), we finalized the Insights
Condition reporting frequency to annually for any Health IT Module that
has or has had an active certification to Sec. 170.407(b)(1) during
the prior six months. We propose to revise Sec. 170.407(b)(1) to
clarify that a developer must provide an annual response to the
Insights Condition of Certification if they had at least one actively
certified Health IT Module as of January 1 of the reporting period
(i.e., start of the data collection year) and remain certified under
the Certification Program at the time of submission (i.e., July of the
following year). We understand that Health IT Modules can be certified
and withdrawn in cycles; however, this proposal would make clear that
we expect health IT developers of certified health IT to be accountable
for any data collected during the calendar-year (CY) data collection
period, which begins January 1, regardless of how many months the
certification remained active. For example, a developer of certified
health IT that has a Health IT Module certified to Sec. 170.315(g)(10)
for only the first three months of CY 2026 would report data reflecting
use during this three-month period even though their Health IT Module
was withdrawn or otherwise no longer certified for the remaining nine
months of CY 2026.
This also applies to newer versions of certified health IT
leveraging inherited certified status (ICS). We expect that developers
of certified health IT requesting ICS for newer versions would include
data for all applicable certified health IT, including newer versions
in scope of the Insights Condition requirements as of January 1, at the
start of the data collection reporting period. We note that developers
of certified health IT would not be expected to separate their
certified health IT, in scope of ICS, by versions when submitting their
response. This has always been the expectation from what we finalized
in the HTI-1 Final Rule (89 FR 1348).
We propose to revise the name of Sec. 170.407 (Insights Condition
and Maintenance of Certification) to simply ``Insights.'' This proposed
change is intended to ensure consistency and uniformity across all the
Conditions and Maintenance of Certification in subpart D of 45 CFR part
170. We welcome comments on our proposals.
Technical Updates in Measure Specification Sheets
In the HTI-1 Final Rule (89 FR 1313), we stated that while the
substantive requirements for each measure are defined in rulemaking, we
determined that measure specification sheets are a logical and
accessible method for the public to also view the technical
specification that supports those requirements, and that this is
consistent with the approach used by other HHS programs related to
measure specifications (e.g., CMS Electronic Clinical Quality Measures
(CMS eCQMs)). Additionally, the measure specification sheets provide
granular definitions and other information needed to operationalize the
metrics to ensure they are implemented in a consistent manner across
health IT developers.
We also stated that we intend to provide up to date measure
specification sheets to assist with the regulated community's
understanding of the finalized measures and metric calculations (89 FR
1313). In January 2025, we provided developers of certified health IT
updated measure specification sheets for certain measures finalized in
the HTI-1 Final Rule, with the flexibility to implement either version
2 or version 4 of the measure specification sheets for the first year
of reporting.\64\ We note that this flexibility is only for the first
year of reporting (until July 2027) and that we expect developers to
comply with the most up to date version of the measure specification
sheets provided at www.healthIT.gov in subsequent years.
---------------------------------------------------------------------------
\64\ https://www.healthit.gov/sites/default/files/page/2025-05/insights_measure_spec_sheet_4_fact_sheet_v03.2_508.pdf.
---------------------------------------------------------------------------
E. ONC Health IT Certification Program Administrative Requirements
1. Principles of Proper Conduct for ONC-ACBs
Under the ``principles of proper conduct (PoPCs) for ONC-ACBs'' in
Sec. 170.523, we require ONC-ACBs to provide ASTP/ONC a ``certified
product listing'' in Sec. 170.523(f) which is a current list of Health
IT Modules that have been certified. We propose to revise Sec.
170.523(f)(1)(viii) to no longer require ONC-ACBs to provide test data
versions used and whether any test data was altered for the
certification criterion or criteria to which the Health IT Module has
been certified. With this proposed revision, we would still require the
test procedure and test tool version used. Through our CHPL, we have
tracked user access to the test data versions used and have found
engagement to be very infrequent. In addition, an analysis of Health IT
Modules in the CHPL indicates that the majority of developers do not
employ custom data when conducting certification testing but instead
utilize the ASTP/ONC-provided test data. Due to low user engagement and
little variance from the use of ASTP/ONC-provided test data, we believe
documenting the test data provides little value to the public and
represents additional administrative burden for both health IT
developers and ONC-ACBs. We believe this proposed revision to remove
this requirement aligns with our goals to reduce burden for both health
IT developers and ONC-ACBs.
We propose to make conforming revisions to the PoPCs for ONC-ACBs
in Sec. 170.523 by removing cross-references to certain certification
criteria that we propose to remove in this proposed rule. Specifically,
we propose to remove and reserve Sec. 170.523(f)(1)(ix) through (xi)
which reference the ``privacy and security'' certification criteria
(Sec. 170.315(d)), the ``quality management system'' certification
criterion (Sec. 170.315(g)(4)), and the ``accessibility-centered
design'' certification criterion (Sec. 170.315(g)(5)). We also propose
to remove and reserve Sec. 170.523(f)(1)(xix), which references the
``safety enhanced
[[Page 61005]]
design'' certification criterion (Sec. 170.315(g)(3)). We also propose
to remove and reserve Sec. 170.523(f)(1)(xxi) because this section
includes a reference to Sec. 170.315(b)(11)(vi) related to
intervention risk management practices and we propose to remove Sec.
170.315(b)(11)(vi) earlier in this proposed rule.
Consistent with the proposals related to the Real World Testing
Condition and Maintenance of Certification in Sec. 170.405, we propose
to remove the ONC-ACB review and confirmation process for real world
testing plans in Sec. 170.523(p)(1) and the reference to submit real
world testing plans in Sec. 170.523(p)(3). We welcome comments on our
proposals.
2. Health IT Module Certification
We propose to revise the ``Health IT Module dependent criteria'' in
Sec. 170.550(g) by removing Sec. 170.550(g)(1) through (4) to conform
with our proposals to remove certain certification criteria related to
privacy and security, and design and performance. We also propose to
renumber the remaining paragraphs in Sec. 170.550(g)(5) and (g)(6) to
(g)(1) and (g)(2), respectively. We propose to remove Sec. 170.550(h)
``privacy and security certification framework'' and Sec. 170.550(j)
``direct project transport method'' to also conform with our proposals
to remove certification criteria in Sec. 170.315(d) and Sec.
170.315(h).
Lastly, we propose to revise Sec. 170.550(e) ``standards updates''
to correct a cross-reference from ``Sec. 171.405(b)(7) or (8)'' to
``Sec. 170.405(b)(7) or (8).'' In the Cures Act Final Rule, we adopted
Sec. 170.550(e) ``standards updates'' requiring ONC-ACBs to provide an
option for certification of Health IT Modules consistent with SVAP to
one or more of the certification criteria referenced in real world
testing requirements in Sec. 170.405(a) based on newer versions of
standards (85 FR 25952). However, in the regulatory text we erroneously
amended Sec. 170.550(e) to require ONC-ACBs provide an option for
certification of Health IT Modules consistent with Sec. 171.405(b)(7)
or (8). We intended, as indicated by the preamble, to adopt the
reference to the real world testing requirements in 45 CFR part 170
instead of 45 CFR part 171 Information Blocking. Therefore, we propose
to revise Sec. 170.550(e) to reference the SVAP requirements in Sec.
170.405(b)(7) and (8). We welcome comments on our proposals.
3. Certification to Newer Versions of Certain Standards
We propose to revise the ``certification to newer versions of
certain standards'' in Sec. 170.555 by removing references to the term
``Complete EHR'' as it is no longer relevant in our Certification
Program. Retaining the references may cause confusion for the public
because the ability to maintain ``Complete EHR'' certification was only
permitted with health IT certified to the 2014 Edition certification
criteria, and the ``Complete EHR'' concept was discontinued for the
2015 Edition (80 FR 62719). The Cures Act Final Rule removed the 2014
Edition certification criteria in Sec. 170.314 and references to
``Complete EHR'', and in the HTI-1 Final Rule, we removed the
``Complete EHR'' language from all reference points in Sec. Sec.
170.523 and 170.524 (89 FR 1209 through 1210). We continued to remove
the remaining references to ``Complete EHR'' in the HTI-2 TEFCA Final
Rule (89 FR 101775) within subpart E of 45 CFR part 170, and we
finalized our proposal to remove the term ``Complete EHR'' including in
Sec. 170.555(b)(2). However, we inadvertently excluded amendatory
instructions to revise Sec. 170.555(b)(2) in the final rule.
Therefore, we propose to revise Sec. 170.555(b)(2) to remove the
reference to ``Complete EHR.'' We welcome comments on our proposal.
4. Effect of Revocation on the Certifications Issued to Health IT
Module(s)
We propose to revise the title of Sec. 170.570 from ``Effect of
revocation on the certifications issued to Complete EHRs and EHR
Module(s)'' to ``Effect of revocation on the certifications issued to
Health IT Module(s).'' As discussed above, the term ``Complete EHRs''
is no longer a relevant term in our Certification Program and retaining
it may cause confusion for the public. Therefore, we propose to revise
the title of Sec. 170.570 to further align with our removals of the
outdated ``Complete EHR'' terminology. We welcome comments on our
proposal.
IV. Information Blocking (Part 171)
Comments received in response to the CMS-ASTP/ONC Request for
Information; Health Technology Ecosystem (90 FR 21034) (CMS-ASTP/ONC
RFI) and other RFIs, such as the Federal Trade Commission's Request for
Public Comment Regarding Reducing Anti-Competitive Regulatory Barriers
(FTC-2025-0028), expressed concerns about several exceptions to the
information blocking rule as well as general concerns about the
exceptions. Innovators and patient advocates indicated that some of the
exceptions as currently codified may be too broad or are being misused
in an anti-competitive or obstructive way. For example, some commenters
suggested narrowing or eliminating the exceptions for infeasibility,
security, and fees. This proposed rule aims to address several
prominent themes among the concerns raised by commenters through
proposals below. Each of these proposed revisions to the information
blocking regulations would be effective, if finalized, on the effective
date of a subsequent final rule. We are also considering further
actions such as future rulemaking, guidance, and educational outreach
in response to other RFI comments and feedback from stakeholders.
A. ``Access'' and ``Use'' Definitions
In the Cures Act Final Rule, we finalized definitions of
``access,'' ``exchange,'' and ``use'' (85 FR 25805). We explained that
the concepts of access, exchange, and use are closely related, and
noted that EHI cannot be used unless it can be accessed, and that this
often requires that EHI be exchanged among different individuals or
entities and through various technological means (85 FR 25805). Our
references to various technological means always included access via
automated means, such as robotic process automation (commonly referred
to as the use of ``bots'') \65\ and autonomous artificial intelligence
systems (``agentic artificial intelligence'' or ``agentic AI''),\66\
but it has come to
[[Page 61006]]
our attention through RFI comments, our own market observations, and
stakeholder interactions that both actors and those who seek to access,
exchange, or use EHI would appreciate explicit clarity regarding
automated means of access, exchange, or use of EHI, particularly with
such means as robotic process automation (commonly referenced as
``RPA'' or ``bots'') and autonomous artificial intelligence systems
(commonly referenced in the field as ``agentic AI'').\67\ Therefore, we
propose to add language to the ``access'' and ``use'' definitions at 45
CFR 171.102. We propose to explicitly codify that access means the
ability or means necessary to make EHI available for exchange or use,
including by automation technologies such as robotic process automation
and autonomous artificial intelligence systems. Similarly, we propose
to explicitly codify that ``use'' means the ability for EHI, once
accessed or exchanged through whatever technological means, to be
understood and acted upon, including, without limitation, by automation
technologies such as autonomous artificial intelligence systems and
robotic process automation.
---------------------------------------------------------------------------
\65\ Robotic process automation is software technology in which
software ``bots'' mimic human actions to accomplish computer-based
activities, automating otherwise-manual tasks or processes that are
structured, repetitive, and follow a set of established rules.
Illustrative types of tasks include, without limitation, data
retrieval, data entry, and transaction processing (e.g., customer
returns of products, appointment scheduling). See, e.g., Moore,
Sara, 2018, ``The bots are coming: robotic process automation saves
DLA time, money'' (https://www.dla.mil/About-DLA/News/News-Article-View/Article/1704350/the-bots-are-coming-robotic-process-automation-saves-dla-time-money/ money/).
\66\ Autonomous artificial intelligence systems that are
designed to execute complex tasks autonomously or with little human
involvement to accomplish pre-determined goals is often referred to
a ``agentic AI'' because these systems' capabilities involve them
acting independently or having ability or means (``agency'') to act
independently (analogous to a human ``having agency'' or power to do
something) or function as an agent of its user. See, e.g., Merriam-
Webster ``agentic'' (https://www.merriam-webster.com/slang/
agentic#:~:text=What%20does%20agentic%20mean?,(%E2%80%9Chaving%20agen
cy%22)). See also, e.g., Acharya, et al, 2025, ``Agentic AI:
Autonomous Intelligence for Complex Goals--A Comprehensive Survey,''
IEEEAccess, Digital Object Identifier 10.1109/ACCESS.2025.3532853
(https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10849561).
\67\ We believe ``artificial intelligence'' is commonly and
generally understood to mean a machine-based system that can, for a
given set of human-defined objectives, make predictions,
recommendations, or decisions influencing real or virtual
environments as well as the capability of a computer, computer
system, or set of algorithms to imitate intelligent human behavior.
See, e.g., National Institute of Standards and Technology Computer
Security Research Center glossary entries for ``artificial
intelligence'' (https://csrc.nist.gov/glossary/term/artificial_intelligence) and ``artificial intelligence system''
(https://csrc.nist.gov/glossary/term/artificial_intelligence_system). See also Merriam-Webster dictionary
definition of ``artificial intelligence'' (https://www.merriam-webster.com/dictionary/artificial%20intelligence).
---------------------------------------------------------------------------
In addition to the discussion in the Cures Act Final Rule regarding
individuals or entities accessing, exchanging, and using EHI (85 FR
25805), we also discussed the concept of automated access in the HTI-1
Final Rule. Specifically, we noted that some entities may provide data
services and that such actions are considered access, exchange, or use
regardless of the route used to request, access, or receive data (89 FR
1363). The heterogeneity in how individuals and entities may access,
exchange, or use EHI as well as the potential for significantly
increased use of automated means to improve efficiency \68\ further
contributes to a conclusion that actors and those who interact with
them would benefit from explicit regulatory text specifying that the
access, exchange, and use definitions are not limited to manual
processes but apply equally to access, exchange and use of EHI that
occurs via automated means including, without limitation, autonomous
artificial intelligence systems and that an actor interfering with such
access, exchange, or use may implicate the information blocking
definition.
---------------------------------------------------------------------------
\68\ Moore, Sara, 2018, ``The bots are coming: robotic process
automation saves DLA time, money'' (https://www.dla.mil/About-DLA/News/News-Article-View/Article/1704350/the-bots-are-coming-robotic-process-automation-saves-dla-time-money/).
---------------------------------------------------------------------------
We are also considering to similarly revise the ``exchange''
definition in Sec. 171.102. We propose to revise the ``exchange''
definition in addition to the proposed revisions to the ``access'' and
``use'' definitions, as an alternative proposal to only revising the
``access'' and ``use'' definitions. Under this alternative proposal, we
propose that the meaning of ``exchange'' includes, without limitation,
the ability for EHI to be transmitted, through use of automation
technologies (e.g., robotic process automation, autonomous artificial
intelligence systems) or otherwise, between and among different
technologies, systems, platforms, or networks. We seek comments on
these proposals, including perspectives on whether actors and those who
interact with actors would find these explicit regulatory updates
helpful.
We remind readers that, as we have explained in prior rules, the
information blocking regulations are designed to operate in a manner
consistent with the framework of the HIPAA Privacy Rule and other laws
providing privacy rights for patients (85 FR 25812). Any actor (as
defined in 45 CFR 171.102) that is also subject to any provision(s) in
45 CFR parts 160, 162, or 164 must continue to comply with such
provision(s) when and to the extent such provisions of the HIPAA Rules
are applicable to the actor's conduct (89 FR 1380), such as with
providing access, exchange, or use of protected EHI.
B. Infeasibility Exception Revisions
We propose and seek comments on revisions to two separate
conditions of the Infeasibility Exception (45 CFR 171.204).
Specifically, we propose to remove the ``third party seeking
modification use'' condition (Sec. 171.204(a)(3)) and to revise or
remove the ``manner exception exhausted'' condition (Sec.
171.204(a)(4)).
1. Third Party Seeking Modification Use Condition
In the HTI-1 Final Rule, we finalized the ``third party seeking
modification use'' condition of the Infeasibility Exception (Sec.
171.204(a)(3)). We explained that when this condition applies and the
overall exception is met, an actor's practice of not fulfilling a
request for use of EHI in order to modify EHI, including but not
limited to creation and deletion functionality, will not be considered
information blocking (89 FR 1200 and 89 FR 1376 through 1380). As
finalized by the HTI-1 Final Rule and currently codified, Sec.
171.204(a)(3) applies to a request to enable use of EHI in order to
modify EHI, provided that the request for such use is not from a health
care provider that is a HIPAA covered entity (as defined in 45 CFR
160.103) requesting such use from an actor that is its business
associate (as defined in 45 CFR 160.103). Thus, the condition is not
available when a health care provider that is also a HIPAA covered
entity requests (directly, or through another business associate of the
health care provider) such use of EHI from an actor who is the health
care provider's business associate (88 FR 23866, 89 FR 1380).
HTI-1 Proposed Rule commenters expressed concern that certain
actors, such as health IT developers of certified health IT, may seek
to misuse the proposal to restrict access to EHI in an overly broad
manner (89 FR 1377). Of these commenters, some expressed concern that
the proposal could potentially inhibit care coordination by making it
too easy for an actor holding EHI to simply refuse modification use
requests from third parties who also furnish services to the same
patient(s) (89 FR 1377).
Commenters on the HTI-1 Proposed Rule stated that the limitation to
this condition is not broad enough, and that ASTP/ONC should expand the
limitation of this condition to also apply when the actor's customers
are not HIPAA covered entities; or are not health care providers, but
are maintaining EHI in systems licensed by an actor (89 FR 1379). For
reasons stated in response to these comments in the HTI-1 Final Rule
(89 FR 1379), we did not expand the finalized exclusion from
applicability of the condition but noted that we may consider amending
the condition in the future (89 FR 1379).
In the HTI-2 Proposed Rule, we proposed two revisions to narrow the
application and use of the third party seeking modification use
condition. First, we proposed to narrow the
[[Page 61007]]
applicability of the condition by changing the words ``health care
provider'' to ``covered entity as defined in 45 CFR 160.103'' (89 FR
63625), which would expand the circumstances in which the condition
could not be used. We noted that this proposed expansion of the
exclusion would encompass requests from all covered entities to their
business associates (89 FR 63625). Second, we also proposed to exclude
from applicability of the condition requests from any health care
provider (as defined in Sec. 171.102) who is not a HIPAA covered
entity (as defined in 45 CFR 160.103) but who is requesting
modification use from an actor whose activities would make the actor a
business associate of that same health care provider if that health
care provider were a HIPAA covered entity (89 FR 63625). This was to
align with the definition of ``actor'' under the information blocking
regulations.
Although comments on the HTI-2 Proposed Rule's potential revisions
to the Infeasibility Exception, including but not limited to the third
party seeking modification use condition, were generally supportive,
some commenters once again raised concerns about the potential for
actors to misuse the Infeasibility Exception and recommended that we
implement measures to mitigate misuse. For example, one commenter
suggested requiring an independent review and appeals process for
actors' claims of infeasibility as well as the mandated public
reporting of all infeasibility claims to hold actors accountable.
We received a relatively small number of comments specific to the
proposed narrowing of the third party seeking modification use
condition (Sec. 171.204(a)(3)). These comments indicate a much more
mixed response to this specific proposal than to the Infeasibility
Exception. Several commenters supported the proposed narrowing of the
third party seeking modification use condition's application. Several
commenters discussed the proposal as an expansion rather than a
contraction of the condition's application, indicating a
misunderstanding of the proposal. Several other commenters requested
additional clarification to understand the revised condition or even to
fully comment on the proposal. For example, one commenter stated that
the proposal was vague, and asked ASTP/ONC to clarify the proposal's
intended function and scope. Another commenter asked for examples of
specific types of scenarios so that they could fully understand the
proposal. Several other commenters, both supportive of the proposal's
intent and critical of it for various reasons, suggested actors would
need extensive guidance to properly implement the third party seeking
modification use condition.
We have evaluated not only our previously proposed revisions to the
condition but also the third party seeking modification use condition
(Sec. 171.204(a)(3)) in light of: the comments we received in response
to the proposal in the HTI-2 Proposed Rule; our observation of the
health information ecosystem and health IT market as they stand today;
the intent of the information blocking regulations, including what are
reasonable and necessary practices for not sharing EHI; and current HHS
policy priorities. We now believe the condition as a whole is
unnecessary and that removing it will better support the access,
exchange, and use of EHI and the goals we set out in the Cures Act
Final Rule to unleash innovation and competition for the improvement of
health outcomes and lower health care costs for all Americans.
In the HTI-1 Proposed Rule, we solicited comment on whether the
(then-proposed) third party seeking modification use condition should
be of limited duration (88 FR 23867). We specifically requested comment
on whether ASTP/ONC should consider proposing, in the future, that the
condition be eliminated if, at some point, health IT is capable of
supporting third-party modification use of EHI by any party with a
legal right to do so (or no legal prohibition against it), with no or
minimal infeasibility or other concerns (88 FR 23867). While the
majority of comments on this subject stated either that the proposal
should not have a sunset date, or that it would be premature to
establish a sunset date at that time, two commenters stated that the
condition should or could be eliminated in the future if technology is
capable of supporting the aforementioned modification use of EHI, with
no or minimal infeasibility or other concerns (89 FR 1378).
We agreed in the HTI-1 Final Rule with those commenters who had
indicated that it would be premature to establish at that time a sunset
date for Sec. 171.204(a)(3) because the appropriateness of eliminating
it depended on the continued development of health IT's capability to
support lawful third-party modification use of EHI by any party and
with no or minimal infeasibility or other concerns (89 FR 1378).
However, we also said that if advances in health IT capabilities or
other changes in the interoperability and information sharing
environment indicated to us that the condition should be modified or
sunset, we would anticipate proposing such a change in a future
rulemaking (89 FR 1378).
We have observed substantial growth in technical approaches that
enable efficient, appropriately secure modification use as well as two-
way exchange interactions between different developers' systems to
support modification use of EHI since HHS announced the HTI-1 Final
Rule in December, 2023.\69\ These approaches appear to be rapidly
maturing. As we increasingly observe modern, innovative approaches
efficiently achieving two-way interoperability, we no longer believe it
is reasonable or necessary for an actor to dismiss as ``infeasible'' a
request for such use from any requestor without engaging in information
gathering or analysis to work through the available alternative
manners. Thus, we now believe the time is ripe to propose to retire the
third party seeking modification use condition. Removing the condition
in its entirety is also the most efficient option to resolve concerns
we have developed from public comments, market observations, and
stakeholder interactions. As noted previously, we are concerned that
some actors may be misapplying the condition or intentionally abusing
customers' and third parties' misunderstandings of the condition or, in
the case of business associates, the flexibility we provided for them
to confirm whether a third-party modification use request is actually
from their HIPAA-regulated health care provider customer.\70\ In
particular, we are concerned that this condition is being abused by EHR
developers to limit third parties, including other actual or potential
business associates of the EHR developer's health care provider
customer, from accessing or using a health care provider's EHR and
relevant
[[Page 61008]]
EHI. This concern is extremely acute for us in that the ability for
health care providers to use other innovative health IT to access and
use the EHR has been a fundamental goal for Congress and HHS since we
first proposed the information blocking regulations.
---------------------------------------------------------------------------
\69\ ``HHS Finalizes Rule to Advance Health IT Interoperability
and Algorithm Transparency,'' news release posted Dec 13, 2023, at
https://www.hhs.gov/about/news/2023/12/13/hhs-finalizes-rule-to-advance-health-it-interoperability-and-algorithm-transparency.html.
Archived content available at: https://us.pagefreezer.com/en-US/wa/browse/0a7f82bb-be6e-448a-ae11-373d22c37842?find-by-timestamp=2024-01-02T03:56:59Z&url=https:%2F%2Fwww.hhs.gov%2Fabout%2Fnews%2F2023%2F12%2F13%2Fhhs-finalizes-rule-to-advance-health-it-interoperability-and-algorithm-transparency.html×tamp=2024-01-02T03:43:14Z.
\70\ See 89 FR 1380 discussion of flexibility for actors to
structure communications and operating procedures as well as our
statement that, for purposes of Sec. 171.204(a)(3), an actor may
choose to verify that the modification use request came from the
health care provider themselves or accept the third party's
representation of a request as coming from a health care provider of
which the actor is a business associate.
---------------------------------------------------------------------------
We are aware that actors may have concerns about third-party
modifications relating to the confidentiality, integrity, or
availability of EHI, or to the potential risks to patient safety
arising from corrupt or misidentified patient data. We remind health
care providers, other actors, patients, and others who may have such
concerns that we have established exceptions designed for those types
of concerns. For example, an actor may choose to satisfy the Security
Exception (Sec. 171.203) where an actor has identified a specific
threat that a request for access, exchange, or use poses to the
confidentiality, integrity, or availability of EHI in an actor's
systems. Similarly, an actor may choose to satisfy the Preventing Harm
Exception (Sec. 171.201) if the actor knows or reasonably suspects
specific data a third party seeks to write into the EHI the actor
maintains to be misidentified or mismatched, corrupt due to technical
failure, or erroneous for another reason. Actors may choose to satisfy
other exceptions, where applicable, regardless of whether we finalize
retirement of the third party seeking modification use condition of the
Infeasibility Exception. We refer readers to subparts B, C, and D of 45
CFR part 171 for the full conditions of each established information
blocking exception as currently codified. However, we remind readers
that for reasons discussed in Section IV.A.2 of this proposed rule, we
propose to revise or remove the manner exception exhausted condition
from the Infeasibility Exception (Sec. 171.204) and for reasons
discussed in Section IV.D of this proposed rule, we propose to remove
subpart D of 45 CFR 171: Exceptions That Involve Practices Related to
Actors' Participation in The Trusted Exchange Framework and Common
Agreement (TEFCA\SM.\).
We also remind actors that, if we were to finalize this proposal to
remove the third party seeking modification use condition, other
conditions of the Infeasibility Exception, including the infeasible
under the circumstances condition would continue to be available to
actors. For example, the infeasible under the circumstances condition
may apply to scenarios where enabling a third party to ``write'' data
to an EHR system would be unduly burdensome on a health IT developer of
certified health IT and its health care provider customers. As always,
for any practice to be considered information blocking, it must be
examined on a case-by-case basis in order to assess the specific facts
and circumstances and determine whether the practice meets the
information blocking definition (see Sec. 171.103, see also
IB.FAQ46.1.2022FEB).\71\
---------------------------------------------------------------------------
\71\ https://www.healthit.gov/faq/how-would-any-claim-or-report-information-blocking-be-evaluated.
---------------------------------------------------------------------------
We note again, as we did in the HTI-1 Final Rule, that the third
party seeking modification use condition does not imply or indicate any
change to the HIPAA Rules (89 FR 1380). Any actor that is subject to
any provision(s) in 45 CFR parts 160, 162, or 164 must continue to
comply with such provision(s) when and to the extent such provisions of
the HIPAA Rules are applicable to the actor's conduct (89 FR 1380).
To preserve accuracy of references in existing information blocking
educational materials to specific conditions of the Infeasibility
Exception by CFR citation, we propose to remove and reserve
subparagraph (3) within Sec. 171.204(a). We are not proposing at this
time to redesignate any of the other conditions currently codified
within Sec. 171.204(a), nor are we proposing to make any other changes
to any of these conditions or the responding to requests condition in
Sec. 171.204(b). We welcome comments on our proposal to remove the
third party seeking modification use condition of the Infeasibility
Exception.
2. Manner Exception Exhausted Condition
In the HTI-1 Proposed Rule, we proposed to re-number the
``infeasible under the circumstances'' condition of the Infeasibility
Exception (45 CFR 171.204) and to codify at (a)(4) a new manner
exception exhausted condition. We stated the proposed manner exception
exhausted condition would apply where an actor is unable to fulfill a
request for access, exchange, or use of EHI despite having exhausted
the Manner Exception in Sec. 171.301 by offering all alternative
manners in accordance with Sec. 171.301(b), so long as the actor does
not currently provide to a substantial number of individuals or
entities similarly situated to the requestor the same requested access,
exchange, or use of the requested EHI (88 FR 23867). We noted that
actors expressed concern about circumstances where the actor's
inability to satisfy the Manner Exception's conditions rests solely on
the requestor refusing to accept access, exchange, or use in any manner
consistent with Sec. 171.301 and that fulfilling the request in the
manner requested would require substantial technical or financial
resources, or both, in the view of the actor, including significant
opportunity costs (88 FR 23868). We noted that actors may have been
experiencing a problematic level of uncertainty about whether they will
be engaging in information blocking if they decline demands from
requestors for non-standard, non-scalable solutions that they do not
currently support. We noted that an actor might have experienced such
uncertainty even after that actor had offered to provide access,
exchange, or use of EHI in the same manner(s) the actor makes the EHI
generally available to its customers or affiliates, and through other
standards-based manners, consistent with Sec. 171.301--including
offering terms for such manners that are consistent with the Fees
(Sec. 171.302) and Licensing (Sec. 171.303) Exceptions (88 FR 23868).
We indicated observing such uncertainty among actors with substantial
skills and other resources to develop new, unique or unusual manners of
supporting access, exchange, or use of EHI (88 FR 23868).
We explained that the proposed manner exception exhausted condition
would provide actors the option of satisfying the Infeasibility
Exception without needing to assess whether they could theoretically or
technically meet the requestor's particularized demands regarding the
manner and/or the terms in which to achieve access, exchange, or use of
requested EHI. We proposed that an actor could satisfy the
Infeasibility Exception when the actor met the requirements of the
Sec. 171.204(b) responding to requests condition and the three factors
of manner exception exhausted condition were true:
(i) The actor could not reach agreement with a requestor in
accordance with Sec. 171.301(a) manner requested condition (as we have
proposed it in this proposed rule) or was technically unable to fulfill
a request for electronic health information in the manner requested;
(ii) The actor offered all alternative manners ``in accordance
with'' Sec. 171.301(b) alternative manner condition (as we have
proposed it in this proposed rule) for the electronic health
information requested but could not reach agreement with the requestor;
and
(iii) The actor does not provide the same access, exchange, or use
of the requested electronic health information to a substantial number
of individuals or entities that are similarly situated to the requester
(88 FR 23869).
[[Page 61009]]
We requested comments on all aspects of the proposal. In
particular, in regards to the second factor, we asked whether an actor
should have to offer access, exchange, or use in manners that would
satisfy all three of the alternative manners in Sec. 171.301(b)(1)
\72\ or if it should be sufficient for an actor to offer to fulfill the
request in two manners that use content and transport standards
published by the Federal Government or a standards-developing
organization accredited by the American National Standards Institute;
or by offering fulfillment in at least one such manner and an
alternative machine-readable format consistent with Sec.
171.301(b)(1)(iii) (88 FR 23869).
---------------------------------------------------------------------------
\72\ Here we are referring to Sec. 171.301(b)(2) as it was
codified at the time the HTI-1 Proposed Rule published; re-
designation of paragraphs within Sec. 171.301 was proposed in that
NPRM and finalized in the HTI-1 Final Rule (89 FR 1437, see also 89
FR 1372).
---------------------------------------------------------------------------
Regarding the third factor, we asked whether the language provided
adequate assurance that actors would not be able to misuse the Sec.
171.204(a)(4) manner exception exhausted condition to avoid supplying
some particular requestor(s) with manner(s) of access, exchange, or use
of the requested EHI that would be more accurately characterized as
generally available than as new, unique, or unusual (88 FR 23870). In
particular, we noted that the third factor is intended to ensure the
condition cannot be satisfied where a manner (mechanisms,
interoperability elements) is currently supported for a substantial
number of individuals or entities but the responding actor wants to
deny that mechanism to particular requestor(s) for inappropriate
reasons, such as to discriminate against competitors, potential
competitors, or those the responding actor may be concerned could use
the resultant access, exchange, or use of EHI to furnish, develop, or
facilitate development of products or services that could compete with
those of the actor (88 FR 23870). We asked if the flexibility of the
``substantial number'' factor would better recognize variations in
actors' operational contexts, including their organization sizes, as
compared to the clarity provided by a simple fixed threshold of ``more
than one,'' or even just one other entity. We also sought comment on
whether we should include ``similarly situated'' requestors or if such
a phrase risked allowing actors to discriminate based on requestor size
or type (88 FR 23870).
In the HTI-1 Final Rule, we finalized the manner exception
exhausted condition of the Infeasibility Exception (Sec.
171.204(a)(4)). In finalizing the manner exception exhausted condition,
we explained that when an actor either technically cannot provide the
access, exchange, or use of EHI in the manner requested, or the actor
and requestor cannot reach agreeable terms on the manner requested, the
actor must attempt to fulfill the request using the alternative manners
in Sec. 171.301(b) in order to exhaust the Manner Exception (89 FR
1381). Under the Manner Exception, for any alternative manner, the
requestor must either specify the manner they would accept (Sec.
171.301(b)(1)(i) and (ii)) or specifically agree with the machine-
readable format that they would accept (Sec. 171.301(b)(1)(iii)). We
stated that in situations where an actor offers at least two
alternative manners and the requestor does not specify or agree to
receive the EHI via the offered alternative manners (as may be the case
if the requestor does not want to receive the EHI in such a manner or
cannot receive the EHI in such a manner), an actor may seek to satisfy
the manner exception exhausted condition of the Infeasibility Exception
(89 FR 1381). In other words, under the manner exception exhausted
condition, it would not matter whether the requestor specified the
alternative manner, which is a requirement to meet the Manner Exception
under Sec. 171.301(b)(1)(i) and (ii). And the manner exception
exhausted condition of the Infeasibility Exception could be met if the
requestor did not agree with the actor upon an offered alternative
machine-readable format, which is a requirement to meet the Manner
Exception under Sec. 171.301(b)(1)(iii).
The manner exception exhausted condition of the Infeasibility
Exception, as finalized in the HTI-1 Final Rule, considers three
factors. First, it requires that the actor could not reach agreement
with a requestor in accordance with Sec. 171.301(a) or was technically
unable to fulfill a request for EHI in the manner requested (Sec.
171.204(a)(4)(i), 89 FR 1384 through 85). Second, the condition
requires that the actor offered at least two alternative manners in
accordance with Sec. 171.301(b) (whether or not the requestor
identified the alternative manner and/or agreed to it), one of which
must use either technology certified to standard(s) adopted in part 170
(Sec. 171.301(b)(1)(i)) or published content and transport standards
consistent with Sec. 171.301(b)(1)(ii) (see Sec. 171.204(a)(4)(ii)).
The third factor requires that the actor does not provide the same
access, exchange, or use of the requested EHI to a substantial number
of individuals or entities that are similarly situated to the requester
(Sec. 171.204(a)(4)(iii), 89 FR 1385 through 86). We explained what
``provide'' means in this context (89 FR 1385 through 86), as well as
``substantial number'' (89 FR 1384 through 85) and ``similarly
situated'' (89 FR 1386).
Specifically, we noted that ``similarly situated'' would serve to
indicate that different specific individuals or entities within a class
of such individuals or entities who are similarly situated to one
another should be treated in a consistent and non-discriminatory
manner, and that it is not our intent for the ``individuals or entities
that are similarly situated to the requester'' criterion of the
condition to be used in a way that differentiates the same access to
EHI simply based on the requestor's status, such as an individual
(e.g., a patient) or entity (e.g., a healthcare system) (89 FR 1386).
We explained that, in determining whether a requestor is similarly
situated, an actor shall not discriminate based on certain factors,
including whether the requestor is an individual as defined in Sec.
171.202(a)(2), the health care provider type and size, and whether the
requestor is a competitor of the actor or whether providing such
access, exchange, or use, would facilitate competition with the actor
(89 FR 1386). We finalized these factors in Sec. 171.204(a)(4)(iv).
The manner exception exhausted condition of the Infeasibility
Exception was intended to provide clarity and flexibility for actors.
We did not intend for it to cover any unreasonable or unnecessary
practice that would allow an actor to avoid providing the access,
exchange, or use of EHI in a manner already supported by that actor.
Based on comments received in response to the CMS-ASTP/ONC RFI,
questions received through the ASTP/ONC Health IT Feedback and Inquiry
Portal,\73\ and other stakeholder feedback, we are concerned that
actors may be abusing the exception in various ways, including claiming
to requestors that the manner exception exhausted condition applies
when the actor has not, in fact, explored whether they could reach
agreeable terms to fulfill a request in the manner requested, or has
not attempted to fulfill the request in at least two other manners
consistent with the Sec. 171.301(b) alternative manner, or both.
Additionally, we are concerned that certain terms and criteria of the
condition (i.e., ``same,'' ``substantial number'' and ``similarly
situated'') are being misused to deny requestors access to existing
APIs and other manners of access, exchange, and use that have
[[Page 61010]]
been granted to other parties. To address these concerns, we now
propose to modify the condition to eliminate the potential for misuse
and abuse.
---------------------------------------------------------------------------
\73\ https://healthit.gov/feedback.
---------------------------------------------------------------------------
Specifically, we propose (in Sec. 171.204(a)(4)(ii)) to increase
the minimum number of alternative manners required to be considered to
have ``exhausted'' the Manner Exception from two to ``all,'' in line
with the original (HTI-1 Proposed Rule) proposal for the condition. In
referring to ``all alternative manners,'' we do not mean all possible
manners of exchange other than the manner requested. Rather, we
specifically mean those manners that are set forth in subparagraph (i),
(ii), or (iii) of Sec. 171.301(b)(1). We seek comment on whether, and
to what extent, actors and those who request EHI access, exchange, or
use from actors would find useful a further reiteration in the text of
the condition that each alternative manner must be attempted consistent
with Sec. 171.301(b) (the alternative manner condition of the Manner
Exception) in order to satisfy the manner exception exhausted condition
of the Infeasibility Exception (Sec. 171.204(a)(4)). This addition
would further reiterate what the regulation text says at present and
what has been stated in the preamble of the HTI-1 Final Rule (see,
e.g., 89 FR 1383). Further, we remind actors that a manner that meets
any sub-paragraph within Sec. 171.301(b)(1) must be consistent with
the entirety of Sec. 171.302(b), which includes Sec. 171.301(b)(2),
under which any fees that would be charged by the actor in relation to
fulfilling the request must satisfy the Fees Exception (Sec. 171.302),
and Sec. 171.301(b)(3), under which any license of interoperability
elements granted by the actor in relation to fulfilling the request
satisfy the Licensing Exception (Sec. 171.303).
We also welcome comment on whether revisions to the wording of
Sec. 171.204(a)(4)(ii) would help ensure an actor can only claim to a
requestor that fulfilling the request is ``infeasible'' under the
manner exception exhausted condition when the actor has exhausted the
Manner Exception, as we intend. We welcome comment on whether any such
revisions could also discourage actors from attempting to abuse the
condition. We also propose to incorporate language into the regulation
text consistent with the preamble of the HTI-1 Final Rule, as discussed
above, to emphasize a distinction between the Manner Exception (Sec.
171.301) and the manner exception exhausted condition (Sec.
171.204(a)(4)): satisfying the manner exception exhausted condition
does not require that the requestor identify the alternative manner or
agree to it, which is required for actors to be able to fully meet the
Manner Exception.
In Sec. 171.204(a)(4)(iii), we propose three revisions. First, we
proposed to replace ``same'' with ``analogous'' as it refers to the
access, exchange, or use of EHI. We discussed in the HTI-1 Final Rule
how ``same'' meant the same requested access, exchange, or use,
including the ``same'' manners of EHI access, exchange, or use, as
provided to others. We still intend to include the concept of ``the
same'' access, exchange, or use of EHI in consideration of whether the
provision is met, but we believe the more expansive term ``analogous''
is more appropriate. We believe using ``analogous'' access, exchange,
or use in comparison to what the actor provides to other individual(s)
or entity(ies) is a basis less subject to manipulation than ``same,''
which some actors may argue equates to ``identical'' access, exchange,
or use of EHI. We do not intend for ``same'' to be interpreted in a way
that could be limiting and potentially manipulated to deny access,
exchange, or use. For example, this condition would not be available to
an actor when a requestor requests API access with certain features,
such as ``write'' capabilities or filtering functionality, that the
actor provides to other entities. Assuming for the sake of this example
that the actor is not prohibited by applicable law from providing the
requested access, exchange, or use of the requested EHI to the
requestor,\74\ the request is not infeasible under any other condition
in Sec. 171.204 (e.g., Sec. 171.204(a)(1) uncontrollable events) and
that no other exception in subpart B of part 171 (e.g., the Privacy
Exception) applies to the particular facts and circumstances, we would
expect such access would be provided to the requestor without
unnecessary delay. In providing such access, exchange, or use, an actor
who seeks certainty that their practices in fulfilling the requested
access, exchange, or use of EHI via the API with certain features will
not be considered information blocking can align their practices with
other relevant exception(s), such as the Fees Exception and, as
necessary, the Licensing Exception.\75\
---------------------------------------------------------------------------
\74\ Where applicable law prohibits an actor from fulfilling a
requestor's requested access, exchange, or use of requested EHI, the
actor need not satisfy an exception to have certainty that complying
with the law to which they are subject will not be considered
``information blocking.'' Where applicable law, such as the HIPAA
Privacy Rule, permits use or disclosure (access, exchange, or use)
of the requested EHI only when certain requirements
(``preconditions'') are met, the Precondition Not Satisfied (45 CFR
171.202(b)) sub-exception of the Privacy Exception outlines a
framework for actors to follow so that the actors' practices of not
fulfilling requests to access, exchange, or use EHI would not
constitute information blocking when a precondition of applicable
law has not been satisfied.
\75\ ``Interoperability element'' is defined in Sec. 171.102.
Additional information about this definition is available in the
preamble of the Cures Act Final Rule at 85 FR 25806 through 25808.
---------------------------------------------------------------------------
Similarly, the manner exception exhausted condition (as Sec.
171.204(a)(4) is currently codified or as we propose in this proposed
rule to modify it) would not be available to an actor if the actor
makes an API available to entities or individuals and a requestor
attempts to access the API through automated means (such as robotic
process automation and agentic AI).\76\ In such cases, the access
achieved by automated means would be the same and analogous to an
entity or individual accessing the API using more manual means.
Accordingly, we believe replacing ``the same'' with ``analogous'' is a
better basis for comparing the request with what the actor provides to
other individuals or entities, including those who may use different
automated means, or may use manual means. We believe this revision
aligns more with the intent of the statutory information blocking
definition (PHSA section 3022(a)(1)), which focuses on practices
``likely to interfere with, prevent, or materially discourage access,
exchange, or use of electronic health information'' without any
specification of, or limitation to, access, exchange, or use of EHI
through particular mechanisms, technologies, or workflows.
---------------------------------------------------------------------------
\76\ Please see section IV.A of this preamble, above, for
descriptions of robotic process automation and agentic AI.
---------------------------------------------------------------------------
Second and third, we propose: changing the ``substantial number''
element to ``any,'' by which we mean at least one individual or entity;
and removing consideration of whether such individual or entity is
similarly situated to the requestor. The proposed revisions to Sec.
171.204(a)(4)(iii) would explicitly exclude from application of the
condition any situation where the actor offers at least one individual
or entity the requested access, exchange, or use. These revisions would
alleviate concerns that the terms ``substantial'' and ``similarly
situated'' are being manipulated to deny access, exchange, or use.
Further, we do not believe that removal of the terms would undermine
the stated overall objective of the condition when it was proposed,
which was to provide certainty to actors when they were faced with
situations where the request would involve building ``one off'' access,
exchange, or use interfaces. Rather, the condition could still be met
if the actor does not provide analogous
[[Page 61011]]
access, exchange, or use of the requested EHI to any other individual
or entity.
If we finalize the proposal to retain the Sec. 171.204(a)(4)
condition with removal of the ``similarly situated'' element from Sec.
171.204(a)(4)(iii), instead of our alternative proposal (below) to
remove Sec. 171.204(a)(4) in its entirety, we also propose to remove
Sec. 171.204(a)(4)(iv). Specifying bases an actor shall not use in
determining whether a requestor is ``similarly situated'' under Sec.
171.204(a)(4)(iii) would be moot upon removal of ``substantially
similar'' from Sec. 171.204(a)(4)(iii).
In the alternative to our proposed revisions to the condition
above, we propose to remove the Sec. 171.204(a)(4) manner exception
exhausted condition entirely if public comments we receive on this
proposed rule indicate that our proposed revisions would not be
sufficient to eliminate or substantially mitigate the misuse or abuse
of the condition. We seek comments on this alternative approach.
If we were to finalize the alternative proposal to remove the Sec.
171.204(a)(4) manner exception exhausted condition, we would reserve
subparagraph (4) within Sec. 171.204(a) to preserve accuracy of
references in existing information blocking education materials to
specific conditions of the Infeasibility Exception by CFR citation. We
are not proposing at this time to redesignate any of the conditions
currently codified within Sec. 171.204(a) that would remain in the
event we finalize the alternative proposal to remove subparagraph (4),
the proposal discussed in section IV.A.1 of this preamble to remove
subparagraph (3) of Sec. 171.204(a), or both.
C. Manner Exception
In the Cures Act Final Rule, we established the Manner Exception
(then referred to as the ``Content and Manner'' Exception) in Sec.
171.301 (85 FR 25959, see also 85 FR 25875 through 25879). In
finalizing the exception, we stated our belief that it addressed
comments received regarding the breadth of the EHI definition and
flexibility in the manner an actor fulfills a request to access,
exchange, or use EHI, while providing market participants the ability
to reach and maintain market negotiated terms (85 FR 25876). As
finalized in the Cures Act Final Rule (85 FR 25642) and the Cures Act
Interim Final Rule (85 FR 70085), the information blocking definition
(Sec. 171.103) and the Content and Manner Exception (Sec. 171.301)
were limited for a period of time to a subset of EHI that was narrower
than the EHI definition finalized in the Cures Act Final Rule in Sec.
171.102. The narrower subset included only the EHI identified by the
data elements represented in USCDI version 1 for the first 18 months
(until May 2, 2022) after the applicability date for 45 CFR part 171
(November 2, 2020) (85 FR 25792). The Cures Act Interim Final Rule
extended the applicability date of 45 CFR part 171 to April 5, 2021 (85
FR 70069). This extension moved the end of the first 18 months of
applicability of 45 CFR part 171 to October 5, 2022 (85 FR 70069).
In the HTI-1 Final Rule (effective April 8, 2024), we revised Sec.
171.301 to remove reference to the content condition, which had been
moot as of October 6, 2022 (89 FR 1372). We also accordingly renumbered
the remaining provisions in Sec. 171.301 and simplified the name to
the ``Manner'' Exception (89 FR 1372).
Based on comments received in response to the CMS-ASTP/ONC RFI,
questions received through the ASTP/ONC Health IT Feedback and Inquiry
Portal,\77\ and other stakeholder feedback, we are concerned that some
actors may be attempting to abuse the exception, and that all
participants in the health information ecosystem would benefit from
greater certainty that the manner requested condition does not apply to
any contracts, agreements, or licenses that are for the purposes of
accomplishing access, exchange, or use of EHI in the manner requested,
but that: (1) are not at ``market'' rate (85 FR 25877); (2) are
contracts of adhesion; or (3) contain unconscionable terms (as defined
below). Specifically, we are concerned that some actors may be
incorrectly citing the manner requested condition to persuade
requestors that the exception applies to agreements and terms to which
it has never applied.
---------------------------------------------------------------------------
\77\ https://healthit.gov/feedback.
---------------------------------------------------------------------------
In both the Cures Act Proposed Rule and the Cures Act Final Rule,
we recognized the inherent power inequity between EHR developers and
various types of requestors (see 84 FR 7520, noting that EHR developers
are in a unique position to block access to EHI for use in competing
systems or applications). We also specifically address this concept of
inequity and how it could impact terms of contracts in the Cures Act
Final Rule (85 FR 25812). Foremost, we stated that a contract may
implicate the information blocking provision if it included
unconscionable terms for the access, exchange, or use of EHI or
licensing of an interoperability element, which could include, but not
be limited to, requiring a software company that produced a patient
access application to relinquish all IP rights to the actor or agreeing
to indemnify the actor for acts beyond standard practice, such as gross
negligence on the part of the actor. Further, we noted that such terms
may be problematic with regard to information blocking in situations
involving unequal bargaining power related to accessing, exchanging,
and using EHI (85 FR 25812).
As currently codified, the Manner Exception's manner requested
condition (Sec. 171.301(a)) applies when an actor fulfills a request
for EHI in any manner requested that the actor is technically able to
fulfill and for which the actor is able to reach agreeable terms with
the requestor. As set forth in the Cures Act Final Rule, if the actor
fulfills a request to access, exchange, or use EHI in any manner
requested, the fees or licensing agreements associated with fulfilling
such requests will not be limited by the conditions in the Fees
Exception (Sec. 171.302) or Licensing Exception (Sec. 171.303). Our
rationale was that actors would first attempt to negotiate agreements
in any manner requested with terms the actor chooses at the ``market''
rate--which supports innovation and competition (85 FR 25877). If the
actor could not reach agreeable terms by negotiation at the market
rate, actors could still fulfill the request in an alternative manner
(85 FR 25877). Given the language in the Cures Act Final Rule, we
understood ``agreeable terms'' were those terms agreed upon by actors
through arms-length negotiation at market rate (85 FR 25877). Agreeable
terms did not incorporate contracts of adhesion or contracts with
unconscionable terms. These types of agreements, by their very nature,
are either not agreed upon through arm's length negotiation or at
market rate.
Further, the manner requested condition allows the negotiation of
market rates and terms for the manner of access, exchange, or use
only--that is, the requested combination of content and transport
standard(s),\78\ ability to use an API or portal, or any other
requested health IT functionality or technological mechanism that
otherwise achieves the requested access, exchange, or use of the
requested EHI.\79\ The
[[Page 61012]]
Manner Exception does not apply to an actor's practices in negotiating
any aspect of a contract with a requestor other than the manner in
which access, exchange, or use of requested EHI is achieved and, if the
request is fulfilled in the manner requested, to market fees for items
and services provided and market terms for any licensing of
interoperability elements needed to fulfill the requested access,
exchange, and use of EHI in that manner.
---------------------------------------------------------------------------
\78\ In the Cures Act Final Rule preamble discussion of
alternative manners using content and transport standards specified
by the requestor under what is now codified at Sec.
171.301(b)(1)(ii), such an alternative ``manner'' includes two
distinct components: (1) content standard; and (2) transport
standard (85 FR 25878).
\79\ Manners of access, exchange, and use would include, without
limitation and where applicable, modification use of EHI that may be
maintained by the actor (for example, where an actor maintains EHI
on behalf of a health care provider and the health care provider
wants to use a third-party app or service to add or update data
points in various data classes or elements).
---------------------------------------------------------------------------
We reiterate the plain language of the Manner Exception, and
particularly the manner requested condition, in that the Manner
Exception only covers the technical manner of exchange of the requested
EHI, and not any other term(s) in any contract or agreement entered or
reached between the actor and requestor. Further, such contracts or
agreements for access, exchange, and use of EHI cannot be contracts of
adhesion or contracts containing unconscionable terms. These types of
contracts are not covered by the Manner Exception even if these
agreements were styled as, or in fact were, achieving access, exchange,
or use of the requested EHI in the requested manner. These types of
contracts would also likely constitute an interference (85 FR 25813)
under the information blocking regulations.
To further explicate the applicability of the Manner Exception
where the actor has the technical capability and is able to reach
agreement with the requestor to fulfill access, exchange, or use of
requested EHI in a manner requested by the requestor, we offer two
proposals. First, we propose to revise Sec. 171.301(a)(2) to add a new
subparagraph (iii) to incorporate in regulation text and explicitly
state that any contract or agreement related to the access, exchange,
or use of EHI: (1) must be at market rate; (2) must not be a contract
of adhesion; and (3) must not contain unconscionable terms. As stated
in the Cures Act Final Rule, agreements must be negotiated at market
rate (85 FR 25877). We propose to define, in Sec. 171.102, ``market
rate'' using paragraph (1) of the definition of ``fair market value''
found in the Stark Law regulations at 42 CFR 411.351: ``(1) General.
The value in an arm's-length transaction, consistent with the general
market value of the subject transaction'' (42 CFR 411.351). We propose
to define, in Sec. 171.102, ``contract of adhesion'' as a contract
provided on a standardized form, or on a ``take it or leave it basis''
without a realistic opportunity to bargain where the desired product,
services, access, use, or exchange cannot be provided except by
acquiescing to the form contract. We propose to incorporate the Merriam
Webster dictionary's definition of ``unconscionable'' to define, in
Sec. 171.102, ``unconscionable terms'' as those terms that are
excessive, unreasonable, or shockingly unfair or unjust. We further
explain unconscionable terms by way of examples in this preamble as
well as by the examples found in the preamble to the Cures Act Final
Rule (85 FR 25811 through 25812). Examples of unconscionable terms
related to the access, exchange, or use of EHI would include
indemnification waivers, waivers of rights to file claims of wrongdoing
with state or Federal authorities, terms that specify unreasonable
revenue sharing beyond fair market value (as already prohibited by the
Fees Exception), or terms that require surrendering intellectual
property rights without fair compensation.
An actor's practice that meets the manner requested condition of
the Manner Exception does not currently, and would not under the first
proposed revision, have to also satisfy the Fees Exception (Sec.
171.302) or the Licensing Exception (Sec. 171.303) in order for the
actor to have certainty the actor's practice specific to charging a fee
or licensing interoperability elements for fulfilling the requested EHI
access, exchange, or use in the manner requested would not be
considered information blocking.
This proposed approach offers both benefits and some potential
challenges. We believe this proposal to define new terms and emphasize
the parameters of the condition would offer more certainty to
responding actors and to requestors \80\ about what types, terms, or
provisions of agreements could be covered by the Manner Exception under
the manner requested condition (Sec. 171.301(a)). However, we also
recognize that actors would not have the same degree of certainty that
any fees and licensing terms the actor may seek to institute are
covered by an exception under the proposed revision of Sec. 171.301(a)
as they would have under the Fees Exception and the Licensing
Exception. Similarly, a requestor would not have the clarity and
certainty provided by the Fees Exception's (Sec. 171.302)
specifications for the fees it covers, including its exclusion of
certain bases for fees (e.g., Sec. 171.302(b)(3) and (4)), or the
requirements in the Licensing Exception (Sec. 171.303) for an actor's
practices in licensing interoperability elements in relation to
fulfilling access, exchange, or use of requested EHI in the manner
requested. Therefore, we offer another proposal discussed in more
detail below. As to this proposal, we seek comments on the proposed
provision and proposed definitions, suggestions for alternative
definitions, and any missing components that would more explicitly
describe excluded contractual terms. For example, should we instead, or
in addition, include the definition of ``general market value'' at 42
CFR 411.351--``with respect to the purchase of an asset, the price that
an asset would bring on the date of acquisition of the asset as the
result of bona fide bargaining between a well-informed buyer and seller
that are not otherwise in a position to generate business for each
other.''?
---------------------------------------------------------------------------
\80\ Any individual or entity can be a requestor, including
without limitation an individual or entity that happens to meet the
Sec. 171.102 ``actor'' definition. For example, a health care
provider is often also a requestor seeking access, exchange, or use
of EHI from health IT developers of certified health IT, HIN/HIEs,
and other health care providers.
---------------------------------------------------------------------------
We recognize the first proposed approach of adding explicit
language to Sec. 171.301(a) to ensure fair market rates and exclude
certain types of contracts and contractual terms may not fully address
all concerns about the misuse of the Manner Exception and may add
complexity or ambiguity with new terms. Therefore, we also propose in
the alternative to remove paragraph (a)(2) from the manner requested
condition of the Manner Exception, and explicitly apply the conditions
of both the Fees Exception (Sec. 171.302) and the Licensing Exception
(Sec. 171.303) to any agreement an actor makes with a requestor
related to fulfilling the request for access, exchange, or use of EHI
in any manner requested. Paragraph (a)(2) is where the manner requested
condition currently states that if an actor fulfills a request for EHI
in any manner requested, any fees charged by the actor in relation to
fulfilling the request are not required to satisfy the Fees Exception
(subparagraph (i) of paragraph (a)(2)), and any license of
interoperability elements granted by the actor in relation to
fulfilling the request are not required to satisfy the Licensing
Exception (subparagraph (ii) of paragraph (a)(2)). Under this
alternative proposal, we propose that the agreement would need to
satisfy the Fees Exception and the Licensing Exception, even when
fulfilling the request in any manner requested. This approach would
mean
[[Page 61013]]
that, while the actor and requestor retain flexibility to reach
mutually agreeable terms for the actor to fulfill access, exchange, or
use of the requested EHI in the manner requested, any fees charged by
the actor and any licensing terms for interoperability elements from
the actor to the requestor related to fulfilling the request must meet
all of the requirements of the Fees Exception and the Licensing
Exception for the actor to have certainty that their practice of
charging fees or licensing interoperability elements would not
constitute information blocking. In addition to simplifying the Manner
Exception, this alternative proposal to revise the Manner Exception
could promote greater consistency in actors' practices specific to fees
and licensing terms for fulfilling EHI access, exchange, and use
requests by following specified provisions of regulatory exceptions.
Removing paragraph (2) from Sec. 171.301(a) and applying the Fees
and Licensing Exceptions also specifically addresses the concerns
related to indemnification terms in contracts, as well as revenue-
sharing agreements. Under this alternative proposal, the actor and
requestor would retain the flexibility to negotiate and execute
specific details related to the requested manner of access, exchange,
or use of the requested EHI. This proposal also ensures there is no
mistaken belief that the Manner Exception would apply to any other
practice of the actor related to fulfilling the request, including any
contract or agreement on fees, licensing terms, or any matter other
than the specific technical details of what EHI is requested, and how
the request to access, exchange, or use the requested EHI will be
fulfilled. As noted above, we have heard that actors may be abusing the
manner requested conditions to convince requestors to accept
disagreeable terms that would be considered an interference and likely
information blocking. Removing paragraph (2) from Sec. 171.301(a) and
applying the Fees Exception and Licensing Exception would address these
issues.
We welcome comments on our proposed revisions to the Manner
Exception, including each of our proposals.
D. Removal of Subpart D Exception and Other Provisions Specific to
TEFCA
In the HTI-1 Final Rule, we finalized a new TEFCA Manner Exception
in 45 CFR 171.403, explaining that an actor's practice of limiting the
manner in which it fulfills a request for access, exchange, or use of
EHI to providing such access, exchange, or use only via TEFCA would not
be considered information blocking when the practice follows certain
conditions (89 FR 1387). The conditions include that the actor and
requestor are both part of TEFCA, that the requestor is capable of such
access, exchange, or use of the requested EHI from the actor via TEFCA,
that the request is not made via the standards adopted in 45 CFR
170.215 or version approved pursuant to 45 CFR 170.405(b)(8), and that
any fees charged by the actor and the terms for any license of
interoperability elements granted by the actor in relation to
fulfilling the request satisfy, respectively, the Fees Exception (45
CFR 171.302) and the Licensing Exception (Sec. 171.303) (89 FR 1388).
In the HTI-2 Proposed Rule, we requested further comment on the
TEFCA Manner Exception. We noted that the finalized exception differed
in two ways from the proposal in the HTI-1 Proposed Rule: by applying
the Fees Exception and the Licensing Exception to the TEFCA Manner
Exception, and by including the limitation that carves out requests
made for access, exchange, or use of EHI via FHIR API standards (89 FR
63643). We also solicited comment on the ``FHIR'' carve out,
specifically for options for revising or sunsetting the condition (89
FR 63643). Having considered comments received, we finalized the
exception without changes in the HTI-2 Final Rule (89 FR 101778 through
80). We also proposed in the HTI-2 Proposed Rule (89 FR 63642) and
finalized in the HTI-2 Final Rule (89 FR 101777 through 78) the
addition of a definitions section (Sec. 171.401) to Subpart D of part
171: ``Exceptions That Involve Practices Related to Actors'
Participation in The Trusted Exchange Framework and Common Agreement
(TEFCA\TM\)''.
We now propose to remove the TEFCA Manner Exception (Sec. 171.403)
from 45 CFR part 171. Based on TEFCA's continued implementation and
maturation and public comments received, including those received in
response to the CMS-ASTP/ONC Request for Information; Health Technology
Ecosystem (90 FR 21034) (CMS-ASTP/ONC RFI), the removal of the TEFCA
Manner Exception (Sec. 171.403) is appropriate for multiple reasons.
The exception was intended to incentivize participation in TEFCA.
However, many of the Qualified Health Information Networks (QHINs)--who
already participate in TEFCA--were critical of the exception when it
was proposed and presumably did not find the exception to be an
incentive. Further, we have observed that there is significant private
sector investment being made toward TEFCA participation in the health
information ecosystem. In comments on the CMS-ASTP RFI, stakeholders
representing health care providers, technology innovators, and other
perspectives, in addition to QHINs, advocated for continued use and
advancement of TEFCA. We therefore believe that it is unnecessary to
sustain the TEFCA Manner Exception to incentivize participation in
TEFCA.
We also believe the TEFCA Exception may be negatively impacting
participants in the health information ecosystem due to some entities'
potential misunderstanding regarding its purpose and applicability. For
example, although we stated when we finalized the exception that an
actor responding to a request from an individual (e.g., a patient or
the patient's personal representative) would not be able to make use of
this exception, we have observed some ongoing misunderstanding of this
exception as shielding actors who are part of TEFCA from information
blocking penalties for practices that interfere with individual-access
use cases.
The exception is also now unnecessary because it describes
activities that are, given the robust TEFCA participation we are
seeing, still covered by the Manner Exception (Sec. 171.301) or
Infeasibility Exception (Sec. 171.204). The Manner Exception
encourages active negotiation between a requestor and actor toward
getting requestors the EHI access, exchange, and use they seek in a
manner to which the requestor agrees. Conversely, the TEFCA Manner
Exception allows for responding actors to limit a requestor who also
participates in TEFCA to receiving EHI only via TEFCA when certain
conditions are met by the actor, potentially slowing adoption of more
innovative manners of access, exchange, or use than may be generally
supported by TEFCA participants at any given point in time. Further, if
an actor is unable to provide access, exchange, or use of EHI in the
manner requested, the actor may find the Infeasibility Exception
applicable to their circumstances, including the ``manner exception
exhausted'' condition.
With consideration of comments received in response to the CMS-
ASTP/ONC RFI and other RFIs, such as the Federal Trade Commission's
Request for Public Comment Regarding Reducing Anti-Competitive
Regulatory Barriers (FTC-2025-0028), we have become concerned that the
narrow TEFCA Manner Exception (applicable only to certain types of
exchange) may create an
[[Page 61014]]
unintended ceiling on future growth of TEFCA by discouraging
participation by new entrants for whom other manners of access,
exchange, or use of EHI will more efficiently support their innovative
products and services. Instead, TEFCA's future growth will be supported
by competition-oriented policies, compliance with applicable laws, and
the continual advancement of efficient, interoperable manners of EHI
access, exchange, and use of EHI that TEFCA supports.
We note that removing the TEFCA Manner Exception would not remove
any obligations an actor may have as a QHIN, Participant, or Sub-
participant in TEFCA to fulfill TEFCA requirements. The TEFCA Manner
Exception does not create, reduce, or otherwise affect any obligations
any actor may have as a QHIN, Participant, or Sub-participant in TEFCA
to fulfill TEFCA requirements.
Finally, we remind readers that removing this exception would not
mean that a practice that would have been covered by the TEFCA Manner
Exception would automatically be considered information blocking. As
always, for any practice to be considered information blocking, it must
be examined on a case-by-case basis in order to assess the specific
facts and circumstances and determine whether the practice meets the
information blocking definition (see Sec. 171.103, see also
IB.FAQ46.1.2022FEB: How would any claim or report of information
blocking be evaluated).\81\
---------------------------------------------------------------------------
\81\ https://www.healthit.gov/faq/how-would-any-claim-or-report-information-blocking-be-evaluated.
---------------------------------------------------------------------------
Because the TEFCA Manner Exception (Sec. 171.403) is the only
exception codified in subpart D of part 171, we also propose to remove
the entire subpart (subpart D). As currently codified, subpart D
includes only three sections: Sec. 171.400; Sec. 171.401; and Sec.
171.403. The removal of Sec. 171.403 would render the remaining two
sections unnecessary. Section 171.400, ``Availability and effect of
exceptions,'' mirrors Sec. Sec. 171.200 and 171.300, stating that a
practice shall not be treated as information blocking if the actor
satisfies an exception to the information blocking provision as set
forth in subpart D by meeting all applicable requirements and
conditions of the exception at all relevant times (89 FR 1388). Without
any exceptions specific to practices related to an actor's
participation in TEFCA, Sec. 171.400 would serve no purpose.
Similarly, Sec. 171.401 would serve no purpose because it only
includes definitions for the subpart via cross-reference to the TEFCA
definitions included 45 CFR part 172, ``Trusted Exchange Framework and
Common Agreement.''
We welcome comments on these proposals.
V. Incorporation by Reference
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). Specifically, 1 CFR 51.5(a)
requires agencies to discuss, in the preamble of a proposed rule, the
ways that the materials they propose to incorporate by reference are
reasonably available to interested parties and how interested parties
can obtain the materials, and to summarize, in the preamble of the
proposed rule, the material it proposes to incorporate by reference.
To make the material we intend to incorporate by reference
reasonably available, we provide a uniform resource locator (URL) for
the standard. This standard is directly accessible through the URL
provided. As an alternative, a copy of the standard may be viewed for
free at the U.S. Department of Health and Human Services, Office of the
National Coordinator for Health Information Technology, 330 C Street
SW, Washington, DC 20201. Please call (202) 690-7171 in advance to
arrange inspection.
The NTTAA and the OMB Circular A-119 require the use of, wherever
practical, technical standards that are developed or adopted by
voluntary consensus standards bodies to carry out policy objectives or
activities, with certain exceptions. The NTTAA and OMB Circular A-119
provide exceptions to selecting only standards developed or adopted by
voluntary consensus standards bodies, namely when doing so would be
inconsistent with applicable law or otherwise impractical. As discussed
in section III.B.1.a of this preamble, we have followed the NTTAA and
OMB Circular A-119 in proposing a standard for adoption, including
describing any exceptions in the adoption of the standard.
As required by 1 CFR 51.5(a), we provide a summary of the standard
we propose to adopt and subsequently incorporate by reference in the
CFR. We also provide relevant information about the standard throughout
the preamble.
United States Core Data for Interoperability--45 CFR 170.213
United States Core Data for Interoperability (USCDI), June
2025, Version 3.1 (v3.1) URL: https://www.healthit.gov/isp/sites/isp/files/USCDI-Version-3-1_2025_508.pdf. This is a direct access link.
Summary: USCDI establishes a minimum set of data classes that are
required to be interoperable nationwide and is designed to be expanded
in an iterative and predictable way over time.
The following standards appear in the amendatory text of this
document and have already been approved for the locations in which they
appear:
--HL7 Messaging Standard Version 2.5.1,
--HL7 Clinical Document Architecture (CDA), Release 2.0, Normative
Edition,
--HL7 CDA(copyright) Release 2 Implementation Guide: Reporting to
Public Health Cancer Registries from Ambulatory Healthcare Providers,
Release 1; DSTU Release 1.1, Volume 1--Introductory Material and Volume
2--Templates and Supporting Material,
--HL7 Implementation Guide for CDA[supreg] Release 2: National Health
Care Surveys (NHCS), Release 1--US Realm, HL7 Draft Standard for Trial
Use, Volume 1--Introductory Material and Volume 2--Templates and
Supporting Material,
--HL7[supreg] FHIR[supreg] Implementation Guide: Electronic Case
Reporting (eCR)--US Realm 2.1.0--STU 2 US (HL7 FHIR eCR IG),
--HL7 CDA[supreg] R2 Implementation Guide: Public Health Case Report--
the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1--
US Realm (HL7 CDA eICR IG),
--HL7[supreg] CDA[supreg] R2 Implementation Guide: Reportability
Response, Release 1, STU Release 1.1--US Realm (HL7 CDA RR IG), and
--Reportable Conditions Trigger Codes Value Set for Electronic Case
Reporting.
No changes are proposed to the IBR material.
VI. Response to Comments
Because of the large number of public comments normally received in
response to Federal Register documents, we are not able to acknowledge
or respond to them individually. We will consider all comments we
receive by the date and time specified in the DATES section of this
preamble, and when we proceed with a subsequent document, we will
respond to the comments in the preamble of that document.
[[Page 61015]]
VII. Collection of Information Requirements
Under the Paperwork Reduction Act of 1995 (PRA), codified as
amended at 44 U.S.C. 3501 et seq., agencies are required to provide
notice in the Federal Register and solicit public comment on a proposed
collection of information before it is submitted to the Office of
Management and Budget for review and approval. In order to fairly
evaluate whether an information collection should be approved by the
OMB, section 3506(c)(2)(A) of the PRA requires that we solicit comment
on the following issues:
1. Whether the information collection is necessary and useful to
carry out the proper functions of the agency;
2. The accuracy of the agency's estimate of the information
collection burden;
3. The quality, utility, and clarity of the information to be
collected; and
4. Recommendations to minimize the information collection burden on
the affected public, including automated collection techniques.
Under the PRA, the time, effort, and financial resources necessary
to meet the information collection requirements referenced in this
section are to be considered. We explicitly seek, and will consider,
public comment on our assumptions as they relate to the PRA
requirements summarized in this section.
A. ONC-ACBs
We propose to descope the ``Real World Testing'' Condition and
Maintenance of Certification requirements in Sec. 170.405 with
deregulatory actions related to real world testing plans, results, and
the use of the standards version advancement process (SVAP). Consistent
with these proposals to descope the Real World Testing Condition and
Maintenance of Certification requirements, we propose to make
conforming edits in Sec. 170.523(p) to remove the ONC-ACB review and
confirmation process for real world testing plans in Sec.
170.523(p)(1), and the submission of real world testing plans in Sec.
170.523(p)(3) which requires ONC-ACBs to collect and report certain
information to ONC related to real world testing plans (e.g., verify
that the health IT developer submits an annual, publicly available real
world testing plan and perform a completeness check). Our proposals in
this proposed rule would not add any new collection of information
burden and would instead reduce reporting burden associated with the
proposed deregulatory actions.
In the 2015 Edition proposed rule (80 FR 16894), we estimated fewer
than ten annual respondents for all of the regulatory ``collection of
information'' requirements that apply to the ONC-Approved Accreditor
(ONC-AA) and ONC-ACBs, including those previously approved by OMB. In
the 2015 Edition Final Rule (80 FR 62733), we concluded that the
regulatory ``collection of information'' requirements for the ONC-AA
and the ONC-ACBs were not subject to the PRA under 5 CFR 1320.3(c). We
continue to estimate less than ten annual respondents for all of the
proposed regulatory ``collection of information'' requirements for ONC-
ACBs under part 170 of title 45, including those previously approved by
OMB and proposed in this proposed rule. Accordingly, the regulatory
``collection of information'' requirements under the Program described
in this section are not subject to the PRA under 5 CFR 1320.3(c). We
welcome comments on these conclusions and the supporting rationale on
which they are based. For the cost and burden reduction estimates
related to these proposed deregulatory actions, we refer readers to
section VIII (Regulatory Impact Analysis) of this proposed rule.
B. Health IT Developers
The ``Insights'' Condition and Maintenance of Certification
requirements in Sec. 170.407 include seven measures that health IT
developers under the ONC Health IT Certification Program must annually
report on consistent with specified regulatory compliance timelines. In
the HTI-1 Final Rule (89 FR 1399), we estimated the total crude upper
bound burden to be 1,767,692 hours. In this proposed rule, we propose
to remove and descope measures associated in Sec. 170.407 to limit
reporting requirements only to the ``use of FHIR in apps through
certified health IT'' measure, which would reduce reporting burden for
health IT developers reporting under the Certification Program. In
other words, we propose to reduce reporting burden associated with the
Insights Condition and Maintenance of Certification requirements, and
do not propose any new requirements that would add information
collection burden. For more detailed discussion of burden reduction
estimates of these deregulatory actions associated with the Insights
Condition and Maintenance of Certification, we refer readers to section
VIII (Regulatory Impact Analysis) of this proposed rule.
VIII. Regulatory Impact Analysis
A. Statement of Need
E.O. 14192 on Unleashing Prosperity Through Deregulation, issued
January 31, 2025, sets the policy to ``to significantly reduce the
private expenditures required to comply with Federal regulations to
secure America's economic prosperity and national security and the
highest possible quality of life for each citizen.'' \82\ To that end,
E.O. 14192 requires that ``any new incremental costs associated with
new regulations shall, to the extent permitted by law, be offset by the
elimination of existing costs associated with at least 10 prior
regulations.'' \83\ This proposed rule, if finalized as proposed, is
expected to be an E.O. 14192 deregulatory action and includes
regulations and policies ASTP/ONC proposes to remove and revise to
unleash prosperity. We believe the proposed changes will reduce burden
on developers of certified health IT, returning time and effort to
them, and in turn, enhancing competition, entrepreneurship, and
innovation. These proposed deregulatory actions will reduce barriers to
entry for novel technologies and digital health solutions, give time
back to developers of certified health IT to focus on the needs and
requests of their customers, and, overall, advance progress toward
nationwide interoperability and universal patient access to their
electronic health information.
---------------------------------------------------------------------------
\82\ https://www.federalregister.gov/d/2025-02345/p-2.
\83\ https://www.federalregister.gov/d/2025-02345/p-6.
---------------------------------------------------------------------------
B. Overall Impact
We have examined the impacts of this proposed rule as required by
E.O. 12866, ``Regulatory Planning and Review''; E.O. 13132,
``Federalism''; E.O. 13563, ``Improving Regulation and Regulatory
Review''; E.O. 14192, ``Unleashing Prosperity Through Deregulation'';
section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C.
1532); and the Regulatory Flexibility Act (RFA) (Pub. L. 96-354).
1. Regulatory Planning and Review Analysis
This proposed rule implements relevant policy priorities outlined
in E.O.s 12866, 13563, and 14192. E.O. 12866 and 13563 direct agencies
to assess all costs and benefits of available regulatory alternatives
and, if regulation is necessary, to select regulatory approaches that
maximize net benefits (including potential economic, environmental,
public health and safety
[[Page 61016]]
effects, and distributive impacts). E.O. 14192 directs agencies to
repeal ten existing regulations for each new regulation issued in 2025
and thereafter and to account for cost savings associated with
deregulatory actions. This proposed rulemaking, if finalized as
proposed, is expected to be an E.O. 14192 deregulatory action, and we
have therefore prepared an RIA that to the best of our ability presents
the expected significant cost savings to regulated entities generated
by the proposed actions.
a. Costs and Benefits
These proposed deregulatory actions provide substantial relief for
developers of certified health IT and significant cost savings realized
from the revision and removal of certain program requirements. For the
purpose of estimating the cost savings of this proposed rulemaking, we
have determined that these policies would continue absent this
regulatory action. The cost savings have been estimated using the best
available data and modeled on the costs estimated and finalized in
prior ASTP/ONC rulemakings. As articulated in the preamble, these
proposed deregulatory actions reduce the effort of developers of
certified health IT to meet ongoing program requirements and reduce
barriers to entry for new program participants. The proposed actions,
importantly, return effort back to developers of certified health IT to
innovate their technology and focus on the needs of their clients and
end users.
Employee Assumptions and Hourly Wage
We have made employee assumptions about the level of expertise
needed to complete the requirements that are affected by this proposed
rule. Unless indicated otherwise, for wage calculations for Federal
employees and ONC-ACBs, we have correlated the employee's expertise
with the corresponding grade and step of an employee classified under
the General Schedule (GS) Federal Salary Classification, relying on the
associated employee hourly rates for the Washington, DC, locality pay
area as published by the OPM for 2025.\84\ We have assumed that other
indirect costs (including benefits) are equal to 100% of pre-tax wages.
Therefore, we have doubled the employee's hourly wage to account for
other indirect costs. We have concluded that a 100% expenditure on
benefits and overhead is an appropriate estimate based on research
conducted by HHS.\85\
---------------------------------------------------------------------------
\84\ https://www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/2025/general-schedule/.
\85\ See U.S. Department of Health and Human Services, Office of
the Assistant Secretary for Planning and Evaluation (ASPE),
Guidelines for Regulatory Impact Analysis, at 28-30 (2016),
available at https://aspe.hhs.gov/reports/guidelines-regulatory-impact-analysis.
---------------------------------------------------------------------------
Unless otherwise noted, we have consistently used the May 2024
National Occupational Employment and Wage Estimates reported by the
U.S. Bureau of Labor Statistics (BLS) to calculate private sector
employee wage estimates (e.g., health IT developers, health care
providers, HINs, attorneys, etc.), as we believe BLS provides the most
accurate and comprehensive wage data for private sector positions.\86\
These wage estimates are a national average and we do not consider
regional wage variation in our estimates. We also do not consider
possible variation in the average wages for software developers in
health care IT positions versus IT positions, more generally, which the
BLS wage estimate is based upon. Just as with the General Schedule
Federal Salary Classification calculations, we have assumed that other
indirect costs (including benefits) are equal to 100% of pre-tax wages.
We welcome comments on our methodology for estimating labor costs,
including the effects of any regional or IT sector wage variation on
our estimates.
---------------------------------------------------------------------------
\86\ https://data.bls.gov/oes/#/industry/000000.
---------------------------------------------------------------------------
According to the May 2024 BLS occupational employment statistics,
the mean hourly wage for a ``Software Developer'' is $69.50. As noted
previously, we have assumed that other indirect costs (including
benefits) are equal to 100% of pre-tax wages, so the hourly wage
including other indirect costs for Software Developers is $139.00.
Quantifying the Estimated Number of Health IT Developers and Products
Given the wide range of proposed deregulatory actions, we have not
adopted a single, over-arching approach to calculate the number of
health IT developers and products affected by this rulemaking. We
believe, however, that each current developer of certified health IT
and participant in the Certification Program will be affected by these
proposed actions, but that impact will vary, given the breadth and
scope of each developer's participation in the Certification Program.
For each set of proposed actions, we describe our methodology for
calculating the current number of health IT developers and products
affected, and, where applicable, model estimated future counts of
developers and products affected.
Number of End Users That Might Be Impacted by ASTP/ONC's Proposed
Regulations
The breadth and scope of the proposed deregulatory actions create
immediate and significant cost savings for developers of certified
health IT. As we have finalized in prior ASTP/ONC rulemakings--Cures
Act Final Rule (85 FR 25642) and HTI-1 Final Rule (89 FR 1192)--we
assume the regulatory costs imposed by those rules on developers may be
passed on to end users of their technology in the form of increased
fees and other costs. These deregulatory actions, though scoped to
provide immediate relief and reduce ongoing burden on developers of
certified health IT, may have downstream impacts on technology end
users who may benefit from lower marginal costs to license and update
their software; focused developers efforts on emerging end user needs;
and other forms of innovation that may lead to unquantified benefits
and savings for end users. We assume developers of certified health IT
will use the cost savings to invest in innovation and emerging
technology, rather than directly reduce costs on their end users, but,
overall, believe the cost savings will create a net benefit to end
users, if not directly as an immediate financial savings.
Costs
We do not expect costs to be associated with the deregulatory
action proposals. We do, however, estimate the costs to review the
rule.
All entities affected by this proposed rule, if finalized, would
spend time to read and understand the final rule, resulting in a one-
time cost. The current Preamble and proposed regulatory text together
contain approximately 64,727 words; we use this as a proxy for the
length of the final rule. Consistent with HHS guidelines, we assume
that industry reviewers read at the average adult reading speed of
approximately 288 (64,727/225) words per minute, so the time to read
and understand the regulation would be about 4 hours per person
(288*60=17,280) (64,727/17,280=3.75). We estimate the total number of
reviewers by taking the number of estimated developers and adding an
estimated number of medical associations that represent health care
providers and health information networks, etc. The counts of
developers included in Table R-1 were calculated using publicly
available Certification Program data available through the
[[Page 61017]]
CHPL.\87\ We took the estimated number of developers from Table R-1,
which is 444 developers and estimated 200 medical associations.\88\ We
then determined that there would likely be 644 individuals to review
the proposed rule. As mentioned above, we used the May 2024 National
Occupational Employment and Wage Estimates reported by the BLS to
calculate private sector employee wage estimates.\89\ We identified the
``Management Analyst'' position as comparable to a position that would
review the rule. According to the May 2024 BLS occupational employment
statistics, the mean hourly wage for a ``Management Analyst'' is
$55.15. As noted previously, we have assumed that other indirect costs
(including benefits) are equal to 100% of pre-tax wages, so the hourly
wage including other indirect costs for a Management Analyst is
$110.30. We estimate it will take four hours to review the proposed
rule. Therefore, the total cost to review the rule for one reviewer
would be $441.20 ($110.30*4). We took the estimated number of
individuals to review the rule which is 644 and then multiplied that by
$441.20 and calculated the estimated total cost to review the rule to
be $284,132 ($441.20*644).
---------------------------------------------------------------------------
\87\ https://chpl.healthit.gov.
\88\ https://www.ama-assn.org/house-delegates/hod-organization/member-organizations-ama-house-delegates?utm_source=chatgpt.com.
\89\ https://data.bls.gov/oes/#/industry/000000.
---------------------------------------------------------------------------
Benefits
We expect the proposed deregulatory actions to result in
significant benefits for health IT developers, providers, ONC-ACBs,
ONC-ATLs, and ASTP/ONC. These expected benefits are detailed below.
Generally, these benefits are in the form of cost and time savings and
reductions in administrative burden to comply with Certification
Program requirements. The proposed actions reduce the scope and breadth
of program requirements. The proposed program revisions provide direct
cost savings (quantified, below) to developers of certified health IT
and their users (i.e., providers) through fewer program requirements
and lower regulatory barriers, freeing up time for more innovation and
meeting customer needs. In turn, the revised program requirements may
reduce the implementation effort on ONC-ACBs, ONC-ATLs, and ASTP/ONC,
who works with ACBs and ATLs to implement program requirements. These
savings in time and effort to ONC-ACBs, ONC-ATLs, and ASTP/ONC can be
used toward remaining program improvement and implementation efforts,
enhancing the operation and management of the program.
1. Removal
1.1 Removal of Certification Criteria
We propose to remove 34 certification criteria. Of these, we
propose to remove 24 criteria as of the effective date of any final
rule and the remaining ten criteria as of January 1, 2027. We developed
a common model for estimating cost savings associated with the removal
of all but one certification criterion, described below. For all
criteria we assume that the cost savings from these criteria would
begin January 1, 2027.
Table R-1, below, provides criterion-level results of our model for
32 of the proposed criteria removals. For each certification criterion
we identified the original costs to certify to the functionality from
prior rules (the lower and upper bounds of ``Total Hours'' in Table R-
1.) 90 91 92 We then assumed that the annual cost to
maintain certification was a small fraction of the initial costs. We
are not aware of any published evidence that would directly inform this
calculation, and, therefore, developed a novel approach using various
information sources. We defined this fraction (``Final Effort
Multiplier'' in Table R-1) based on five factors: (1) ``Test'': the
criterion's certification conformance method, assuming that criteria
with a test procedure had additional maintenance costs while those with
a conformance method of attestation had no additional cost beyond what
was initially incurred; (2) ``Stakeholder feedback'': stakeholder
feedback received by ASTP/ONC through meetings, informal conversations,
and letters from impacted parties on effort involved in certifying and
updating the specific certification criterion; (3) ``Complexity of
standard'': whether the criterion referenced a standard and an
assessment of the complexity involved in maintaining and updating
conformance to that standard over time, including through future
regulatory requirements to update criteria to support new versions of
the USCDI; (4) ``Complexity of test procedure'': an assessment of the
complexity of the test procedure or evaluative work to support
attestation when it was necessary to undertake the certification
process; and (5) ``General complexity'': an overall assessment of the
complexity of maintaining the certification criterion and underlying
functionality.
---------------------------------------------------------------------------
\90\ https://www.federalregister.gov/documents/2015/10/16/2015-25597/2015-edition-health-information-technology-health-it-certification-criteria-2015-edition-base#p-185.
\91\ https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and.
\92\ https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification.
---------------------------------------------------------------------------
The ``Final Effort Multiplier'' is a sum of the five factors listed
in the table and described above. We then used this multiplier to
determine the annual costs of meeting and maintaining the individual
criteria by taking the product of the lower and upper bound ``Total
Hours'', described above, and this multiplier. We then estimated the
lower and upper bounds of ``Hours saved'' by multiplying the ``Annual''
hours by the number of products that certify each criterion. The counts
of developers and products included in Table R-1 are current as of May
1, 2025. The counts were calculated using publicly available
Certification Program data available through the CHPL.\93\ Although we
primarily use the count of products to estimate ``Hours saved'', the
count of developers is included for reference and comparison.
---------------------------------------------------------------------------
\93\ https://chpl.healthit.gov.
---------------------------------------------------------------------------
BILLING CODE 4150-45-P
[[Page 61018]]
[GRAPHIC] [TIFF OMITTED] TP29DE25.036
BILLING CODE 4150-45-C
Table R-1--Panel B--Annual Undiscounted Cost Savings Estimates for the Removal of Certification Criteria
----------------------------------------------------------------------------------------------------------------
Criterion Name Lower bound Upper bound
----------------------------------------------------------------------------------------------------------------
Sec. 170.315(a)(12)......................... Family health history........... $248,463 $496,925
Sec. 170.315(a)(14)......................... Implantable device list......... 1,909,026 5,454,360
Sec. 170.315(b)(2).......................... Clinical information 5,195,820 6,234,984
reconciliation and
incorporation.
Sec. 170.315(b)(7).......................... Security tags--summary of care-- 640,512 1,040,832
send.
[[Page 61019]]
Sec. 170.315(b)(8).......................... Security tags--summary of care-- 620,496 1,008,306
receive.
Sec. 170.315(b)(9).......................... Care plan....................... 569,205 813,150
Sec. 170.315(c)(4).......................... Clinical quality measures 838,170 1,257,255
(CQMs)--filter.
Sec. 170.315(d)(1).......................... Authentication, access control, 315,252 630,504
authorization.
Sec. 170.315(d)(2).......................... Auditable events and tamper- 341,523 683,046
resistance.
Sec. 170.315(d)(3).......................... Audit report(s)................. 537,096 1,074,192
Sec. 170.315(d)(4).......................... Amendments...................... 218,508 437,016
Sec. 170.315(d)(5).......................... Automatic access time-out....... 69,917 139,834
Sec. 170.315(d)(6).......................... Emergency access................ 118,428 236,856
Sec. 170.315(d)(7).......................... End-user device encryption...... 383,779 767,558
Sec. 170.315(d)(8).......................... Integrity....................... 297,391 594,781
Sec. 170.315(d)(9).......................... Trusted connection.............. 914,064 1,828,128
Sec. 170.315(d)(10)......................... Auditing actions on health 56,295 112,590
information.
Sec. 170.315(d)(11)......................... Accounting of disclosures....... 125,656 188,484
Sec. 170.315(d)(12)......................... Encrypt authentication 444,175 888,349
credentials.
Sec. 170.315(d)(13)......................... Multi-factor authentication..... 242,277 484,554
Sec. 170.315(e)(3).......................... Patient health information 1,163,430 1,861,488
capture.
Sec. 170.315(f)(4).......................... Transmission to Cancer 538,208 672,760
Registries.
Sec. 170.315(f)(7).......................... Transmission to PHAs--Health 700,560 980,784
Care Surveys.
Sec. 170.315(g)(1).......................... Automated numerator recording... 462,592 693,888
Sec. 170.315(g)(2).......................... Automated measure calculation... 6,116,000 9,785,600
Sec. 170.315(g)(4).......................... Quality management system....... 409,355 1,309,936
Sec. 170.315(g)(5).......................... Accessibility-centered design... 409,355 818,710
Sec. 170.315(g)(6).......................... Consolidated CDA creation 4,403,520 9,907,920
performance.
Sec. 170.315(g)(7).......................... Application access--patient 1,010,808 1,347,744
selection.
Sec. 170.315(g)(9).......................... Application access--all data 2,962,368 3,949,824
request.
Sec. 170.315(h)(1).......................... Direct Project.................. 5,112,976 7,030,342
Sec. 170.315(h)(2).......................... Direct Project, Edge Protocol, 480,384 660,528
and XDR/XDM.
-----------------------------------------------------------------
Total Cost Savings........................ ................................ 37,855,816 63,391,228
----------------------------------------------------------------------------------------------------------------
* The lower and upper bound cost savings estimates use the hourly wage ($139.00) we describe above in ``Employee
Assumptions and Hourly Wage''.
For the 32 certification criteria proposed for removal in Table R-
1, we estimate the total annual hours saved to range from 272,344 to
456,052, among 444 developers of certified health IT and 589 certified
products (Table R-1). Using the hourly labor rate ($139), described
above, we estimate the total undiscounted annual cost savings to range
from $37,855,816 to $63,391,228. We welcome comments on the proposed
methodology and the accuracy and validity of the model's estimates.
1.2 Removal of Safety-Enhanced Design
Cost savings from the proposed removal of Sec. 170.315(g)(3)
safety-enhanced design (SED) is estimated separately from non-SED
removed criteria. In the 2015 Edition Final Rule, we estimated that
developers would spend 300 to 400 hours implementing the SED criterion
at a cost of $63 per hour and that 266 developers would certify to SED.
This resulted in a final cost estimate ranging from $5,027,400 to
$6,703,200 in 2014 dollars. Since the finalization of that policy, we
have received substantial input from developers of certified health IT
that the cost estimates specified in that rule were an under-estimate
of the initial and recurring costs associated with the SED
certification criterion. In contrast to those estimates, we understand
that individual developers of certified health IT incur recurring costs
greater than $200,000 to recruit participants and conduct testing
specified by the SED certification criterion. In response to input from
the impacted community, we have revised our estimates of the costs of
SED and potential cost savings that can be realized from the proposed
removal of the SED certification criterion in this proposed rule.
The SED certification criterion is required for all developers
seeking certification to Sec. 170.315(a)(1) through (5), (9) (until
the certification criterion's expiration date), (a)(14), (b)(2), (b)(3)
or (b)(11). Developers must recruit at least ten participants, conduct
testing, and submit metrics for each of the criterion for which they
seek certification that is referenced within Sec. 170.315(g)(3). Thus,
we believe cost savings from the removal of SED are incremental per the
number of dependent criteria certified because there are additional
costs per product associated with SED testing and data reporting. Based
on stakeholder input and because developers can certify multiple
products each with up to ten criteria that requires SED, we believe an
estimated annual cost of between $8,000 and $12,000 per product per
certification criterion that requires SED testing is appropriate. This
estimate represents the effort to design tests, recruit participants,
conduct testing, document that testing, and report results to the ONC-
ACB in the required format.
To estimate the total costs of SED, we estimated the number of
products that will be certified to SED and the number of SED criteria
each product will certify. We report those costs in Table R-2. The
count of products that are certified to SED and number of SED criteria
each product certifies in the table are current as of May 1, 2025. The
counts were calculated using publicly available Certification Program
data available through the CHPL.\94\
---------------------------------------------------------------------------
\94\ https://chpl.healthit.gov.
[[Page 61020]]
Table R-2--Annual Cost Savings Estimates for Removal of Sec. 170.315(g)(3)
----------------------------------------------------------------------------------------------------------------
Lower bound Upper bound
Number of cost per cost per Total lower Total upper
Number of SED criteria certified products product product bound cost ($) bound cost ($)
(hours) (hours)
----------------------------------------------------------------------------------------------------------------
1............................... 17 8,000 12,000 136,000 204,000
2............................... 4 8,000 12,000 64,000 96,000
3............................... 7 8,000 12,000 168,000 252,000
4............................... 19 8,000 12,000 608,000 912,000
5............................... 21 8,000 12,000 840,000 1,260,000
6............................... 28 8,000 12,000 1,344,000 2,016,000
7............................... 33 8,000 12,000 1,848,000 2,772,000
8............................... 62 8,000 12,000 3,968,000 5,952,000
9............................... 182 8,000 12,000 13,104,000 19,656,000
-------------------------------------------------------------------------------
373 .............. .............. 22,080,000 33,120,000
----------------------------------------------------------------------------------------------------------------
Note: The lower and upper bound cost estimates use the hourly wage ($139.00) we describe above in ``Employee
Assumptions and Hourly Wage''.
In total, 373 products are certified to SED and at least one SED
certification criterion. Based on Table R-2, we estimate the total
undiscounted annual cost savings from removing the SED certification
criteria to be between $22,080,000 and $33,120,000. We welcome comments
on the proposed methodology and the accuracy and validity of the
estimates.
2. Revisions
2.1 Revision of Certification Criteria
We propose to revise seven certification criteria. For each revised
certification criterion, we have estimated the annual savings generated
by the proposed revisions.
2.1.1 Sec. 170.315(a)(5) Patient Demographics and Observations
We propose to codify certification guidance for the Certification
Program exercising our enforcement discretion--specifically, for the
``patient demographics and observations'' certification criterion in
Sec. 170.315(a)(5).\95\ We expect this proposed revision to reduce the
effort associated with meeting the requirements in Sec. 170.315(a)(5)
in the form of reduced maintenance costs. Using the approach described
for removed criteria, we estimate that the removal of these
requirements will reduce the annual effort of maintaining certification
by 5% of the projected development costs estimated in the HTI-1 Final
Rule. We note that 288 developers have certified 352 products to Sec.
170.315(a)(5) and that the initial developer hours estimated to
implement updates to the criterion in the HTI-1 Final Rule had a lower
bound of 720 hours and an upper bound of 1,860 hours. We therefore
estimate that the revision of this criterion will reduce effort by
between 36 and 93 hours per product and 12,672 to 32,736 hours across
all products. We estimate the total undiscounted annual cost savings
for reduced maintenance to range from $1,761,408 to $4,550,304.
---------------------------------------------------------------------------
\95\ https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion-notice.
---------------------------------------------------------------------------
2.1.2 Sec. 170.315(b)(1) Transitions of Care
We propose to revise the certification criterion in Sec.
170.315(b)(1) to reduce burden on developers of health IT by removing
the ``send and receive via edge protocol'' C-CDA requirement and
``create'' C-CDA requirement in the criterion and by simplifying the
remaining criterion requirements to focus solely on validating receipt
of C-CDA documents. We believe that these revisions remove a
substantial proportion of the ongoing effort required to maintain and
update the functional requirement of the certification criterion, but
we acknowledge that it does not remove requirements to support the C-
CDA standard or to update functionality to receive C-CDA documents. We
assume that this reduces the overall ongoing cost for this criterion by
60%. Following the methodology described for removed criterion, we
considered annual maintenance of Sec. 170.315(b)(1) to represent high
complexity equivalent to 15% of the initial development costs annually.
We note from an analysis of current Certification Program data that 256
developers have certified 300 products to Sec. 170.315(b)(1) and that
the initial developer hours estimated to implement the criterion had a
lower bound of 3,000 hours and an upper bound of 4,000 hours in the
2015 Edition Final Rule (80 FR 62602).\96\ We therefore estimate that
the revision of this criterion will reduce effort to maintain the
criterion annually by 9% annually or between 270 and 360 hours per
product and 81,000 to 108,000 hours across all products. We estimate
the total undiscounted annual cost savings to range from $11,259,000 to
$15,012,000.
---------------------------------------------------------------------------
\96\ https://www.federalregister.gov/d/2015-25597/p-1773.
---------------------------------------------------------------------------
2.1.3 Sec. 170.315(b)(11) Decision Support Interventions
We propose to remove all requirements related to source attributes,
their access, and modification and requirements to manage risks related
to the development of predictive DSIs.
In the HTI-1 Final Rule, we indicated that the costs to implement
Sec. 170.315(b)(11) ranged from 2,200 hours to 4,600 hours, that
updating source attribute information annually would cost an additional
0 to 1085 hours annually, depending on the number of DSIs the developer
supplied, and that engaging in risk management and updating information
would result in an additional 0 to 285 hours annually. Without this
revision, we estimate that annual maintenance costs for this criterion
would represent 12% of initial development costs. We believe these
changes reduce these costs by 80% and would eliminate annual costs to
update information for source attributes and risk management.
In total, we estimate that the revision will reduce maintenance
costs by 211 to 1,812 hours per product. We note that 232 products
developed by 183 developers were certified to Sec. 170.315(b)(11)
resulting in an annual reduction of 48,952 to 420,384 labor hours. We
estimate the total undiscounted annual cost savings to range from
$6,804,328 to $58,433,376.
[[Page 61021]]
2.1.4 Sec. 170.315(c)(3) Clinical Quality Measures (CQMs)--Report
We propose revisions to Sec. 170.315(c)(3) to remove expired
standards references. These proposed revisions are considered de
minimis and do not create net new cost savings.
2.1.5 Sec. 170.315(e)(1) View, Download and Transmit to a 3rd Party
We propose to revise Sec. 170.315(e)(1) to remove the standards
referenced in Sec. 170.315(e)(1)(i), Web Content Accessibility
Guidelines (WCAG) 2.0, and Sec. 170.315(e)(1)(ii), Network Time
Protocol (NTP) standard. We believe that the requirement to demonstrate
conformance to the WCAG standard creates substantial burden for
developers. We received feedback from developers that licensing a tool
for WCAG assessments costs thousands of dollars annually. We
acknowledge that the current referenced standards are old and do not
easily work with newer versions of both the standard itself as well as
testing tools to determine compliance. Thus, we expect these changes
will reduce unnecessary burden associated with maintaining current
conformance requirements as part of certification. In total, we
estimate that the annual maintenance burden associated with the WCAG
standard represented 2% of the initial development costs of the VDT
criterion. We note that 215 developers have certified 255 products to
Sec. 170.315(e)(1) and that the initial developer hours estimated to
implement the criterion had a lower bound of 1,300 hours and an upper
bound of 2,000 hours in the 2015 Edition Final Rule which included the
updated WCAG requirement. We therefore estimate that the revision of
this criterion will reduce effort to maintain the criterion annually by
2% annually or between 26 and 40 hours per product and 6,630 to 10,200
hours across all products. We estimate the total undiscounted annual
cost savings to range from $921,570 to $1,417,800.
2.1.6 Sec. 170.315(f)(5) Transmission to Public Health Agencies--
Electronic Case Reporting
We propose to codify certification guidance for the Certification
Program exercising our enforcement discretion for--specifically, the
``Transmission to public health agencies--electronic case reporting''
certification criterion in Sec. 170.315(f)(5).\97\ We expect this
proposed revision to reduce the burden associated with meeting the
requirements in the eCR certification criterion in the form of reduced
maintenance costs. Following the methodology described for removed
criterion, we considered annual maintenance of Sec. 170.315(f)(5), as
finalized in the HTI-1 Final Rule and becoming effective on December
31, 2025, to represent high complexity equivalent to 27% of the initial
development costs annually. We estimate that removal of standards-based
requirements will reduce annual maintenance costs to 10% of initial
development costs, a 63% reduction in effort.
---------------------------------------------------------------------------
\97\ http://healthit.gov/topic/electronic-case-reporting-certification-criterion-enforcement-discretion-notice.
---------------------------------------------------------------------------
Currently, 94 developers and 127 products are certified to Sec.
170.315(f)(5). Eighty-six developers and 112 products are certified to
the ``functional'' requirements in Sec. 170.315(f)(5)(i) alone, while
10 developers and 15 products are certified to the standards-based
requirements in Sec. 170.315(f)(5)(ii). The initial developer hours
estimated to implement the criterion had a lower bound of 0 hours and
an upper bound of 2,160 in the HTI-1 Final Rule. We therefore estimate
that the revision of this criterion will reduce annual effort to
maintain the criterion by between 0 and 367 labor hours per product and
0 to 46,609 labor hours across all 127 products. We estimate the total
undiscounted annual cost savings for reduced maintenance to range from
$0 to $6,478,651.
2.1.7 Sec. 170.315(f)(6) Transmission to Public Health Agencies--
Antimicrobial Use and Resistance Reporting
We propose to remove the standards-based requirements in Sec.
170.315(f)(6) that were adopted in the 2015 Edition Final Rule and
revise this criterion to be a functional requirement. We received
stakeholder feedback that the CDA-based standards cited in this
criterion are not required for users to submit antimicrobial use and
resistance (AUR) data to the CDC's National Healthcare Safety Network
(NHSN), creating a disconnect between the criterion and what is used in
practice. We expect the removal of standards-based requirements to
better align with the NHSN's goals for reporting and reduce the burden
on developers to meet this requirement. Following the methodology
described for removed criteria, we considered annual maintenance of
Sec. 170.315(f)(6) to represent medium complexity equivalent to 20% of
the initial development costs annually. We estimate that removal of
standards-based requirements will reduce annual maintenance costs to 6%
of initial development costs, resulting in a 70% reduction in effort.
Currently, 28 developers and 47 products are certified to Sec.
170.315(f)(6). The initial developer hours estimated to implement the
criterion had a lower bound of 1,000 hours and an upper bound of 1,400
hours in the 2015 Edition. We therefore estimate that the revision of
this criterion will reduce effort to maintain the criterion annually by
14% or between 140 to 196 hours per product and 6,580 to 9,212 hours
across all products. We estimate the total undiscounted annual cost
savings to range from $914,620 to $1,280,468.
In Table R-3, we estimate the total annual hours saved from the
proposed criteria revisions to range from 155,834 to 627,141 among 328
developers of certified health IT and 418 certified products. Using the
labor rate of $139, described above, we estimate the total undiscounted
annual cost savings to range from $21,660,9326 to $87,172,599. We
welcome comments on the proposed methodology and the accuracy and
validity of the estimates.
[[Page 61022]]
Table R-3--Panel A--Estimates of Labor Hours Saved for the Revisions of Certification Criteria
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total hours Annual hours Percent effort Hours saved
--------------------------------------------------------------------------------------------------------------------------------- Developers Products -------------------------------
Criterion citation LB UB LB UB Saved certified certified LB UB
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sec. 170.315(a)(5)............................ 720 1,860 36 93 100% 288 352 12,672 32,736
Sec. 170.315(b)(1)............................ 3,000 4,000 450 600 60% 256 300 81,000 108,000
Sec. 170.315(b)(11) Task 1. Annual Maintenance 2,200 4,600 264 552 80% 183 232 48,952 102,544
Sec. 170.315(b)(11) Task 2. Information 0 1,370 0 1,370 100% 183 232 0 317,840
Updates........................................
Sec. 170.315(e)(1)............................ 1300 2000 8 24 20% 215 255 6,630 10,200
Sec. 170.315(f)(5)............................ 0 2,160 0 216 63% 94 127 0 46,609
Sec. 170.315(f)(6)............................ 1,000 1,400 60 84 70% 28 47 6,580 9,212
All criteria.................................... .............. .............. .............. .............. .............. 328 418 155,834 627,141
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[[Page 61023]]
Table R-3--Panel B--Annual Cost Savings Estimates for Revisions of
Certification Criteria
------------------------------------------------------------------------
Annual cost savings
------------------------------------------------------------------------
Criterion citation LB UB
------------------------------------------------------------------------
Sec. 170.315(a)(5).................... $1,761,408 $4,550,304
Sec. 170.315(b)(1).................... 11,259,000 15,012,000
Sec. 170.315(b)(11)................... 6,804,328 58,433,376
Sec. 170.315(e)(1).................... 921,570 1,417,800
Sec. 170.315(f)(5).................... 0 6,478,651
Sec. 170.315(f)(6).................... 914,620 1,280,468
-------------------------------
Total Annual Cost Savings........... 21,660,926 87,172,599
------------------------------------------------------------------------
Note: The lower and upper bound cost estimates use the hourly wage
($139.00) we describe above in ``Employee Assumptions and Hourly
Wage''.
2.2 Revisions to Standards and Implementation Specifications for Health
Information Technology
2.2.1 Revisions to the United States Core Data for Interoperability
(USCDI) v3
We propose to codify certification guidance for the Certification
Program exercising our enforcement discretion--specifically, for the
United States Core Data for Interoperability (USCDI) v3 standard.\98\
The action removed or revised data elements from USCDI v3, as finalized
in the HTI-1 Final Rule (89 FR 1192).
---------------------------------------------------------------------------
\98\ https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion-notice.
---------------------------------------------------------------------------
As finalized in the HTI-1 Final Rule, developers of certified
health IT were required to update and certify their Health IT Modules
to adopt USCDI v3 by January 1, 2026. This proposal reduces the effort
for developers of certified health IT to adopt the USCDI v3 via the
removal or revision of two data elements: sexual orientation and gender
identity. We do not estimate reduced effort from ongoing maintenance of
these requirements, as the effort is considered part of activities that
occurred prior to the effective date of any final rule. We request
comments on this approach.
2.3 Revisions to the ONC Health IT Certification Program Administration
Unless noted differently, proposed revisions to Certification
Program administration conform to revisions proposed elsewhere related
to Certification Program requirements. We do not assess net new cost
savings or costs to program administration for these conforming
revisions. We welcome comments on whether these conforming revisions
create net new cost savings or costs.
2.3.1 Principles of Proper Conduct for ONC-ACBs
Under the principles of proper conduct for ONC-ACBs, we propose to
revise the ``certified product listing'' principle in Sec.
170.523(f)(1)(viii) to remove requirements on ONC-ACBs to include the
test data version used and whether any test data was altered for the
certification criterion or criteria to which the Health IT Module has
been certified. This proposed revision is meant to reduce the overall
effort for ONC-ACBs for this principle, as our analysis shows that
these data elements for the ``certified product listing'' are low
value. We determined that the cost savings to ONC-ACBs are de minimis,
and welcome comments on this analysis. In addition, we propose
conforming revisions to the principles of proper conduct for ONC-ACBs.
These conforming revisions do not create net new cost savings to
developers of certified health IT, ASTP/ONC, or ONC-ACBs. These conform
to revisions made elsewhere to Certification Program requirements, and
cost savings, if applicable, are assessed elsewhere in this impact
analysis.
2.3.2 Principles of Proper Conduct for ONC-ATLs
We propose conforming revisions to the principles of proper conduct
for ONC-ATLs. These conforming revisions do not create net new cost
savings to developers of certified health IT, ASTP/ONC, or ONC-ATLs.
These conform to revisions made elsewhere to Certification Program
requirements, and cost savings, if applicable, are assessed elsewhere
in this impact analysis.
2.3.3 Health IT Module Certification
We propose conforming revisions to Health IT Module certification.
These conforming revisions do not create net new cost savings to
developers of certified health IT, ASTP/ONC, or ONC-ACBs. These conform
to revisions made elsewhere to Certification Program requirements, and
cost savings, if applicable, are assessed elsewhere in this impact
analysis.
2.3.4 Certification to Newer Versions of Certain Standards
We propose conforming revisions to certification to newer versions
of certain standards. These conforming revisions do not create net new
cost savings to developers of certified health IT, ASTP/ONC, or ONC-
ACBs. These conform to revisions made elsewhere to Certification
Program requirements, and cost savings, if applicable, are assessed
elsewhere in this impact analysis.
2.3.5 Effect of Revocation on the Certifications Issued to Health IT
Module(s)
We propose conforming revisions that do not create net new cost
savings.
2.4 Revisions to Conditions and Maintenance of Certification
Requirements for Health IT Developers (Subpart D)
2.4.1 Assurances Condition of Certification
We propose updates to the Code of Federal Regulations (CFR) that do
not create net new cost savings.
2.4.2 Application Programming Interfaces Condition of Certification
We propose updates to the CFR that do not create net new cost
savings.
2.4.3 Real World Testing Condition of Certification
We propose revisions to the Real World Testing Condition of
Certification that de-scope reporting requirements and codify
certification guidance for the Certification Program exercising our
enforcement discretion for the Condition of Certification.\99\ As
finalized in the Cures Act Final Rule (85 FR 25642), real world testing
would be
[[Page 61024]]
applicable for specific criteria--at the time of finalization, 23
criteria in all. This deregulatory action revises the Real World
Testing Condition of Certification to apply reporting to only the API
criteria adopted by the Certification Program. This revision creates
cost savings to developers of certified health IT, as developers would
no longer be required to plan, collect, and report on real world
testing results for the full originally finalized set of criteria. We
explain below the rationale and methodology that informed the cost
savings for these proposed revisions to real world testing.
---------------------------------------------------------------------------
\99\ https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement.
---------------------------------------------------------------------------
The proposed revisions to real world testing would take effect
beginning in 2027. Cost savings to developers for ongoing compliance
are, therefore, estimated beginning in 2027. Any costs for 2024 and
2025 are considered sunk. Beginning in the 2026 reporting year, as
permitted in the real world testing enforcement discretion, only
developers of certified APIs would be required to report for real world
testing, specifically developers who certify to the standardized API
for patient and population services certification criterion, Sec.
170.315(g)(10).\100\ Cost savings calculations beginning in 2027
reflect the decreased burden on developers of certified health IT to
comply with the condition of certification minus requirements that
remain in place for developers who certify to the applicable API-based
criteria.
---------------------------------------------------------------------------
\100\ https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement.
---------------------------------------------------------------------------
As of the end of 2024, using publicly available Certification
Program data, we calculated that 336 developers had submitted real
world testing plans for 2025 collection and 2026 reporting.\101\ That
is 93 fewer developers required to report for real world testing than
estimated in the Cures Act Final Rule--a decrease of about 19
developers per year.\102\ Calculating developer exits during this time
period, after the Cures Act Final Rule took effect and prior to this
proposed rule's effective date, is important to assess the estimated
number of developers expected to comply with the remaining real world
testing requirements, as proposed.
---------------------------------------------------------------------------
\101\ https://chpl.healthit.gov/.
\102\ https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification.
---------------------------------------------------------------------------
Beginning in 2026, we calculated an expected count of developers
who we estimated would be required to report for real world testing in
2026 and beyond. This count assumes attrition from the original count
of developers required to report for real world testing as finalized in
the Cures Act Final Rule, as we described above for years prior to
2026. But given the changed program dynamics, in that real world
testing would be required only for developers of certified APIs, the
attrition rate beyond 2026 is harder to estimate. Given that current
requirements are applicable for over 20 criteria adopted in the
Certification Program and our attrition rate is based on participant
exits from the Certification Program (for developers who certify for
any of these criteria), we assume that attrition rate is likely more
profound than exits for developers of certified APIs alone. We
therefore estimate a new rate of developers who would be required to
report for real world testing in total (n=320), beginning in 2026.
In our RIA for the HTI-4 Final Rule (included in the FY2026 IPPS/
LTHC PPS Final Rule (90 FR 36536) as an ancillary provision), we
estimated that beginning in 2027, approximately 189 developers would
certify an electronic prior authorization API. The 189 count is a proxy
measure, representing our estimation of the number of developers that
would certify the Sec. 170.315(g)(10) certification criterion in 2027.
Given that the revised Real World Testing Condition of
Certification would only be associated with developers of certified
APIs, we estimate beginning in 2026 that approximately 189 developers
would be subject to the revised real world testing requirements. We
used this count (189) to determine the net number of developers who
would have been required to report for real world testing under the
original requirements (inclusive of those who would have reported Sec.
170.315(g)(10) testing results under the original requirements.)
At the end of 2024, of the 336 developers required to report for
real world testing, 198 developers certified to the Sec.
170.315(g)(10) certification criterion or 59% of all developers. Using
this rate, we estimate that beginning in 2026, approximately 320
developers would be subject to real world testing requirements, as
finalized by the Cures Act Final Rule.\103\ In 2026, however, only 189
developers would be subject to revised real world testing
requirements--our estimate of the number of developers who would be
subject to revised real world testing requirements (API only.) This
considers some attrition but at a different rate than used for years
prior to 2026, as explained above.
---------------------------------------------------------------------------
\103\ Formula: 189/(1-0.41) = 320.
---------------------------------------------------------------------------
Total savings beginning in 2027 are considered consistent and do
not decrease due to future unknown attrition; however, we consider
these cost savings to be realized by developers when the revised
requirements take effect. If they were to exit the program in a year
beyond 2027, these are still cost savings to be realized today from
requirements they do not need to meet in all future years.
Beginning in 2027, cost savings are calculated by totaling the cost
to all developers who certify real world testing applicable criteria to
meet current real world testing requirements as finalized in the Cures
Act Final Rule and revised in subsequent rulemakings (the HTI-1 Final
Rule and the HTI-4 Final Rule) and subtracting the remaining cost for
developers of certified APIs to comply with revised real world testing
requirements. We estimate that, per developer, the cost of collecting
and reporting real world testing data on Sec. 170.315(g)(10) would be
on average $4,400 annually. We estimate this by calculating the average
cost per criterion to meet real world testing requirements as finalized
by the Cures Act Final Rule ($109,557/23 = $4,763) and decrease that by
the proposed eliminated effort to submit annual testing plans
(estimated to be 8% of total annual testing effort.) \104\ This is
congruent with our methodology finalized in the HTI-4 Final Rule about
the average per criterion cost to plan, collect, and report for real
world testing.\105\ The total cost of the remaining requirement to test
for Sec. 170.315(g)(10) would be subtracted from the total original
program cost, as finalized by the Cures Act Final Rule, to estimate
this deregulatory action's annual cost savings.
---------------------------------------------------------------------------
\104\ Formula: $4,763 x (1-0.08) = $4,382.
\105\ https://www.federalregister.gov/d/2025-14681/p-7025.
---------------------------------------------------------------------------
Beginning in 2027, we also assume that developers of certified APIs
would need to meet requirements for Sec. 170.315(g)(10), as well as
for Sec. 170.315(g)(31), (g)(32), and (g)(33), as finalized in the
HTI-4 Final Rule.\106\ Real world testing requirements for the
certification criteria adopted in Sec. 170.315(g)(31), (g)(32), and
(g)(33) were finalized in the HTI-4 Final Rule and would be a net new
cost minus revisions to real world testing for developers not to submit
annual testing plans. Furthermore, we also updated real world testing
requirements in the HTI-4 Final Rule to include the new
[[Page 61025]]
Sec. 170.315(b)(4) certification criterion, which created net new
costs to developers for real world testing. This deregulatory action
now removes the Sec. 170.315(b)(4) real world testing requirement and
so we also assess the cost savings from that revision beginning in 2027
as well.
---------------------------------------------------------------------------
\106\ https://www.federalregister.gov/documents/2025/08/04/2025-14681/medicare-program-hospital-inpatient-prospective-payment-systems-for-acute-care-hospitals-ipps-and.
---------------------------------------------------------------------------
We estimate cost savings for reduced upfront effort in 2027 to be
(original real world testing costs + Sec. 170.315(b)(4) planning
costs) minus (Sec. 170.315(g)(10) revised costs), which equal $35.1
million in undiscounted cost savings for 2026. For costs savings,
beginning in 2027 and in perpetuity, we estimate that together,
(original real world testing costs + Sec. 170.315(b)(4) costs) minus
((g)(10)+(g)(31)+(g)(32)+(g)(33) revised costs) equal the estimated
annual undiscounted cost savings of $33.6 million.
2.4.4 Attestations
We propose updates to the CFR that do not create net new cost
savings.
2.4.5 Insights Condition of Certification
In the HTI-1 Final Rule (89 FR 1192), we finalized requirements for
developers to report on the Insights Condition of Certification, a set
of uniform measures collected and reported by developers of certified
health IT about the performance of their certified technology.\107\
Applicable developers would be required to begin data collection
January 1, 2026, for ``Year 1'' measures, with results reported in July
2027 and with ``Year 2'' measures set to begin collection January 1,
2027. Effort to plan and develop capabilities for these finalized
measures was estimated to begin after the effective date of the HTI-1
Final Rule in January 2024. Effort to plan and develop the measurement
capabilities for measures required to be collected in 2026 (``Year 1'')
would be completed by January 1, 2026, and effort to plan and develop
the measurement capabilities for measures required to be collected for
the first time in 2027 (``Year 2'') would be completed by January 1,
2027, etc. We estimated developers would face annual data collection
and reporting costs beginning in 2026 and in perpetuity. As we
finalized in the HTI-1 Final Rule, the large majority of costs to
developers of certified health IT would be costs to plan and develop
for initial data collection of the finalized measures (effort largely
expended from 2024-2026 in our original analysis).
---------------------------------------------------------------------------
\107\ https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and.
---------------------------------------------------------------------------
ASTP/ONC issued enforcement discretion in April 2025 that
effectively de-scoped Insights requirements on developers to a single
measure--``Use of FHIR''--a ``Year 1'' measure.\108\ The enforcement
discretion effectively paused development and planning efforts to
collect all Insights measures but one (``Use of FHIR''), reducing sunk
costs and creating cost savings to developers by reducing the upfront
effort to plan and report for Insights. We propose to codify
certification guidance for the Certification Program exercising our
enforcement discretion for the Insights Condition of Certification. We
explain below the rationale and methodology that informed the cost
savings for these proposed revisions to Insights.
---------------------------------------------------------------------------
\108\ https://www.healthit.gov/topic/insights-condition-and-maintenance-certification-enforcement-discretion.
---------------------------------------------------------------------------
To calculate cost savings associated with the proposed revisions to
the Insights Condition of Certification, we subtracted the estimated
amount for developers to report for the remaining Insights measure
(``Use of FHIR'') from the estimated cost for developers to meet the
Insights Condition of Certification, as finalized in the HTI-1 Final
Rule. In Table 35 of the HTI-1 Final Rule, we estimated that the upper
bound cost for all developers to report on the ``Use of FHIR'' measure
over a ten-year period was $36.3 million.\109\ The total upper bound
cost to report on all measures for all developers over a ten-year
period was $218.7 million. Therefore, we estimate the ``Use of FHIR''
measure to be 17% of all estimated Insights costs.
---------------------------------------------------------------------------
\109\ https://www.federalregister.gov/d/2023-28857/p-2641.
---------------------------------------------------------------------------
In Table R-4 we show the undiscounted revised costs for the
Insights Condition of Certification. We estimated, on average, that the
HTI-1 Final Rule costs for Insights would be $137.9 million. We
estimated that the cost for developers to begin implementing Insights
in 2024 (toward effort to collect and report on measures in 2026 and
2027) would on average, total $46.4 million. This included initial
planning and development costs for all measures with more assumed
effort toward completing work to prepare for ``Year 1'' measures set to
begin collection January 1, 2026. We consider these costs as sunk. The
Insights enforcement discretion, however, reduced effort for ongoing
planning and development work for 2025 and after. We consider this
reduced effort in 2025 and 2026 and reduced effort to meet this
requirements in years 2027 and after to be a net cost savings to
developers, as Table R-4 shows.
Cost savings in 2027 and thereafter are considered tied to the
reduced effort associated with ongoing planning and reporting for the
proposed revised requirements. The total undiscounted cost savings for
this reduced ongoing effort, beginning in 2027, are $12.7 million
(Table R-4).
Table R-4--Revised Insights Undiscounted Cost Savings
----------------------------------------------------------------------------------------------------------------
Year Upfront effort Ongoing effort Total
----------------------------------------------------------------------------------------------------------------
2024............................................................ $0 $0 $0
2025............................................................ 38,513,661 0 38,513,661
2026............................................................ 24,814,672 0 24,814,672
2027............................................................ 0 8,601,676 8,601,676
2028............................................................ 0 680,593 680,593
-----------------------------------------------
Total--Undiscounted......................................... 63,328,333 12,685,234 76,013,568
----------------------------------------------------------------------------------------------------------------
b. Accounting Statement and Table
This proposed rule, if finalized as proposed, is expected to be an
E.O. 14192 deregulatory action. The proposals remove or reduce
requirements on developers of certified health IT. No proposals create
net new requirements or additional burden to comply with existing
requirements. However, we do estimate some costs for reviewers who
review this proposed rule. We estimate those costs to be
[[Page 61026]]
$284,132 in total for an estimated 644 reviewers, which include
developers and medical associations. As articulated in the preamble,
these proposed deregulatory actions reduce the effort of developers of
certified health IT to meet ongoing program requirements and reduce
barriers to entry for new program participants, generating benefits to
developers of certified health IT in the form of time back to them to
innovate their technology and focus on the needs of their clients and
end users. We do not, however, quantify these benefits, and instead
rely on our calculation of cost savings to developers of certified
health IT to quantify in dollars the time and effort developers would
have expended had these requirements remained in effect in perpetuity.
We estimate that these proposals do generate significant cost savings
for developers of certified health IT.
To calculate the cost savings associated with this proposed
rulemaking, we replicate the analysis of prior finalized rulemakings
and align those with current data, adopting, where necessary, novel
methodologies and models to assess the current costs to developers of
certified health IT of the proposed revisions to the Certification
Program. As shown in Table R-5, we present the undiscounted cost
savings over ten years and in Table R-6 we present the discounted cost
savings associated with these proposals. In Table R-6, we adopt a 3%
and 7% discount rate consistent with Circular A-4 (2003).\110\ Cost
savings for this proposed rulemaking include savings from reduced
ongoing effort to comply with finalized requirements, as shown in
Tables R-5 and R-6. In total, this proposed rulemaking would result in
a present value of cost savings of $1.53 billion in 2024 dollars and
discounted at a rate of 7%, beginning in 2027 and in perpetuity,
consistent with analytic guidance on E.O. 14192, as shown in Table R-
7.\111\
---------------------------------------------------------------------------
\110\ https://trumpwhitehouse.archives.gov/sites/whitehouse.gov/files/omb/circulars/A4/a-4.pdf.
\111\ https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-20-Guidance-Implementing-Section-3-of-Executive-Order-14192-Titled-Unleashing-Prosperity-Through-Deregulation.pdf.
Table R-5--E.O. 12866 Summary Table Non-Discounted Flows
[2024 Dollars]
--------------------------------------------------------------------------------------------------------------------------------------------------------
Year 1 Year 2 Year 3 Year 4 Year 5
--------------------------------------------------------------------------------------------------------------------------------------------------------
Costs.................................................... $284,132 ................. ................. ................. .................
Cost Savings............................................. 174,843,873.10 $166,922,790.67 $166,922,790.67 $166,922,790.67 $166,922,790.67
--------------------------------------------------------------------------------------------------------------------------------------------------------
Year 6 Year 7 Year 8 Year 9 Year 10
--------------------------------------------------------------------------------------------------------------------------------------------------------
Costs.................................................... ................. ................. ................. ................. .................
Cost Savings............................................. 166,922,790.67 166,922,790.67 166,922,790.67 166,922,790.67 166,922,790.67
--------------------------------------------------------------------------------------------------------------------------------------------------------
Table R-6--E.O. 12866 Summary Table
[2024 Dollars]
------------------------------------------------------------------------
Primary (3%) Primary (7%)
------------------------------------------------------------------------
Present Value of Quantified Costs. $275,856.31 $265,543.93
Present Value of Quantified Cost 2,491,079,993.12 1,775,785,303.03
Savings..........................
Present Value of Net Cost Savings. 2,490,804,136.81 1,775,519,759.11
Annualized Quantified Costs....... 18,541.88 25,065.47
Annualized Quantified Cost Savings 167,439,704.42 167,621,570.24
Annualized Net Quantified Cost 167,421,162.54 167,596,504.78
Savings..........................
------------------------------------------------------------------------
Table R-7--E.O. 14192 Summary Table
[2024 Dollars]
------------------------------------------------------------------------
Primary (7%)
------------------------------------------------------------------------
Present Value of Quantified Costs.................... $265,543.93
Present Value of Quantified Cost Savings............. 1,525,278,264.39
Present Value of Net Cost Savings.................... 1,525,012,720.46
Annualized Quantified Costs.......................... 25,065.47
Annualized Quantified Cost Savings................... 143,975,477.95
Annualized Net Quantified Cost Savings............... 143,950,412.48
------------------------------------------------------------------------
C. Regulatory Flexibility Act
The Regulatory Flexibility Act (RFA) requires agencies to analyze
options for regulatory relief of small businesses if a rule has a
significant impact on a substantial number of small entities. The Small
Business Administration (SBA) establishes the size of small businesses
for Federal Government programs based on average annual receipts or the
average employment of a firm.\112\
---------------------------------------------------------------------------
\112\ The SBA references that annual receipts mean ``total
income'' (or in the case of a sole proprietorship, ``gross income'')
plus ``cost of goods sold'' as these terms are defined and reported
on Internal Revenue Service tax return forms.
---------------------------------------------------------------------------
The entities that are likely to be directly affected by the
requirements in this proposed rule are health IT developers. We note
that the reasonable and necessary activities identified by the
Secretary as not constituting information blocking are themselves
exceptions to compliance with the information blocking definition and
[[Page 61027]]
provide relief for those entities subject to the information blocking
regulations. We refer readers to section IV for our information
blocking-related proposals and welcome comments on their impacts on
small entities.
While health IT developers that pursue certification of their
health IT under the Certification Program represent a small segment of
the overall information technology industry, we believe that many
health IT developers impacted by the requirements proposed in this
proposed rule most likely fall under the North American Industry
Classification System (NAICS) code 541511 ``Custom Computer Programming
Services.''
OMB advised that the Federal statistical establishment data
published for reference years beginning on or after January 1, 2022,
should be published using the 2022 NAICS United States codes.\113\ The
SBA size standard associated with this NAICS code is set at $34 million
annual receipts or less. There is enough data generally available to
establish that between 75% and 90% of entities that are categorized
under the NAICS code 541511 are under the SBA size standard. We also
note that with the exception of aggregate business information
available through the U.S. Census Bureau and the SBA related to NAICS
code 541511, it appears that many health IT developers that pursue
certification of their health IT under the Certification Program are
privately held or owned and do not regularly, if at all, make their
specific annual receipts publicly available. As a result, it is
difficult to locate empirical data related to many of these health IT
developers to correlate to the SBA size standard. However, although not
perfectly correlated to the size standard for NAICS code 541511, we do
have information indicating that over 60% of health IT developers that
have had Complete EHRs and/or Health IT Modules certified to the 2011
Edition have less than 51 employees.
---------------------------------------------------------------------------
\113\ https://www.sba.gov/article/2022/feb/01/guidance-using-naics-2022-procurement.
---------------------------------------------------------------------------
With the exception of rule review costs, this proposed rulemaking
is deregulatory and does not create new requirements on developers of
certified health IT, including small businesses. We believe the
proposed deregulatory actions will create net cost savings for
developers and would not create a significant economic impact on a
substantial number of small entities. Additionally, the Secretary
proposes to certify that this proposed rule would not have a
significant economic impact on a substantial number of small entities.
However, we request comments on whether: there are (and how many) small
entities that currently pursue certification of health IT under the
Certification Program; what products they certify; whether there are
any negative or unintended costs for small entities from the proposals
included in this proposed rule; and whether small entities will
significantly benefit from the proposals include in this proposed rule.
D. Executive Order 13132--Federalism
E.O. 13132 establishes certain requirements that an agency must
meet when it promulgates a proposed rule (and subsequent final rule)
that imposes substantial direct requirement costs on State and local
governments, preempts State law, or otherwise has federalism
implications. Nothing in this proposed rule imposes substantial direct
compliance costs on State and local governments, preempts State law, or
otherwise has federalism implications. We are not aware of any State
laws or regulations that are contradicted or impeded by any of the
proposals in this proposed rule. We welcome comments on this
assessment.
E. Unfunded Mandates Reform Act of 1995
Section 202 of the Unfunded Mandates Reform Act of 1995 requires
that agencies assess anticipated costs and benefits before issuing any
rule that imposes unfunded mandates on State, local, and Tribal
governments or the private sector requiring spending in any one year of
$100 million in 1995 dollars, updated annually for inflation. The
current inflation-adjusted statutory threshold is approximately $187
million in 2025. This proposed rule is deregulatory, and, therefore,
the estimated potential cost effects of this proposed rule do not reach
the statutory threshold. This proposed rule does not impose unfunded
mandates on State, local, and Tribal governments, or the private
sector. We welcome comments on these conclusions.
List of Subjects
45 CFR Part 170
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Healthcare, Health
information technology, Health insurance, Health records, Hospitals,
Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy,
Reporting and record keeping requirements, Public health, Security.
45 CFR Part 171
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Healthcare, Health
care provider, Health information exchange, Health information
technology, Health information network, Health insurance, Health
records, Hospitals, Privacy, Public health, Reporting and record
keeping requirements, Security.
For the reasons set forth in the preamble, HHS proposes to amend 45
CFR subtitle A, subchapter D, as follows:
PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY
0
1. The authority citation for part 170 continues to read as follows:
Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 552
0
2. Amend Sec. 170.102 by:
0
a. In the definition of ``Base EHR'':
0
i. Revising paragraph (3)(i); and
0
ii. Removing and reserving paragraphs (3)(ii) and (iii); and
0
b. Removing definitions for ``Common Clinical Data Set,'' ``Global
Unique Device Identification Database (GUDID),'' and ``Production
Identifier.''
The revision reads as follows:
Sec. 170.102 Definitions.
* * * * *
Base EHR * * *
(3) * * *
(i) Section 170.315(a)(1), (2), or (3), (a)(5), (b)(1) and (11),
(c)(1), and (g)(10).
* * * * *
0
3. Revising and republishing Sec. 170.202 to read as follows:
Sec. 170.202 Transport standards and other protocols.
The Secretary adopts the following transport standard: ONC
Applicability Statement for Secure Health Transport, Version 1.2
(incorporated by reference in Sec. 170.299).
Sec. 170.204 [Removed and Reserved]
0
4. Removing and reserving Sec. 170.204.
0
5. Amend Sec. 170.205 by:
0
a. Removing and reserving paragraphs (a)(3) and (5);
0
b. Revising paragraphs (d)(2) and (i)(2);
0
c. Removing and reserving paragraphs (k)(1) and (2) and (r)(1); and
0
d. Revising paragraphs (s)(1) and (t)(1) through (4).
The revisions read as follows:
[[Page 61028]]
Sec. 170. 205 Content exchange standards and implementation
specifications for exchanging electronic health information.
* * * * *
(d) * * *
(2) Standard. HL7 Messaging Standard Version 2.5.1 (incorporated by
reference in Sec. 170.299).
* * * * *
(i) * * *
(2) Standard. HL7 Clinical Document Architecture (CDA), Release
2.0, Normative Edition (incorporated by reference in Sec. 170.299).
Implementation specifications. HL7 CDA(copyright) Release 2
Implementation Guide: Reporting to Public Health Cancer Registries from
Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1, Volume
1--Introductory Material and HL7 CDA(copyright) Release 2
Implementation Guide: Reporting to Public Health Cancer Registries from
Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1 (US
Realm), Volume 2--Templates and Supporting Material (incorporated by
reference in Sec. 170.299). The adoption of this standard expires on
January 1, 2027.
* * * * *
(s) * * *
(1) Standard. HL7 Implementation Guide for CDA[supreg] Release 2:
National Health Care Surveys (NHCS), Release 1--US Realm, HL7 Draft
Standard for Trial Use, Volume 1--Introductory Material and HL7
Implementation Guide for CDA[supreg] Release 2: National Health Care
Surveys (NHCS), Release 1--US Realm, HL7 Draft Standard for Trial Use,
Volume 2--Templates and Supporting Material (incorporated by reference
in Sec. 170.299). The adoption of this standard expires on January 1,
2027.
* * * * *
(t) * * *
(1) Standard. HL7[supreg] FHIR[supreg] Implementation Guide:
Electronic Case Reporting (eCR)--US Realm 2.1.0--STU 2 US (HL7 FHIR eCR
IG) (incorporated by reference, see Sec. 170.299). The adoption of
this standard expires on January 1, 2027.
(2) Standard. HL7 CDA[supreg] R2 Implementation Guide: Public
Health Case Report--the Electronic Initial Case Report (eICR) Release
2, STU Release 3.1--US Realm (HL7 CDA eICR IG) (incorporated by
reference, see Sec. 170.299). The adoption of this standard expires on
January 1, 2027.
(3) Standard. HL7[supreg] CDA[supreg] R2 Implementation Guide:
Reportability Response, Release 1, STU Release 1.1--US Realm (HL7 CDA
RR IG) (incorporated by reference, see Sec. 170.299). The adoption of
this standard expires on January 1, 2027.
(4) Standard. Reportable Conditions Trigger Codes Value Set for
Electronic Case Reporting. (incorporated by reference, see Sec.
170.299). The adoption of this standard expires on January 1, 2027.
* * * * *
Sec. 170.207 [Amended]
0
6. Amend Sec. 170.207 by:
0
a. Removing paragraphs (a)(4) and (c)(3);
0
b. Removing and reserving paragraphs (d)(1)(ii) and (iii);
0
c. Removing paragraphs (e)(3) and (4);
0
d. Removing and reserving paragraphs (f)(2), (m)(1), (n)(1) and (3),
and (o); and
0
e. Removing paragraphs (r) and (s).
Sec. 170.210 [Removed and Reserved]
0
7. Removing and reserving Sec. 170.210.
0
8. Revising Sec. 170.213 to read as follows:
Sec. 170.213 United States Core Data for Interoperability.
The Secretary adopts the following versions of the United States
Core Data for Interoperability standard:
(a) Standard. United States Core Data for Interoperability Version
3.1 (USCDI v3.1) (incorporated by reference, see Sec. 170.299).
(b) [Reserved]
Sec. 170.215 [Amended]
0
9. Amend Sec. 170.215 by removing and reserving paragraphs (b)(1)(i)
and (c)(1).
0
10. Revising and republishing Sec. 170.299 to read as follows:
Sec. 170.299 Incorporation by reference.
(a) Certain material is incorporated by reference into this part
with the approval of the Director of the Federal Register under 5
U.S.C. 552(b) and 1 CFR part 51. All approved incorporation by
reference (IBR) material is available for inspection at the U.S.
Department of Health and Human Services (HHS) and at the National
Archives and Records Administration (NARA). Contact HHS at: U.S.
Department of Health and Human Services, Office of the National
Coordinator for Health Information Technology, 330 C Street SW,
Washington, DC 20201; call ahead to arrange for inspection at 202-690-
7151. For information on the availability of this material at NARA,
visit www.archives.gov/federal-register/cfr/ibr-locations or email
[email protected]. The material may be obtained from the sources
in the following paragraphs of this section.
(b) Centers for Disease Control and Prevention, 2500 Century
Parkway, Mailstop E-78, Atlanta, GA 30333; phone: (800) 232-4636);
website: www.cdc.gov/cdc-info/index.html.
(1)-(3) [ Reserved]
(4) HL7 2.5.1 Implementation Guide for Immunization Messaging
Release 1.0, May 1, 2010, IBR approved for Sec. 170.205.
(5) PHIN Messaging Guide for Syndromic Surveillance: Emergency
Department and Urgent Care Data, ADT Messages A01, A03, A04, and A08,
HL7 Version 2.5.1 (Version 2.3.1 Compatible), Release 1.1, August 2012,
IBR approved for Sec. 170.205.
(6) Conformance Clarification for EHR Certification of Electronic
Syndromic Surveillance, ADT MESSAGES A01, A03, A04, and A08, HL7
Version 2.5.1, Addendum to PHIN Messaging Guide for Syndromic
Surveillance: Emergency Department and Urgent Care Data (Release 1.1),
August 2012, IBR approved for Sec. 170.205.
(7)-(8) [Reserved]
(9) ELR 2.5.1 Clarification Document for EHR Technology
Certification, July 16, 2012, IBR approved for Sec. 170.205.
(10) PHIN Messaging Guide for Syndromic Surveillance: Emergency
Department, Urgent Care, Inpatient and Ambulatory Care Settings,
Release 2.0, April 21, 2015, IBR approved for Sec. 170.205(d).
(11) Erratum to the CDC PHIN 2.0 Implementation Guide, August 2015;
Erratum to the CDC PHIN 2.0 Messaging Guide, April 2015 Release for
Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient
and Ambulatory Care Settings, IBR approved for Sec. 170.205(d).
(12) HL7 2.5.1 Implementation Guide for Immunization Messaging,
Release 1.5, October 1, 2014, IBR approved for Sec. 170.205(e).
(13) HL7 Version 2.5.1 Implementation Guide for Immunization
Messaging (Release 1.5)--Addendum, July 2015, IBR approved for Sec.
170.205(e).
(14)-(16) [Reserved]
(17) HL7[supreg] Standard Code Set CVX--Vaccines Administered,
dated June 15, 2022; IBR approved for Sec. 170.207(e).
(18) National Drug Code Directory (NDC)--Vaccine NDC Linker, dated
July 19, 2022; IBR approved for Sec. 170.207(e).
(19) CDC Race and Ethnicity Code Set version 1.2 (July 08, 2021);
IBR approved for Sec. 170.207(f).
(c) Centers for Medicare & Medicaid Services, Office of Clinical
Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland
21244; phone: (410) 786-3000; website: www.cms.gov.
(1) CMS PQRI 2009 Registry XML Specifications, IBR approved for
Sec. 170.205.
(2) 2009 Physician Quality Reporting Initiative Measure
Specifications Manual for Claims and Registry, Version
[[Page 61029]]
3.0, December 8, 2008 IBR approved for Sec. 170.205.
(3) [Reserved]
(4) CMS Implementation Guide for Quality Reporting Document
Architecture: Category I; Hospital Quality Reporting Implementation
Guide for 2020; published December 3, 2019, IBR approved for Sec.
170.205(h).
(5) CMS Implementation Guide for Quality Reporting Document
Architecture: Category III; Eligible Clinicians and Eligible
Professionals Programs Implementation Guide for 2020; published April
30, 2020, IBR approved for Sec. 170.205(k).
(d) Council of State and Territorial Epidemiologists, 2635 Century
Parkway NE, Suite 700, Atlanta, GA 30345; phone: (770) 458-3811;
website: www.cste.org/.
(1) Reportable Conditions Trigger Codes Value Set for Electronic
Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March
29, 2022; IBR approved for Sec. 170.205(t).
(2) [Reserved]
(e) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann
Arbor, MI 48104; phone: (734) 677-7777; website: www.hl7.org/.
(1) [Reserved]
(2) Health Level Seven Messaging Standard Version 2.5.1 (HL7
2.5.1), An Application Protocol for Electronic Data Exchange in
Healthcare Environments, February 21, 2007, IBR approved for Sec.
170.205.
(3) [Reserved]
(4) HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory
Reporting to Public Health, Release 1 (US Realm) HL7 Version 2.5.1:
ORU-R01, HL7 Informative Document, February, 2010, IBR approved for
Sec. 170.205.
(5)-(8) [Reserved]
(9) HL7 Clinical Document Architecture, Release 2.0, Normative
Edition, May 2005, IBR approved for Sec. 170.205.
(10)-(11) [Reserved]
(12) HL7 Implementation Guide for CDA[supreg] Release 2: Quality
Reporting Document Architecture, DTSU Release 2 (Universal Realm),
Draft Standard for Trial Use, July 2012, IBR approved for Sec.
170.205.
(13) HL7 v2.5.1 IG: Electronic Laboratory Reporting to Public
Health (US Realm), Release 1 Errata and Clarifications, September, 29,
2011, IBR approved for Sec. 170.205.
(14)-(17) [Reserved]
(18) HL7 Implementation Guide for CDA[supreg] Release 2:
Consolidated CDA Templates for Clinical Notes (US Realm), Draft
Standard for Trial Use, Volume 1--Introductory Material, Release 2.1,
August 2015, IBR approved for Sec. 170.205(a).
(19) HL7 Implementation Guide for CDA[supreg] Release 2:
Consolidated CDA Templates for Clinical Notes (US Realm), Draft
Standard for Trial Use, Volume 2--Templates and Supporting Material,
Release 2.1, August 2015, IBR approved for Sec. 170.205(a).
(20) HL7 CDA[supreg] R2 Implementation Guide: Quality Reporting
Document Architecture--Category I (QRDA I); Release 1, DSTU Release 3
(US Realm), Volume 1--Introductory Material, June 2015, IBR approved
for Sec. 170.205(h).
(21) HL7 CDA[supreg] R2 Implementation Guide: Quality Reporting
Document Architecture--Category I (QRDA I); Release 1, DSTU Release 3
(US Realm), Volume 2--Templates and Supporting Material, June 2015, IBR
approved for Sec. 170.205(h).
(22)-(24) [Reserved]
(25) HL7 Version 3 Implementation Guide: Data Segmentation for
Privacy (DS4P), Release 1, Part 1: CDA R2 and Privacy Metadata Reusable
Content Profile, May 16, 2014, IBR approved for Sec. 170.205(o).
(26) [Reserved]
(27) HL7 Implementation Guide for CDA[supreg] Release 2: National
Health Care Surveys (NHCS), Release 1--US Realm, HL7 Draft Standard for
Trial Use, Volume 1--Introductory Material, December 2014, IBR approved
for Sec. 170.205(s).
(28) HL7 Implementation Guide for CDA[supreg] Release 2: National
Health Care Surveys (NHCS), Release 1--US Realm, HL7 Draft Standard for
Trial Use, Volume 2--Templates and Supporting Material, December 2014,
IBR approved for Sec. 170.205(s).
(29-30) [Reserved]
(31) HL7 FHIR[supreg] Bulk Data Access (Flat FHIR[supreg]) (v1.0.0:
STU 1), August 22, 2019, IBR approved for Sec. 170.215(a).
(32) HL7 FHIR SMART Application Launch Framework Implementation
Guide Release 1.0.0, November 13, 2018, IBR approved for Sec.
170.215(a).
(33) HL7 Fast Healthcare Interoperability Resources Specification
(FHIR[supreg]) Release 4, Version 4.0.1: R4, October 30, 2019,
including Technical Correction #1, November 1, 2019, IBR approved for
Sec. 170.215(a).
(34) HL7 FHIR[supreg] US Core Implementation Guide STU3 Release
3.1.1, August 28, 2020, IBR approved for Sec. 170.215(a).
(35) HL7 CDA[supreg] R2 Implementation Guide: C-CDA Templates for
Clinical Notes STU Companion Guide, Release 4.1 (US Realm) Standard for
Trial Use, Specification Version: 4.1.1, June 2023 (including
appendices A and B); IBR approved for Sec. 170.205(a).
(36) HL7 FHIR[supreg] Implementation Guide: Electronic Case
Reporting (eCR)--US Realm, Version 2.1.0--STU 2 US (HL7 FHIR eCR IG),
August 31, 2022; IBR approved for Sec. 170.205(t).
(37) HL7 CDA[supreg] R2 Implementation Guide: Public Health Case
Report--the Electronic Initial Case Report (eICR) Release 2, STU
Release 3.1--US Realm (HL7 CDA eICR IG), July 2022, volumes 1 and 2;
IBR approved for Sec. 170.205(t).
(38) HL7 CDA[supreg] R2 Implementation Guide: Reportability
Response, Release 1, STU Release 1.1--US Realm (HL7 CDA RR IG), July
2022, volumes 1 through 4; IBR approved for Sec. 170.205(t).
(39) HL7 FHIR US Core Implementation Guide Version 6.1.0--STU 6,
June 19, 2023; IBR approved for Sec. 170.215(b).
(40) HL7 FHIR[supreg] SMART App Launch [Implementation Guide],
2.0.0--Standard for Trial Use, November 26, 2021; IBR approved for
Sec. 170.215(c).
(41) HL7 FHIR[supreg] Da Vinci--Coverage Requirements Discovery
(CRD) Implementation Guide, Version 2.0.1--STU 2, January 8, 2024, IBR
approved for Sec. 170.215(j).
(42) HL7 FHIR[supreg] Da Vinci--Documentation Templates and Rules
(DTR) Implementation Guide, Version 2.0.1--STU 2, January 11, 2024, IBR
approved for Sec. 170.215(j).
(43) HL7 FHIR[supreg] Da Vinci Prior Authorization Support (PAS)
FHIR Implementation Guide, Version 2.0.1--STU 2, December 1, 2023, IBR
approved for Sec. 170.215(j).
(44) HL7 FHIR[supreg] CARIN Consumer Directed Payer Data Exchange
(CARIN IG for Blue Button[supreg]) Implementation Guide, Version
2.0.0--STU 2 US, November 28, 2022, IBR approved for Sec. 170.215(k).
(45) HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex)
Implementation Guide, Version 2.1.0--STU 2.1, June 18, 2025, IBR
approved for Sec. 170.215(k).
(46) HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) US Drug
Formulary Implementation Guide, Version 2.0.1--STU 2, December 1, 2023,
IBR approved for Sec. 170.215(m).
(47) HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) Plan Net
Implementation Guide, Version 1.1.0--STU 1.1 US, April 4, 2022, IBR
approved for Sec. 170.215(n).
(48) HL7 FHIR[supreg] Subscriptions R5 Backport Implementation
Guide, Version 1.1.0--Standard for Trial Use, draft as of January 11,
2023, IBR approved for Sec. 170.215(h).
(49) HL7 FHIR[supreg] CDS Hooks Implementation Guide, Version
2.0.1--ci-build, March 12, 2025, IBR approved for Sec. 170.215(f).
[[Page 61030]]
(f) Integrating the Healthcare Enterprise (IHE), 820 Jorie
Boulevard, Oak Brook, IL Telephone (630) 481-1004, http://www.ihe.net/.
(1) IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-
2b), Transactions Part B--Sections 3.29--2.43, Revision 7.0, August 10,
2010, IBR approved for Sec. 170.205(p).
(2) [Reserved]
(g) Internet Engineering Task Force (IETF) Secretariat, c/o
Association Management Solutions, LLC (AMS), 48377 Fremont Blvd., Suite
117, Fremont, CA 94538, Telephone (510) 492-4080, http://www.ietf.org/rfc.html.
(1)-(2) [Reserved]
(3) Request for Comment (RFC) 5646, ``Tags for Identifying
Languages, September 2009,'' copyright 2009, IBR approved for Sec.
170.207(g).
(h) International Telecommunication Union (ITU), Place des Nations,
1211 Geneva 20 Switzerland, Telephone (41) 22 730 511, http://www.itu.int/en/pages/default.aspx.
(1) ITU-T E.123, Series E: Overall Network Operation, Telephone
Service, Service Operation and Human Factors, International operation--
General provisions concerning users: Notation for national and
international telephone numbers, email addresses and web addresses,
February 2001, IBR approved for Sec. 170.207(q).
(2) ITU-T E.164, Series E: Overall Network Operation, Telephone
Service, Service Operation and Human Factors, International operation--
Numbering plan of the international telephone service, The
international public telecommunication numbering plan, November 2010,
IBR approved for Sec. 170.207(q).
(i) National Council for Prescription Drug Programs (NCPDP),
Incorporated, 9240 E Raintree Drive, Scottsdale, AZ 85260-7518; phone
(480) 477-1000; fax: (480) 767-1042: website: www.ncpdp.org.
(1) NCPDP SCRIPT Standard, Implementation Guide, Version 2017071,
ANSI-approved July 28, 2017; IBR approved for Sec. 170.205(b).
(2) NCPDP SCRIPT Standard, Implementation Guide, Version 2023011,
ANSI-approved January 17, 2023; IBR approved for Sec. 170.205(b).
(3) NCPDP Real-Time Prescription Benefit Standard, Implementation
Guide, Version 13, ANSI-approved May 19, 2022; IBR approved for Sec.
170.205(c).
(4) NCPDP Formulary and Benefit Standard, Implementation Guide,
Version 60, ANSI-approved April 12, 2023; IBR approved for Sec.
170.205(u).
(j) Office of the National Coordinator for Health Information
Technology (ONC), 330 C Street SW, Washington, DC 20201; phone: (202)
690-7151; website: https://healthit.gov.
(1) United States Core Data for Interoperability (USCDI), Version
3.1 (v3.1), June 2025, IBR approved for Sec. 170.213.
(2) [Reserved]
(k) Public Health Data Standards Consortium, 111 South Calvert
Street, Suite 2700, Baltimore, MD 21202; phone: (801) 532-2299;
website: www.nahdo.org/sopt.
(1) Public Health Data Standards Consortium Source of Payment
Typology Code Set Version 5.0 (October 2011), IBR approved for Sec.
170.207(s).
(2) Users Guide for Source of Payment Typology, Version 9.2,
December 2020; IBR approved for Sec. 170.207(s).
(l) Regenstrief Institute, Inc., LOINC[supreg] c/o Regenstrief
Center for Biomedical Informatics, Inc., 410 West 10th Street, Suite
2000, Indianapolis, IN 46202-3012; phone: (317) 274-9000; website:
https://loinc.org/ and https://ucum.org/ucum.
(1) Logical Observation Identifiers Names and Codes (LOINC[supreg])
Database Version 2.72, February 2022; IBR approved for Sec.
170.207(c).
(2) The Unified Code for Units of Measure, Version 2.1, November
21, 2017; IBR approved for Sec. 170.207(m).
(m) U.S. National Library of Medicine, 8600 Rockville Pike,
Bethesda, MD 20894; phone (301) 594-5983; website: www.nlm.nih.gov/.
(1) SNOMED CT[supreg] [SNOMED Clinical Terms] U.S. Edition, March
2022 Release; IBR approved for Sec. 170.207(a).
(2) RxNorm, Full Update Release, July 5, 2022; IBR approved for
Sec. 170.207(d).
(3) RxNorm, December 4, 2023, Full Update Release, IBR approved for
Sec. 170.207(d).
0
11. Amend Sec. 170.315 by:
0
a. Revising and republishing paragraph (a)(5);
0
b. Removing and reserving paragraphs (a)(9), (12), and (14);
0
c. Revising paragraph (b)(1);
0
d. Removing and reserving paragraphs (b)(2) and (7) through (9);
0
e. Removing paragraph (b)(11)(ii)(B);
0
f. Redesignating paragraph (b)(11)(ii)(C) as paragraph (b)(11)(ii)(B);
0
g. Revising paragraph (b)(11)(iii) introductory text and paragraph
(b)(11)(iii)(B);
0
h. Removing and reserving paragraphs (b)(11)(iv) through (vi);
0
i. Revising paragraph (c)(3);
0
j. Removing and reserving paragraphs (c)(4) and (d);
0
k. Revising and republishing paragraph (e)(1);
0
l. Removing and reserving paragraphs (e)(3) and (f)(4);
0
m. Revising paragraph (f)(5) introductory text;
0
n. Removing and reserving paragraph (f)(5)(ii);
0
o. Revising paragraph (f)(6);
0
p. Removing paragraph (f)(7);
0
q. Removing and reserving paragraphs (g)(1) through (7) and (9); and
0
r. Removing and reserving paragraph (h).
The revisions and republication read as follows:
Sec. 170.315 ONC certification criteria for Health IT.
* * * * *
(a) * * *
(5) Patient demographics. (i) Enable a user to record, change, and
access patient demographic data including race, ethnicity, preferred
language, sex, and date of birth.
(A) Race and ethnicity. (1) Enable each one of a patient's races to
be recorded in accordance with, at a minimum, the standard specified in
Sec. 170.207(f)(3) and whether a patient declines to specify race.
(2) Enable each one of a patient's ethnicities to be recorded in
accordance with, at a minimum, the standard specified in Sec.
170.207(f)(3) and whether a patient declines to specify ethnicity.
(3) Aggregate each one of the patient's races and ethnicities
recorded in accordance with paragraphs (a)(5)(i)(A)(1) and (2) of this
section to the categories in the standard specified in Sec.
170.207(f)(1).
(B) Preferred language. Enable preferred language to be recorded in
accordance with the standard specified in Sec. 170.207(g)(2) and
whether a patient declines to specify a preferred language.
(C) Sex. Enable sex to be recorded in accordance with the standard
specified in Sec. 170.207(n)(2).
(ii) Inpatient setting only. Enable a user to record, change, and
access the preliminary cause of death and date of death in the event of
mortality.
* * * * *
(b) * * *
(1) Transitions of care--receive and validate--(i) Validate C-CDA
conformance--system performance. Demonstrate the ability to detect
valid and invalid transition of care/referral summaries received and
formatted in accordance with the standard specified in Sec.
170.205(a)(6) for the Continuity of Care Document, Referral Note, and
(inpatient setting only) Discharge Summary document templates. This
includes the ability to:
(A) Parse each of the document types.
(B) Detect errors in corresponding ``document-templates,''
``section-templates,'' and ``entry-templates,'' including invalid
vocabulary standards and codes not specified in the standard adopted in
Sec. 170.205(a)(6).
[[Page 61031]]
(C) Identify valid document-templates and process the data elements
required in the corresponding section-templates and entry-templates
from the standard adopted in Sec. 170.205(a)(6).
(D) Correctly interpret empty sections and null combinations.
(E) Record errors encountered and allow a user through at least one
of the following ways to:
(1) Be notified of the errors produced.
(2) Review the errors produced.
(ii) [Reserved]
* * * * *
(11) * * *
(iii) Decision support intervention selection. Enable a limited set
of identified users to select (i.e., activate) electronic decision
support interventions that are:
* * * * *
(B) Predictive Decision Support Interventions and use any data in
paragraph (b)(11)(iii)(A) of this section as well as Clinical Notes and
Assessment and Plan of Treatment expressed in the standards for this
data in Sec. 170.213.
* * * * *
(c) * * *
(3) Clinical quality measures--report. Enable a user to
electronically create a data file for transmission of clinical quality
measurement data in accordance with the applicable implementation
specifications specified by the CMS implementation guides for Quality
Reporting Document Architecture (QRDA), category I, for inpatient
measures in Sec. 170.205(h)(3) and CMS implementation guide for QRDA,
category III for ambulatory measures in Sec. 170.205(k)(3).
* * * * *
(e) * * *
(1) View, download, and transmit to 3rd party--(i) General.
Patients (and their authorized representatives) must be able to use
internet-based technology to view, download, and transmit their health
information to a 3rd party in the manner specified in this paragraph
(e)(1)(i).
(A) View. Patients (and their authorized representatives) must be
able to use health IT to view, at a minimum, the following data:
(1) [Reserved]
(2) The data classes expressed in the standards in Sec. 170.213
(which should be in their English (i.e., non-coded) representation if
they associate with a vocabulary/code set), and in accordance with
Sec. 170.205(a)(4) and (6), and paragraphs (e)(1)(i)(A)(3)(i) through
(iii) of this section.
(3) The following data classes:
(i) Assessment and plan of treatment. In accordance with the
``Assessment and Plan Section (V2)'' of the standard specified in Sec.
170.205(a)(4); or in accordance with the ``Assessment Section (V2)''
and ``Plan of Treatment Section (V2)'' of the standard specified in
Sec. 170.205(a)(4).
(ii) Goals. In accordance with the ``Goals Section'' of the
standard specified in Sec. 170.205(a)(4).
(iii) Health concerns. In accordance with the ``Health Concerns
Section'' of the standard specified in Sec. 170.205(a)(4).
(iv) Unique device identifier(s) for a patient's implantable
device(s). In accordance with the ``Product Instance'' in the
``Procedure Activity Procedure Section'' of the standards specified in
Sec. 170.205(a)(4).
(4) Ambulatory setting only. Provider's name and office contact
information.
(5) Inpatient setting only. Admission and discharge dates and
locations; discharge instructions; and reason(s) for hospitalization.
(6) Laboratory test report(s). Laboratory test report(s),
including:
(i) The information for a test report as specified all the data
specified in 42 CFR 493.1291(c)(1) through (7);
(ii) The information related to reference intervals or normal
values as specified in 42 CFR 493.1291(d); and
(iii) The information for corrected reports as specified in 42 CFR
493.1291(k)(2).
(7) Diagnostic image report(s).
(B) Download. (1) Patients (and their authorized representatives)
must be able to use technology to download an ambulatory summary or
inpatient summary (as applicable to the health IT setting for which
certification is requested) in the following formats:
(i) Human readable format; and
(ii) The format specified in accordance with the standard specified
in Sec. 170.205(a)(4) and (6) and following the CCD document template.
(2) When downloaded according to the standard specified in Sec.
170.205(a)(4) and (6) following the CCD document template, the
ambulatory summary or inpatient summary must include, at a minimum, the
following data (which, for the human readable version, should be in
their English representation if they associate with a vocabulary/code
set):
(i) Ambulatory setting only. All of the data specified in paragraph
(e)(1)(i)(A)(1), (2), (4), and (5) of this section.
(ii) Inpatient setting only. All of the data specified in
paragraphs (e)(1)(i)(A)(1) and (3) through (5) of this section.
(3) Inpatient setting only. Patients (and their authorized
representatives) must be able to download transition of care/referral
summaries that were created as a result of a transition of care
(pursuant to the capability expressed in the certification criterion
specified in paragraph (b)(1) of this section).
(C) Transmit to third party. Patients (and their authorized
representatives) must be able to:
(1) Transmit the ambulatory summary or inpatient summary (as
applicable to the health IT setting for which certification is
requested) created in paragraph (e)(1)(i)(B)(2) of this section in
accordance with both of the following ways:
(i) Email transmission to any email address; and
(ii) An encrypted method of electronic transmission.
(2) Inpatient setting only. Transmit transition of care/referral
summaries (as a result of a transition of care/referral as referenced
by paragraph (e)(1)(i)(B)(3) of this section) of this section selected
by the patient (or their authorized representative) in both of the ways
referenced in paragraphs (e)(1)(i)(C)(1)(i) and (ii) of this section).
(D) Timeframe selection. With respect to the data available to
view, download, and transmit as referenced paragraphs (e)(1)(i)(A)
through (C) of this section, patients (and their authorized
representatives) must be able to:
(1) Select data associated with a specific date (to be viewed,
downloaded, or transmitted); and
(2) Select data within an identified date range (to be viewed,
downloaded, or transmitted).
(ii) Activity history log. (A) When any of the capabilities
included in paragraphs (e)(1)(i)(A) through (C) of this section are
used, the following information must be recorded and made accessible to
the patient (or his/her authorized representative):
(1) The action(s) (i.e., view, download, transmission) that
occurred;
(2) The date and time each action occurred;
(3) The user who took the action; and
(4) Where applicable, the addressee to whom an ambulatory summary
or inpatient summary was transmitted.
(B) [Reserved]
(iii) Request for restrictions. Patients (and their authorized
representatives) must be able to use an internet-based method to
request a restriction to be applied for any data expressed in the
standards in Sec. 170.213. Conformance with this paragraph is required
by January 1, 2026.
* * * * *
(f) * * *
(5) Transmission to public health agencies--electronic case
reporting.
[[Page 61032]]
Enable a user to create a case report for electronic transmission
meeting the requirements described in paragraph (f)(5)(i) of this
section.
* * * * *
(6) Transmission to public health agencies--antimicrobial use and
resistance reporting. Create antimicrobial use and resistance reporting
information for electronic transmission.
* * * * *
0
12. Amend Sec. 170.402 by
0
a. Revising paragraph (b)(2); and
0
b. Removing paragraph (b)(4).
The revision reads as follows:
Sec. 170.402 Assurances.
* * * * *
(b) * * *
(2) A health IT developer that must comply with the requirements of
paragraph (a)(4) of this section must provide all of its customers of
certified health IT with the health IT certified to the certification
criterion in Sec. 170.315(b)(10).
* * * * *
0
13. Amend Sec. 170.404 by:
0
a. Revising the introductory text and paragraph (b)(2) introductory
text;
0
b. Removing paragraphs (b)(3) and (4); and
0
c. Revising the definition for ``Certified API technology'' in
paragraph (c).
The revisions read as follows:
Sec. 170.404 Application programming interfaces.
The following Condition and Maintenance of Certification
requirements apply to developers of Health IT Modules certified to any
of the certification criteria adopted in Sec. 170.315(g)(10) and (31)
through (33) unless otherwise specified in this section.
* * * * *
(b) * * *
(2) Service base URL publication. For all Health IT Modules
certified to Sec. 170.315(g)(10), a Certified API Developer must
publish, at no charge, the service base URLs and related organization
details that can be used by patients to access their electronic health
information. This includes all customers regardless of whether the
Health IT Modules certified to Sec. 170.315(g)(10) are centrally
managed by the Certified API Developer or locally deployed by an API
Information Source. These service base URLs and organization details
must conform to the following:
* * * * *
(c) * * *
Certified API Technology means the capabilities of Health IT
Modules that are certified to any of the API-focused certification
criteria adopted in Sec. 170.315(g)(10), (31), (32), and (33).
0
14. Amend Sec. 170.405 by:
0
a. Revising paragraph (a);
0
b. Removing and reserving paragraph (b)(1);
0
c. Revising and republishing paragraph (b)(2); and
0
d. Revising paragraph (b)(8) introductory text.
The revisions and republication read as follows:
Sec. 170.405 Real world testing.
(a) Condition of Certification requirement. A health IT developer
with one or more Health IT Module(s) certified to any one or more of
the Certification Criteria for Health IT in Sec. 170.315(b), (c), (e),
(f), (g), and (j) must, on an annual basis, successfully test the real
world use of those Health IT Module(s) for interoperability (as defined
in 42 U.S.C. 300jj(9) and Sec. 170.102) in the type of setting in
which such Health IT Module(s) would be/is marketed.
(b) * * *
(2) Real world testing results reporting. (i) If in the course of
conducting real world testing the developer discovers one or more non-
conformities with the full scope of any certification criterion under
the Program, the developer must report that non-conformity to the ONC-
ACB within 30 days.
(ii) For real world testing activities conducted during the
immediately preceding calendar year, a health IT developer must submit
to its ONC-ACB an annual real world testing results report that:
(A) Addresses each of its certified Health IT Modules that were
certified to, including through Inherited Certified Status, the Sec.
170.315(g) certification criteria referenced in paragraph (a) in the
year preceding the real world testing calendar year reporting period.
(B) Includes the newer versions of certified Health IT Modules that
include the Sec. 170.315(g) certification criteria referenced in
paragraph (a) of this section that were updated using Inherited
Certified Status during the real world testing reporting period; and
(C) Is submitted by a date determined by the ONC-ACB that enables
the ONC-ACB to publish a publicly available hyperlink to the results
report on the CHPL no later than March 15 of each calendar year,
beginning in 2023.
(iii) The real world testing results must report the following for
each of the Sec. 170.315(g) certification criteria identified in
paragraph (a) of this section that are included in the Health IT
Module's scope of certification:
(A) The method(s) that was used to demonstrate real world
interoperability;
(B) The care setting(s) that was tested for real world
interoperability;
(C) The voluntary updates to standards and implementation
specifications that the National Coordinator has approved through the
Standards Version Advancement Process;
(D) A list of the key milestones met during real world testing;
(E) The outcomes of real world testing including a description of
any challenges encountered during real world testing; and
(F) At least one measurement/metric associated with the real world
testing.
(iv) For each Health IT Module certified to any certification
criterion specified in paragraph (a) of this section, other than the
Sec. 170.315(g) certification criteria (see paragraph (b)(2)(iii) for
requirements), identify the voluntary updates to standards and
implementation specifications that the National Coordinator has
approved through the Standards Version Advancement Process.
* * * * *
(8) Standards Version Advancement Process--voluntary updates of
certified health IT to newer versions of standards and implementation
specifications. A health IT developer of certified health IT subject to
paragraph (a) of this section is permitted to update Health IT
Module(s) certified to any one or more of the certification criteria
referenced in paragraph (a) of this section to a newer version of any
adopted standard or implementation specification included in the
criterion, provided that newer version is approved by the National
Coordinator for use in certifications issued under the ONC Health IT
Certification Program. A developer that pursues such updates to its
certified Health IT Module(s) must:
* * * * *
0
15. Amend Sec. 170.406 by revising paragraphs (a)(4) and (5) to read
as follows:
Sec. 170.406 Attestations.
(a) * * *
(4) Section 170.404 if the health IT developer has a Health IT
Module(s) certified to any of the certification criteria adopted in
Sec. 170.315(g); and such health IT developer must also ensure that
health IT allows for health information to be exchanged, accessed, and
used, in the manner described in Sec. 170.404; and
(5) Section 170.405 if a health IT developer has a Health IT
Module(s) certified to any one or more ONC
[[Page 61033]]
Certification Criteria for Health IT set forth in Sec. 170.405(a).
* * * * *
0
16. Amend Sec. 170.407 by:
0
a. Revising the section heading and paragraphs (a)(1)(ii)(B) and (C)
and (a)(3); and
0
b. Revising and republishing paragraph (b).
The revisions and republication read as follows:
Sec. 170.407 Insights.
(a) * * *
(1) * * *
(ii) * * *
(B) Have health IT certified to the certification criteria
specified in each measure in paragraph (a)(3) of this section; or
(C) Have any users using the certified health IT specified in each
measure in paragraphs (a)(3) of this section during the reporting
period.
* * * * *
(3) Measures--(i) Use of FHIR in apps through certified health IT.
If a health IT developer has a Health IT Module certified to Sec.
170.315(g)(10), then the health IT developer must submit responses on
the number of requests made to distinct certified health IT deployments
that returned FHIR resources, number of distinct certified health IT
deployments active at any time, the number of distinct deployments
active at any time that returned FHIR resources in response to API
calls from apps connected to certified health IT, including stratifying
responses by the following:
(A) User type;
(B) FHIR resource; and
(C) US Core Implementation Guide version.
(ii) [Reserved]
(b) Maintenance of Certification. (1) A health IT developer must
provide responses to the Insights Condition of Certification specified
in paragraph (a) of this section annually for any Health IT Module that
has or has had an active certification as of January 1 for each
reporting period under the ONC Health IT Certification Program:
(i) A health IT developer must provide responses for measures
specified in:
(A) Paragraphs (a)(3)(i)(A) and (B) of this section beginning July
2027.
(B) Paragraphs (a)(3)(i)(C) of this section beginning July 2028.
(2) [Reserved]
0
17. Amend Sec. 170.523 by:
0
a. Revising paragraph (f)(1)(viii);
0
b. Removing and reserving paragraphs (f)(1)(ix) through (xi), (xix),
and (xxi) and (p)(1); and
0
c. Revising paragraph (p)(3).
The revisions read as follows.
Sec. 170.523 Principles of proper conduct for ONC-ACBs.
* * * * *
(f) * * *
(1) * * *
(viii) The certification criterion or criteria to which the Health
IT Module has been certified, including the test procedure and test
tool version used;
* * * * *
(p) * * *
(3) Submit real world testing results by March 15 of each calendar
year to ONC for public availability.
* * * * *
0
18. Amend Sec. 170.550 by:
0
a. Revising paragraph (e);
0
b. Revising and republishing paragraph (g); and
0
c. Removing and reserving paragraphs (h) and (j).
The revisions and republication read as follows:
Sec. 170.550 Health IT Module certification.
* * * * *
(e) Standards updates. ONC-ACBs must provide an option for
certification of Health IT Modules consistent with Sec. 170.405(b)(7)
or (8) to any one or more of the criteria referenced in Sec.
170.405(a) based on newer versions of standards included in the
criteria which have been approved by the National Coordinator for use
in certification.
* * * * *
(g) Health IT Module dependent criteria. When certifying a Health
IT Module to the ONC Certification Criteria for Health IT, an ONC-ACB
must certify the Health IT Module in accordance with the certification
criteria at:
(1) Section 170.315(b)(10) when a health IT developer presents a
Health IT Module for certification that can store electronic health
information at the time of certification by the product, of which the
Health IT Module is a part.
(2) Section 170.315(b)(4) if the Health IT Module is presented for
certification to the certification criteria in Sec. 170.315(b)(3).
* * * * *
0
19. Amend Sec. 170.555 by revising and republishing paragraph (b)(2)
to read as follows:
Sec. 170.555 Certification to newer versions of certain standards.
* * * * *
(b) * * *
(2) A certified Health IT Module may be upgraded to comply with
newer versions of standards identified as minimum standards in subpart
B of this part without adversely affecting its certification status,
unless the Secretary prohibits the use of a newer version for
certification.
0
20. Amend Sec. 170.570 by revising the section heading to read as
follows:
Sec. 170.570 Effect of revocation on the certifications issued to
Health IT Module(s).
* * * * *
PART 171--INFORMATION BLOCKING
0
21. The authority citation for part 171 continues to read as follows:
Authority: 42 U.S.C. 300jj-52; 5 U.S.C. 552.
0
22. Amend Sec. 171.102 by:
0
a. Revising definitions of ``Access'' and ``Use'';
0
b. Adding, in alphabetical order, the definitions of ``Contract of
adhesion'', ``Market rate'', and ``Unconscionable terms''.
The revisions and additions read as follows:
Sec. 171.102 Definitions.
* * * * *
Access means the ability or means necessary to make electronic
health information available for exchange or use, including, without
limitation, by automation technologies (e.g., robotic process
automation, agentic artificial intelligence).
* * * * *
Contract of adhesion means a contract provided on a standardized
form, or on a ``take it or leave it basis'' without a realistic
opportunity to bargain where the desired product, services, access,
use, or exchange cannot be provided except by acquiescing to the form
contract.
* * * * *
Market rate means the value in an arm's-length transaction,
consistent with the general market value of the subject transaction.
* * * * *
Unconscionable terms means contractual terms that are excessive,
unreasonable, or shockingly unfair or unjust.
* * * * *
Use means the ability for electronic health information, once
accessed or exchanged through automation technologies or otherwise, to
be understood and acted upon, including, without limitation, by
automation technologies (e.g., robotic process automation, autonomous
artificial intelligence systems).
0
23. Amend Sec. 171.204 by:
0
a. Removing and reserving paragraph (a)(3);
0
b. Revising and republishing paragraphs (a)(4)(ii) and (iii); and
[[Page 61034]]
0
c. Removing and reserving paragraph (a)(4)(iv).
The revisions and republication read as follows:
Sec. 171.204 Infeasibility exception--When will an actor's practice
of not fulfilling a request to access, exchange, or use electronic
health information due to the infeasibility of the request not be
considered information blocking?
* * * * *
(a) * * *
(4) * * *
(ii) The actor offered all alternative manners that are set forth
in Sec. 171.301(b) in accordance with Sec. 171.301(b), regardless of
whether the requestor specified the manner or agreed to it.
(iii) The actor does not provide analogous access, exchange, or use
of the requested electronic health information to any other individual
or entity.
* * * * *
0
24. Amend Sec. 171.301 by:
0
a. Removing the word ``and'' at the end of paragraph (a)(2)(i);
0
b. Removing the period at the end of paragraph (a)(2)(ii) and adding
``; and'' in its place; and
0
c. Adding paragraph (a)(2)(iii).
The addition reads as follows:
Sec. 171.301 Manner exception--When will an actor's practice of
limiting the manner in which it fulfills a request to access, exchange,
or use electronic health information not be considered information
blocking?
* * * * *
(a) * * *
(2) * * *
(iii) Any contract or agreement under which the actor and requestor
agree to fulfill a request for access, exchange, or use of EHI, and any
license from the actor of interoperability elements used in fulfilling
the request in the manner requested:
(A) must be at market rate,
(B) must not be a contract of adhesion, and
(C) must not contain unconscionable terms.
* * * * *
Subpart D [Removed and Reserved]
0
25. Remove and reserve subpart D, consisting of Sec. Sec. 171.400
through 171.403.
Robert F. Kennedy, Jr.,
Secretary, Department of Health and Human Services.
[FR Doc. 2025-23896 Filed 12-22-25; 4:15 pm]
BILLING CODE 4150-45-P