Home/Federal/Federal Register/2026-21943

Rule2026-21943

Health Data, Technology, and Interoperability: 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

October 28, 2026

Effective

December 28, 2026

Issuing agencies

Health and Human Services Department

Abstract

This final rule focuses on deregulatory actions identified in HHS regulations regarding health information technology standards, implementation specifications, and certification criteria and regarding certification programs for health information technology. This final rule reduces burden, offers flexibility to both developers and providers, and supports innovation through the removal and revision of certain certification criteria and regulatory provisions.

Full Text

<html>
<head>
<title>Federal Register, Volume 91 Issue 207 (Wednesday, October 28, 2026)</title>
</head>
<body><pre>
[Federal Register Volume 91, Number 207 (Wednesday, October 28, 2026)]
[Rules and Regulations]
[Pages 67916-67998]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2026-21943]

[[Page 67915]]

Vol. 91

Wednesday,

No. 207

October 28, 2026

Part II

Department of Health and Human Services

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

45 CFR Parts 170 and 172

Health Data, Technology, and Interoperability: ONC Deregulatory Actions
To Unleash Prosperity; Final Rule

Federal Register / Vol. 91 , No. 207 / Wednesday, October 28, 2026 /
Rules and Regulations

[[Page 67916]]

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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Parts 170 and 172

RIN 0955-AA09

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

AGENCY: Office of the National Coordinator for Health Information
Technology (ONC), Department of Health and Human Services (HHS).

ACTION: Final rule.

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

SUMMARY: This final rule focuses on deregulatory actions identified in
HHS regulations regarding health information technology standards,
implementation specifications, and certification criteria and regarding
certification programs for health information technology. This final
rule reduces burden, offers flexibility to both developers and
providers, and supports innovation through the removal and revision of
certain certification criteria and regulatory provisions.

DATES: This final rule is effective on December 28, 2026, except for
amendatory instructions 7, 10, and 12 which are effective January 1,
2027. The incorporation by reference of certain material listed in the
rule was approved by the Director of the Federal Register between
February 12, 2010, and October 1, 2025.

FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Programs
and Implementation, 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
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
C. Severability
D. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation Specifications, and Certification
Criteria
2. Health IT Certification Program(s)
B. ONC Health IT Certification Program Regulatory History
C. General Comments on the Proposed Rule
D. Comments Beyond the Scope of Certification Program Proposals
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. Clinical Decision Support
b. Family Health History
c. 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
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
B. Standards and Implementation Specifications for Health
Information Technology
1. 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. Trusted Exchange Framework and Common Agreement (Part 172)--
Restoring the Office of the National Coordinator (ONC)
V. Incorporation by Reference
VI. Collection of Information Requirements
A. ONC-ACBs
B. Health IT Developers
VII. 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

Since the inception of the ONC Health IT Certification Program
(Certification Program) (42 U.S.C. 300jj-11(c)(5)), 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, we reviewed the existing requirements and made
updates. Through both formal notice and comment rulemaking and informal
engagements, we received suggestions on how to update the Certification
Program to meet current market needs. This final rule includes
deregulatory actions that: take into consideration suggestions and
comments received on the Health Data, Technology, and Interoperability:
ASTP/ONC Deregulatory Actions To Unleash Prosperity Proposed Rule (90
FR 60970) (``Proposed Rule''); account for the current and future state
of technology; reduce burden on health IT developers; and promote
innovation for health IT developers, providers, and other interested
parties.
These efforts directly align with Administration goals as outlined
in E.O. 14192 (Unleashing Prosperity through

[[Page 67917]]

Deregulation) \1\ and E.O. 14267 (Reducing Anti-Competitive Regulatory
Barriers).\2\ By removing burdensome and unnecessary requirements of
the Certification Program, this final rule supports providers in caring
for their patients. Developers of certified health IT will have more
time to support providers' specific technological needs. Further, by
increasing competition in the certified health IT market that will come
from reduced barriers to entry for the certification of health IT,
providers also will have more choices to meet their health IT needs.
---------------------------------------------------------------------------

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

America's interoperability arc in healthcare has bent decisively
toward Fast Healthcare Interoperability Resources (FHIR[supreg])-based
application programming interfaces (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 final
rule, we aggressively reduce and remove long-standing functionality-
oriented and non-FHIR-based certification criteria from the
Certification Program. While this approach will directly and rapidly
reduce compliance burdens for health IT developers that participate in
the Certification Program, more broadly, it will enable 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 will allow more creative super intelligence \3\ (SI)-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),'' \4\ and
will further embrace the 21st Century Cures Act (Pub. L. 114-255)
(Cures Act)'s reference to successor technology and standards in the
API Condition of Certification.\5\
---------------------------------------------------------------------------

\3\ Executive Order 14434 (September 29, 2026); <a href="https://www.federalregister.gov/documents/2026/10/02/2026-20321/inaugurating-the-era-of-super-intelligence">https://www.federalregister.gov/documents/2026/10/02/2026-20321/inaugurating-the-era-of-super-intelligence</a>.
\4\ <a href="https://modelcontextprotocol.io/introduction">https://modelcontextprotocol.io/introduction</a>.
\5\ 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, consistent with all legal
requirements: (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
use cases focused on timely reporting (e.g., public health, quality,
government programs).
The transition to a FHIR-based API ecosystem is a strategic
imperative and an investment in the US's interoperability future.
Successful execution of this vision will require a collective
commitment from clinicians, patients, payers, policymakers, and
software developers, alike. Together, we can build interoperable
solutions that meet today's challenges and anticipate tomorrow's
opportunities.
In this final rule, we have finalized the removal or revision of
certain certification criteria that are consistent with our drive
toward and our support for the FHIR standard. The push toward universal
adoption of FHIR is not just important for secure, streamlined data
access, it is a critical step toward modernizing our healthcare system
with the ultimate goal of Making America Healthy Again.

B. Summary of Major Provisions

For the purposes of this final rule, we have reviewed and responded
to comments on a narrowed set of proposals from the Proposed Rule.
Comments received in response to other Proposed Rule proposals not
discussed in this final rule remain under review and consideration. The
Proposed Rule proposals not discussed in this final rule may, in the
future, be included in subsequent final rules or as revised proposals
in subsequent proposed rules.
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
In the Proposed Rule, we identified certification criteria for
proposed removal or revision (90 FR 60973). We noted that the removal
or revision of the identified certification criteria would reduce
burden and costs for health IT developers and clinicians by eliminating
the need to design and meet specific certification functionalities; to
prepare, test, and certify health IT in certain instances; and to
maintain conformance to certification requirements. As explained in the
Proposed Rule, we have observed that over time certification is likely
no longer a primary factor driving improvements or compliance in
particular areas. Throughout this final rule, we include finalized
revisions and removals of certification criteria that 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.
In the Proposed Rule, out of the 60 certification criteria that are
currently in effect, we proposed to remove 34 and revise seven. In this
final rule, we have finalized the removal of 14 certification criteria
and the revision of seven criteria. Of the revised criteria, one of the
more substantial revisions reduces the scope of the ``decision support
interventions'' certification criterion to fully remove the super
intelligence ``model card'' requirements in Sec. 170.315(b)(11)(iv)
for source attribute support and Sec. 170.315(b)(11)(v) for source
attribute access and modification. We have retained and made no changes
to 39 certification criteria, which include new and revised 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). The HTI-4 final rule was a ``rider'' in
the FY 2026 CMS Hospital Inpatient Prospective Payment System and Long-
Term Care Hospital Prospective Payment System final rule (90 FR 36536).
The new and revised criteria that were finalized in the HTI-4 final
rule were: three new electronic prior authorization API criteria, a new
``real-time prescription benefit'' criterion,\6\ a revised e-
prescribing criterion, and two criteria supporting modular API
capabilities.
---------------------------------------------------------------------------

\6\ ONC finalized the real-time prescription benefit criterion
in order to implement section 119(b)(3) of Title I of the
Consolidated Appropriations Act, 2021 (Pub. L. 116-260).
---------------------------------------------------------------------------

b. Standards and Implementation Specifications for Health Information
Technology
As proposed in the Proposed Rule (90 FR 60973), in some instances
where we finalize the removal or revision of a certain certification
criterion, we also finalize the removal of the standard(s) that is
referenced by the certification criterion. In some cases, we have
finalized the removal of standards consistent with a certification
criterion transition period until January 1, 2027.

[[Page 67918]]

In one circumstance, we retain a standard that was referenced in a
certification criterion that we removed for purposes of health IT
interoperability alignment.\7\ We also finalized the removal of
standards that are outdated and no longer referenced in the
Certification Program.
---------------------------------------------------------------------------

\7\ 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 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
We have finalized, as proposed, to make conforming edits to the
terms and definitions in Sec. 170.102. We revised the definition of
``Base EHR'' to remove references to certification criteria that we
have removed from the Code of Federal Regulations (CFR). We have also
removed the term (and associated definition) ``Common Clinical Data
Set'' because this is no longer referenced in part 170.
d. Conditions and Maintenance of Certification Requirements for Health
IT Developers
We have finalized our proposals 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 (90 FR 61001
through 61003).
In addition to conforming edits, we also finalized our proposal 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). As noted in the Proposed
Rule, these actions are consistent with the enforcement discretion
notice we issued on June 30, 2025.\8\ Lastly, we finalized most, but
not all, of our proposals to remove and descope measures associated
with the ``Insights'' Condition and Maintenance of Certification
requirements (Sec. 170.407).
---------------------------------------------------------------------------

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

