Home/Federal/Federal Register/2025-23896

Proposed Rule2025-23896

Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions To Unleash Prosperity

Primary source

Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.

Published

December 29, 2025

Issuing agencies

Health and Human Services Department

Abstract

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.

Full Text

<html>
<head>
<title>Federal Register, Volume 90 Issue 245 (Monday, December 29, 2025)</title>
</head>
<body><pre>
[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 [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[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.
<bullet> Federal eRulemaking Portal: Follow the instructions for
submitting comments. Attachments should be in Microsoft Word, Microsoft
Excel, or Adobe PDF; however, we prefer Microsoft Word. <a href="http://www.regulations.gov">http://www.regulations.gov</a>.
<bullet> Regular, Express, or Overnight Mail: Department of Health
and Human Services, 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.
<bullet> 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
<a href="http://www.regulations.gov">http://www.regulations.gov</a>.
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 <a href="http://www.regulations.gov">http://www.regulations.gov</a> 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\ <a href="https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation">https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation</a>.
---------------------------------------------------------------------------

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\ <a href="https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation">https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation</a>.
\3\ <a href="https://www.federalregister.gov/documents/2025/04/15/2025-06463/reducing-anti-competitive-regulatory-barriers">https://www.federalregister.gov/documents/2025/04/15/2025-06463/reducing-anti-competitive-regulatory-barriers</a>.
---------------------------------------------------------------------------

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\ <a href="https://hl7.org/fhir/summary.html">https://hl7.org/fhir/summary.html</a>.
\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 <a href="https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019">https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019</a>; and also <a href="https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/">https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/</a>.
---------------------------------------------------------------------------

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\ <a href="https://modelcontextprotocol.io/introduction">https://modelcontextprotocol.io/introduction</a>.
\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\ <a href="https://chpl.healthit.gov/">https://chpl.healthit.gov/</a>.
---------------------------------------------------------------------------

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 <a href="https://www.healthit.gov/topic/hhs-health-it-alignment-program">https://www.healthit.gov/topic/hhs-health-it-alignment-program</a>.
---------------------------------------------------------------------------

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\ <a href="https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement">https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement</a>.
\12\ <a href="https://www.healthit.gov/topic/insights-condition-and-maintenance-certification-enforcement-discretion">https://www.healthit.gov/topic/insights-condition-and-maintenance-certification-enforcement-discretion</a>-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\ <a href="https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records">https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records</a>.

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]
<a href="https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion">https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion</a>-notice.
\15\ <a href="https://www.healthit.gov/test-method/patient-demographics-and-observations">https://www.healthit.gov/test-method/patient-demographics-and-observations</a>.
---------------------------------------------------------------------------

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\ <a href="https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records">https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records</a>.
\17\ We discuss USCDI v3.1 in section III.B.1.
\18\ <a href="https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6">https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6</a>.
---------------------------------------------------------------------------

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\ <a href="https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records">https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records</a>.
---------------------------------------------------------------------------

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\ <a href="https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6">https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6</a>.
---------------------------------------------------------------------------

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 <a href="https://www.federalregister.gov/d/2025-13271/p-3055andtheFY2026IPPS/LTCH">https://www.federalregister.gov/d/2025-13271/p-3055andtheFY2026IPPS/LTCH</a> PPS Final Rule (90 FR 36536) Table X.F.-05
available at <a href="https://www.federalregister.gov/d/2025-14681/p-4161">https://www.federalregister.gov/d/2025-14681/p-4161</a>.
---------------------------------------------------------------------------

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
<a href="https://www.federalregister.gov/d/2025-13271/p-3055andtheFY2026IPPS/LTCH">https://www.federalregister.gov/d/2025-13271/p-3055andtheFY2026IPPS/LTCH</a> PPS Final Rule Table X.F.-05 available at <a href="https://www.federalregister.gov/d/2025-14681/p-4161">https://www.federalregister.gov/d/2025-14681/p-4161</a>.
---------------------------------------------------------------------------

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 <a href="https://chpl.healthit.gov/">https://chpl.healthit.gov/</a>) 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\ <a href="https://chpl.healthit.gov/">https://chpl.healthit.gov/</a> 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\ <a href="https://chpl.healthit.gov/">https://chpl.healthit.gov/</a> search conducted June 2025.
\27\ <a href="https://www.healthit.gov/topic/standardsbulletin_25-1">https://www.healthit.gov/topic/standardsbulletin_25-1</a>.
---------------------------------------------------------------------------

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\ <a href="https://www.federalregister.gov/d/2025-02172/p-3">https://www.federalregister.gov/d/2025-02172/p-3</a>.
\29\ Federal Register: Removing Barriers to American Leadership
in Artificial Intelligence (90 FR 8741).
\30\ <a href="https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and">https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and</a>.
---------------------------------------------------------------------------

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: <a href="https://www.ehra.org/sites/ehra.org/files/EHR%20Association%20Letter%20to%20ASTP-ONC%20-%20Certification%20Program%20Deregulatory%20Suggestions.pdf#page=7">https://www.ehra.org/sites/ehra.org/files/EHR%20Association%20Letter%20to%20ASTP-ONC%20-%20Certification%20Program%20Deregulatory%20Suggestions.pdf#page=7</a>.
\32\ See 88 FR 23780 at <a href="https://www.federalregister.gov/d/2023-07229/p-547">https://www.federalregister.gov/d/2023-07229/p-547</a>.
---------------------------------------------------------------------------

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,<SUP>35 36</SUP> we acknowledge that our authorities have
limitations that inhibit our collective efforts to treat similar
technologies similarly under a single Department-wide policy.
---------------------------------------------------------------------------

\33\ <a href="https://www.ehra.org/sites/ehra.org/files/EHR%20Association%20Letter%20to%20ASTP-ONC%20-%20Certification%20Program%20Deregulatory%20Suggestions.pdf#page=7">https://www.ehra.org/sites/ehra.org/files/EHR%20Association%20Letter%20to%20ASTP-ONC%20-%20Certification%20Program%20Deregulatory%20Suggestions.pdf#page=7</a>.
\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\ <a href="https://www.ecfr.gov/current/title-45/part-92#p-92.4">https://www.ecfr.gov/current/title-45/part-92#p-92.4</a>(Health%20program%20or%20activity).
\42\ <a href="https://www.ecfr.gov/current/title-45/part-92#p-92.4">https://www.ecfr.gov/current/title-45/part-92#p-92.4</a>(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
<a href="https://www.federalregister.gov/d/2025-13271/page-32744">https://www.federalregister.gov/d/2025-13271/page-32744</a>.
---------------------------------------------------------------------------

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\ <a href="https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/index.html">https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/index.html</a>.
---------------------------------------------------------------------------

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\ <a href="https://www.healthit.gov/topic/electronic-case-reporting-certification-criterion-enforcement-discretion-notice">https://www.healthit.gov/topic/electronic-case-reporting-certification-criterion-enforcement-discretion-notice</a>.
---------------------------------------------------------------------------

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
<a href="https://www.federalregister.gov/d/2025-13271/p-3055">https://www.federalregister.gov/d/2025-13271/p-3055</a> and the FY2026
IPPS/LTCH PPS Final Rule Table X.F.-05 available at <a href="https://www.federalregister.gov/d/2025-14681/p-4161">https://www.federalregister.gov/d/2025-14681/p-4161</a>.
---------------------------------------------------------------------------

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 <a href="https://www.federalregister.gov/d/2025-14681/p-4161">https://www.federalregister.gov/d/2025-14681/p-4161</a>.
---------------------------------------------------------------------------

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
<a href="https://www.cdc.gov/nhsn/psc/aur/index.html">https://www.cdc.gov/nhsn/psc/aur/index.html</a>.
---------------------------------------------------------------------------

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
<a href="https://www.federalregister.gov/d/2025-13271/p-3055">https://www.federalregister.gov/d/2025-13271/p-3055</a> and the FY2026
IPPS/LTCH PPS Final Rule Table X.F.-05 available at <a href="https://www.federalregister.gov/d/2025-14681/p-4161">https://www.federalregister.gov/d/2025-14681/p-4161</a>.
---------------------------------------------------------------------------

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 <a href="https://build.fhir.org/ig/HL7/fhir-health-care-surveys-reporting-ig/">https://build.fhir.org/ig/HL7/fhir-health-care-surveys-reporting-ig/</a>.
---------------------------------------------------------------------------

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

[…truncated; see source link]

View on FederalRegister.gov →Plain-text source

Indexed from Federal Register on December 29, 2025.

This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.