e. ONC Health IT Certification Program Administrative Requirements
We have finalized our proposals to make conforming edits, to remove
references to certification criteria that we proposed to remove in the
Proposed Rule, in subpart E of 45 CFR part 170, (specifically, in
Sec. Sec. 170.523, 170.550, 170.555, and 170.570 (90 FR 60973). We
have also finalized a revision to Sec. 170.523 to remove references to
the Assistant Secretary for Technology Policy (ASTP).
2. Trusted Exchange Framework and Common Agreement (Part 172)--
Restoring the Office of the National Coordinator (ONC)
We have finalized the removal of all references to ASTP within 45
CFR part 172.

C. Severability

It is our intent that each provision of this final rule be
severable from other provisions of this final rule. This means that if
any provision of this final rule is held to be invalid or unenforceable
facially, or as applied to any person or plaintiff, or stayed pending
further judicial or agency action, we intend that such provision shall
be severable from other provisions of this final rule, and from rules
and regulations currently in effect. We provided notice of this intent
in the HTI-5 Proposed Rule (90 FR 60974). 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 final rule, we have finalized 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 of 45 CFR, our
intention is that other provisions of such subparagraph(s),
paragraph(s), or section(s) operate independently of said provision and
would remain in effect.
If any revision to any provision of part 170 (such as 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, we explained our intent that such provision--and any
section or paragraph of part 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 finalized proposals in
this final rule. The finalized 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 ONC rulemakings. The finalized deregulatory actions reduce the
effort for developers of certified health IT to meet ongoing
Certification Program requirements and reduce entry barriers for new
Certification Program participants. The finalized actions, importantly,
return resources 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 finalized deregulatory
actions. We expect the finalized deregulatory actions to result in
significant benefits for health IT developers, providers, ONC-
Authorized Certification Bodies (ONC-ACBs), ONC-Authorized Testing
Laboratories (ONC-ATLs), and 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 finalized
actions reduce the scope and breadth of Certification Program
requirements.
The analysis included in this final rule indicates that the
finalized updates to the Certification Program would result in $0 in
implementation and compliance costs on developers of certified health
IT. However, we estimated some costs for reviewers who reviewed this
final rule. We estimated those costs to be $1,293,508 in total for an
estimated 616 reviewers, which include developers, medical
associations, and other health and health IT community members. We did
not quantify benefits for this final 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

[[Page 67919]]

expended had these requirements remained in effect in perpetuity. In
total, consistent with analytic guidance on E.O. 14192, this finalized
rulemaking would result in a present value of cost savings of $1.55
billion and annualized net cost savings of $108.1 million 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 healthcare 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.\9\
---------------------------------------------------------------------------

\9\ See, e.g., ``Health Information Technology Advisory
Committee Schedule of Meetings'' (91 FR 2542). <a href="https://www.federalregister.gov/documents/2026/01/21/2026-01046/health-information-technology-advisory-committee-schedule-of-meetings">https://www.federalregister.gov/documents/2026/01/21/2026-01046/health-information-technology-advisory-committee-schedule-of-meetings</a>.
---------------------------------------------------------------------------

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(s)
Section 3001(c)(5) of the PHSA provides the National Coordinator
with the authority to establish a certification program or programs for
the voluntary certification of health IT. Section 3001(c)(5)(A)
specifies that the National Coordinator, in consultation with the
Director of the National Institute of Standards and Technology (NIST),
shall keep or recognize a program or programs for the voluntary
certification of health IT that is in compliance with applicable
certification criteria adopted 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
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.

[[Page 67920]]

B. ONC Health IT Certification Program 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' 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
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

[[Page 67921]]

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 that the 2015 Edition
Base EHR definition encompassed 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 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 ``21st Century Cures Act: Interoperability,
Information Blocking, and the ONC Health IT Certification Program''
(Cures Act Final Rule) was published in the Federal Register (85 FR
25642). The final rule

[[Page 67922]]

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 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 healthcare system additional flexibilities in furnishing
services to combat the COVID-19 pandemic.
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 United
States Core Data for Interoperability (USCDI).
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) and ``electronic case reporting,'' as well as
adopted a new baseline version of the USCDI standard, USCDI Version 3
(v3). 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 the
Trusted Exchange Framework and Common Agreement (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 July 31, 2025, 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 ``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'' (FY 2026 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.
On December 29, 2025, the Secretary issued a withdrawal of non-
finalized provisions titled, ``Health Data, Technology, and
Interoperability: Patient Engagement, Information Sharing, and Public
Health Interoperability; Withdrawal'' (90 FR 60602) (HTI-2 Withdrawal
Notice). The HTI-2 Withdrawal Notice withdrew the remaining proposals
that have not been finalized from the HTI-2 Proposed Rule.
On December 29, 2025, the Secretary published the ``Health Data,
Technology, and Interoperability: ASTP/ONC Deregulatory Actions to
Unleash Prosperity'' Proposed Rule (90 FR 60970) (Proposed Rule). The
Proposed Rule focused on deregulatory actions identified in HHS
regulations regarding health IT standards, implementation
specifications, certification criteria and certification programs for
health IT, and information blocking. The Proposed Rule sought 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.

[[Page 67923]]

C. General Comments on the Proposed Rule

Comments. Many commenters were supportive of modernizing the
Certification Program around FHIR-based APIs and reducing outdated or
duplicative requirements, stating that it would have the benefit of
reducing administrative burden, improving standards-based
interoperability, and supporting automation, innovation, and more
scalable exchange. They also noted that this modernization would allow
vendors and implementers to redirect effort away from low-value
compliance activities and toward real-world interoperability,
reliability, scalability, and more granular exchange. Some of these
commenters emphasized that a ``FHIR-forward'' approach should advance
computable interoperability, where exchanged data are reliably
structured, attributable, and usable, not simply accessible. The
commenters noted that this would reduce integration burden, improve
data quality, and accelerate innovation across care delivery, payer,
public health, and third-party application ecosystems.
Response. We thank commenters for their support for America's FHIR-
forward future. We may take these comments into consideration to inform
future rulemaking.
Comments. We received numerous comments that were not supportive of
the deregulatory approach to reducing or removing certification and
related interoperability guardrails without replacement safeguards.
These commenters expressed significant concerns that such approaches
would weaken baseline functionality, increase fragmentation and cost,
and shift operational, compliance, and financial burdens to providers,
public health agencies, and other end users. Some of these commenters
expressed concerns that when foundational capabilities are no longer
required, they reappear as optional modules, implementation fees, or
premium features that providers must purchase to achieve necessary
functionality. A commenter recommended prompt release of the next
future rulemaking stating difficulties commenting on the Proposed Rule
without knowing future plans for the Certification Program. These
commenters noted that our proposal for a transition toward a FHIR-based
API ecosystem would require additional guidance or specification of
phased timelines, readiness thresholds, implementation best practices,
testing and performance expectations, and the continued role of
existing exchange pathways during transition.
Some commenters highlighted that many organizations continue to
operate in a hybrid environment where document-based exchange remains
foundational to many workflows. Several commenters also warned that,
absent a required, standardized, and patient-accessible FHIR-native
alternative, removal of Consolidated Clinical Document Architecture (C-
CDA)-based summary functionality could leave patients and caregivers
with technically complete but clinically fragmented information during
care transitions. Many of these commenters also expressed similar
concerns in relation to specific proposals, which we address in their
respective sections throughout this final rule.
A couple of commenters urged ONC to be mindful of financial and
workforce strain on rural and other low-resourced providers. Commenters
suggested ONC create grants for small and rural providers to implement
APIs and electronic health record upgrades. Another commenter requested
clarification on whether the rule limits State authority to require
certain standards if certification no longer guarantees certain
capabilities.
Response. We thank commenters for their feedback. We first clarify
that the removal of certain certification criteria does not limit State
authority as States remain able to establish their own requirements as
permitted by law. Generally, we note that these concerns are likely
mitigated by our final decisions to retain the majority of
certification criteria and to give additional transition time for
certain C-CDA certification criteria. In addition, we have further
addressed these comments in section III below as they relate to
specific proposals to remove criteria or functionality. We have also
addressed timelines for certification criteria relevant to the Medicare
Promoting Interoperability Program and the MIPS Promoting
Interoperability performance category in their respective sections.
We acknowledge commenters' concerns that capabilities no longer
included in the Certification Program could be offered as optional or
premium features. The purpose of the Certification Program is to
establish the minimum criteria that health IT must meet to obtain
certification. We do not believe that users will see a significant
increase in overall costs because the costs for certain functionalities
were likely included in the costs that customers currently pay to use a
particular certified Health IT Module. As noted by commenters,
functionalities associated with removed criteria were part of the
certified Health IT Module that a customer purchased or licensed for a
fee, which presumably included the costs of the functionality. To the
extent that health IT developers continue to charge for specified
functionalities, customers may now be able to see the cost of a
specific functionality independent of the certified Health IT Modules,
providing further price transparency to the decision-making and
purchasing processes.
Comments. Another commenter recommended that ONC provide technical
assistance and develop model contracting/procurement tools (e.g., model
contract language and BAA provisions) to help under-resourced providers
preserve capabilities if certification requirements are removed.
Response. While this comment is generally out of scope, we direct
readers to the EHR Contract Guide.\10\
---------------------------------------------------------------------------

\10\ <a href="https://healthit.gov/wp-content/uploads/2025/03/EHR_Contracts_Untangled.pdf">https://healthit.gov/wp-content/uploads/2025/03/EHR_Contracts_Untangled.pdf</a>.
---------------------------------------------------------------------------

Comments. A commenter suggested that ONC remove any certification
criteria by enforcement discretion to allow for maximum flexibility
rather than the proposed timelines to reduce confusion regarding the
timing of when to seek certification.
Response. In response to the commenter suggesting removing
certification criteria by enforcement discretion, we emphasize that use
of enforcement discretion does not remove a regulatory requirement.
Rather, it provides regulated entities with assurance that they will
not be found nonconformant or non-compliant with regulatory provisions
for a temporary period of time. Consideration of public feedback and
ultimately finality is achieved through notice and comment rulemaking.
Comments. Some commenters requested we publish a consolidated,
executable implementation plan or roadmap and guidance to transition to
HL7[supreg] FHIR[supreg], especially for rural providers, and State,
Tribal, Local, and Territorial (STLT) public health authorities (PHAs),
who remain dependent on C-CDA based criteria for data exchange. A
couple of commenters also recommended providing clear, consolidated
implementation guidance for ONC-ACBs and ONC-ATLs, particularly on the
operational side during the transition.
Response. We maintain a web page dedicated to HL7[supreg]
FHIR[supreg], which includes a draft FHIR Action Plan among many other
resources related to

[[Page 67924]]

HL7[supreg] FHIR[supreg] maturity and use cases.\11\ We also have an
upcoming planned regulatory action that will focus on HL7[supreg]
FHIR[supreg] based exchange.\12\ Ultimately, the regulatory process
provides for public input that informs actual requirements that can be
relied upon for investments and implementation.
---------------------------------------------------------------------------

\11\ <a href="https://healthit.gov/interoperability/investments/fhir/">https://healthit.gov/interoperability/investments/fhir/</a>.
\12\ <a href="https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0955-AA10">https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0955-AA10</a>.
---------------------------------------------------------------------------

D. Comments Beyond the Scope of Certification Program Proposals

Comments. We received numerous comments that were out of scope for
this rulemaking including, but not limited to, the following comments.
Some commenters recommended that our proposals for future API-focused
policies should require specification of endpoint discovery and
onboarding, implementation consistency, write capabilities, performance
expectations, alignment with existing frameworks and public health
workflows, as well as guardrails regarding fees, rate limiting,
contracting delays, and enforcement. A few of these commenters
recommended ONC to publish all regulated FHIR API endpoints in a single
publicly available location or directory.
Many commenters suggested additional future rulemaking goals and
policies including support for real-time bi-directional exchange,
standardized value sets, digital identity, and further support for
clinical efficiency, patient access, public health reporting, data
quality using rubrics and frameworks, quality measurement and
reporting, and bulk data access and support. Commenters also opined on
SI oversight, TEFCA policies, and CMS Programs.
Response. We thank commenters for their input and interest in
future rulemaking. These comments are out of scope for the Proposed
Rule in that we did not propose any new standard, certification
criteria, and requirements in this rulemaking. Comments regarding CMS
program requirements are also out of scope as ONC does not have direct
authority to change CMS policy. We refer readers to CMS programs for
further information.

III. Health Information Technology Standards, Implementation
Specifications, and Certification Criteria and Certification Programs
for Health Information Technology (Part 170)

Reading This Final Rule

In this preamble, we present our finalizations in an order that
begins with the certification criteria we finalized for removal and
subsequently the standards, definitions, and other related
Certification Program provisions finalized for removal or revision.
This approach should make it easier for readers to follow our finalized
Certification Program removals, in part, due to the natural cascading
effects of finalizing to remove or revise a certification criterion.
Additionally, we finalized the removal of standards when they are
no longer referenced by existing certification criteria. In very
limited circumstances, we retained a standard that is cross-referenced
in a certification criterion that we finalized for removal. We did this
because the standard is cross-referenced in another criterion and/or
supports health IT interoperability alignment. Further, as noted above,
we finalized the removal of certain Conditions and Maintenance of
Certification requirements and other Certification Program
requirements.
As stated above, for the purposes of this final rule, we have
reviewed and responded to comments on a narrowed set of proposals from
the Proposed Rule. Comments received in response to other Proposed Rule
proposals remain under review and consideration. The Proposed Rule
proposals not discussed in this final rule may, in the future, be
included in subsequent final rules or as revised proposals in
subsequent proposed rules.

RFI Feedback

Recently, the Office of Management and Budget (OMB), the
Department, and CMS-ONC issued requests for information (RFIs) related
to deregulation. We reviewed comments related to ONC. In response to
the CMS-ONC Request for Information; Health Technology Ecosystem (90 FR
21034) (CMS-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 SI 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 a focus on promoting standardized and scalable interoperability.
ONC addresses a number of these comments below, specifically the
suggestions to remove non-interoperability-focused and non-essential
certification criteria. Commenters were strongly supportive of our
focus on FHIR-based standards. Some commenters, however, included
suggestions related to new regulatory actions. As noted in the Proposed
Rule, these suggestions are out of scope for this deregulatory rule,
but we may consider the suggestions for a future rulemaking (90 FR
60979).

A. Certification Criteria for Health Information Technology

In this final rule we have identified certification criteria for
removal or revision. For some of the certification 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

[[Page 67925]]

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 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. 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 2024 shows that 99 percent
of hospitals and 91 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 99 and 91 percent of hospitals and
physicians, respectively. The certification criteria finalized for
removal or revision 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 the proposals we have finalized in detail in their respective
sections of the preamble and have provided a table (see Table 1) for a
list of all certification criteria finalized for removal and revision.
---------------------------------------------------------------------------

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

BILLING CODE 4150-45-P

[[Page 67926]]

[GRAPHIC] [TIFF OMITTED] TR28OC26.022

[[Page 67927]]

[GRAPHIC] [TIFF OMITTED] TR28OC26.023

BILLING CODE 4150-45-C
1. Clinical Certification Criteria
a. Clinical Decision Support
As of January 1, 2025, the ``clinical decision support'' (CDS)
certification criterion in Sec. 170.315(a)(9) is no longer available
in the Certification Program because it expired on January 1, 2025 (89
FR 1237). Therefore, in the Proposed Rule, we proposed to remove the
CDS certification criterion and reserve Sec. 170.315(a)(9) with an
effective date of a final rule (90 FR 60982).
Comments. Commenters who supported the proposal to remove the CDS
certification criterion shared that it would clean up outdated
requirements without affecting current certification pathways and
promote innovation given that the certification criterion has expired
or been superseded by decision support interventions.
Response. We thank the commenters for their support on this
proposal. We agree that removing Sec. 170.315(a)(9) from the CFR will
clean up outdated requirements without affecting current certification
pathways and will promote innovation.
Comments. Of the commenters who were not supportive of this
proposal, some expressed concerns that it would weaken patient safety
safeguards, reduce transparency and accountability, and shift oversight
and implementation burdens to providers and healthcare organizations.
Another commenter urged ONC to delay removal until 2028 to achieve
cross-agency, harmonized standards. Some commenters conveyed that our
proposal for removing the certification criterion would require
additional guidance or specification of how transparency requirements
would be preserved if Sec. 170.315(a)(9) is removed or if source
attribute requirements are removed from Sec. 170.315(b)(11).
Response. We thank the commenters for their feedback on this
proposal. In response to comments that appeared to connect our proposal
in Sec. 170.315(a)(9) with our proposals in Sec. 170.315(b)(11), we
remind readers that in the HTI-1 Final Rule we originally expired the
CDS certification criterion effective January 1, 2025 (89 FR 1430). At
the time, we declined commenters' request to extend the expiration date
noting that it will not move the Certification Program forward. CDS is
an expired certification criterion that is no longer available in the
Certification Program and health IT developers have been unable to
certify their health IT products to CDS since January 1, 2025.
Therefore, removing Sec. 170.315(a)(9) from the CFR will not result in
any further substantive effects, and delaying its removal is
unnecessary.
We appreciate commenters' requests for guidance. However, we do not
think guidance is necessary for the removal of an expired certification
criterion that is no longer a requirement for certification.
Comments. Some commenters requested that, despite its expiration,
we retain (i.e., not remove) the certification criterion in Sec.
170.315(a)(9), reinstate the certification criterion, or use the
requirements in the CDS certification criterion in Sec. 170.315(a)(9)
instead of the narrower DSI requirements in Sec. 170.315(b)(11) for
evidence-based CDS in order to preserve transparency.
Response. We thank the commenters for their suggestions. As noted
above, we did not propose in the HTI-5 Proposed Rule to reverse our
prior determination to remove the CDS certification criterion and/or
reinstate the CDS certification criterion. Further, in the HTI-1 Final
Rule, we stated that it is suitable to implement the CDS certification
criterion in Sec. 170.315(a)(9) in a revised version in Sec.
170.315(b)(11) due to the structure of the certification criterion, and
that this approach is more straight-forward than having substantially
similar yet separate certification criteria (89 FR 1237). Similarly, we
issued the Proposed Rule to reduce burden by eliminating redundant
requirements and to promote innovation (90 FR 60971). Consistent with
this approach, adopting a separate CDS certification criterion in Sec.
170.315(a)(9) with requirements similar to those in Sec.
170.315(b)(11)(iii), which we have revised but not removed from the
Certification Program (see section III.A.2.e), would undermine these
goals and would not serve the interests of the Certification Program or
users of certified health IT. Rather, it would recreate two
substantially similar but separate certification criteria, adding
complexity and burden to the Certification Program. Accordingly, we
have finalized the removal of Sec. 170.315(a)(9) CDS certification
criterion from the CFR and reserved that section as proposed as of the
effective date of this final rule.
In section III.A.2.e of this final rule, we note that we have
finalized removal of the requirements in Sec. 170.315(b)(11)(iv). As a
result, some elements that were similar between Sec. 170.315(a)(9) and
Sec. 170.315(b)(11)(iv) have been removed from the Certification
Program. As noted in that section of the preamble of this final rule,
we will take under consideration for future rulemaking whether such
elements of ``source attributes

[[Page 67928]]

transparency'' should be restored to the DSI certification criterion.
b. Family Health History
In the Proposed Rule (90 FR 60982 through 60983), we proposed to
remove the ``family health history'' certification criterion and
reserve Sec. 170.315(a)(12). We explained that 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). We noted that this certification
criterion is not included in the Base EHR definition in Sec. 170.102
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).
Therefore, we proposed a January 1, 2027, effective date for its
removal to allow sufficient time for CMS to update the CEHRT
definitions.
Comments. Some commenters expressed support for the proposal to
remove the family health history certification criterion. These
commenters agreed that the family health history functionality is
already well established in certified health IT and that it is likely
to remain available through existing product capabilities or evolving
data standards. Some commenters opined that exchange data standards can
replace ``functional'' certification requirements, and retaining the
family health history is duplicative of the requirements in USCDI v6.
Another commenter expressed that, with appropriate USCDI and
interoperability-based certification policies, removing the standalone
family health history certification criterion would not affect the
quality or integrity of the Certification Program. Another commenter
noted that retaining the certification criterion is unnecessary because
it is not cited in the Qualified EHR definition.
Response. We thank the commenters for their support of the
proposal. We appreciate the commenters feedback on the removal of this
certification criterion from the Certification Program. We have
finalized our proposal to remove the family health history
certification criterion from the CFR and we have reserved Sec.
170.315(a)(12), with an effective date of January 1, 2027. We address
other comments received on this proposal below.
Comments. The majority of comments received on our proposal to
remove the family health history certification criterion generally did
not support the proposal. Many commenters, including several community
health centers, expressed significant concerns that it would reduce
structured, standardized capture of family health history and thereby
impair interoperability, clinical decision support, preventive care,
and population health activities. Some commenters also raised concerns
that the proposal is premature, would increase manual burden, lead to
inconsistent implementations, and reduce data quality. Commenters also
asserted that removal could shift burden to health care providers.
Response. We thank commenters for their feedback. The retention of
the family health history certification criterion in the Certification
Program would not support our stated goal of advancing interoperability
because it is a non-FHIR-based certification criteria (90 FR 60972
through 60973) and only focuses on internal capabilities to record,
change, and access family health history according to the SNOMED
CT[supreg] U.S. Edition standard. However, we note that the removal of
the family health history certification criterion does not impact
existing functionality within implemented systems, and does not remove
the Family Health History data element from use and reference within
standards adopted for the Certification Program. Instead, the removal
of the family health history certification criterion is consistent with
our goal to transition to FHIR-based exchange, as demonstrated by the
inclusion of Family Health History data elements in USCDI v6 \14\ and
the HL7[supreg] FHIR[supreg] US Core Implementation Guide (IG) 9.0.0--
CI Build.\15\ Representing these data in FHIR as part of the US Core IG
is a more effective way to ensure these data are widely available not
only for access, but also for exchange and use to improve patient care.
This approach not only maintains but enhances the ability to leverage
family health history for clinical decision support, preventive care,
and population health activities by promoting standardized,
interoperable data exchange.
---------------------------------------------------------------------------

\14\ <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>.
\15\ <a href="http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core">http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core</a>.
---------------------------------------------------------------------------

As we discussed in the Proposed Rule, the functionality included in
the family health history certification criterion (capability to
capture family health history according to SNOMED CT[supreg] U.S.
Edition) has been widely adopted by hospitals and physicians (90 FR
60979 through 60980). Thus, we disagree that there is a shift in burden
from developers to health care providers because this functionality is
well-integrated into existing health IT products, and we do not
anticipate that health care providers will experience changes related
to this functionality in the health IT products they use.
Similarly, removing the family health history certification
criterion will have minimal impact on data consistency because many
developers of certified health IT will continue to conform to the
SNOMED CT[supreg] U.S. Edition standard and the functionality to code
family health history with this standard will likely remain in
certified health IT adopted by hospitals and physicians (90 FR 60982).
Moreover, the updates to USCDI v6 demonstrates ONC's commitment to the
exchange of family health history information using the SNOMED
CT[supreg] U.S. Edition standard. We note that while USCDI v6 has not
been adopted in regulation at this time, as of August 29, 2026, health
IT developers participating in the Certification Program may
voluntarily use the 2026 SVAP-approved standards, which include USCDI
v6, in their certified Health IT Modules.\16\ Accordingly, health IT
developers may voluntarily update their certified Health IT Modules to
USCDI v6 to support family health history information exchange (90 FR
60983).
---------------------------------------------------------------------------

\16\ See <a href="https://healthit.gov/blog/standards/advancements-in-health-it-oncs-2026-approved-svap-standards/">https://healthit.gov/blog/standards/advancements-in-health-it-oncs-2026-approved-svap-standards/</a>.
---------------------------------------------------------------------------

Regarding commenters' concerns about data quality related to
removing the family health history certification criterion, we clarify
that we work directly with HL7[supreg] to finalize HL7[supreg]
FHIR[supreg] US Core and C-CDA specifications for each published
version of USCDI, including USCDI v6. Where appropriate, these
specifications include standardized code systems, such as SNOMED
CT[supreg] U.S. Edition, that guide which values may be entered for
certain data fields. To further support implementation of USCDI v6, we
worked with HL7[supreg] to update the C-CDA validator and Inferno test
tools to align with USCDI v6 and to validate the quality of the data.
Consequently, not only will we continue to identify opportunities to
work with industry to improve data quality when we publish subsequent
versions of USCDI and other standard specifications, but we will also
continue to monitor and analyze approaches by health IT developers for
real world implementation.
Comments. Some commenters cautioned that the proposal to remove

[[Page 67929]]

this certification criterion may conflict with or complicate CMS
program requirements. A few commenters requested that we delay removal
until a later rulemaking or until at least 2028 to ensure alignment
with CMS between its program requirements and evolving ONC
certification criteria. Conversely, another commenter stated we should
adopt the removal effective on the effective date of a final rule
rather than delaying implementation. Some commenters requested that we
provide guidance and sufficient lead time for implementation.
Response. We thank commenters for their feedback regarding
alignment with CMS requirements and assure commenters that we work
closely with CMS across multiple programs and initiatives on aligning
program requirements and deadlines. Consistent with this coordination,
we note that in 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) 2027 Rates; Requirements for Quality Programs; and Other Policy
Changes'' \17\ proposed rule (FY 2027 IPPS/LTCH PPS proposed rule), CMS
proposed to remove the reference to Sec. 170.315(a)(12) in the CEHRT
definition in 42 CFR 495.4 (91 FR 19620). On August 4, 2026, CMS
published a final rule entitled ``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) 2027 Rates; Requirements for Quality Programs; and
Other Policy Changes; and Adoption of Updated Versions of Certain
Health Information Technology Standards'' \18\ (FY 2027 IPPS/LTCH PPS
final rule) and finalized the proposed update to the CEHRT definition
effective upon the effective date of the FY 2027 IPPS/LTCH PPS final
rule (91 FR 50034 through 50035). CMS also proposed to revise paragraph
(2) of the CEHRT definition in 42 CFR 414.1305 to remove reference to
Sec. 170.315(a)(12) in the ``Medicare and Medicaid Programs; CY 2027
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''
proposed rule (CY 2027 PFS proposed rule) (91 FR 43842), which is
applicable to the MIPS Promoting Interoperability performance category
(91 FR 44169 through 44171). As noted in the Proposed Rule, removing
the family health history certification criterion, which does not
support a specific CMS program measure, from the Certification Program
effective January 1, 2027, provides sufficient time for CMS to update
the CEHRT definitions to remove any reference to the certification
criterion and allows for alignment with CMS programs (90 FR 60983).
Because it is necessary to provide this lead time to CMS and health
care providers participating in CMS programs, we decline the
recommendation to shorten the effective date timeframe. We will
continue to coordinate with CMS on the finalization of proposed updates
to regulations as well as future proposals to ensure alignment with the
policies we have finalized in this final rule, as well as issuing
relevant guidance and informational materials.
---------------------------------------------------------------------------

\17\ ``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) 2027 Rates; Requirements for Quality Programs; and Other
Policy Changes.'' (91 FR 19312) <a href="https://www.federalregister.gov/d/2026-07203/p-2659">https://www.federalregister.gov/d/2026-07203/p-2659</a>.
\18\ ``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) 2027 Rates; Requirements for Quality Programs; Other
Policy Changes; and Adoption of Updated Versions of Certain Health
Information Technology Standards.'' (91 FR 49570). <a href="https://www.federalregister.gov/documents/2026/08/04/2026-15833/medicare-program-hospital-inpatient-prospective-payment-systems-for-acute-care-hospitals-ipps-and">https://www.federalregister.gov/documents/2026/08/04/2026-15833/medicare-program-hospital-inpatient-prospective-payment-systems-for-acute-care-hospitals-ipps-and</a>.
---------------------------------------------------------------------------

Comments. Some commenters expressed opinions regarding the burden
reduction that would result from removing this specific certification
criterion. These commenters stated that, in practice, the proposal
likely does not significantly reduce burden for health IT developers
because of the inclusion of the Family Health History data elements in
USCDI v6.
Response. We thank the commenters for their input on the burden
reduction associated with removing this certification criterion. We
acknowledge that removal of the family health history certification
criteria may not result in a significant burden reduction. However, the
removal of the family health history certification criteria will result
in some burden reduction because health IT developers with Health IT
Modules certified to Sec. 170.315(a)(12) will no longer need to go
through the process of certification to a standalone criterion and
maintain updates and conformance to the certification criterion. We
maintain that even a modest reduction in burden is more beneficial than
maintaining the certification criterion, and removal can still lead to
improved efficiency and cost savings over time. We refer readers to
section VII (Regulatory Impact Analysis) for a full discussion on the
costs and benefits of our finalized deregulatory actions.
Comments. Several commenters raised concerns about liability
exposure as a specific consequence if family history is harder to
locate and tied this concern to the possibility of missing clinically
significant risk factors.
Response. We thank the commenters for expressing their concerns
regarding potential liability exposure if family health history becomes
more difficult to obtain, particularly as it relates to the
identification of clinically significant risk factors. While we note
that whether or not commenters will be exposed to further liability is
a question that is outside the scope of this rulemaking, we do not
agree that such family health history data would be ``harder to
locate'' because of removal of the family health history certification
criterion, as we noted the functionality has widespread implementation
and the Family Health History data element is referenced within the
USCDI v6 for representation and exchange.
c. Implantable Device List
In the Proposed Rule, we proposed to remove and reserve the
``implantable device list'' (IDL) certification criterion in Sec.
170.315(a)(14) (90 FR 60983). The IDL 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. The IDL certification criterion is included in the Base
EHR definition, and we proposed 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 the Proposed Rule). We proposed to make these
changes effective as of the effective date of the final rule (90 FR
60984).
Comments. Of the commenters that specifically commented on this
criterion, commenters were generally supportive of removal of the
certification criterion, noting that the functionality is well-
established, included in USCDI, and that removal would streamline the
Certification Program without sacrificing interoperability.
Response. We thank the commenters for expressing their support to
remove the IDL certification criterion. We have not, however, finalized
our proposal to

[[Page 67930]]

remove the IDL certification criterion (Sec. 170.315(a)(14)) nor any
related proposals such as removing the IDL certification criterion from
the Base EHR definition.
Comments. Commenters who were not supportive of removing the IDL
certification criterion expressed concerns that removal of the
criterion would undermine interoperability, create inconsistency in
implementation, and jeopardize patient safety.
Response. We thank the commenters for expressing their concerns,
but presume these concerns are moot since we are not removing the IDL
certification criterion. Therefore, we are not specifically addressing
these concerns.
After publication of the Proposed Rule, CMS proposed, in the FY
2027 IPPS/LTCH PPS proposed rule, to adopt the ``Unique Device
Identifiers (UDIs) for Implantable Medical Devices'' measure within the
Public Health and Clinical Data Exchange objective for eligible
hospitals and CAHs participating in the Medicare Promoting
Interoperability Program. CMS stated that this measure would foster
consistent workflows for capturing device data as discrete EHR elements
and strengthen the ability of eligible hospitals, CAHs, beneficiaries,
and public health agencies to use interoperable health information to
improve outcomes, manage risk, and respond rapidly to device-related
safety concerns. (91 FR 19629 through 19631). CMS proposed that an
eligible hospital or critical access hospital (CAH) must use CEHRT to
electronically capture and store, as one or more discrete data elements
within the patient's electronic health record, the complete UDI, which
includes the device identifier and, when present on the device label,
the production identifier, for each implantable medical device subject
to UDI requirements used for patient care delivery. CMS proposed to
require eligible hospitals and CAHs to attest to this measure beginning
with the EHR reporting period in CY 2027.
In its proposed rule, CMS noted that there are numerous health IT
certification criteria that reference UDI, including the IDL
certification criterion in Sec. 170.315(a)(14) (91 FR 19631). CMS
stated this certification criterion would be required to support the
measure. CMS also highlighted our proposal to remove the IDL
certification criterion in the Proposed Rule (90 FR 60983) and stated
that if ONC finalizes removal of the IDL certification criterion then
CMS would not reference the IDL certification criterion as required to
support the measure. CMS explained that, separate from the dedicated
IDL certification criterion, the UDI is a named data element within the
USCDI v3 as the ``Unique Device Identifier(s) for a patient's
implantable device(s).'' CMS noted that UDI is therefore a supported
element within the HL7[supreg] FHIR[supreg] US Core Implementation
Guide STU 6.1.0 FHIR IG and Health IT Modules certified to the
``standardized API for patient and population services'' certification
criterion (Sec. 170.315(g)(10)) must be capable of providing any UDI
information available in response to requests for patient data. CMS
also identified the standardized API for patient and population
services criterion as required to support fulfillment of the measure,
which is also part of the Base EHR definition in Sec. 170.102 and thus
already incorporated into the CEHRT definition at 42 CFR 495.4. CMS
welcomed comments as to whether other certification criteria should be
considered to support this measure.
In the 2027 IPPS/LTCH PPS final rule, CMS adopted the Unique Device
Identifiers for Implantable Medical Devices measure within the Public
Health and Clinical Data Exchange objective as proposed (91 FR 50055).
Many commenters supported CMS's proposal to adopt the measure, noting
that recording UDI in EHRs would improve post-market surveillance and
care coordination, reduce patient safety risks, and enable faster, more
accurate public health responses (91 FR 50057). However, another
commenter expressed concern with ONC's proposal to remove the IDL
certification criterion, stating that removal could impact performance
on the Unique Device Identifiers for Implantable Medical Devices
measure (91 FR 50060).
After consideration of the public comments CMS received, CMS
finalized its proposal to adopt the Unique Device Identifiers for
Implantable Medical Devices measure beginning with the EHR reporting
period in CY 2027 (91 FR 50060). In response to comments regarding
potential removal of the IDL certification criterion, CMS stated its
belief that health IT functionality related to UDI access, storage, and
exchange would continue to be maintained because other certification
criteria under the Certification Program continue to reference or
support exchange of UDI for implantable devices, including the
``standardized API for patient and population services'' certification
criterion (91 FR 50060). CMS also noted that removal of the specific
IDL certification criterion would not preclude health IT developers
from continuing to support Access GUDID lookup, device attribute
display, validation, or related functionality. CMS further stated that
it would continue to coordinate with ONC and monitor implementation to
ensure that hospitals and CAHs have appropriate certified health IT
capabilities to support UDI capture and exchange (91 FR 50060).
ONC and CMS are committed to ensuring ongoing support for UDI-
related functions. In order to more fully support the new Unique Device
Identifiers (UDIs) for Implantable Medical Devices measure within the
Public Health and Clinical Data Exchange objective in the Medicare
Promoting Interoperability Program, we have not finalized our proposal
to remove the IDL certification criterion from the Certification
Program. In addition, as noted above, we have not finalized our
proposal to remove Sec. 170.315(a)(14) from the Base EHR definition
(please see section III.C.1 of this final rule). Therefore, health IT
developers will need to continue to certify their health IT to the IDL
certification criterion and maintain certification to the IDL
certification criterion to meet the Base EHR definition. In addition,
eligible hospitals and CAHs attesting to the new Unique Device
Identifiers (UDIs) for Implantable Medical Devices measure will
continue to have the IDL functionality because, as noted above, the IDL
certification criterion is included in the Base EHR definition and thus
already incorporated into the CEHRT definition.
Comments. Some commenters noted that finalization of our proposal
would require additional guidance or specification of how certified
health IT should continue to support functionality such as standardized
parsing of UDIs and retrieval of device attributes from GUDID
(including SNOMED CT[supreg]-encoded information).
Response. Having not finalized our proposal, the IDL certification
criterion remains part of the Certification Program and all relevant
guidance for compliance with the criterion is still applicable such as
the IDL Certification Companion Guide.\19\
---------------------------------------------------------------------------

\19\ <a href="https://healthit.gov/test-method/implantable-device-list/">https://healthit.gov/test-method/implantable-device-list/</a>.
---------------------------------------------------------------------------

2. Care Coordination Certification Criteria
a. Transitions of Care
We proposed 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. The transitions of care criterion
supports the ability to create,

[[Page 67931]]

send, and receive care summaries and referral summaries to ensure
continuity and care coordination as patients move between providers (90
FR 60984). We proposed 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. We proposed 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 proposed to remove the
requirements in Sec. 170.315(b)(1)(ii)(B) and (C). We also proposed 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 proposed to
remove the references to Sec. 170.205(a)(3) and to replace the
references to Sec. 170.205(a)(5), which expired on January 1, 2026,
with references to Sec. 170.205(a)(6).
Comments. The majority of commenters were not supportive of our
proposal to revise the transitions of care certification criterion to
remove or narrow C-CDA creation and transmission capabilities for
transitions of care/referral summaries, primarily due to concerns about
timing and readiness with respect to transitioning to FHIR-based
document exchange for transitions of care. Many commenters stated that
C-CDA-based document exchange is still widely used, and some stressed
that certain settings, including long-term and post-acute care (LTPAC),
behavioral health, small, rural and safety net providers, are
particularly reliant on C-CDA-based document exchange in current
transitions of care workflows. Several commenters expressed concerns
that both C-CDA and Direct secure messaging serve as core national
exchange mechanisms at this time. Several commenters stated that
readiness for FHIR-based exchange is uneven across settings, and thus
the proposal could increase disparities. Several commenters stated that
C-CDA-based document exchange functions as the current means of sharing
structured health information with dental providers, who are less FHIR-
ready. Another commenter noted that many public health systems are
dependent on C-CDA-based document exchange and may face data quality or
compatibility challenges without a viable alternative. Many commenters
stressed that there is currently no mature and broadly adopted FHIR-
based replacement for C-CDA-based document exchange and had concerns
that without a replacement, removal of C-CDA creation and transmission
capabilities would weaken interoperability, increase burden, disrupt
care coordination, and increase patient safety risks. Additionally,
many commenters expressed concern that there is no phased migration
plan, readiness criteria, sunset roadmap, or clear bridge between
current C-CDA-based document exchange requirements and future FHIR-
based exchange requirements. Several commenters stated that C-CDA-based
document exchange remains a necessary backup, and several stated that
C-CDA-based document exchange supports migration to FHIR.
Response. We thank commenters for expressing their concerns
regarding FHIR readiness and the removal of the current C-CDA-based
document exchange requirements in Sec. 170.315(b)(1). We appreciate
the concerns expressed by commenters about the impact the proposal
would have on C-CDA-based document exchange, which continues to be
widely used, particularly in specific settings, as well as the impact
on Direct secure messaging. We have reconsidered our proposed policy
and have decided to finalize our proposal with modification by
extending the timeline for removing the Direct requirements and the C-
CDA-based document exchange requirements in Sec. 170.315(b)(1) to
January 1, 2030. Specifically, we have finalized our proposed removal
of Sec. 170.315(b)(1)(i) ``send and receive via edge protocol,'' Sec.
170.315(b)(1)(iii) ``create,'' Sec. 170.315(b)(1)(ii)(B) ``display,''
and Sec. 170.315(b)(1)(ii)(C) ``display section views'' with an
effective date of January 1, 2030. We have finalized the proposed
removal of references to Sec. 170.205(a)(3) in Sec. 170.315(b)(1)(ii)
and replacement of references to Sec. 170.205(a)(5) in Sec.
170.315(b)(1)(ii) with references to Sec. 170.205(a)(6) as of the
effective date of this final rule. We have not finalized the proposed
renaming of the criterion and renumbering of the requirements in Sec.
170.315(b)(1)(ii)(A). We note that in the Proposed Rule we did not
propose to remove references to Sec. 170.205(a)(3) or replace
references to Sec. 170.205(a)(5) with references to Sec.
170.205(a)(6) in Sec. 170.315(b)(1)(ii)(B) and (C) and in Sec.
170.315(b)(1)(iii) because we proposed to remove Sec.
170.315(b)(1)(ii)(B) and (C) and Sec. 170.315(b)(1)(iii) entirely.
However, because we have not finalized our proposal to remove Sec.
170.315(b)(1)(ii)(B) and (C) and Sec. 170.315(b)(1)(iii) as of the
effective date of a final rule, but the references to Sec.
170.205(a)(3) and (5) remain outdated, we have finalized removal of
references to Sec. 170.205(a)(3) and replacement of references to
Sec. 170.205(a)(5) with references to Sec. 170.205(a)(6) in Sec.
170.315(b)(1)(ii)(B) and (C) and in Sec. 170.315(b)(1)(iii) as of the
effective date of this final rule, similar to how we proposed and
finalized removal of references to Sec. 170.205(a)(3) and replacement
of references to Sec. 170.205(a)(5) with references to Sec.
170.205(a)(6) in Sec. 170.315(b)(1)(ii).
Delaying the effective date of removal of Sec. 170.315(b)(1)(i)
``send and receive via edge protocol'' and Sec. 170.315(b)(1)(iii)
``create'' to January 1, 2030, helps address commenter concerns
regarding our proposed removal of C-CDA-based standards requirements
and Direct secure messaging requirements from the Certification
Program. Significant advances are occurring in the development and
adoption of FHIR-based standards, and the revised deadline of January
1, 2030, allows for a more gradual and achievable adoption of FHIR-
based exchange. In response to concerns regarding C-CDA being
considered a necessary backup, we note that while we anticipate that
the extended timeline will allow increased adoption of FHIR-based
exchange, the removal of C-CDA-based exchange requirements in Sec.
170.315(b)(1) does not prevent the use of C-CDA-based exchange
standards where necessary for users. In response to comments expressing
concerns regarding the lack of a phased transition plan or roadmap for
moving from C-CDA-based exchange to FHIR-based exchange, we note that
providing this extended deadline will serve as a helpful timeline and
migration pathway for moving from C-CDA-based document exchange to
FHIR-based document exchange. Additionally, ONC will continue to
provide resources related to transitioning to FHIR-based exchange.
Comments. There were multiple comments about timing challenges, and
a number of commenters recommended extending the deadline for removal
of C-CDA-based document exchange requirements in Sec. 170.315(b)(1).
Several commenters urged ONC to adopt FHIR-based exchange standards for
transitions of care prior to removing C-CDA-based document exchange
requirements. Another commenter stated that the proposed January 1,
2027, deadline for removing Sec. 170.315(b)(1)(i) would

[[Page 67932]]

require new developers to meet the requirements of Sec.
170.315(b)(1)(i) for potentially just a portion of a year before they
would need to transition to a FHIR-based exchange alternative. The
commenter recommended allowing developers who are actively developing
certified health IT to be allowed to meet the new proposed Sec.
170.315(b)(1) requirements rather than fully implement the current
Sec. 170.315(b)(1)(i) requirements for a short compliance period.
Response. We thank commenters for expressing their timing concerns,
including the January 1, 2027, deadline for removal of C-CDA-based
document exchange requirements in the proposed rule and the need for
more time for movement away from C-CDA-based document exchange toward
FHIR-based exchange. In order to provide more time for transition away
from C-CDA based document exchange requirements, we have extended the
deadline for removal of Sec. 170.315(b)(1)(i) and (iii) to January 1,
2030. We note that this extension would also address concerns regarding
new developers having to meet the current requirements in Sec.
170.315(b)(1)(i) for less than a year before the requirements are
revised.
Comments. A number of commenters expressed concerns that the
proposal to remove C-CDA-based document exchange requirements could
create interoperability gaps and fragmentation. Some commenters
expressed concern that developers would implement these functions less
consistently, stop supporting them altogether, or charge more for them
once certification no longer required them.
Response. We appreciate these concerns from commenters about
interoperability gaps and fragmentation as well as the concerns about
developers not providing support for C-CDA-based document exchange or
charging more for such support. As stated above, we have extended the
deadline for removal of certain C-CDA-based requirements in the
transitions of care certification criterion in Sec. 170.315(b)(1).
This extension will limit the potential for providers to experience
extra charges or reduced support from developers for C-CDA-based
exchange. Additionally, because the certification criterion in Sec.
170.315(b)(1) is widely adopted, we do not anticipate interoperability
gaps as more developers move to FHIR-based exchange, nor do we
anticipate that developers would cease supporting functionality for
transitions of care after the January 1, 2030, expiration date due to
the removal of certain C-CDA-based requirements in the certification
criterion.
Comments. A number of commenters expressed concern that the
proposal to remove C-CDA-based document exchange requirements would
result in increased burden. Some commenters stated that testing,
validation, troubleshooting, integration, and governance burdens would
move to providers, health information exchange (HIE) or health
information network (HIN) operators, public health agencies, or shared
service networks. Another commenter stressed that if certification no
longer covers create and send capabilities, then implementation
consistency may degrade and may increase downstream burden. Some
commenters stated that the proposal could result in a return to manual
workflows, likely increasing errors, delays, and administrative burden.
Some commenters stated that the proposal could result in added fees
from developers for C-CDA-related capabilities, unwanted technology
changes, or adoption of technology that was not ready.
Response. We thank commenters for expressing these concerns about
increased burden and fees. We recognize the importance of ensuring that
additional burden is not placed on providers when removing requirements
related to C-CDA-based document exchange. As stated previously, we have
extended the deadline for removal of certain C-CDA-based requirements
in the transitions of care certification criterion in Sec.
170.315(b)(1) to January 1, 2030. This extension provides additional
time for more achievable and broader adoption of FHIR-based exchange,
and as such we do not anticipate significantly increased burden on
providers or added fees for capabilities that are not required by a
certification criterion.
Comments. A number of commenters expressed concerns about patient
safety risks and impact on care coordination. Some commenters stated
the proposed removal of C-CDA-based document exchange requirements
could result in various issues related to continuity of care, including
missing or delayed clinical context during care handoffs, adverse
events, readmissions, and mortality. Some commenters stated that
removing transitions of care criterion requirements weaken the
Certification Program's role as a national safety and accountability
floor. Several commenters stated that the proposal directly threatens
patient safety in LTPAC settings and emphasized the high-risk nature of
transitions of care.
Response. We appreciate these comments regarding patient safety and
care coordination, especially in particular settings. We understand the
importance of making sure that health information is exchanged safely
and reliably during transitions of care. We have extended the deadline
for the removal of certain C-CDA-based document exchange requirements
in the transitions of care certification criterion in Sec.
170.315(b)(1) to January 1, 2030. This extension will allow more time
for certified health IT to move away from C-CDA-based standards and for
more achievable adoption of FHIR-based exchange. We do not anticipate
that this transition would negatively impact interoperability during
transitions of care and thus endanger patients or increase safety
risks. Also, the certification criterion in Sec. 170.315(b)(1) is
widely adopted, and we do not anticipate patient safety risks due to
developers ceasing to support this certification criterion
functionality after the January 1, 2030, expiration date of certain C-
CDA-based document exchange requirements.
Comments. A number of commenters expressed concern about patient
matching. Many of these commenters stated that removing ``create''
requirements in Sec. 170.315(b)(1)(iii) would essentially eliminate
the only certification criterion requirement that explicitly relates to
patient matching and could thus increase the risk of misidentification
and create issues regarding patient safety, privacy, billing, and care
coordination.
Response. We thank commenters for sharing these concerns regarding
the impact of our proposal on patient matching capabilities in
certified health IT. We disagree that Sec. 170.315(b)(1)(iii) is the
only certification criterion in the Certification Program that relates
to patient matching and that could be used to ensure appropriate
support for the data elements needed for effective patient matching.
For example, Sec. 170.315(g)(10) requires support for the data
elements needed for effective patient matching, including the exchange
of USCDI data elements for patient name, date of birth, and address.
Comments. Several commenters expressed concern about the proposed
removal of requirements related to Direct and edge protocol, which were
described as still necessary for security purposes.
Response. We thank commenters for these comments and appreciate
these concerns. We have extended the deadline for the removal of the
``send and receive via edge protocol'' requirements in the transitions
of care certification criterion in Sec. 170.315(b)(1)(i) to January 1,
2030. We anticipate that the extended time for

[[Page 67933]]

removal of the requirements will allow for more achievable and broader
adoption of secure FHIR-based exchange, which we believe will alleviate
concerns about impacts to security.
Comments. Some commenters expressed concerns about alignment with
CMS and other Federal or State programs built around C-CDA or Direct
workflows with some mentioning State program submission requirements,
HIE/HIN enabled exchange, TEFCA-related exchange, and other Federal
program dependencies.
Response. We thank commenters for these comments regarding
alignment with Federal and State programs. With respect to the Medicare
Promoting Interoperability Program for eligible hospitals and CAHs and
the Promoting Interoperability performance category of MIPS, the
certification criterion in Sec. 170.315(b)(1) is currently 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 HIE Bi-
directional Exchange and Enabling Exchange under TEFCA measure.
In the FY 2027 IPPS/LTCH PPS proposed rule (91 FR 19312), CMS
proposed to remove the Support Electronic Referral Loops by Sending
Health Information and Support Electronic Referral Loops by Receiving
and Reconciling Health Information measures beginning with the EHR
reporting period in calendar year 2028 (91 FR 19622). In the FY 2027
IPPS/LTCH PPS final rule, which appeared in the Federal Register on
August 4, 2026, CMS finalized these proposals with modification,
finalizing removal of the measures from the Medicare Promoting
Interoperability Program beginning with the EHR reporting period in CY
2029 (91 FR 49570). However, our final policy to delay removal of
certain requirements in the criterion in Sec. 170.315(b)(1) from the
CFR will extend the period during which the currently available set of
certified functionality is available to support the actions identified
in the measure. We will continue to coordinate with CMS on the
finalization of this policy to ensure alignment around the requirements
of these measures and certification criteria available in the
Certification Program.
We note that, as of the publication date of this final rule, CMS
has not proposed to revise or remove the Support Electronic Referral
Loops by Sending Health Information and Support Electronic Referral
Loops by Receiving and Reconciling Health Information measures from the
Promoting Interoperability performance category of MIPS. With respect
to State program requirements, we note that nothing in our finalized
policy would prevent a user of certified health IT from following
requirements established for State programs or from using HIE/HIN
enabled exchange.
Comments. Several commenters stated that the proposal was not the
best way to reduce burden and that burden reduction could come from
removing duplicative testing elsewhere, especially regarding Sec.
170.315(e)(1), or by changing the testing approach.
Response. We appreciate these comments regarding reducing burden by
removing duplicative testing elsewhere. In section III.A.5.a of this
final rule we discuss proposed revisions to Sec. 170.315(e)(1), and we
note that while we revised the criterion, we did not propose removal
for burden reduction purposes. However, in section III.A.7.f of this
final rule, we have finalized our proposal to remove the certification
criterion in Sec. 170.315(g)(6) for burden reduction purposes. This
reduces burden because Sec. 170.315(g)(6) is a conditional, secondary
C-CDA implementation requirement that is applied to health IT for which
certification to a primary C-CDA-based certification criterion is
sought and would require duplicative testing to the ability to generate
and format C-CDA files.
Comments. Several commenters expressed support for the proposal.
These commenters stated that the proposal reduced burden and was
consistent with a FHIR-forward, deregulatory approach. Some commenters
stated that the criterion was duplicative and added complexity without
benefit. Several commenters noted that the testing tool was not user-
friendly.
Response. We thank commenters for expressing their support for this
proposal. We agree with commenter assessments that the proposal will
reduce burden and encourage movement toward FHIR-based exchange. We
have finalized the proposal with modifications. We have extended the
effective date of our proposed revisions to Sec. 170.315(b)(1) to
January 1, 2030, with the exception of the removal of references to
Sec. 170.205(a)(3) and replacement of references to Sec.
170.205(a)(5) with references to Sec. 170.205(a)(6), which we have
finalized as of the effective date of a final rule. We have not
finalized the proposed renaming of the criterion and renumbering of the
requirements in Sec. 170.315(b)(1)(ii)(A).
Comments. Several commenters identified issues that were out of
scope for our proposal, such as broader patient-matching legislation or
standards, proposals to strengthen the criterion, support for Qualified
Health Information Network (QHIN) participation, a proposal for new
certification requirements to create a FHIR-based summary of care for
transitions of care, and proposals for future recognition of additional
specialty-specific FHIR implementation guides.
Response. We thank commenters for these comments. However, these
comments were outside the scope of this rulemaking.
b. Clinical Information Reconciliation and Incorporation
We proposed 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 in C-CDA format 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 in the
Medicare Promoting Interoperability Program and the MIPS Promoting
Interoperability performance category for the Support Electronic
Referral Loops by Receiving and Reconciling Health Information measure
and also is 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.\20\
---------------------------------------------------------------------------

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

Comments. The majority of commenters were not supportive of
removing the CIRI certification criterion in Sec. 170.315(b)(2),
generally due to concerns about timing and FHIR readiness. Commenters
expressed concern that FHIR-based alternatives are not yet mature,
adopted, or available across all care settings. Several commenters
stated that existing C-CDA-based document exchange remains foundational
and often the only

[[Page 67934]]

mechanism available in many settings. Another commenter stated that
EHRs must be able to generate and transmit C-CDA documents in order for
many receiving systems to incorporate any data at all. Several
commenters stated that small, rural, safety-net, behavioral health,
LTPAC, and other settings with limited resources are less ready and
able to move to FHIR-based standards and could thus face wider
disparities. Some commenters expressed concern about the lack of a
phased plan or roadmap for transitioning to FHIR-based standards, and
some commenters urged timeline extensions for transition. There were
also several comments that removal of the criterion prior to a FHIR-
based replacement being widely available would create a regulatory gap,
and commenters expressed concern that external data may remain siloed,
duplicative, incomplete, or inaccurately incorporated. Additionally,
commenters expressed concern that a gap due to lack of a FHIR-based
replacement would weaken baseline safety and interoperability
protections, increase manual reconciliation burden, shift
administrative burden to clinicians and providers that still rely on
existing exchange workflows, and create risks for care coordination,
transitions of care, and patient safety. Several commenters recommended
ONC delay removal or adopt a phased transition to FHIR-based exchange
instead, and another commenter recommended that ONC retain the CIRI
certification criterion in Sec. 170.315(b)(2) as a functional
requirement, thus allowing developers more flexibility in adopting
FHIR-based solutions.
Response. We appreciate these concerns regarding FHIR readiness and
removal of the current C-CDA-based document exchange requirements in
Sec. 170.315(b)(2) prior to a mature and widely adopted FHIR-based
alternative being in place. Additionally, we understand that C-CDA-
based document exchange is currently widely used, particularly in
certain settings. Further, we appreciate the concerns expressed by
commenters that due to a perceived lack of mature and widely adopted
FHIR-based replacements, removal of the criterion in Sec.
170.315(b)(2) could increase manual reconciliation burden and shift
administrative burden to clinicians and providers. We also appreciate
the recommendation to consider retaining the certification criterion in
Sec. 170.315(b)(2) as a functional requirement and agree that would
provide developers of certified health IT more flexibility to adopt
FHIR-based solutions.
We have reconsidered our proposed policy and have not finalized
complete removal of the certification criterion in Sec. 170.315(b)(2).
Instead, we have reduced the burden for certification to this criterion
and increased flexibility for certification. First, we have provided
that health IT can demonstrate conformance with the criterion in a
broader range of workflows instead of only upon receipt of a transition
of care/referral summary. For example, health IT could demonstrate the
ability to reconcile information according to the certification
criterion's requirements when received from a patient, during internal
patient transitions within a health care system, or when a patient is
discharged to any external entity. Second, we have finalized removal of
the references to standards for exchanging electronic health
information in Sec. 170.315(b)(2), thus making it a functional
criterion, effective with the effective date of this final rule. Last,
we have finalized the removal of the requirement to simultaneously
display the data from at least two sources in a manner that allows a
user to view the data and their attributes. We believe this finalized
policy will not result in provider burden from manual reconciliation or
provider burden from increased cost for electronic reconciliation
functions, and at the same time will allow movement toward innovative,
FHIR-based solutions. Additionally, as noted in the Proposed Rule (90
FR 60984) and discussed in more detail in a comment response below, the
criterion in Sec. 170.315(b)(2) is required for certain CMS measures,
and maintaining it as a functional criterion ensures that certified
functionality is available to support the actions identified in those
measures.
We have finalized removal throughout Sec. 170.315(b)(2) of the
requirements to use the content exchange standards and implementation
specifications specified in Sec. 170.205(a)(3), (4), and (6) for
exchanging electronic health information, as well as made conforming
revisions for clarity and readability related to the removal of
references to those standards. As noted above, we have also finalized
removal of references to the standard in Sec. 170.205(a)(5) which
expired on January 1, 2026. In addition, we have finalized removal of
the requirement to simultaneously display (i.e., in a single view)
information received from another source. We believe removal of this
requirement is consistent with our objective of providing greater
flexibility under the criterion while reducing unnecessary burden. We
understand that the simultaneous display requirement may, in some
cases, have constrained the development and implementation of improved
workflows. We are also aware that some health IT developers are
pursuing more automated approaches to reconciliation, including
approaches for data received from trusted sources. Accordingly, we
expect removal of this requirement will afford health IT developers
greater flexibility to design and implement more efficient and
innovative reconciliation workflows that better support clinician
users, including automated approaches to reconciliation. As finalized,
the criterion requires the ability to match data received from a
transition of care/referral summary or other workflow with the correct
patient; create a single reconciled list of medications, allergies and
intolerances, and problems; enable user review and validation of the
accuracy of a final set of data; and upon a user's confirmation,
automatically update the list and incorporate medications, allergies
and intolerances, and problems expressed according to, at a minimum,
the version of the standard in Sec. 170.213. We note that we do not
expect that a health IT developer with a Health IT Module currently
certified to Sec. 170.315(b)(2) would need to make any changes to the
certified Health IT Module to meet the revised criterion, because if a
health IT developer's Health IT Module was previously conformant to the
certification criterion in Sec. 170.315(b)(2), then the Health IT
Module would also be conformant to the revised criterion. Since we have
not removed this certification criterion in its entirety, we have made
the revisions effective with the effective date of this final rule.
This will provide health IT developers with the discussed flexibility
and reduced burden as soon as practical.
Comments. Many commenters expressed concerns about patient safety.
A number of commenters had concerns that removal of the certification
criterion in Sec. 170.315(b)(2) could compromise patient safety during
transitions of care and medication reconciliation. Several commenters
stated that removal of the certification criterion would weaken care
coordination, continuity of care, referrals, and integrated or team-
based care. Multiple commenters stated that certification was like a
national safety floor or baseline safeguard and removing the criterion
would reduce accountability, transparency, uniformity, and assurance
that

[[Page 67935]]

important capabilities remain available, ultimately impacting patient
safety. Another commenter stated that removing the certification
criterion could reduce motivation to provide or use reconciliation
functionality uniformly, which could affect accurate quality reporting.
Response. We appreciate commenter concerns regarding patient
safety, and we understand the importance of ensuring that health
information is exchanged reliably during transitions of care and
reconciliation. We have not finalized complete removal of the
certification criterion in Sec. 170.315(b)(2) as proposed and instead
have finalized removal of the requirements in Sec. 170.315(b)(2) to
use the content exchange standards and implementation specifications in
Sec. 170.205(a)(3), (4), and (6) for exchanging electronic health
information, thus making it a functional criterion. We believe this
addresses concerns from commenters by ensuring that certified health IT
has the capability of reconciling and incorporating patient health
information appropriately.
Comments. There were a number of comments related to burden. Many
commenters stated that the proposal would increase manual
reconciliation, transcription, and workflow burden on clinicians and
staff. A commenter stressed that when certified health IT lacks
reliable reconciliation functionality, reconciliation burden is shifted
directly onto physicians and clinical staff, increasing manual work,
workflow inefficiencies, and the risk of incomplete or inaccurate
records. Another commenter stated that removing the certification
criterion in Sec. 170.315(b)(2) would remove the expectation that
reconciliation is supported and increase reliance on manual
transcription, significantly raising the risk of errors. Some
commenters stated that removal of the certification criterion would
shift verification, compliance, operational burden, and in some cases
liability from developers or government to providers, and some stressed
that this would especially impact small, independent, and rural
practices that rely on certified systems to meet regulatory, reporting,
and security obligations.
Response. We thank commenters for expressing their concerns that
removal of the certification criterion in Sec. 170.315(b)(2) would
shift burden to providers. We appreciate the importance of not
increasing burden on providers or introducing manual workflows. We have
not finalized complete removal of the certification criterion in Sec.
170.315(b)(2) as proposed and instead have finalized removal of the
requirements in Sec. 170.315(b)(2) to use content exchange standards
and implementation specifications for exchanging electronic health
information, thus making it a functional criterion. We believe this
addresses these burden-related concerns from commenters by ensuring
that certified health IT has the capability to reconcile and
incorporate patient health information electronically.
Comment. There were several comments about timing, and commenters
generally stated that the proposed timing was too aggressive, allowed
insufficient time to transition to FHIR-based standards, and provided a
poorly defined path from current C-CDA-based requirements.
Response. We appreciate concerns regarding the timeline of the
proposal and the need for additional time to transition to FHIR-based
solutions. We have not finalized removal of the certification criterion
in Sec. 170.315(b)(2) as proposed and instead have finalized removal
of the requirements in Sec. 170.315(b)(2) to use content exchange
standards and implementation specifications for exchanging electronic
health information, thus making it a functional criterion. We believe
this in effect provides additional time for the transition to FHIR-
based solutions while at the same time ensuring that certified health
IT maintains the capability to appropriately reconcile and incorporate
patient health information electronically.
Comments. Several commenters expressed concerns about aligning with
CMS. Another commenter stated that the current proposed timelines would
not give CMS time to determine if Promoting Interoperability measures
require changes and, if changes are required, it would be impossible
for health IT developers to have the changes in place by the start of
the 2027 Promoting Interoperability reporting performance year,
resulting in significant additional burden for hospitals and providers
participating in these programs.
Response. We thank commenters for these comments regarding
alignment with CMS. Currently, the certification criterion in Sec.
170.315(b)(2) is required by CMS 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 (see
86 FR 45490 and 87 FR 49330-49331, respectively) and the MIPS Promoting
Interoperability performance category (see 85 FR 84889 and 87 FR 70084,
respectively). We have not finalized removal of the certification
criterion in Sec. 170.315(b)(2) as proposed and instead have finalized
revisions to Sec. 170.315(b)(2) to make it a functional criterion,
thus ensuring that certified functionality is available to support the
actions identified in the CMS measures noted above. Therefore, we do
not anticipate that our finalized policy will require any changes to
the references to this certification criterion in either the Medicare
Promoting Interoperability or MIPS programs.
Comments. There were several comments rejecting the ``widespread
adoption'' rationale for removing a certification criterion. Commenters
stated that adoption results from certification is not uniform across
settings and may not persist after deregulation. Another commenter
stated that ONC has not provided data demonstrating that these
capabilities are uniformly implemented across all practice sizes,
specialties, and healthcare settings and that ``widespread'' among
large health systems is not the same as ``widespread'' among small
practices, rural clinics, behavioral health providers, or SI health
applications. Several commenters stated that market incentives do not
guarantee continued support and that functionality could become an add-
on, be left unmaintained, or be sunset. Another commenter stated that
removing certification does not create incentives for improvement but
instead risks stagnation.
Response. We thank commenters for these comments regarding our
rationale for proposing removal of certification criteria that have
been widely adopted. In the Proposed Rule, we explained how we
determined which certification criteria could be considered ``widely
adopted'' (90 FR 60979 through 60980). We also referenced recent Real
World Testing results regarding routine use of the certification
criterion in Sec. 170.315(b)(2) that demonstrate its widespread
implementation and use in certified health IT at this time and indicate
that the functionality is not likely to be removed (90 FR 60985). While
we maintain that the current broad adoption and use of CIRI
capabilities would ensure retention of that functionality in certified
health IT, we have not, as discussed in detail above, finalized removal
of the certification criterion in Sec. 170.315(b)(2) as proposed. This
action provides further assurance that this functionality

[[Page 67936]]

will be maintained in certified health IT.
Comments. Some commenters expressed support for removal or
simplification of the certification criterion in Sec. 170.315(b)(2),
stating that it is widely adopted, overly prescriptive, and could
permit more flexible and innovative approaches.
Response. We thank commenters for their support of our proposal. We
agree with commenters that removal of the criterion in Sec.
170.315(b)(2) would provide room for innovation in this space. However,
the finalized functional requirement in Sec. 170.315(b)(2) also will
give health IT developers greater flexibility to adopt FHIR-based
solutions and innovative approaches, while at the same time ensuring
that certified health IT maintains the capability to appropriately
reconcile and incorporate patient health information electronically.
Comments. Several commenters expressed concerns that the
certification criterion does not address automated or computational
reconciliation or define guardrails for SI-assisted reconciliation,
human review, auditability, and accountability.
Response. We thank commenters for these comments. While automated,
computational, or SI-assisted reconciliation could be workflows and
technology used to now meet the requirements of this certification
criterion, we did not propose to make them functionalities required to
meet the criterion. We also did not propose any form of ``guardrails''
(e.g., human review or auditability) for inclusion in the CIRI
certification criterion. Therefore, these recommendations are generally
outside the scope of this rulemaking, and we decline to adopt them in
this final rule.
c. Security Tags--Summary of Care
We proposed 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 are designed to 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 or CEHRT definitions. We proposed 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 this final rule.
Comments. The majority of commenters were not supportive of
removing 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), primarily
due to concerns that C-CDA-based standards are still widely used at
this time and FHIR-based standards are not sufficiently mature or
widely adopted. Commenters were concerned that there was not an
adequate replacement in place, and many opposed removal of the
certification criteria without a transition plan, clear alternative
pathway, or FHIR-based replacement. Commenters expressed concerns that
removal of the criteria without an adequate replacement would weaken
privacy protections for sensitive data, increase variability in
implementation, and create risks of over-sharing, under-sharing, or
manual workarounds during exchange and transitions of care. A commenter
stated that readiness to transition to FHIR is uneven across care
settings and that removal without sufficient transition time could
increase interoperability gaps, reduce transparency into whether
certified technology works reliably across settings, and worsen
disparities. Some commenters noted that certain settings have resource
limitations and would benefit from retaining the criteria or delaying
removal. Several commenters stressed that current C-CDA-based exchange
still has meaningful utility and value during the transition to FHIR-
based approaches. Some commenters recommended changing certification to
attestation or keeping the criteria optional while more progress is
made on FHIR standards, and some recommended retaining the criteria or
extending timelines for removal. Several commenters recommended a
transition plan to minimize disruption and ensure that segmentation
capabilities are not lost and that consent and restricted data
indicators continue to function consistently across networks.
Response. We appreciate the concerns raised regarding the removal
of the C-CDA-based security tags criteria in Sec. 170.315(b)(7) and
(b)(8). We recognize that C-CDA-based standards are frequently used for
health information exchange at this time; however, as we stated in the
Proposed Rule, there has been limited certification to the security
tags criteria in Sec. 170.315(b)(7) and (8) (90 FR 60985). We believe
this indicates that the criteria are not as beneficial as some
commenters suggest, thus lacking sufficient value as part of the
Certification Program, and that there is promising movement toward
FHIR-based solutions in the industry (90 FR 60985). We have heard
repeatedly that the criteria present implementation challenges and are
not effective in managing complex sensitive data. We appreciate that
technical solutions to issues around patient consent and data
segmentation are notoriously challenging and that current technology
does not allow for segmenting specific health data and controlling its
disclosure in a way that matches most expectations. Removal of these
under-adopted certification criteria from the Certification Program
will allow for greater focus on the continued development of a robust
and effective FHIR-enabled data privacy and segmentation standard. We
believe this focus can lead to more innovation in this area and enable
us to propose more effective solutions in the future. Finally, we note
that where users are successfully implementing C-CDA based data tagging
solutions, including those that have been certified, our removal of the
voluntary criteria from the Certification Program does not necessitate
removal of such functionality from implemented systems or real world
use. We are simply no longer certifying such technology by any means,
including through attestation,\21\ as we believe the burden on the
Certification Program and health IT developers to be greater than the
benefit derived specifically from certification to these criteria.
Accordingly, we have finalized removal of the criteria as proposed.
We reassure commenters that we support and encourage technical
approaches that offer patients a range of consent choices,\22\ as we
have noted in

[[Page 67937]]

prior rulemaking exploring both the C-CDA and the FHIR Data
Segmentation for Privacy (DS4P) standards and related security label
taxonomy (See for example 89 FR 1299 through 1305). We intend to
maintain our focus on this area in future rulemaking as well as in our
work with standards development organizations and health IT innovators.
For example, ONC's Leading Edge Acceleration Projects (LEAP) in Health
IT program has supported efforts around scalable consent frameworks for
the advancement of interoperability with FHIR-based APIs.\23\ With
respect to comments regarding a transition plan or alternative pathway,
we note that the C-CDA exchange requirement in Sec. 170.315(b)(1)
would remain in effect until January 1, 2030, providing a clear
transition period for developers to support continued use of the
security tag capabilities where implemented by users for C-CDA document
exchange. We reiterate that the removal of the certification criteria
does not necessitate removal of the functionality from health IT
systems for users who may have these functions implemented, nor does it
prohibit continued use of the referenced standards in existing and new
health IT implementations.
---------------------------------------------------------------------------

\22\ We note that for purposes of this discussion, when we
discuss ``consent'' and technical approaches to the electronic
capture, management, and exchange of patient consent preferences or
information in accordance with those preferences, we are addressing
technical capabilities, controls, and engineering that may support
permissions required under a range of applicable laws, including
HIPAA authorizations, consents required under 42 CFR part 2, or
State law, and other individual, patient-facing or patient-directed
privacy choices, restrictions, or preferences about the disclosure,
release, and/or sharing of their information under applicable law.
Additionally, for purposes of this discussion, ``computable
consent'' refers to automated, standards-driven, consent capture,
management, and exchange, including both system-side consent
automation and patient-facing request capabilities.
\23\ See <a href="https://healthit.gov/interoperability/investments/leap/2019-leap-health-it-projects/">https://healthit.gov/interoperability/investments/leap/2019-leap-health-it-projects/</a> and <a href="https://healthit.gov/blog/onc-funding/san-diego-health-connect-takes-a-big-leap-over-the-barrier-of-consent-management/">https://healthit.gov/blog/onc-funding/san-diego-health-connect-takes-a-big-leap-over-the-barrier-of-consent-management/</a>.
---------------------------------------------------------------------------

Comments. A number of commenters noted that the security tags
criteria in Sec. 170.315(b)(7) and (8) are the only existing mechanism
in the Certification Program to support the segmentation of sensitive
health information and had concerns about removal. Several commenters
stressed that the criteria are still needed to protect especially
sensitive categories of information, including behavioral health,
substance use disorder, and adolescent data, and that removal could
limit participation in health information exchange. Some commenters
expressed concerns that removing the criteria would lower the security
floor for health IT and create more variability in whether and how
segmentation tags and security tags are implemented. Several commenters
stated that removal of the criteria could increase the risk of over-
sharing, under-sharing, or unauthorized sharing of data, especially
during referrals and transitions of care. Another commenter stated that
removal could encourage under-documentation or make records less
reliable if providers avoid documenting sensitive information or rely
on nonstandard workarounds.
Response. We appreciate concerns that the security tags criteria in
Sec. 170.315(b)(7) and (8) are the only criteria in the Certification
Program that support data segmentation and the protection of sensitive
health information. As stated above, we support and encourage technical
approaches that allow for the electronic capture, management, and
exchange of an individual's consent preferences and offer patients a
range of choices related to the use and sharing of health information
under applicable law. We also note promising industry initiatives in
this area, including an increasing availability of consent management
tools on the market as well as State and HIE/HIN efforts to advance
consent management approaches.\24\
---------------------------------------------------------------------------

\24\ See for example the CRISP Consent Tool at <a href="https://www.crisphealth.org/consent-tool/">https://www.crisphealth.org/consent-tool/</a>, Washington's Consent Link project
at <a href="https://www.hca.wa.gov/about-hca/programs-and-initiatives/clinical-collaboration-and-initiatives/electronic-consent-management">https://www.hca.wa.gov/about-hca/programs-and-initiatives/clinical-collaboration-and-initiatives/electronic-consent-management</a>, and the Shift Sandbox at <a href="https://www.shiftinterop.org/our-work/the-shift-sandbox/">https://www.shiftinterop.org/our-work/the-shift-sandbox/</a>.
---------------------------------------------------------------------------

Comments. Several commenters expressed concern that patients may
disengage from or lose trust in health information exchange if
computable privacy controls are unavailable. Some commenters expressed
concern that removal of the criteria could erode public trust. Some
commenters expressed concern that patients with sensitive health
information may be harmed or avoid care if the criteria are removed.
Response. We thank commenters for expressing these concerns and
understand how critical it is to ensure patient trust in the electronic
exchange of health information. As noted above, we support initiatives
exploring the capture, management, and exchange of patient consent
preferences. Additionally, we note that as described in detail in
section III.A.4 of this final rule, we have retained the privacy and
security certification criteria in Sec. 170.315(d) and the associated
Privacy and Security Certification Framework under Sec. 170.550(h)
that we had proposed to remove in the Proposed Rule. We appreciate the
concern that patients may disengage or lose trust in health information
exchange if computable privacy controls are unavailable. Research
indicates that public expectations and preferences for what
``computable privacy controls'' should deliver are growing,\25\ and we
believe that neither Sec. 170.315(b)(7) nor Sec. 170.315(b)(8) are
optimal approaches to meeting those expectations. As document-based
approaches tied to summary record exchange, these criteria are not
aligned with granular controls pertaining to the release of
information, as an individual would expect from modern API-based
interactions. Again, we note that removal from the program does not
necessitate removal from systems where the standards and functionality
have been successfully implemented. Based on input from clinicians and
health IT developers, we do understand that some such implementations
exist although they are not widely in use. We believe that ongoing
development in FHIR can better meet growing public expectations.
---------------------------------------------------------------------------

\25\ Kassam I, Ilkina D, Kemp J, Roble H, Carter-Langford A,
Shen N. (2023). Patient Perspectives and Preferences for Consent in
the Digital Health Context: State-of-the-art Literature Review.
Journal of Medical Internet Research, 25, Article e42507. <a href="https://doi.org/10.2196/42507">https://doi.org/10.2196/42507</a>.
---------------------------------------------------------------------------

Comments. Several commenters stated that developers may
deprioritize segmentation capabilities or create proprietary, non-
interoperable segmentation and consent solutions if the certification
expectation is reduced or removed.
Response. We appreciate these concerns regarding potential actions
of developers to deprioritize segmentation capabilities due to removal
of the security tags criteria in Sec. 170.315(b)(7) and (8). However,
as previously noted, these criteria are not included in the Base EHR or
CEHRT definitions, and have not been required to meet any measures
under the Medicare Promoting Interoperability Program or the Promoting
Interoperability performance category of MIPS. The inclusion of these
criteria in the Certification Program has not driven uptake within the
industry, in large part because prioritization of these functionalities
that are generally held to be only partially effective would divert
resources from other efforts that may have greater efficacy. We
understand the importance of ensuring the appropriate capture,
management, and exchange of patient consent preferences. As described
above, we believe that removal of the certification criteria in Sec.
170.315(b)(7) and (8) will allow more space for innovation in this
area, and we intend to maintain a focus on supporting and encouraging
technical approaches that offer patients a range of consent choices,
including in future rulemaking.
Comments. A number of commenters expressed concerns about burden
and warned that removing this functionality without a mature
replacement would shift burden to providers. Some commenters stated
that removal of the criteria could result in manual redactions based on
patient preference, separate documentation, manual

[[Page 67938]]

collation, and other workarounds that would shift work to providers and
staff.
Response. We appreciate these comments regarding burden shifting
due to removal of the security tags criteria in Sec. 170.315(b)(7) and
(8) and we understand the importance of not increasing burden on
providers. We reiterate that we have heard repeatedly that the criteria
present implementation challenges, are not meeting expectations, and
are not effective in managing the sharing and/or release of complex
sensitive data. Additionally, we note that certification to the
criteria is voluntary, and as mentioned in the Proposed Rule and above,
few Health IT Modules are currently certified to the criteria (90 FR
60985). Therefore, due to the small number of products certified to
these criteria and low implementation, we do not expect that removal of
these criteria will result in a significant burden shift to providers.
We believe that removal of the security tags criteria in Sec.
170.315(b)(7) and (8) will allow health IT developers and others in
industry to move toward more effective technical solutions in this
space, and we will continue to support and encourage technical
approaches that enable operationalizing patient choices, including
through future rulemaking.
Comments. Several commenters rejected ``low uptake'' as a
sufficient reason for removal, arguing that the underlying privacy need
remains. Another commenter stated that low adoption is not a valid
reason to remove protections when an underlying need persists.
Response. We thank commenters for these comments regarding the low
level of certification to the security tags criteria in Sec.
170.315(b)(7) and (8). As stated above, we believe the relatively small
number of products certified to these criteria indicates that they do
not have sufficient value to the users or implementers. In addition to
the low level of certification, we have received multiple complaints
that the criteria present implementation challenges and can be
ineffective, which also influenced our proposal to remove these
criteria. For example, industry has reported that security labels
required by Sec. 170.315(b)(7) and (8) can be difficult to use
consistently because different systems may label, interpret, and
enforce sensitive information differently, which limits how reliably
those labels protect data when information is exchanged between
organizations.\26\ We agree with commenters that privacy needs are
important to address. We believe that removal of the security tags
criteria in Sec. 170.315(b)(7) and (8) will allow health IT developers
and industry to develop and adopt more effective solutions in this
space, and we will continue to focus on identifying and supporting
technical approaches that enable a range of consent choices.
---------------------------------------------------------------------------

\26\ Sarabu C, Sharko M, Petersen C, Galvin H. (2023). Shifting
into Action: from Data Segmentation to Equitable Interoperability
for Adolescents (and Everyone Else). Applied Clinical Informatics,
14(3), 544-554. <a href="https://doi.org/10.1055/s-0043-1769924">https://doi.org/10.1055/s-0043-1769924</a>.
---------------------------------------------------------------------------

Comments. A commenter stated that maintaining these voluntary
criteria would not add burden but would continue to signal the
importance of a standards-based approach to computable consent.
Response. We thank the commenter for this comment, and we agree
that standards-based approaches to computable consent are very
important. As stated above, ONC supports initiatives working to improve
the capture, management, and exchange of patient consent preferences,
and we note promising growth in industry initiatives in this area and
an increasing availability of consent management tools. We support and
encourage technical solutions that enable computable consent, and we
intend to maintain a focus on this issue in future rulemaking.
Comments. A commenter had concerns about alignment with CMS and
recommended delaying removal of these criteria until at least 2028 so
that ONC can work with CMS to ensure alignment between its program
requirements and evolving ONC certification criteria.
Response. We thank the commenter for this comment. We note that
currently there are no CMS requirements requiring health care providers
to adopt or use health IT certified to the certification criteria in
Sec. 170.315(b)(7) and (8). We do not believe that removal of these
criteria will lead to regulatory alignment concerns for health care
providers participating in CMS programs. Additionally, we note that the
criteria are not included in the definition for Base EHR at 45 CFR
170.102.
Comments. Some commenters expressed support for removal, noting
that the criteria have had low adoption and limited real-world utility.
Response. We thank commenters for these comments in support of our
proposal to remove the security tags criteria in Sec. 170.315(b)(7)
and (8). We agree with commenters that the criteria have been poorly
adopted and have limited utility. We have repeatedly heard complaints
that the criteria present implementation challenges and can be
ineffective. We have finalized the proposal to remove the security tags
criteria in Sec. 170.315(b)(7) and (8) as of the effective date of a
final rule.
d. Care Plan
We proposed to remove the ``care plan'' certification criterion in
Sec. 170.315(b)(9) and reserve that section as of the effective date
of a final rule. The certification criterion in Sec. 170.315(b)(9)
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.
As of September 2026, 48 unique Health IT Modules are certified to
the criterion in Sec. 170.315(b)(9) out of a total of 714 active and
non-suspended certifications listed on the Certified Health IT Product
List (CHPL),\27\ indicating low interest by health IT developers in
certifying to this criterion. We also noted in the Proposed Rule that
the industry is moving away from C-CDA-based standards to the use of
FHIR-based standards, and we highlighted the development of FHIR-based
care plan implementation guides (IGs), including the Multiple Chronic
Condition eCare Plan and the Electronic Long Term Services & Support
Care Plan IGs (90 FR 60986). Additionally, we noted input from industry
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 (90 FR 60986).
---------------------------------------------------------------------------

\27\ <a href="https://chpl.healthit.gov">https://chpl.healthit.gov</a> search conducted September 2026.
---------------------------------------------------------------------------

Comments. The proposal received relatively few comments, and the
majority of commenters were not supportive of removing the care plan
certification criterion in Sec. 170.315(b)(9), primarily due to
concerns that FHIR adoption and readiness were uneven and immature and
there was not a viable replacement standard or plan for transitioning
to FHIR. Commenters noted a lack of widespread use of FHIR push
capabilities, interoperability issues with legacy systems, uneven
adoption of FHIR across organizations, maintenance burdens, and
inconsistent use of terminologies and value sets as examples of FHIR
challenges and readiness issues. Commenters expressed

[[Page 67939]]

concerns that removing a criterion that relies on C-CDA-based standards
at a time when FHIR-based standards are not mature and widely adopted
would weaken care coordination, increase patient safety risks, and
exacerbate interoperability gaps during the transition from C-CDA-based
exchange to FHIR-based exchange. Several commenters cautioned that
removing this requirement prematurely could increase administrative
burden, create fragmentation across care settings, and
disproportionately affect rural, small, safety net, dental, and other
providers that continue to rely on existing C-CDA-based document
exchange. Several commenters stressed that some settings were less
ready to transition to FHIR, such as LTPAC, behavioral health, small,
rural, safety-net, and dental settings, and that removal of the
criterion could widen interoperability gaps and disparities.
Response. We thank commenters for expressing these concerns
regarding the removal of the care plan certification criterion in Sec.
170.315(b)(9). We appreciate the points expressed by commenters that
FHIR-based alternatives are not mature and widely available at this
time and that certain settings are not ready to transition to FHIR.
However, we note that the care plan certification criterion in Sec.
170.315(b)(9) is just one of several certification criteria in the
Certification Program that require use of C-CDA-based document exchange
standards. The transitions of care certification criterion in Sec.
170.315(b)(1) includes C-CDA-based requirements, and as discussed
earlier in section III.A.2.a, we have extended the timeline for
removing the C-CDA-based creation and transmission requirements in
Sec. 170.315(b)(1) until January 1, 2030. Also, we are retaining the
requirements in Sec. 170.315(b)(1)(ii)(A) to validate C-CDA
performance beyond January 1, 2030. We believe this addresses commenter
concerns regarding the removal of C-CDA-based requirements from the
Certification Program. Further, as we noted in the Proposed Rule,
adoption of the certification criterion in Sec. 170.315(b)(9) is
currently very low and removal of the certification criterion would
help promote greater innovation and advancement in this area (90 FR
60986). Given these factors, we have finalized the removal of the
criterion in Sec. 170.315(b)(9) as of the effective date of this final
rule as proposed.
Comments. Several commenters expressed concerns about patient
safety and stated that removal of the criterion could result in
incomplete, delayed, lost, duplicated, or insufficiently supported
health information. Several commenters stated that the criterion was
still viewed as providing baseline safeguards and that removal could
lead to degradation, inconsistency, loss of capability, or less
transparency about whether certified tools perform reliably.
Response. We appreciate commenter concerns about patient safety,
and we understand the importance of ensuring that health information is
exchanged reliably as part of patient care and care coordination. As
stated above, we note that the care plan certification criterion in
Sec. 170.315(b)(9) is not the only certification criterion in the
Certification Program that requires use of C-CDA-based standards and
helps ensure reliable exchange of clinical data for patient care. The
transitions of care certification criterion in Sec. 170.315(b)(1)
includes C-CDA-based requirements, and as discussed earlier in section
III.A.2.a, we have extended the timeline for removing the C-CDA-based
creation and transmission requirements in Sec. 170.315(b)(1) until
January 1, 2030. This extension should provide time for certified
health IT to move from C-CDA-based standards to FHIR-based standards
for exchange without sacrificing patient safety and help address
commenter concerns. Also, we are retaining the requirements in Sec.
170.315(b)(1)(ii)(A) to validate C-CDA performance beyond January 1,
2030. We do not believe it is necessary to also maintain requirements
in Sec. 170.315(b)(9) because health IT developers are likely to
continue supporting C-CDA-based exchange under Sec. 170.315(b)(1),
which also contains requirements to support C-CDA document templates.
Additionally, as we stated in the Proposed Rule, we do not believe that
health IT developers are likely to cease supporting the functionality
in Sec. 170.315(b)(9) if the criterion is removed from the
Certification Program (90 FR 60986). We also note that USCDI v3
includes data elements supporting the exchange of the components of a
care plan, including Problems, Clinical Tests, Procedures, and Patient
Goals. Additionally, USCDI v6 adds a Care Plan data element, and the
USCDI standard follows the Standards Version Advancement Process (SVAP)
to allow health IT developers to update their systems to newer version
of USCDI and provide these updates to their customers.\28\ We note that
beginning August 29, 2026, health IT developers participating in the
Certification Program may voluntarily use the 2026 SVAP-approved
standards, which include USCDI v6, in their certified Health IT
Modules.\29\
---------------------------------------------------------------------------

\28\ See <a href="https://isp.healthit.gov/united-states-core-data-interoperability-uscdi#uscdi-v6">https://isp.healthit.gov/united-states-core-data-interoperability-uscdi#uscdi-v6</a>.
\29\ See <a href="https://healthit.gov/blog/standards/advancements-in-health-it-oncs-2026-approved-svap-standards/">https://healthit.gov/blog/standards/advancements-in-health-it-oncs-2026-approved-svap-standards/</a>.
---------------------------------------------------------------------------

Comments. Several commenters stated that removal of the
certification criterion in Sec. 170.315(b)(9) without ensuring support
for the functionality while transitioning to FHIR could shift burden to
providers, clinicians, and system administrators. Commenters stated
that this could result in manual workflows, manual transcription, and
added operational burden, especially for smaller or under-resourced
practices.
Response. We thank commenters for expressing these concerns about
burden and appreciate the importance of not imposing additional burden
on providers. As stated above, we have extended the deadline for
removal of C-CDA-based creation and transmission requirements in the
transitions of care certification criterion in Sec. 170.315(b)(1), and
this extension will provide time for certified health IT to move from
C-CDA-based standards to FHIR-based standards without significantly
increasing burden on providers. We do not believe it is necessary to
also maintain requirements in Sec. 170.315(b)(9) because health IT
developers are likely to continue supporting C-CDA-based exchange under
Sec. 170.315(b)(1). Further, as discussed above we do not believe that
health IT developers that currently support this functionality are
likely to cease supporting the functionality in Sec. 170.315(b)(9) if
the criterion is removed from the Certification Program, and therefore
we do not anticipate additional burden on providers associated with
removal of the criterion or a shifting of burden to providers.
Comments. Several commenters disagreed that vendors would
voluntarily keep the same functionality after deregulation and stated
that vendors may stop maintaining the functionality, let the
functionality become obsolete, or charge extra for the functionality.
Another commenter stressed that the care plan criterion was one of the
few certification signals to developers that care planning matters and
recommend that ONC identify alternative pathways to accelerate adoption
of care planning functionality.
Response. We appreciate these concerns from commenters regarding
developers ceasing to support C-CDA-based exchange and care plan
documents or charging more for the functionality. We understand the
importance of ensuring that support for C-CDA-based exchange and Care
Plan

[[Page 67940]]

functionality is continued during a transition to FHIR-based exchange.
However, because this functionality is so widely adopted, we are not
persuaded that developers will cease supporting C-CDA-based exchange
and care plan documents, or charge more for such functionality, due to
removal of the criterion in Sec. 170.315(b)(9). As stated above, other
certification criteria in the Certification Program also require use of
C-CDA-based standards, including the transitions of care certification
criterion in Sec. 170.315(b)(1), and can help ensure support of C-CDA-
based standards during a transition from C-CDA-based exchange to FHIR-
based exchange. We have extended the deadline for removal of C-CDA-
based creation and transmission requirements in the transitions of care
certification criterion in Sec. 170.315(b)(1) to January 1, 2030. We
do not believe it is necessary to also maintain requirements in Sec.
170.315(b)(9) because health IT developers are likely to continue
supporting C-CDA-based exchange under Sec. 170.315(b)(1). Regarding
alternative means of encouraging care planning functionality, we note
that USCDI v3 includes data elements supporting the exchange of the
components of a care plan, including Problems, Clinical Tests,
Procedures, and Patient Goals, and that USCDI v6 includes a Care Plan
data element.
Comments. Some commenters stated that our proposal for removing the
care plan certification criterion and related C-CDA-based certification
criteria would require transition timelines and additional guidance and
safeguards to ensure continued baseline functionality. Commenters
requested phased or delayed implementation, clearer transition
strategies, support for participation in national exchange frameworks,
or replacement criteria, such as FHIR-based care plan requirements,
before removing the existing criterion.
Response. We appreciate these concerns from commenters regarding
the need for timelines, strategies and resources related to
transitioning from C-CDA-based exchange to FHIR-based exchange. We also
understand the importance of ensuring that support for care plan
functionality is continued during a transition to FHIR-based exchange.
As stated above, we have extended the deadline for removal of C-CDA-
based creation and transmission requirements in the transitions of care
certification criterion in Sec. 170.315(b)(1) to January 1, 2030. This
extension helps provide a timeline and pathway for transition to FHIR
for developers of certified health IT. As stated earlier, we do not
feel it is necessary to also maintain requirements in Sec.
170.315(b)(9) because health IT developers are likely to continue
supporting C-CDA-based exchange under Sec. 170.315(b)(1).
Additionally, we will continue to provide resources related to
transitioning to FHIR-based exchange on our website. Regarding
replacement criteria, we did not propose a FHIR-based replacement for
the certification criterion in Sec. 170.315(b)(9), and therefore, we
are not finalizing a FHIR-based replacement here. However, as we stated
in the Proposed Rule, there have been advancements in this area, and we
may consider whether to propose a replacement in future rulemaking (90
FR 60986). We also note that USCDI v6 includes a Care Plan data
element, which we believe may alleviate some of commenters' concerns
regarding lack of continuity for care plans.
Comments. A commenter had concerns about CMS alignment.
Response. We thank the commenter for this comment. We note that
currently there are no CMS requirements requiring health care providers
to adopt or use health IT certified to the certification criterion in
Sec. 170.315(b)(9). Therefore, we do not believe that removal of this
criterion will lead to regulatory alignment concerns for health care
providers participating in CMS programs.
Comments. Commenters who supported removal of the care plan
criterion stated that it would reduce burden and that the criterion is
no longer tied to active regulatory program requirements or widely
used. These commenters noted that the criterion had been associated
with the Comprehensive Primary Care Plus (CPC+) program, which is no
longer active, and that its removal would not compromise Certification
Program integrity.
Response. We thank commenters for these comments in support of the
proposal. We agree with commenters that removal of the certification
criterion in Sec. 170.315(b)(9) will reduce burden, including costs to
maintain certification. We also agree with commenters that the
certification criterion in Sec. 170.315(b)(9) is no longer associated
with an active CMS program or other incentive program and that removal
will not compromise Certification Program integrity. We have finalized
the proposal to remove the certification criterion in Sec.
170.315(b)(9) as of the effective date of a final rule as proposed.
e. Decision Support Interventions
We proposed to revise the ``decision support interventions'' (DSI)
certification criterion in Sec. 170.315(b)(11) in order to reduce
burden and promote innovation of SI in healthcare (90 FR 60986 through
60988). 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 (PDSIs) and enabling users'
access to transparent information on DSI performance and quality. In
particular, the source attribute requirements in Sec. 170.315(b)(11)
support ``model cards'' for PDSIs, which essentially function as
nutrition labels and provide important information for providers using
a PDSI, such as how a PDSI's algorithm was trained, its intended use
and limitations, and how it performs across different patient groups.
However, as discussed in more detail below, we did not find that users
of certified health IT have relied on these requirements to review such
information or that the requirements have positively impacted patient
care (90 FR 60987). We have finalized removal of the requirements
related to ``model cards'' as well as other revisions for the reasons
discussed in detail below.
We proposed 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), and we proposed to redesignate
the certification criterion requirement currently in Sec.
170.315(b)(11)(ii)(C) as Sec. 170.315(b)(11)(ii)(B). We also proposed
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 this final rule. Additionally, we proposed 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. Finally, we proposed 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)

[[Page 67941]]

regarding intervention risk management for predictive DSIs.
Comments. A large majority of commenters were not supportive of our
proposal, primarily due to concerns about removing DSI transparency and
risk-management requirements in Sec. 170.315(b)(11). Concerns included
that reducing transparency and accountability for SI-enabled tools
would shift evaluation, governance, and liability burdens to providers
and health systems and undermine patient safety, clinician trust, and
the ability to evaluate bias, performance, and appropriateness. Many
commenters expressed concerns that eliminating ``model card''
requirements in Sec. 170.315(b)(11) was premature since the
requirements have been in effect for less than two years and have not
been fully evaluated. Commenters stated that removal of the model card
requirements would create a significant regulatory gap in SI governance
at a time when SI adoption is accelerating. Some commenters stated that
providers would lose important information about intended use,
provenance, training data, limitations, performance, and known risks.
Some commenters stated that the loss of information would make it more
difficult to determine the appropriateness of a tool for particular
patient populations or settings. Another commenter noted that in
behavioral health and substance use cases, reduced transparency may
complicate safe and lawful use of tools that process sensitive
information, creating confidentiality and compliance concerns. Several
commenters noted as a distinct benefit of model cards or source
attribute disclosures that funding-source disclosures help detect
hidden commercial or pharmaceutical influence on CDS recommendations.
Over half of the commenters expressing concerns about transparency
wanted ONC to retain the model cards requirements, or the full
criterion, while the other commenters with transparency concerns wanted
some form of guardrails even if model card requirements are removed.
Commenter suggestions for guardrails included establishing voluntary
transparency standards, creating a voluntary transparency designation
for predictive SI, retaining the useful elements of predictive DSI
transparency and risk management requirements, retaining the criterion
in Sec. 170.315(a)(9), clarifying developer responsibilities related
to transparency, acknowledging transparency as a best practice, or
public model cards as a means of ensuring transparency.
Response. We appreciate these commenter concerns and understand the
importance of ensuring appropriate transparency around decision support
interventions. However, as we stated in the Proposed Rule, 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 DSIs (90 FR 60987). Further, we have
identified no evidence through peer reviewed publication or trade press
indicating that users of certified health IT have relied on the
transparency requirements in Sec. 170.315(b)(11) to access, record, or
modify source attributes, or that the requirements have led to positive
impacts on patient care (90 FR 60987). We have also found no evidence
that source attribute transparency requirements in Sec. 170.315(b)(11)
have improved healthcare delivery organizations' evaluation and
effective use of SI (90 FR 60987). We believe that we have had a
sufficient amount of time to evaluate the effectiveness of the
transparency requirements in Sec. 170.315(b)(11), including via peer
reviewed publication, articles in the press, and reports from
developers of health IT, and are not persuaded of their value,
particularly given the feedback we have received from developers that
the requirements are burdensome and detrimental to innovation (90 FR
60987). We do, however, believe it is important to continue to ensure
the ability for users to leverage health IT for clinical decision-
making and to select both evidence-based and predictive DSIs, and we
encourage users of certified health IT to discuss SI quality and
performance before deploying DSIs supplied by the developer of their
certified health IT. We note that removing requirements for DSI
performance and quality as part of the Certification Program does not
mean that such information about intended use, provenance, training
data, limitations, performance, and known risks is unknown or
unavailable to users of certified health IT, or that such information
could not be communicated to them. We encourage users of certified
health IT to ask their developers for such information, and in
particular we remind users of certified health IT of the importance of
complying with applicable requirements to identify potential bias in
PDSIs and to avoid discrimination through the use of such tools. See 45
CFR 92.210. We note that we did not propose to remove requirements in
Sec. 170.315(b)(11)(ii)(C) for evidence-based DSIs regarding
electronic feedback data, which support transparency by enabling
providers to share, export, and report on the performance of DSIs in
real-world settings. We did, however, propose to redesignate Sec.
170.315(b)(11)(ii)(C) as Sec. 170.315(b)(11)(ii)(B).
Specifically, we have finalized as proposed revisions in Sec.
170.315(b)(11) to remove the requirement in Sec.
170.315(b)(11)(ii)(B); redesignate Sec. 170.315(b)(11)(ii)(C) as Sec.
170.315(b)(11)(ii)(B); remove the reference in Sec.
170.315(b)(11)(iii) to ``drug-drug and drug-allergy contraindication
checking''; revise the requirements in Sec. 170.315(b)(11)(iii)(B) to
limit the application of the certification criterion; and remove the
source attribute support, source attribute access and modification, and
intervention risk management requirements in Sec. 170.315(b)(11)(iv),
(v), and (vi). While we have retained a revised CIRI certification
criterion in this final rule, we believe that removal of the
requirement in Sec. 170.315(b)(11)(ii)(B) is still appropriate. The
requirement prescribed enabling DSI in a specific circumstance with
limited data elements (i.e., transition of care/referral summary
focused on only medications, allergies and intolerance, and problems).
Such prescription has minimal value for certification, particularly
compared to the DSI certification criterion requirement to support
selection of interventions based on a wider breadth of data as
identified in Sec. 170.315(b)(11)(iii). This requirement further
provides flexibility for health IT developers and their customers to
determine how interventions are incorporated into customer workflows.
We acknowledge that the prior CDS ``source attributes
transparency'' requirements (Sec. 170.315(a)(9)(v)) for evidence-based
interventions have been part of the Certification Program for many
years and may not present significant burden or costs for health IT
developers with health IT previously certified to the CDS certification
criterion. As such, we will further consider for future rulemaking
whether these or similar requirements should be reinstated in the
Certification Program.
Comments. A number of commenters expressed concerns regarding
burden. Commenters stated that the proposal would shift evaluation,
governance, and liability burdens related to SI tools to providers and
health systems. Some commenters stated that the burden shift would be
especially problematic for small, rural, safety-net, shared-network,
community healthcare, and LTPAC

[[Page 67942]]

organizations that lack data-science, governance, legal, or IT
capacity.
Response. We appreciate these concerns expressed by commenters
regarding evaluation, governance, and liability burden shifting to
providers and healthcare systems. We understand the importance of
ensuring that additional burdens related to selecting DSIs or DSI
functionality are not placed on providers and health systems. As
discussed above, we did not propose removal of requirements related to
feedback tools for evidence-based DSIs in redesignated Sec.
170.315(b)(11)(ii)(B), and we believe these requirements can help
provide assurances regarding the performance of evidence-based DSI
functionality in Health IT Modules certified to Sec. 170.315(b)(11).
As also discussed above, we are not persuaded of the value of the
transparency requirements in Sec. 170.315(b)(11), and thus we do not
believe that our finalized removal of the requirements to enable access
to source attributes for evidence-based and predictive DSIs will
significantly impair the ability to evaluate DSI tools. We believe the
finalized revisions to Sec. 170.315(b)(11) provide sufficient
assurances and transparency to make any significant increase or shift
in the evaluation, governance, or liability burden of providers and
healthcare systems unlikely.
Comments. A number of commenters expressed concern that the
proposal would undermine patient safety. Commenters expressed concern
that the proposal would impair the ability to evaluate bias,
performance, and appropriateness. Some commenters stated that the
proposal could result in unsafe recommendations, preventable harm,
inappropriate reliance, and weaker clinician oversight. A couple of
commenters expressed concern that loss of transparency could increase
automation bias, salience bias, or other overreliance problems. Several
commenters expressed concern that the proposal removes a core
safeguard. Several commenters also stressed that certain populations
and settings need population-specific validation and transparency
because they are especially vulnerable to underrepresentation or
inappropriate extrapolation. A commenter expressed concern that
removing the DSI reference to drug-drug and drug-allergy
contraindication checking could negatively affect patient care.
Response. We appreciate these comments expressing concerns about
patient safety, and we understand the importance of ensuring that the
use of DSI tools does not harm patients or negatively impact patient
care. We note that, as we stated in the Proposed Rule, we are not aware
of any publicly available evidence showing that transparency
requirements in Sec. 170.315(b)(11) led to positive impacts on patient
care, including removal of defective algorithms (90 FR 60987). In
response to commenters' concerns regarding a need for population-
specific validation and transparency, we agree that such information is
important, especially for patients belonging to underrepresented
groups, and we encourage users of certified health IT to discuss these
facets of SI quality and performance before deploying their developer's
supplied PDSIs. We do not believe that our policy to remove
requirements for user transparency will significantly impair efforts to
evaluate DSI tools or discuss such matters with health IT developers.
Regarding removal of the reference to drug-drug and drug-allergy
contraindication checking, we note that, as stated in the Proposed
Rule, the retention of requirements in Sec. 170.315(b)(11)(iii)(A)(2)
and (3) regarding enabling evidence-based DSIs that include
``Medications'' and ``Allergies and Intolerances'' as data types
ensures support for such interaction checks by Health IT Modules
certified to Sec. 170.315(b)(11) (90 FR 60986 through 60987).
Comments. Some commenters stated that the proposal would weaken
provider and patient trust in SI-enabled decision support and that this
could slow responsible adoption of SI-enabled decision support.
Response. We appreciate these comments regarding trust in SI-
enabled decision support. We are committed to encouraging trust in
health IT and health information exchange, including trust in SI-
enabled decision support. We do not believe that our revisions to Sec.
170.315(b)(11) will significantly lessen trust in SI-enabled decision
support because, as described above, we found that the requirements
lacked utility. Additionally, the retained requirements related to
feedback tools in redesignated Sec. 170.315(b)(11)(ii)(B) help provide
assurances regarding the performance of DSI functionality in Health IT
Modules certified to Sec. 170.315(b)(11). We believe the finalized
revisions to Sec. 170.315(b)(11) provide sufficient assurances and
transparency, and that our finalized policies will not contribute to an
erosion in provider or patient trust in health IT and SI-enabled DSI.
Comments. Some commenters rejected the premise that low clinician
use at the point of care means the information lacks value, arguing
that the real users are governance, procurement, implementation,
compliance, and safety teams.
Response. We appreciate these comments regarding clinician use of
source attribute information and the value of that information. We
noted in the Proposed Rule that developers of certified health IT
reported that during care delivery, most clinical users did not have
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 (90 FR 60987). We recognize
that there is value in transparency regarding DSIs, however we remain
cognizant of the need to minimize burden on developers of certified
health IT, especially when the required functionality is not widely
used and may not be equally applied to other developers that do not
participate in the Certification Program. We note that we have retained
requirements related to feedback tools for evidence-based DSI in
redesignated Sec. 170.315(b)(11)(ii)(B), which we believe help ensure
transparency.
Comments. Some commenters expressed specific concerns about
removing risk-management requirements, including that it would weaken
drift monitoring, control over updates and changes, auditability, root-
cause analysis, and ongoing quality review.
Response. We appreciate concerns regarding the removal of risk-
management requirements, including concerns related to monitoring
drift, updates, auditability, root-cause analysis, and ongoing quality
reviews. While we understand the importance of ensuring that predictive
DSI functions appropriately and effectively, we also seek to minimize
burden on developers of certified health IT and encourage innovation in
this evolving area. We believe that removal of the risk-management
requirements in Sec. 170.315(b)(11)(vi) provides substantial burden
relief for developers of certified health IT without hindering
developer's ability to work with their customers to institute ongoing
monitoring of predictive DSI performance and effectiveness.
Requirements to apply risk management to supplied PDSIs may still be
considered best practices and may still be incentivized through other
policies, such as those established by the FDA for premarket approvals.
Comments. Several commenters expressed concern about fragmentation
and variability that might occur if requirements in Sec.
170.315(b)(11) are removed. Some commenters stated that removing the
Federal framework could

[[Page 67943]]

produce fragmented oversight, including divergent State requirements or
weaker cross-agency alignment. Several commenters stated that resulting
variability across developers could make SI less portable, less
comparable, or less predictable across health systems. A commenter
stated that removing the requirements soon after HTI-1 implementation
would undercut recent compliance investments and create regulatory
instability.
Response. We appreciate these comments regarding fragmentation and
variability that could occur if requirements in Sec. 170.315(b)(11)
are removed. We note that we are retaining a number of requirements in
the certification criterion in Sec. 170.315(b)(11), including
requirements to support DSI selection. We do not agree that our
revisions to Sec. 170.315(b)(11) will create regulatory instability.
Rather, we anticipate that by removing requirements for developers of
certified health IT to supply their customers with access to DSI
performance and quality information, we are reducing the Department's
regulatory footprint and concentrating requirements solely within other
Department authorities, such as those exerted by the FDA.
Comments. Some commenters expressed concerns about the proposal's
data support and selection requirements in Sec. 170.315(b)(11)(iii).
Some commenters stated that the requirements were confusing, ambiguous,
or misaligned with the FHIR API framework, especially where no clear
standard for ``selection'' was specified. Some commenters objected to
narrowing the scope of predictive DSIs because certain tools may need
broader clinical context, including longitudinal history and social or
behavioral context. A commenter stated that ONC needed a standard for
enabling third-party predictive DSIs in Sec. 170.315(b)(11)(iii)(B).
Response. We appreciate these comments expressing concerns
regarding requirements in Sec. 170.315(b)(11)(iii). As we stated in
the Proposed Rule, 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 is
overly burdensome and costly (90 FR 60986). We also noted in the
Proposed Rule that many USCDI data elements, such as phone number and
phone number type data elements, are not likely to be used as inputs
for predictive DSIs (90 FR 60986). We believe that revising the
requirements to focus on fewer data elements will simplify requirements
and significantly reduce burden for health IT developers without
diminishing users' ability to activate a wide variety of predictive
DSIs (90 FR 60987). With respect to the comment regarding the need for
a standard for enabling ``selection'' of third-party predictive DSIs
according to Sec. 170.315(b)(11)(iii), we continue to maintain a
flexible and non-prescriptive posture regarding how a health IT
developer supports selection of DSIs according to Sec.
170.315(b)(11)(iii). We reiterate long-standing Certification Program
expectations that health IT developers with Health IT Modules certified
to Sec. 170.315(b)(11) support a user's selection of DSIs based on
whether a DSI uses specified data, and we decline to dictate how
developers support selection of such DSIs at this time.
Comments. Some commenters expressed support for our proposed
revisions to the DSI certification criterion. These commenters stated
that the revisions would reduce burden from rarely used or overly
prescriptive requirements and allow more flexible or voluntary
approaches to transparency. Many supporters of our proposal noted
extremely low use of the required functionality and a lack of value for
clinicians at the point of care. Several supporters of our proposal
stated that the SI landscape is rapidly evolving and that industry-led
frameworks are more appropriate than Federal transparency requirements
that could quickly become outdated. A supporter of our proposal noted
that the current requirements in Sec. 170.315(b)(11) exceed those of
other Federal Government programs utilizing SI, and that the FDA is
best situated to ensure SI safety. Another supporter of our proposal
stated that most SI solutions function as downstream consumers of
interoperable data and are not components of certified EHRs. A
supporter of our proposal stated that source attribute information
embedded into clinical interfaces risks alert fatigue without providing
benefit to patients.
Respons

[…truncated; see source link]

View on FederalRegister.gov →Plain-text source

Indexed from Federal Register on October 28, 2026.

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.