Health Data, Technology, and Interoperability: ONC Deregulatory Actions To Unleash Prosperity
This final rule focuses on deregulatory actions identified in HHS regulations regarding health information technology standards, implementation specifications, and certification...
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
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
( printed 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.
America's interoperability arc in healthcare has bent decisively toward Fast Healthcare Interoperability Resources (FHIR®)-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]
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 § 170.315(b)(11)(iv) for source attribute support and § 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.
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.
( printed 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.
c. Terms and Definitions
We have finalized, as proposed, to make conforming edits to the terms and definitions in § 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” (§ 170.402), “Application Programming Interfaces” (§ 170.404), and “Attestations” (§ 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 (§ 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 (§ 170.407).
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 §§ 170.523, 170.550, 170.555, and 170.570 (90 FR 60973). We have also finalized a revision to § 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
( printed 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]
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.
( printed 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
( printed 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
( printed 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 § 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.
( printed 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]
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® FHIR®, 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® FHIR®, which includes a draft FHIR Action Plan among many other resources related to
( printed page 67924)
HL7® FHIR® maturity and use cases.[11]
We also have an upcoming planned regulatory action that will focus on HL7® FHIR® based exchange.[12]
Ultimately, the regulatory process provides for public input that informs actual requirements that can be relied upon for investments and implementation.
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
( printed page 67925)
included in the Base EHR definition in § 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.
( printed page 67926)
( printed page 67927)
1. Clinical Certification Criteria
a. Clinical Decision Support
As of January 1, 2025, the “clinical decision support” (CDS) certification criterion in § 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 § 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 § 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 § 170.315(a)(9) is removed or if source attribute requirements are removed from § 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 § 170.315(a)(9) with our proposals in § 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 § 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 § 170.315(a)(9), reinstate the certification criterion, or use the requirements in the CDS certification criterion in § 170.315(a)(9) instead of the narrower DSI requirements in § 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 § 170.315(a)(9) in a revised version in § 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 § 170.315(a)(9) with requirements similar to those in § 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 § 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 § 170.315(b)(11)(iv). As a result, some elements that were similar between § 170.315(a)(9) and § 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
( printed 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 § 170.315(a)(12). We explained that Health IT Modules certified to § 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 § 170.207(a)(1) (SNOMED CT®, U.S. Edition, March 2022 Release). We noted that this certification criterion is not included in the Base EHR definition in § 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 § 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® 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® FHIR® 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.
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® 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® 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® 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).
Regarding commenters' concerns about data quality related to removing the family health history certification criterion, we clarify that we work directly with HL7® to finalize HL7® FHIR® 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® 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® 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
( printed 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 § 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 § 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.
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 § 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 § 170.315(a)(14) (90 FR 60983). The IDL certification criterion requires Health IT Modules certified to § 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 § 170.102 to remove § 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
( printed page 67930)
remove the IDL certification criterion (§ 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 § 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® FHIR® 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 (§ 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 § 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 § 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®-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]
2. Care Coordination Certification Criteria
a. Transitions of Care
We proposed to revise the “transitions of care” certification criterion in § 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,
( printed 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 § 170.315(b)(1)(i) “send and receive via edge protocol” and in § 170.315(b)(1)(iii) “create” and to simplify the requirements in § 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 § 170.315(b)(1)(ii)(B) and (C). We also proposed to move the requirements in § 170.315(b)(1)(ii)(A) “validate C-CDA conformance—system performance” to § 170.315(b)(1)(i) and to rename § 170.315(b)(1) to read “transitions of care—receive and validate.” Additionally, in § 170.315(b)(1)(ii)(A) we proposed to remove the references to § 170.205(a)(3) and to replace the references to § 170.205(a)(5), which expired on January 1, 2026, with references to § 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 § 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 § 170.315(b)(1) to January 1, 2030. Specifically, we have finalized our proposed removal of § 170.315(b)(1)(i) “send and receive via edge protocol,” § 170.315(b)(1)(iii) “create,” § 170.315(b)(1)(ii)(B) “display,” and § 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 § 170.205(a)(3) in § 170.315(b)(1)(ii) and replacement of references to § 170.205(a)(5) in § 170.315(b)(1)(ii) with references to § 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 § 170.315(b)(1)(ii)(A). We note that in the Proposed Rule we did not propose to remove references to § 170.205(a)(3) or replace references to § 170.205(a)(5) with references to § 170.205(a)(6) in § 170.315(b)(1)(ii)(B) and (C) and in § 170.315(b)(1)(iii) because we proposed to remove § 170.315(b)(1)(ii)(B) and (C) and § 170.315(b)(1)(iii) entirely. However, because we have not finalized our proposal to remove § 170.315(b)(1)(ii)(B) and (C) and § 170.315(b)(1)(iii) as of the effective date of a final rule, but the references to § 170.205(a)(3) and (5) remain outdated, we have finalized removal of references to § 170.205(a)(3) and replacement of references to § 170.205(a)(5) with references to § 170.205(a)(6) in § 170.315(b)(1)(ii)(B) and (C) and in § 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 § 170.205(a)(3) and replacement of references to § 170.205(a)(5) with references to § 170.205(a)(6) in § 170.315(b)(1)(ii).
Delaying the effective date of removal of § 170.315(b)(1)(i) “send and receive via edge protocol” and § 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 § 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 § 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 § 170.315(b)(1)(i) would
( printed page 67932)
require new developers to meet the requirements of § 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 § 170.315(b)(1) requirements rather than fully implement the current § 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 § 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 § 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 § 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 § 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 § 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 § 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 § 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 § 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 § 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, § 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.
Comment
s. 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 § 170.315(b)(1)(i) to January 1, 2030. We anticipate that the extended time for
( printed 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 § 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 § 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 § 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 § 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 § 170.315(g)(6) for burden reduction purposes. This reduces burden because § 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 § 170.315(b)(1) to January 1, 2030, with the exception of the removal of references to § 170.205(a)(3) and replacement of references to § 170.205(a)(5) with references to § 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 § 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 § 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]
Comments.
The majority of commenters were not supportive of removing the CIRI certification criterion in § 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
( printed 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 § 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 § 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 § 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 § 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 § 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 § 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 § 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 § 170.315(b)(2) of the requirements to use the content exchange standards and implementation specifications specified in § 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 § 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 § 170.213. We note that we do not expect that a health IT developer with a Health IT Module currently certified to § 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 § 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 § 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
( printed 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 § 170.315(b)(2) as proposed and instead have finalized removal of the requirements in § 170.315(b)(2) to use the content exchange standards and implementation specifications in § 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 § 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 § 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 § 170.315(b)(2) as proposed and instead have finalized removal of the requirements in § 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 § 170.315(b)(2) as proposed and instead have finalized removal of the requirements in § 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 § 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 § 170.315(b)(2) as proposed and instead have finalized revisions to § 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 § 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 § 170.315(b)(2) as proposed. This action provides further assurance that this functionality
( printed page 67936)
will be maintained in certified health IT.
Comments.
Some commenters expressed support for removal or simplification of the certification criterion in § 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 § 170.315(b)(2) would provide room for innovation in this space. However, the finalized functional requirement in § 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 § 170.315(b)(7) and the “security tags—summary of care—receive” certification criterion in § 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 § 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 § 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 § 170.315(b)(7) and the security tags—summary of care—receive certification criterion in § 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 § 170.315(b)(7) and the security tags—summary of care—receive certification criterion in § 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 § 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 § 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
( printed 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 § 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.
Comments.
A number of commenters noted that the security tags criteria in § 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 § 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]
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 § 170.315(d) and the associated Privacy and Security Certification Framework under § 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 § 170.315(b)(7) nor § 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.
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 § 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 § 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
( printed 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 § 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 § 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 § 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 § 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 § 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.
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 § 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 § 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 § 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 § 170.315(b)(9) and reserve that section as of the effective date of a final rule. The certification criterion in § 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 § 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).
Comments.
The proposal received relatively few comments, and the majority of commenters were not supportive of removing the care plan certification criterion in § 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
( printed 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 § 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 § 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 § 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 § 170.315(b)(1) until January 1, 2030. Also, we are retaining the requirements in § 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 § 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 § 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 § 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 § 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 § 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 § 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 § 170.315(b)(9) because health IT developers are likely to continue supporting C-CDA-based exchange under § 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 § 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]
Comments.
Several commenters stated that removal of the certification criterion in § 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 § 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 § 170.315(b)(9) because health IT developers are likely to continue supporting C-CDA-based exchange under § 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 § 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
( printed 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 § 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 § 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 § 170.315(b)(1) to January 1, 2030. We do not believe it is necessary to also maintain requirements in § 170.315(b)(9) because health IT developers are likely to continue supporting C-CDA-based exchange under § 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 § 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 § 170.315(b)(9) because health IT developers are likely to continue supporting C-CDA-based exchange under § 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 § 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 § 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 § 170.315(b)(9) will reduce burden, including costs to maintain certification. We also agree with commenters that the certification criterion in § 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 § 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 § 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 § 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 § 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 § 170.315(b)(2)(iii)(D), and we proposed to redesignate the certification criterion requirement currently in § 170.315(b)(11)(ii)(C) as § 170.315(b)(11)(ii)(B). We also proposed to remove the parenthetical reference in § 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 § 170.315(b)(11)(iii)(B), which currently relate to enabling predictive DSIs that use any data expressed in the standards in § 170.213, to limit the application of the certification criterion to just data expressed in § 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 § 170.213. Finally, we proposed to remove the requirements in § 170.315(b)(11)(iv) and (v) regarding source attribute support, access, and modification and in § 170.315(b)(11)(vi)
( printed 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 § 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 § 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 § 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 § 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 § 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 § 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.
See45 CFR 92.210. We note that we did not propose to remove requirements in § 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 § 170.315(b)(11)(ii)(C) as § 170.315(b)(11)(ii)(B).
Specifically, we have finalized as proposed revisions in § 170.315(b)(11) to remove the requirement in § 170.315(b)(11)(ii)(B); redesignate § 170.315(b)(11)(ii)(C) as § 170.315(b)(11)(ii)(B); remove the reference in § 170.315(b)(11)(iii) to “drug-drug and drug-allergy contraindication checking”; revise the requirements in § 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 § 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 § 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 § 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 (§ 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
( printed 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 § 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 § 170.315(b)(11). As also discussed above, we are not persuaded of the value of the transparency requirements in § 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 § 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 § 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 § 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 § 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 § 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 § 170.315(b)(11)(ii)(B) help provide assurances regarding the performance of DSI functionality in Health IT Modules certified to § 170.315(b)(11). We believe the finalized revisions to § 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 § 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 § 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 § 170.315(b)(11) are removed. Some commenters stated that removing the Federal framework could
( printed 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 § 170.315(b)(11) are removed. We note that we are retaining a number of requirements in the certification criterion in § 170.315(b)(11), including requirements to support DSI selection. We do not agree that our revisions to § 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 § 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 § 170.315(b)(11)(iii)(B).
Response.
We appreciate these comments expressing concerns regarding requirements in § 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 § 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 § 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 § 170.315(b)(11)(iii). We reiterate long-standing Certification Program expectations that health IT developers with Health IT Modules certified to § 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 § 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.
Response.
We appreciate these comments in support of our proposal. We agree with commenters that our proposed revisions to § 170.315(b)(11) would reduce burden related to under-utilized requirements and allow for greater innovation in this area. We also agree that, as several commenters stated, the SI landscape is rapidly evolving and industry-led efforts to provide transparency have promise. We have finalized our proposed revisions to § 170.315(b)(11) as proposed.
Comments.
Several commenters commented on issues that were out of scope for our proposal, including broader audit trail and data preservation requirements, patient-facing notice regarding downstream SI-related uses of data, contractual issues, and support for emerging interoperability approaches beyond existing standards.
Response.
We appreciate these comments; however, these comments were outside the scope of this rulemaking.
In the Proposed Rule (90 FR 60988), we proposed to revise the “clinical quality measures (CQM)—report” certification criterion in § 170.315(c)(3) as of the effective date of this final rule. This certification criterion enables a user to electronically create a data file for transmission of clinical quality measure data. In the Cures Act Interim Final Rule, we revised § 170.315(c)(3) to include a corrected compliance transition timeline for the criterion in § 170.315(c)(3)(ii), which specified the use of standards in §§ 170.205(h)(2) and (k)(1) and (2), for the period before December 31, 2022 (85 FR 70075 and 70083). In the Proposed Rule, we proposed to remove § 170.315(c)(3)(ii) because that transition time period had elapsed (90 FR 60988). We also proposed to move the requirements in § 170.315(c)(3)(i) to § 170.315(c)(3), thus removing all subparagraphs and including all certification criterion requirements in the main paragraph for § 170.315(c)(3). For further background and history on this certification criterion, we refer readers to the Proposed Rule (90 FR 60988).
Comments.
The majority of commenters supported our proposal to revise the CQM—report certification criterion to remove expired transition language, stating that the proposal would streamline outdated regulatory requirements with little or no practical impact. Several of these commenters characterized the proposal as a narrow cleanup that would align the regulation with current practice and remove obsolete references to expired standards.
Some commenters used their discussion of this certification criterion to recommend broader changes to quality measurement policy, including recommending: revising § 170.315(c)(3) to permit technology-neutral quality reporting, allowing certified Health IT Modules to satisfy the certification criterion requirement using either Quality Reporting Document Architecture (QRDA) or FHIR-based quality reporting implementation guides, and establishing a transition
( printed page 67944)
pathway toward FHIR-based quality reporting. A few commenters expressed concern that continued reliance on QRDA is inconsistent with FHIR-based modernization efforts because it limits quality reporting to legacy document standards. Other commenters also noted that continued reliance on QRDA-based reporting introduces architectural inconsistency with interoperability efforts that are transitioning to FHIR-based APIs and may require developers to maintain parallel infrastructure, limiting their available modernization resources. A cross-cutting concern expressed by a few commenters was that revisions to certification requirements should not risk continuity by creating a gap in quality reporting infrastructure before FHIR-based or other modernized approaches are fully implemented. Additionally, many of the commenters who recommend broader changes to quality measurement policy encouraged broader API-driven quality measurement approaches and strengthening post-certification oversight and transparency regarding the quality measurement capabilities of certified health IT products, including tracking which quality measurement capabilities are included versus offered as paid add-ons to products. A few other commenters expressed concerns regarding the continuity of quality reporting infrastructure, workflow burden and costs for providers, comparability and auditability of quality measurement outputs, maintaining a consistent baseline for interoperability and quality reporting, and supporting digital quality measures, including measures that use patient-reported data.
Response.
We thank commenters for their feedback. We have finalized our proposal to revise § 170.315(c)(3), including the removal of § 170.315(c)(3)(ii) and transfer of the requirements in former § 170.315(c)(3)(i) to § 170.315(c)(3), as of the effective date of this final rule. We note that the revisions to § 170.315(c)(3) do not alter the substantive requirements a Health IT Module must meet to obtain certification to § 170.315(c)(3) that remain applicable under the CQM—report certification criterion.
We acknowledge commenters' recommendations that we use this final rule to adopt broader revisions related to quality measurement modernization efforts, including technology-neutral QRDA or FHIR-based quality reporting implementation guides, a sequenced transition pathway for broader FHIR-based quality reporting, as well as concerns expressed by commenters regarding provider burden. However, we did not propose these broader revisions to § 170.315(c)(3) in the Proposed Rule (90 FR 60988), and therefore, we have not adopted these revisions in this final rule.
Comments.
Some commenters opposed removal of the CQM—report certification criterion and recommended coordinating certification changes related to quality reporting with CMS program requirements and requested that any future substantive changes to quality reporting certification requirements include mechanisms to evaluate impacts on CMS program compliance. A number of these commenters recommended that such substantive changes to quality reporting certification requirements be delayed until 2028 or until alignment with CMS program timelines can be achieved.
Response.
We acknowledge commenters' recommendations to coordinate changes to certification criteria related to quality reporting with CMS program requirements and to include mechanisms to evaluate potential impacts on CMS program compliance. We also recognize commenters' requests that substantive changes be delayed until alignment with CMS program timelines can be achieved. However, we did not propose to remove the CQM—report certification criterion, therefore, these comments are out of scope for this rulemaking. The revisions we have finalized are limited to removal of expired transition language and reorganization of regulatory text in the CFR, and they do not alter the substantive requirements a Health IT Module must meet to obtain certification to § 170.315(c)(3) that remain applicable under this certification criterion. We will continue to coordinate with CMS, as appropriate, on any future proposals to substantively change this certification criterion in future rulemaking in order to support alignment of Certification Program criteria with CMS program needs.
b. Clinical Quality Measures—Filter
In the Proposed Rule, we proposed to remove the “clinical quality measures (CQM)—filter” certification criterion in § 170.315(c)(4) with an effective date of January 1, 2027 (90 FR 60988). This certification criterion assesses whether a Health IT Module can filter quality data based on a set of standardized data elements for electronic clinical quality measures (eCQM) calculated using certified health IT. As stated in the Proposed Rule (90 FR 60988), we proposed to remove this certification criterion because we identified that the administrative costs of certification for CQM—filter are no longer offset by the benefits of advancing the specific functionality supported by the criterion. Additionally, quality reporting programs, such as those required by States and CMS programs, require broader supplemental data and capabilities beyond what we currently require for certification. We also stated in the Proposed Rule (90 FR 60988) that health IT developers have widely implemented technology solutions that expand beyond the baseline requirements of the CQM—filter certification criterion. We further stated that § 170.315(c)(4) is not included in the Base EHR definition in § 170.102 but is included in the CEHRT definition used by programs including MIPS in 42 CFR 414.1305. We clarify here that § 170.315(c)(4) is specified as optional for inclusion as part of CEHRT necessary to report on clinical quality measures in paragraph (2) of the definition. We also explained that health care providers participating in CMS alternative payment models, as well as health IT developers supporting quality initiatives, reported using different options to filter eCQM results, including customized systems and support from third parties to meet particular quality measure reporting needs. For further background and history on this certification criterion, we refer readers to the Proposed Rule (90 FR 60988).
Comments.
Many commenters opposed the removal of the CQM—filter certification criterion. These commenters expressed concerns that removal could shift responsibility for maintaining quality reporting, stratification, and workflow functionality from health IT developers to clinical providers, increase provider burden and costs, require manual workarounds or third-party tools, and reduce comparability and confidence in quality measure outputs across systems. Some commenters recommended that we not remove the CQM—filter certification criterion until a fully functional, low cost, standardized replacement is available, noting that § 170.315(c)(4) serves as a baseline capability supporting consistency across systems.
Several commenters representing providers stated that the CQM—filter certification criterion is important for day-to-day quality reporting workflows and for supporting some Federal, State, and other programmatic reporting requirements. Another commenter specified that these reporting workflow functions support demographic stratification, validating measure denominators and numerators, generating clinician-facing lists for gap closure, and reconciling measure
( printed page 67945)
discrepancies across systems. Several commenters, including payer- and plan-affiliated organizations, echoed concerns expressed by providers, particularly with respect to workflow integration and the potential for disruption to existing reporting processes, including for safety-net providers and organizations that rely on certified functionality to support Uniform Data System (UDS) and other program reporting requirements.
Response.
We thank commenters for their feedback. We have finalized our proposal to remove the CQM—filter certification criterion in § 170.315(c)(4) with an effective date of January 1, 2027.
We continue to believe that the administrative costs of certification for § 170.315(c)(4) are no longer offset by the benefits of maintaining this specific certification requirement. As noted in the Proposed Rule (90 FR 60988), quality reporting programs generally require broader supplemental data and capabilities than the limited functionality described in § 170.315(c)(4), and health IT developers have widely implemented technological solutions that extend beyond the criterion's minimum certification requirements.
While we recognize the importance of functionality within EHRs to filter quality data by common variables, current rates of certification indicate that such functionality is not being driven by compliance with this certification criterion. As of May 2026, CHPL [30]
data indicates there is low interest by health IT developers in certifying their Health IT Modules to § 170.315(c)(4). For example, there are 326 active Health IT Modules certified to § 170.315(c)(1), (2), or (3), but only 62 active Health IT Modules certified to § 170.315(c)(4). Additionally, we find from publicly available 2024 Promoting Interoperability data that less than 2 percent of MIPS-eligible clinicians and less than 8 percent of eligible hospitals and critical access hospitals reported using health IT certified to the CQM—filter certification criterion, showing that few healthcare providers used technology certified to this criterion.[31 32]
These findings are consistent with feedback received through listening sessions with a wide range of health care provider types and sites of service, as well as through public correspondence.
We appreciate comments recommending that we do not remove this certification criterion until a fully functional, low cost, standardized replacement is available. However, based on the utilization data described above, removal of the CQM—filter certification criterion is not expected to result in a decrease in the availability of quality measure filtering functionality in health IT, as developers and users have existing options to support filtering and stratification functions beyond the limited functionality described in § 170.315(c)(4).
We acknowledge concerns expressed by commenters surrounding the importance of supporting reliable and efficient quality measure data reporting workflows across Federal, State, and other programmatic reporting requirements. We also acknowledge that some providers, particularly safety-net providers and organizations with limited resources, may rely on filtering functionality within their EHRs to support specific reporting workflows, including those related to UDS reporting. Additionally, we acknowledge concerns expressed by commenters that removal could shift responsibility for maintaining quality reporting functionality from health IT developers to clinical providers resulting in an increase in provider burden. However, given the low rates of certification to this criterion, we believe health IT developers provide this functionality in response to customer needs, rather than to obtain certification for their Health IT Modules to this certification criterion. Therefore, we do not believe removing the availability of § 170.315(c)(4) for certification will result in a loss of quality measure filtering functionality from health IT systems, in a shift of responsibility from health IT developers to clinical providers, or in a potential disruption to workflow integration or existing reporting processes. We also do not believe that removing the CQM—filter certification criterion will increase provider burden and costs, require additional manual workarounds or third-party tools, or affect existing comparability and confidence in quality measure outputs across systems. As noted in the Proposed Rule (90 FR 60988), developers and providers have implemented a range of approaches to support filtering, stratification, and validation functions that extend beyond the limited baseline established by this certification criterion.
Comments.
Some commenters who opposed removal of the CQM—filter certification criterion recommended a transition plan instead of immediate removal of the criterion. A commenter recommended that any changes to certification requirements should allow a two-year window of voluntary compliance following publication of a requirement in final rulemaking. Several commenters recommended a phased or delayed sunset in coordination with CMS program timelines. A few of these commenters recommended we adopt a phased transition as more standardized approaches to digital quality measurement and API-based quality data exchange mature.
Response.
We appreciate commenters' requests that we coordinate the timing of removal of the CQM—filter certification criterion with CMS program timelines and future quality measure modernization efforts. We acknowledge the cross-cutting concern expressed by commenters; however, the certification criterion is specified as optional under the definition of CEHRT in 42 CFR 414.1305, which is referenced by certain CMS programs, including MIPS. As a certification criterion that may “optionally” be included in the definition of CEHRT with respect to criteria necessary to support the calculation and reporting of clinical quality measures, health care providers are not subject to program requirements to use EHR technology certified to this criterion in order to meet the definition of CEHRT in 42 CFR 414.1305. Additionally, 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” (CY 2027 Physician Fee Schedule Proposed Rule) (91 FR 43842, July 16, 2026), CMS proposed to remove the reference to § 170.315(c)(4) for the CY 2027 performance period/2029 MIPS payment year, such that this certification criterion would no longer be included in the definition of CEHRT, effective January 1, 2027 (91 FR 44170).
We will continue to coordinate with CMS to ensure alignment between the definition of CEHRT and our final policy with respect to the certification criterion in § 170.315(c)(4). We are not aware of any Federal programs that require use of technology certified to this criterion. At the same time, low rates of certification to the CQM—filter criterion across health IT products, combined with feedback that this functionality is valuable and widespread in health IT systems, indicate that current functionality for
( printed page 67946)
filtering is being deployed by health IT developers without obtaining certification to this criterion. Accordingly, removal of this certification criterion should not result in a gap in functionality or otherwise necessitate a two-year window of voluntary compliance or a phased or delayed sunset. Therefore, we have finalized our proposal to remove § 170.315(c)(4), effective January 1, 2027.
Comments.
A smaller number of commenters expressed support for removing § 170.315(c)(4), citing low adoption and limited current utility or value, including because this certification criterion no longer supports current CMS program needs.
Response.
We thank commenters for their feedback and agree that because this certification criterion no longer supports current CMS program needs, and CHPL data demonstrates low interest among health IT developers, that removal of this criterion is appropriate.
4. Privacy and Security Certification Criteria
We proposed to remove all the privacy and security (P&S) certification criteria in § 170.315(d) and the associated Privacy and Security Certification Framework (P&S Certification Framework) under § 170.550(h) as of the effective date of this final rule. We proposed to remove the P&S certification criteria and P&S Certification Framework for a multitude of reasons that led to our conclusion that the costs and burden of these certification criteria and Certification Program requirements far exceed their intended purpose and benefits (90 FR 60989-60990). We reiterate these reasons below.
First, we have found that health IT developers have changed their development processes to build in P&S capabilities to meet these certification requirements rather than attempting to demonstrate that their technology could interface with other health IT that provides these capabilities. This has led to negative experiences for health care providers who have sought to use a best-of-breed, non-certified security technology to work across their deployed enterprise (
e.g.,
a third-party audit log).
Second, certified health IT (which is generally EHR-focused technology) is often implemented in enterprise-wide settings (
e.g.,
group practices, large healthcare systems, multi-provider cloud-supported services). However, it cannot, in isolation or independently, provide the necessary P&S capabilities across all relevant technologies in the enterprise-wide setting for covered entities to comply with the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule (45 CFR part 160 and subparts A and C of part 164).
Third, while certified health IT has always been “linked” to the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, those programs have not required participating health care providers to use or implement the P&S capabilities included in certified health IT for purposes of meeting the security risk analysis measure. Rather, the health care providers must “have” such certified health IT. As such and as discussed in more detail below (and in the Proposed Rule), health care providers participating in the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category are required to adopt certified capabilities that they may not use because, for example, they may prefer a non-certified security health IT product to meet their overall security needs, including compliance with the HIPAA Security Rule.
Fourth, many interested parties have overinterpreted the Certification Program's limited scope and policy purpose with respect to health IT security and instead have assumed that the Certification Program assessed discrete specific security capabilities at significant depths, such as when and how the capabilities are implemented in health care provider or system settings. For example, interested parties have expressed incorrect expectations of certified health IT and developers, such as expectations that the Certification Program required health IT developers of certified health IT to implement and conduct penetration testing of certified health IT or ensure that certified authentication and authorization capabilities protect against known or unknown vulnerabilities. In contrast, to allow for significant scalable deployment flexibility, a certified Heath IT Module must only, for example, demonstrate support for basic authentication and role-based access control.
Fifth, there remains a disconnect between health IT certified to the P&S certification criteria under the Certification Program and the implementation and compliance responsibilities of most purchasers and users of certified health IT with the requirements of the HIPAA Privacy [33]
and Security Rules. This disconnect has led to the introduction of unnecessary regulatory burden and duplication, as well as unwarranted opportunity costs for innovation. As we noted above and in our prior rulemakings related to the P&S certification criteria, the adoption of health IT certified to the P&S certification criteria does not guarantee compliance with the requirements of the HIPAA Privacy and Security Rules. Further, the adoption of health IT certified to the P&S certification criteria does not serve as an affirmative defense, has not been identified as a mitigating factor in assessing HIPAA civil money penalties, and does not exempt a HIPAA-regulated entity from having to comply with any applicable provision of the HIPAA Privacy or Security Rules (or the HIPAA Breach Notification Rule [34]
). These facts alone have created unnecessary burden for health care providers that adopt certified health IT and health IT developers of certified health IT that also meet the definition of a covered entity or business associate, respectively, and are subject to the HIPAA Privacy and Security Rules.[35]
In fact, we have heard from interested parties both arguing that our certification requirements go beyond the HIPAA Security Rule requirements (75 FR 44619, 80 FR 62707) or do not go far enough in meeting the requirements of the HIPAA Privacy Rule and Security Rule (80 FR 62691, 62706). Considering these opposing perspectives, our Certification Program requirements may be diverting financial resources and efforts from innovative, agile, and comprehensive solutions that can address the threats faced by health care providers and meet their regulatory obligations under the HIPAA Privacy and Security Rules. As highlighted in the Proposed Rule, by removing the P&S certification requirements under the Certification Program, we would provide health IT developers with the flexibility to innovate in this area and to develop new solutions to address the needs of their customers. Such an approach should also spur competition and give health care providers, including small practices, the opportunity to choose the best P&S technologies that fit their needs at the best price as opposed to being forced to accept those capabilities included in certified health IT that may not fit their health information P&S needs for various reasons. Finally, we noted that we did not plan to completely forego the adoption of P&S capabilities within the
( printed page 67947)
Certification Program. Instead, going forward, we stated that we intend to prioritize the adoption of P&S capabilities that are fit for purpose, use case specific, and deliver much needed technical consistency in the market when paired with specific conformance requirements. As an example, we stated that as we pursue more API-focused certification criteria, if the standards and implementation guides adopted for them do not specify or leave optional specific security requirements, we may look to add further constraints (
e.g.,
multi-factor authentication support). Further, we stated that, in all cases, we intended to make security capability conformance a built-in part of a certification criterion's conformance and not the separate and stand-alone conformance assessment that currently exists.
In lieu of removing, on the effective date of this final rule, all of the P&S certification criteria in § 170.315(d) and the associated P&S Certification Framework under § 170.550(h), we offered an alternative proposal. We proposed to retain the “auditable events and tamper resistance” (§ 170.315(d)(2)), “audit report(s)” (§ 170.315(d)(3)), and “auditing actions on health information” (§ 170.315(d)(10)) certification criteria and associated P&S Certification Framework certification requirements. We stated that these certification criteria and included functionality may serve to help identify fraud and abuse. We noted that the functionality may also support health care provider compliance obligations and investigations by relevant entities, including both civil and criminal matters at the Federal and State levels. As mentioned in the Proposed Rule, identifying and addressing fraud and abuse increases confidence in the nation's healthcare system, reduces inappropriate and wasteful spending, and protects taxpayer dollars when it comes to government spending on healthcare (90 FR 60990).
Comments.
We received some comments supporting our proposal to completely remove the P&S certification criteria and the associated P&S Certification Framework. These commenters strongly agreed with our rationale, including noting that removal would eliminate regulatory duplication. These commenters asserted that certification involved intensive and costly testing. Some of these commenters also advocated for a “system-wide approach” to certification and a uniform national governance structure for privacy and security. Another commenter highlighted the availability of alternative certification processes, such as HITRUST.
Response.
We thank commenters for their feedback. We have ultimately decided not to finalize our proposal to remove the P&S certification criteria and the P&S Certification Framework for the reasons we discuss hereafter.
Comments.
The vast majority of commenters did not support our proposal to remove all of the P&S certification criteria and the P&S Certification Framework. With limited exceptions, these commenters generally did not comment on or respond to our rationale for proposing to remove the P&S certification criteria and the P&S Certification Framework. Rather, they offered different rationales for keeping the P&S certification criteria and P&S Certification Framework. Commenters stated that certification provides a minimum baseline of P&S capabilities and a mechanism for verifying that these capabilities exist in health IT products that health care providers purchase, license, and use. Further, health care providers expressed concern that removal of the certification requirements will both shift burden to health care providers to verify the existence of the capabilities and lead to developers removing P&S capabilities due to costs and burden. These concerns were particularly acute for small and rural providers that stated they had limited resources to address these concerns and negotiate inclusion of capabilities in health IT. A few commenters asserted that privacy and security capabilities also support patient safety (
e.g.,
ensuring health information remains reliable).
Commenters who responded to our rationale that P&S certification criteria do not guarantee compliance with the requirements of the HIPAA Privacy and Security Rules, do not serve as an affirmative defense, have not been identified as a mitigating factor in assessing HIPAA civil money penalties, and do not exempt a HIPAA-regulated entity from having to comply with any applicable provision of the HIPAA Privacy or Security Rules, recommended that we work with the HHS Office for Civil Rights to find ways to leverage the adoption and use of health IT certified to P&S certification criteria for compliance with the HIPAA Privacy and Security Rules.
In response to our alternative proposal, commenters expressed strong support for retaining the three “auditing” certification criteria. However, many of these same commenters pointed out that the criteria-incorporated audit standard (ASTM E2147-18) is outdated and should be updated.
Some commenters argued for the specific retention of other P&S certification criteria such as the authentication (§ 170.315(d)(1)) and encryption (§ 170.315(d)(7) and (9)) criteria.
A few commenters suggested using testing alternatives to lower burden.
Response.
We appreciate the robust response from commenters and their strong views in favor of preserving the P&S certification criteria and the P&S Certification Framework. As noted above, commenters generally did not respond to our rationale for removal. Further, we were not persuaded by the comments that did respond to some of our rationale because we expect that developers would remove P&S capabilities that are redundant or could be replaced by a health care provider with a better alternative and this would be preceded by discussions with customers (
e.g.,
health care providers). However, we have reassessed our proposals in light of commenters' explanations for why we should retain some (and update) P&S certification criteria. As we stated in the Proposed Rule, we have always supported strong P&S health IT infrastructure and plan to continue to incorporate P&S capabilities into the Certification Program. The Proposed Rule did not address all potential options for revisions to the P&S certification criteria and the P&S Certification Framework. Rather, it focused primarily on a binary choice between removing all the P&S certification criteria and P&S Certification Framework (with a discrete alternative proposal focused on three P&S certification criteria) or not. We have decided not to finalize our proposal to remove any of the P&S certification criteria, the P&S Certification Framework, or the alternative proposal to retain the “auditing” certification criteria only. We will continue to consider the best regulatory approach for the P&S certification of health IT under the Certification Program in anticipation of future rulemaking. This will also provide additional time to consider comments related to alignment of the P&S certification of health IT under the Certification Program with policies and requirements of the HIPAA Privacy and Security Rules. Future rulemaking may include proposing to remove all or some P&S certification criteria, updating certain P&S certification criteria, changing the P&S Certification Framework, or other options to address the concerns we have expressed in this
( printed page 67948)
rulemaking and those concerns raised by commenters.
We also draw readers' attention to the fact that we did not include the following certification criteria in the P&S Certification Framework when we adopted the criteria: § 170.315(g)(31) “provider prior authorization API—coverage requirements discovery”; § 170.315(g)(32) “provider prior authorization API—documentation templates and rules”; § 170.315(g)(33) “provider prior authorization API—prior authorization support”; § 170.315(j)(20) “workflow triggers for decision support interventions—clients”; and § 170.315(j)(21) “subscriptions—client.” As part of any future rulemaking, we will consider whether to add them to the P&S Certification Framework if such framework is retained or revised.
5. Patient Engagement Certification Criteria
a. View, Download, and Transmit to a 3rd Party
We proposed to revise the “view, download, and transmit to 3rd party” (VDT) certification criterion in multiple ways. We proposed to remove the Web Content Accessibility Guidelines (WCAG) conformance requirement from the certification criterion (found in § 170.315(e)(1)(i)). We proposed to remove the VDT requirement in § 170.315(e)(1)(ii)(A)(
2) to conform with any Network Time Protocol (NTP) standard for purposes of “date and time each action occurred” under the activity log. Finally, we proposed the following conforming revisions: (1) remove and reserve § 170.315(e)(1)(i)(A)(
1) because the requirement had an expiration date of December 31, 2025; revise § 170.315(e)(1)(i)(B)(
1) and (
2) to remove references to § 170.205(a)(5) because the standard codified in these paragraphs also had an expiration date of December 31, 2025; and provide a heading for the paragraph at § 170.315(e)(1)(i), which would be “general” and would align with the Office of the Federal Register (OFR) Drafting Handbook. In the Proposed Rule, we noted that the proposed revisions, if finalized, would be effective as of the effective date of this final rule.
WCAG
Comments.
Comments from developers of certified health IT supported removing the WCAG standard and conformance requirement. These commenters noted that the WCAG conformance requirement appears duplicative and redundant with accessibility requirements imposed elsewhere, most specifically the nondiscrimination requirements rooted in section 1557 of the Patient Protection and Affordable Care Act (“Affordable Care Act”). These commenters also emphasized that removing the outdated standard and conformance requirement would reduce certification burden and provide design flexibility.
The majority of commenters argued that we should not remove the WCAG standard and conformance requirement. These commenters asserted that certification provides explicit compliance verification and reinforces existing Federal obligations. Commenters also suggested that developers would stop including accessibility requirements and would charge more for accessibility tools. A commenter asserted that not all developers are subject to the Americans with Disabilities Act of 1990 (ADA) obligations. Some commenters contended that removing the conformance requirement would shift burden to health care providers. A few commenters suggested that removal of the WCAG conformance requirement would have a negating impact on patient access and usability.
Response.
We appreciate the comments submitted that supported and opposed our proposal. We recognize that the WCAG conformance requirement in the Certification Program served a function distinct from the obligations imposed by Federal civil rights laws because certification provides an evaluation of specified health IT functionality, while the other laws impose obligations on entities covered by those laws. We also considered commenters' concerns that removing the certification requirement could reduce accessibility for patients with disabilities or place greater responsibility on health care providers to evaluate the accessibility of the health IT they purchase and use. Overall, we disagree with and are not persuaded by the commenters that opposed our proposal.
As noted in the Proposed Rule, the baseline certification standard of WCAG 2.0 Level A was adopted with the 2014 Edition in 2012 and has been part of the voluntary Certification Program and specifically the VDT certification criterion since that time. The functionality is now sufficiently widespread among certified health IT and health care providers who adopt such technology. This is true because the VDT certification criterion has been part of the CEHRT definitions and specifically supports the “Provide Patients Electronic Access to their Health Information” measures under the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category since the 2014 Edition. By removing the WCAG conformance requirement (WCAG 2.0, Level A or optional Level AA), developers of health IT currently certified to § 170.315(e)(1) will likely not abandon accessibility functionality for that certified health IT. Rather, they will have the opportunity to consider other innovative ways to provide patients with accessible viewing functionality. In short, the purpose of certification under the Certification Program has been achieved in drawing attention to accessibility design and in establishing a baseline functionality for such design.
Further, as we noted in the 2011 Edition Interim Final Rule and again in response to comments on the 2011 Edition Interim Final Rule, in providing patients with access to their online health information, the accessibility requirements of the ADA and Section 504 of the Rehabilitation Act of 1973 still apply to entities covered by these Federal civil rights laws (75 FR 2036, 75 FR 44643). In addition, this final rule does not alter the obligations of any entity under the ADA,[36]
Section 504 of the Rehabilitation Act,[37]
Section 1557 of the Affordable Care Act,[38]
or any other applicable Federal or State law.
Even if a developer of certified health IT was not covered by relevant laws as suggested by a commenter, we expect developers to include, as requested by their clients (
e.g.,
health care providers), accessibility functionality needed to support their clients' compliance with applicable laws. In response to commenters' suggestions that the removal of the WCAG conformance requirement will increase both burden and costs for health care providers, we respectfully disagree. We recognize commenters' concern that removing the WCAG conformance requirement could place greater responsibility on health care providers to evaluate the accessibility of the health IT they purchase and use for compliance with relevant laws. However, the legal obligations of health care providers under applicable disability and accessibility laws are not affected by this final rule. In addition, costs of certification to the adopted WCAG standard are likely built into the certified health IT licensed or purchased by the health care provider. Costs for such functionality are also likely to be
( printed page 67949)
the same or less if purchased or licensed without certification.
For all these reasons, we expect health IT developers will continue to provide accessibility functionalities within their products certified to the VDT certification criterion and have finalized our proposal to remove the WCAG conformance requirement from the certification criterion (found in § 170.315(e)(1)(i)).
Comments.
A commenter encouraged ONC to consider revising the certification requirement to an attestation-based approach. Another commenter suggested that we adopt a functionally equivalent, testable accessibility baseline. Some commenters suggested further revising the criterion to withdraw the “view” requirements enumerated under sub-paragraph (i)(A) to have the flexibility to support basic “viewing” in more innovative and user-friendly formats and methods, while retaining the ability to “download” and “transmit” health information in the standardized HL7 CDA C-CDA document format for interoperability purposes. Another commenter suggested that we removed the VDT criterion completely.
Response.
These comments were outside the scope of the proposal and were not considered for finalization.
Network Time Protocol
Comments.
We received few comments on the proposal to remove the NTP conformance requirement. Those comments directly focused on the proposal offered support for removing the NTP conformance requirement. Commenters stated that aligning with a NTP standard was an established industry functionality. Commenters also noted that time synchronization is handled at the infrastructure or operating-system level; and that most environments already maintain accurate time through domain controllers or equivalent mechanisms. Commenters also expressed agreement with our assessment that certification adds little value and that developers will continue using NTP regardless of conformance requirements.
Response.
We thank commenters for their support. As noted in the Proposed Rule and supported by comments received on the Proposed Rule, the NTP functionality is not native to the EHR technology (rather part of the operating system within which the EHR technology runs) and unnecessary for certification because EHRs use of underlying operating system clocks is commonplace. Consistent with our overall goal to reduce regulatory burden, we agree that there is currently little value, and unnecessary burden, in maintaining the conformance requirement as part of certification. As noted in the Proposed Rule and confirmed by developers in comments of the Proposed Rule, we do not expect that developers will stop using NTP with their certified health IT. Rather, we expect that developers will continue to use NTPs, due to ongoing evolution in the industry. Accordingly, we have finalized our proposal to remove the NTP requirements from the VDT certification criterion.
Conforming Proposals
We did not receive any comments opposing our proposed conforming revisions to the VDT certification criterion. Therefore, we have finalized the conforming revisions as proposed. We have removed and reserved § 170.315(e)(1)(i)(A)(
1) because the requirement expired on December 31, 2025. We have revised § 170.315(e)(1)(i)(B)(
1) and (
2) to remove references to § 170.205(a)(5) because the standard codified in these paragraphs expired on December 31, 2025. We have provided a heading for the paragraph at § 170.315(e)(1)(i), which is “general.” This heading approach aligns with similar level paragraphs that have headings (§ 170.315(e)(1)(ii) and (iii)) and is compliant with the OFR Drafting Handbook.
We note that we have also corrected a grammatical error in § 170.315(e)(1)(i)(A)(
6)
(
i) by removing “specified all the data.” The provision now reads as follows: (
i) The information for a test report as specified in 42 CFR 493.1291(c)(1) through (7). It previously read as (
i) The information for a test report as specified all the data specified in 42 CFR 493.1291(c)(1) through (7).
All revisions to the VDT certification criterion are effective as of the effective date of this final rule.
b. Patient Health Information Capture
We proposed to remove and reserve the “patient health information capture” certification criterion in § 170.315(e)(3) with an effective date of January 1, 2027. The patient health information capture certification criterion allows health care providers to incorporate unstructured patient generated health data or data from a non-clinical setting into a patient record. The criterion is not currently included in the Base EHR definition; however, the criterion is included in the definitions of CEHRT established by CMS in 42 CFR 495.4 and 42 CFR 414.1305 for programs including the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category.
We have reviewed and evaluated the patient health information capture certification criterion in § 170.315(e)(3) and sought to identify ways to reduce burden while still supporting our policy goals. As we have stressed in prior rulemaking, we take an incremental approach to improving health IT interoperability and performance, relying on factors such as market prevalence and industry readiness to harmonize current and future standards and phase out standards and certification criteria as needed (75 FR 2021).
As we mentioned in the Proposed Rule, removing the patient health information capture certification criterion in § 170.315(e)(3) on January 1, 2027, would reduce administrative burden as well as burden for health IT developers of certified health IT and health care providers while still allowing us to achieve our policy goals (90 FR 60991 and 60992).
Comments.
Of the commenters who specifically commented on the patient health information capture proposal, they were generally evenly split on supporting or not supporting removal of the patient health information capture certification criterion (§ 170.315(e)(3)) with those in support noting that it would reduce burden by eliminating a criterion they described as widely implemented, poorly defined, or not delivering value.
Commenters not supporting removal (or recommending delay/retention) expressed concerns that removing the criterion could reduce support for incorporating patient- and caregiver-contributed information (including unstructured patient-generated health data) in certain settings, including Long Term and Post Acute Care, weaken patient engagement and accessibility, and create challenges for providers seeking to meet other program and interoperability expectations. Another commenter, who did not support the removal, recommended that we add the patient health information capture certification criterion to the Base EHR definition in § 170.102.
In particular, commenters noted that our proposal for removing the patient health information capture criterion would require additional guidance or specification of transition planning and impact evaluation (including coordination with other Federal program requirements). A commenter stated that ONC would also need to clarify how the shift toward FHIR-based APIs would support family caregiver access, including proxy access
( printed page 67950)
mechanisms, delegation workflows, and caregiver-contributed data capture through third-party applications.
Another commenter suggested delaying the removal of the criterion until at least 2028 to support alignment with CMS requirements.
Response.
We thank commenters for their input and support of our proposal to remove the patient health information capture certification criterion. We have finalized the removal of the patient health information capture certification as proposed with an effective date of January 1, 2027. As mentioned in the Proposed Rule and supported by a number of commenters, the capabilities described in the criterion are widely implemented and used in health IT at this time, suggesting that these capabilities will remain in health IT products even if the corresponding criterion is removed from the Certification Program (90 FR 60991). We also noted in the Proposed Rule that removing the criterion from the Certification Program could spur greater development and innovation in this area (90 FR 60991). We stated that there are other certification criteria that support patient engagement, such as the “view, download, and transmit to 3rd party” and “standardized API for patient and population services” certification criteria (90 FR 60991). We have seen developers integrate the functionality in the patient health information capture certification criterion as part of other patient engagement features, such as patient portals. With these considerations in mind, we believe removing this criterion from the Certification Program will help reduce burden and costs, while also spurring further innovations in patient engagement (90 FR 60991).
Because the certification criterion in § 170.315(e)(3) is a requirement for CEHRT definitions established by CMS, we proposed to remove the patient health information capture certification criterion in § 170.315(e)(3) effective January 1, 2027 (90 FR 60991), and we have finalized this date for removal in this final rule. Because patient health information capture is a requirement of the CEHRT definition, and both the Medicare Promoting Interoperability program and the MIPS program are on a calendar year rulemaking cycle, it is appropriate to align changes to the certification criteria that are included in the definition of CEHRT to a calendar year cycle as well. In the FY 2027 IPPS/LTCH PPS proposed rule, CMS proposed to update the definition of CEHRT in 42 CFR 495.4 to remove the cross-reference to the certification criterion in § 170.315(e)(3) (91 FR 19620). CMS finalized this proposal in the FY 2027 IPPS/LTCH PPS final rule, which appeared in the
Federal Register
on August 4, 2026 (91 FR 50033). CMS made similar proposals for the definition of CEHRT in 42 CFR 414.1305 in the 2027 Physician Fee Schedule proposed rule (91 FR 43842). This final action and proposed policy will (or would in the case of proposed policies) enable CMS to ensure that requirements in the definitions of CEHRT are updated to align with our final policy regarding the removal of this certification criterion. ONC will continue to coordinate with CMS to ensure alignment around changes resulting from the policies in this final rule.
We also appreciate commenters who opposed removal or recommended delaying removal based on concerns about patient- and caregiver-contributed information (including unstructured patient-generated health data) in Long Term and Post Acute Care settings, patient engagement, accessibility, and providers' ability to meet other program and interoperability expectations. We recognize the importance of enabling patients, families, caregivers, and other authorized representatives to contribute information. However, we do not believe that continued certification to § 170.315(e)(3) is necessary to preserve or advance those capabilities. The removal of the certification criterion does not prohibit health IT developers from continuing to offer these functions, does not prevent providers from using or procuring such capabilities, and does not limit the ability of health IT products to support patient- or caregiver-contributed information. Rather, removal means that this specific functionality will no longer be addressed through a certification criterion under the Certification Program. We acknowledge commenters' specific concerns regarding family caregiver access, proxy access, delegation workflows, and caregiver-contributed data capture through third-party applications. We agree that these are important use cases. However, § 170.315(e)(3) does not establish detailed requirements for proxy access, caregiver delegation, identity proofing, authorization management, or application-based caregiver contribution workflows. Retaining this criterion would therefore not, by itself, ensure that those more specific capabilities are available or implemented consistently across health IT products. We also decline to add the patient health information capture certification criterion to the Base EHR definition in § 170.102. Because we are finalizing removal of § 170.315(e)(3), adding the criterion to the Base EHR definition would be inconsistent with our determination that the availability of a certification criterion for this specific functionality is no longer necessary. The Base EHR definition reflects certification capabilities that remain necessary as a minimum foundation for certified health IT. Based on the widespread implementation of this functionality, the availability of other patient engagement and API criteria, and the burden associated with maintaining certification to § 170.315(e)(3), we do not believe this criterion should be added to the Base EHR definition. We also considered the recommendation to delay removal until at least 2028. We do not believe a further delay is necessary. The January 1, 2027, effective date allows for regulatory alignment with CMS program requirements under the CEHRT definitions while avoiding the continued burden of maintaining a certification requirement that no longer provides sufficient incremental value. Extending the criterion beyond that date would prolong certification and compliance costs for developers and providers without materially advancing patient engagement beyond what is already supported through existing product functionality, other certification criteria, and applicable Federal policies. ONC has a history of recognizing the importance of patient engagement as a core component of modern healthcare, driving improved outcomes, enhanced safety, and lower costs by leveraging technology and intends to continue doing so with future policies. The ONC Cures Act Final Rule implemented parts of section 4006(a) of the Cures Act to support patients' access to their EHI in a form convenient for patients, such as making a patient's EHI more electronically accessible through the adoption of standards and certification criteria and the implementation of information blocking policies that support patient electronic access to their health information at no cost (85 FR 25644). Specifically, the ONC Cures Act Final Rule supported patient access to their health information by: (1) enabling patients to securely access their EHI using smartphone applications of their choice through standardized APIs; (2) emphasizing under the information blocking “fees exception” that an actor's practice of charging for the electronic access to EHI by a patient, their personal representative, or another person or entity designated by the patient, would be inherently suspect under an information blocking review; and (3)
( printed page 67951)
permitting actors regulated by the information blocking regulations to educate and advise individuals about privacy and security risks posed by applications they use to steward their information while also fully supporting an individual's right to choose which application(s) they want to share their EHI with—if any. The HTI-1 Final Rule further supported patients by requiring developers certified to the “view, download, and transmit to 3rd party” certification criterion to support an “internet-based method” for patients to request a restriction on the use or disclosure of their data (89 FR 1299). We will continue to prioritize patient and caregiver engagement and monitor future developments. ONC seeks to further the advancement of patient engagement by promoting electronic access to health data and increasing resources dedicated to curbing the practice of information blocking.[39]
6. Public Health Certification Criteria
a. Transmission to Cancer Registries
We proposed to remove and reserve the “transmission to cancer registries” certification criterion in § 170.315(f)(4) with an effective date of January 1, 2027. This criterion assesses whether a Health IT Module can properly create and format cancer case information for electronic transmission according to a CDA-based implementation specification for reporting to public health agencies. We stated that removing the certification criterion in § 170.315(f)(4) would reduce burden and encourage ongoing evolution in cancer registry reporting by offering health IT developers space to move toward FHIR standards and modern reporting solutions, further encouraging innovation.
Comments.
The large majority of commenters were not supportive of removing the transmission to cancer registries certification criterion in § 170.315(f)(4), primarily due to the criterion aiding in developers' support of cancer registry reporting and concern that FHIR-based replacements are still under development and not yet sufficiently tested, adopted, implemented, or operationally ready to serve as a successor for the criterion. A commenter who stated they had participated in pilot testing of current FHIR resources for cancer reporting stressed that the current FHIR resources have potential but are not yet ready for broad operational deployment. Some commenters stated that many receiving public health systems are not ready to operationalize FHIR at scale. Several commenters stated that the current CDA-based reporting approaches are still necessary and relied upon by registries and providers, and the criterion encourages developers to support cancer registry reporting functionality. Many commenters expressed support for moving toward FHIR-based solutions but stated that we should retain the current CDA-based criterion until FHIR is consistently implemented by providers and cancer registries and can be included in an updated criterion. Commenters expressed concerns that removal of the certification criterion would disrupt timely, complete, and standardized cancer case reporting, create a reporting gap, and shift burden to providers and public health registries.
Response.
We thank commenters for expressing these concerns regarding removing the certification criterion in § 170.315(f)(4), including concerns that developers would no longer support cancer registry reporting and that standardized reporting and interoperability would be disrupted. We also appreciate the concerns regarding public health systems and FHIR readiness. In light of issues raised by commenters and our reconsideration of the proposal in response thereto, we have decided not to finalize the proposal to remove the certification criterion in § 170.315(f)(4). However, we also agree with the multiple comments supporting movement toward FHIR-based solutions, and we have confidence in the future progression of FHIR in this space. We intend to continue to monitor and support advancements in the use of FHIR-based standards for cancer reporting and reflect such advancements in Certification Program requirements in the future as appropriate.
Comments.
Many commenters stated that the proposed removal of the certification criterion in § 170.315(f)(4) would shift burden to providers and public health in a variety of ways. Commenters stated that removal of the certification criterion could result in increased variability, uneven implementations, bespoke interfaces, and a return to manual or non-standardized processes. Commenters stated that registries could be required to do more local specification, onboarding, testing, validation, and direct developer coordination as a result of removal of the certification criterion.
Response.
We appreciate these comments regarding the potential for burden shifting due to the proposed removal of the certification criterion in § 170.315(f)(4). We have not finalized the proposed removal of the certification criterion in § 170.315(f)(4) for the reasons noted in the response directly above.
Comments.
Some commenters expressed concerns that the proposal could disrupt cancer reporting to a degree that it would negatively impact cancer care and research. Commenters stated that data quality, completeness, timeliness, continuity, and reliability could decline as a result of removal of the certification criterion in § 170.315(f)(4). Some commenters described cancer reporting as too important to risk such disruption and noted the importance of cancer reporting to surveillance, incidence tracking, research, disparities work, treatment evaluation, prevention, resource allocation, and public health investigations. Some commenters viewed certification to the certification criterion in § 170.315(f)(4) as an important safeguard or accountability mechanism to ensure against disruption in cancer reporting.
Response.
We thank commenters for these comments expressing concern regarding a potential disruption of cancer reporting. We agree with comments regarding the importance of cancer reporting and its impact on cancer care and research. Given the value that commenters indicated certification continues to bring to this use case as well as the concerns raised by commenters regarding disruption of standardized reporting and interoperability, we have not finalized the proposed removal of the certification criterion in § 170.315(f)(4).
Comments.
Some commenters expressed concerns that the proposal does not align with CMS program requirements. Some commenters noted that providers still rely on this functionality for the MIPS Promoting Interoperability performance category and related public health participation.
Response.
We thank commenters for expressing these concerns about CMS alignment. We noted in the Proposed Rule that MIPS eligible clinicians that report on the Public Health Registry measure in the MIPS Promoting Interoperability performance category may earn optional bonus points for submitting data to cancer registries using health IT certified to the criterion in § 170.315(f)(4) (90 FR 60992). We have not finalized the proposed removal of the certification criterion in § 170.315(f)(4) and do not anticipate any issues regarding alignment with CMS program requirements.
Comments.
Some commenters stated that the proposal relies on an incomplete understanding of the Helios
( printed page 67952)
work. They stated that the Helios cancer work is about query/response or supplemental follow-up information and is not a replacement for initial cancer case reporting.
Response.
We thank commenters for these comments. Commenters are correct that Helios has worked on query/response, but there are other HL7 initiatives and standards development work related to cancer reporting. ONC will continue to monitor progress on the FHIR-based Central Cancer Registry Reporting Content Implementation Guide, as well as the work related to USCDI+ Cancer [40]
and their associated implementation guides. Specifically, USCDI+ Cancer has been working closely with the Central Cancer Registry Reporting Content Implementation Guide v2.0 to incorporate early incidence reporting from EHR data. This version was balloted in January 2026.
Comments.
A few commenters stated that removing the certification criterion in § 170.315(f)(4) would weaken incentives for EHRs and developers to support interoperability.
Response.
We thank commenters for expressing concerns about maintaining developer support for interoperability. We appreciate the important role of the Certification Program in improving interoperability and will continue to support that goal through Certification Program requirements. As stated above, we have not finalized the proposed removal of the certification criterion in § 170.315(f)(4), and we will continue to monitor industry progress to inform whether future rulemaking is needed to help ensure interoperability and effective reporting to cancer registries.
Comments.
Several commenters stated that substantial investment has already been made in the current CDA standards-based infrastructure, and removal could undo harmonization progress.
Response.
We thank commenters for these comments regarding the investments made to date in CDA-based standards for cancer reporting. We have not finalized the proposed removal of the certification criterion in § 170.315(f)(4), and we will continue to monitor industry progress towards FHIR-based standards for cancer reporting.
Comments.
Several commenters expressed concerns about timelines and stated that developers, registries, public health agencies, and providers need more implementation time before removal of the certification criterion in § 170.315(f)(4). Another commenter supported an effective date no earlier than January 1, 2029, for the removal of the CDA-based public health-related certification criteria and the adoption of FHIR-based approaches to reporting.
Response.
We appreciate the concerns regarding timelines and the need for more implementation time prior to removal of the certification criterion in § 170.315(f)(4). We have not finalized the proposed removal of the certification criterion in § 170.315(f)(4).
Comments.
Some commenters expressed support for removal of the criterion, stating that it could reduce burden, was appropriate given low adoption of the current criterion, and could allow developers to shift efforts toward FHIR-based reporting. A commenter stated that provider-based reporting for cancer is likely redundant because a mandate for laboratory reporting already exists under the Clinical Laboratory Improvement Amendments (CLIA).
Response.
We thank commenters for these comments in support of our proposal. We agree with commenters regarding the importance of shifting toward FHIR-based reporting to cancer registries. While we have not finalized our proposal to remove this certification criterion at this time, we will continue to monitor advancements in FHIR-based cancer reporting.
Regarding the comment received regarding the redundancy of provider-based cancer reporting due to CLIA requirements, we note that the CLIA requirements in 42 CFR part 493 only require that a laboratory has “an adequate manual or electronic system(s) in place” [41]
to send test results accurately and reliably, and thus the standards-based certification requirements in § 170.315(f)(4) are not redundant. Further, CLIA covers pathology reporting and laboratories, and cancer registry reporting encompasses more than pathology and covers hospitals and providers, in addition to laboratories.
Comments.
Several commenters identified issues that are out of scope, such as broader public health infrastructure funding and workforce readiness, contract language issues, the need to coordinate updates to State reporting laws, expanding Health IT certification requirements to public health systems, CDC's Vocabulary Access and Distribution System, and coordination with other agencies to avoid misaligned incentives.
Response.
We thank commenters for these comments. However, these comments were outside the scope of this rulemaking.
b. Transmission to Public Health Agencies—Electronic Case Reporting
We proposed to revise the “transmission to public health agencies—electronic case reporting” (eCR) certification criterion in § 170.315(f)(5). This criterion enables a user to create case reports that can be transmitted electronically to public health agencies. We proposed to revise the eCR certification criterion to be a functional requirement in order to reduce burden and allow for industry innovation. In particular, we proposed to rescind the expiration date for the functional requirements defined in § 170.315(f)(5) as of the effective date of this final rule. We proposed to revise the introductory text of the criterion to enable a user to create a case report for electronic transmission meeting the functional requirements described in paragraph (f)(5)(i) of this section. Additionally, we proposed to remove the standards-based requirements defined in § 170.315(f)(5)(ii) as of the effective date of this final rule and to reserve that section.
Comments.
The vast majority of comments, including those from health care providers, developers and public health, were not supportive of revising the eCR certification criterion to remove standards-based requirements and rely on a functional-only approach, primarily due to concerns that FHIR-based standards for eCR are still maturing and not ready as a replacement for CDA-based standards. Several commenters also stressed that many receiving public health systems were not ready for FHIR-based reporting. Some commenters recommended retaining flexibility for either CDA-based or FHIR-based standards for eCR in the short-term and moving exclusively to FHIR-based requirements only after the FHIR standard fully matures and there is sufficient implementation time to ensure that the CDC, Public Health Authorities (PHAs), and physicians have the technology and standards in place to transition to FHIR. Some commenters stressed that the current requirement provides an opportunity to use CDA-based or FHIR-based standards and to migrate as needed, thus serving as a clear glidepath to FHIR-based standards and enabling progress toward exclusively FHIR-based eCR in the future. Many commenters indicated support for FHIR-based eCR in the future but expressed concerns that
( printed page 67953)
revising the eCR certification criterion to remove standards-based requirements prior to a FHIR-based standard being widely available would increase variability in implementations, shift burden to providers and public health agencies, and reduce the timeliness, completeness, and reliability of public health reporting.
Response.
We thank commenters for expressing these concerns regarding revising the eCR certification criterion in § 170.315(f)(5) to be a functional requirement prior to having a mature FHIR-based standard widely available. We recognize that there is still a significant amount of reliance on CDA-based standards for eCR as well as limited adoption of FHIR-based standards for eCR on both the sending and receiving ends of transactions. Having considered the points raised by commenters, we have decided not to finalize the proposal to revise the certification criterion in § 170.315(f)(5) to be a functional requirement. However, we also have confidence in the future progression of FHIR in this space and agree with commenters that retaining the ability to certify to either CDA-based standards or FHIR-based standards for eCR in the meantime can provide a helpful glidepath and encourage progress toward a fully FHIR-based future.
Comments.
A number of commenters expressed concerns about removing standards in the eCR criterion and making it a functional criterion. Several commenters stressed that a functional-only approach would undermine interoperability, consistency, and predictability. Some stressed that the shift to functional requirements could degrade data quality, integrity, completeness, timeliness, reliability, usability, and comparability. Some commenters stated that a functional requirement could result in increased integration burdens on downstream systems such as public health agencies. Some commenters stated that the proposal would disrupt significant progress that has been made through standards-based eCR adoption. These commenters stated that standards-based eCR adoption has steadily increased and has reduced burden on both public health and healthcare organizations to meet reporting requirements. Another commenter stated that removal of standards-based requirements may result in fragmented and jurisdiction-specific reporting. Some commenters stressed that standards are needed to prevent inconsistencies and variability that would undermine public health efforts, including outbreak response and real-time surveillance, and require burdensome workarounds. Several commenters noted specific benefits of the eCR criterion, including detecting and responding to communicable diseases impacting the population. Another commenter stated that having the eCR criterion as part of CEHRT has been vital to advancing eCR and that if it becomes a functional requirement only, PHAs would have the burden of processing non-standardized formats and providers may revert to fax-based reporting, eroding efficiency and reversing progress.
Response.
We appreciate the concerns expressed by commenters regarding removal of standards in the eCR criterion and instead relying on functional requirements, including concerns that it would result in fragmentation and variability that would impede public health efforts and increase burden. While functional requirements are appropriate in some instances, we recognize that may not be the case where there is ongoing modernization of standards. We agree with commenters that the current criterion requirements, which allow the use of either CDA-based standards or FHIR-based standards for eCR, have been successful in moving eCR forward to date and that retaining them for the time being can help ensure continued progress. We have not finalized the proposal to revise the certification criterion in § 170.315(f)(5) to be a functional requirement. We will continue to monitor advancements in the use of FHIR-based standards for eCR.
Comments.
A number of commenters expressed concerns that the proposal would reduce public health situational awareness, create public health operations issues, and weaken emergency preparedness, including disease surveillance and outbreak detection and response.
Response.
We thank commenters for expressing these concerns, and we understand the importance of not impeding vital public health operations. We have not finalized the proposal to revise the certification criterion in § 170.315(f)(5) to be a functional requirement.
Comments.
A number of commenters expressed concern about burden. Some commenters stated that burden would move from certification and developers to providers, public health agencies, and governments. Some commenters stressed that small, rural and under-resourced providers would be particularly impacted by increased burden. In addition, some commenters stated that public health agencies lacked the infrastructure, workforce, funding, or governance capacity to transition to FHIR. Some commenters stated that the proposal will shift the burden of assessing health IT functionality and standards adoption away from ONC to the users of health IT, imposing additional burden on individuals, governments, and healthcare organizations as they evaluate and select health IT to purchase and implement. Several commenters characterized the proposal as an unfunded mandate.
Response.
We appreciate these commenter concerns regarding burden. We understand that for many under-resourced settings moving toward FHIR-based standards for eCR could be burdensome. We have not finalized the proposal to revise the certification criterion in § 170.315(f)(5) to be a functional requirement and are retaining the current criterion requirements, which require the use of either CDA-based standards or FHIR-based standards for certification to the eCR criterion. This addresses commenter concerns about burden and, as stated above, provides a helpful glidepath toward more ubiquitous FHIR-based eCR in the future.
Comments.
Several commenters stated that developers who already invested in the current standards-based options in § 170.315(f)(5)(ii) would be penalized. Another commenter was concerned that all developers were required to comply with paragraph § 170.315(f)(5)(ii) by February 28, 2026, and that developers would now be required to revert back to meeting the requirements of § 170.315(f)(5)(i). They noted that paragraph § 170.315(f)(5)(i) specifically refers to standards in § 170.213, § 170.207(i), and § 170.207(a)(1) and that reverting back to § 170.315(f)(5)(i) would create additional burden for developers by requiring them to ensure their product meets those requirements and to attest to paragraph § 170.315(f)(5)(i) again.
Response.
We thank the commenter for raising this concern. We have not finalized the proposal to revise the certification criterion in § 170.315(f)(5) to be a functional requirement and have retained the current criterion requirements. Additionally, we recognize and appreciate the efforts of developers who have certified to the requirements in § 170.315(f)(5)(ii).
Comments.
Several commenters recommended extending expiration dates, generally recommending establishing an expiration date for CDA-based eCR no later than December 31, 2028, and for full FHIR-based implementation of eCR by January 1, 2029.
( printed page 67954)
Response.
We thank commenters for these comments. We have not finalized the proposal to revise the certification criterion in § 170.315(f)(5) to be a functional requirement.
Comments.
Several commenters expressed concerns about aligning with CMS programs.
Response.
We appreciate these concerns regarding alignment with CMS programs. We note that the certification criterion in § 170.315(f)(5) is currently required to complete the Electronic Case Reporting measure in the CMS MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program.[42]
In the “Medicare and Medicaid Programs; CY 2026 Payment Policies Under the Physician Fee Schedule and Other Changes to Part B Payment and Coverage Policies; Medicare Shared Savings Program Requirements; and Medicare Prescription Drug Inflation Rebate Program” final rule (CY 2026 PFS final rule), CMS finalized a policy to suppress the measure for performance for MIPS eligible clinicians meeting the requirements of the MIPS Promoting Interoperability performance category for the CY 2025 performance period and for eligible hospitals and CAHs participating in the Medicare Promoting Interoperability Program for the EHR reporting period in CY 2025 (90 FR 49892). As there is no change to the availability of the certification criterion in § 170.315(f)(5) under this final rule, there is no related impact to current CMS requirements with respect to certified functionality for the Electronic Case Reporting measure.
Comments.
Comments in support of the proposal stated it would reduce unnecessary standards-specific burden, avoid prescribing standards before the public health sector is ready, and allow continued use of existing operational exchange pathways.
Response.
We thank commenters for these comments in support of our proposal. We understand the importance of reducing unnecessary burden on developers of certified health IT as well as the need to avoid requiring standards before the public health sector is ready. Due to commenter concerns regarding the potential standards-conformance and interoperability impact of moving to a functional approach, we have retained the current criterion requirements which requires the use of either CDA-based standards or FHIR-based standards for certification to the eCR criterion. We believe this will help provide a glidepath toward more universal adoption of FHIR-based eCR in the future.
Comments.
Several commenters identified issues that were out of scope for our proposal. These included comments regarding the enforcement discretion, adoption of newer standards, broader public health infrastructure funding, incentives for adoption, CDC's Vocabulary Access and Distribution System, trigger standardization, alternative oversight or accountability mechanisms outside certification, and finalizing our proposals in HTI-2.
Response.
We thank commenters for these comments; however, these comments were outside the scope of this rulemaking.
c. Transmission to Public Health Agencies—Antimicrobial Use and Resistance Reporting
We proposed to revise the “transmission to public health agencies—antimicrobial use and resistance reporting” certification criterion in § 170.315(f)(6). This criterion assesses whether Health IT Modules can create and properly format an antimicrobial use and resistance report for electronic transmission, following specified sections of a CDA-based implementation guide. We proposed to revise the criterion requirements to be functional only and proposed to remove the reference to the standard in § 170.205(r)(1) as of the effective date of this final rule.
Comments.
The majority of commenters were not supportive of revising the transmission to public health agencies—antimicrobial use and resistance reporting certification criterion in § 170.315(f)(6) to remove referenced standards and rely on a functional requirement, often due to concerns that FHIR was not fully mature or widely adopted. Several commenters stated that receiving public health agencies were not ready for full FHIR-based reporting, and some stated that the existing CDA-based standards for reporting to public health have been adopted in a number of settings and are important for continuity. Some commenters expressed concerns about timing due to lack of FHIR readiness and did not support revising the certification criterion in § 170.315(f)(6) to remove the referenced CDA-based standard until a FHIR-based replacement was operationally ready. Another commenter supported an effective date no earlier than January 1, 2029, for any changes to the certification criterion in § 170.315(f)(6) and for removal of the CDA-based public health-related certification criteria and adoption of FHIR-based approaches to reporting. Commenters had concerns that without a FHIR-based replacement available, removal of the referenced standard in § 170.315(f)(6) would reduce standardization, increase variability, shift burden and costs to providers and public health agencies, and disrupt public health reporting and surveillance.
Response.
We thank commenters for expressing these concerns regarding FHIR readiness and removing the CDA-based standards from the certification criterion in § 170.315(f)(6). We recognize that for certain public health use cases CDA-based standards are widely used for public health reporting and FHIR-based standards are still in development. However, antimicrobial use and resistance reporting is made to the CDC's National Healthcare Safety Network (NHSN), and the CDA-based standard referenced in § 170.315(f)(6) is currently not aligned with NHSN requirements. Additional rulemaking to address this misalignment would likely require several years to complete, and we believe that lack of alignment with NHSN requirements will undermine the effectiveness of the certification criterion in § 170.315(f)(6) until such steps can be completed. As we noted in the Proposed Rule, the CDC is working to move reporting to FHIR-based standards [43]
and has already implemented a more recent version of the CDA-IG. Further, we identified trends within the industry regarding a shift in reporting approach that supports revision of this criterion (90 FR 60993).[44]
Revising the certification criterion in § 170.315(f)(6) to include a functional requirement rather than a mis-aligned CDA-based requirement ensures that antimicrobial use and resistance reporting capabilities are still included in certified health IT while also allowing developers of certified health IT to better align with, and advance alongside, NHSN requirements at this time. Accordingly, we have adopted our revisions as proposed. We will continue to monitor the development of FHIR-based standards in this area as they mature.
Comments.
Several commenters expressed concerns about burden, including increasing manual reporting burden on providers and registries. Commenters expressed concern that the
( printed page 67955)
proposal would result in increased variability and significant integration work for health IT developers, healthcare organizations, and public health agencies, as well as increased burden around selecting health IT. Some commenters expressed concern that significant costs would shift to providers and public health.
Response.
We appreciate concerns regarding increased costs and burdens for providers, public health, and health IT developers. We understand the importance of ensuring interoperability and reducing variability in public health reporting. However, the current standard in § 170.315(f)(6) is misaligned, and including, as we have finalized, a functional requirement in § 170.315(f)(6) instead will allow for better alignment with NHSN reporting requirements while still ensuring that certified health IT has antimicrobial use and resistance reporting capabilities.
Comments.
Several commenters expressed concern about alignment with CMS requirements.
Response.
We thank commenters for these comments regarding CMS alignment. We noted in the Proposed Rule that the certification criterion in § 170.315(f)(6) is required for completing the Antimicrobial Use Surveillance and Antimicrobial Resistance Surveillance measures in the Medicare Promoting Interoperability Program for eligible hospitals and CAHs (90 FR 60993). We did not propose to remove the certification criterion in § 170.315(f)(6), and even though we have revised it to include functional requirements only, we do not anticipate any alignment issues with CMS requirements, as eligible hospitals and CAHs would continue to use EHR technology certified to the criterion when reporting the measure.
Comments.
Several commenters expressed concerns about replacing the current standards-based requirements with functional requirements. Some commenters stated that functional requirements could undermine interoperability, consistency, and predictability. Another commenter recommended listing multiple standards instead of having a functional requirement.
Response.
We appreciate commenter concerns regarding issues with functional requirements. We understand the importance of ensuring interoperability and consistency in public health reporting. However, the current standard in § 170.315(f)(6) is misaligned with NHSN reporting requirements, and including a functional requirement in § 170.315(f)(6) instead will allow for better alignment with NHSN reporting requirements while still ensuring that certified health IT has antimicrobial use and resistance reporting capabilities.
Comment
s. Several commenters requested that ONC provide a clearer transition path toward FHIR-based reporting, and another commenter who supported the proposal suggested ongoing monitoring and implementation guardrails as reporting transitions from the C-CDA standards required in the criterion.
Response.
We appreciate these comments regarding a transition path toward FHIR-based reporting. As noted above, the CDC is working to move reporting to FHIR-based standards, and revising the certification criterion in § 170.315(f)(6) as proposed to include a functional requirement will allow developers of certified health IT to move to FHIR-based standards as those standards mature. Further, the functional criterion will allow developers to use the most recent version of the CDA IG as the FHIR transition occurs. As discussed above, there is current misalignment, even with SVAP, between the certification criterion's standard and NHSN. The shift to a functional criterion will allow for faster implementation of standards advancement and remove the current issue with misalignment between Federal programs. We encourage that transition to FHIR-based standards and note that we will continue to provide resources and guidance regarding movement toward FHIR-based standards on our website.
Comments.
Commenters in support of the proposal stated that it would reduce the burden of maintaining duplicative standards and better align certification with NHSN reporting requirements. They stated that because AUR reporting is exclusively directed to the NHSN, which has its own separate standards and validation process, the current certification requirement is duplicative. Some commenters stated that the criterion was poorly adopted.
Response.
We thank commenters for their comments in support of our proposal. We agree with commenters that the current standard in § 170.315(f)(6) is misaligned with NHSN reporting requirements and creates burden for developers of certified health IT. We have finalized the proposal as proposed.
Comments.
Several commenters identified issues that were out of scope for our proposal. These included comments regarding penicillin allergy de-labeling, preferred terminology choices, laboratory order and result standards, contracting language for public health exchange, withdrawn proposals from HTI-2, and incentives for FHIR adoption.
Response.
We thank commenters for these comments. However, these comments were outside the scope of this rulemaking. We have finalized the proposal as proposed.
d. Transmission to Public Health Agencies—Health Care Surveys
We proposed to remove the “transmission to public health agencies—health care surveys” certification criterion in § 170.315(f)(7). This criterion supports the transmission of health care surveys directly to the CDC. We stated that removing the certification criterion in § 170.315(f)(7) would reduce burden while at the same time honoring our policy goals to ensure health IT interoperability and functionality (90 FR 60994). We also stated that removal would encourage industry to modernize reporting approaches alongside CDC's efforts (90 FR 60994). We proposed a January 1, 2027, effective date for the removal of the transmission to public health agencies—health care surveys criterion in § 170.315(f)(7).
Comments.
The majority of commenters were not supportive of our proposal to remove the transmission to public health agencies—health care surveys certification criterion in § 170.315(f)(7), primarily due to concerns that FHIR-based standards are not mature enough and receiving public health systems are not ready for FHIR-based reporting. While commenters often expressed support for FHIR-based public health reporting in the future, many commenters stated that readiness, implementation, scalability, maintenance, and receiving-system capacity for FHIR-based public health reporting are not yet sufficient. Several commenters stated that immediate removal of the certification criterion in § 170.315(f)(7) is not appropriate without a future FHIR path, or other alternative, in place before removal. Commenters expressed concerns that without a replacement, removal of the certification criterion in § 170.315(f)(7) would weaken established reporting capabilities, reduce standardization, increase manual processes or burden, and disrupt data used for public health planning, surveillance, and quality reporting. Some commenters recommended retaining the criterion until January 1, 2029. A few commenters recommended a short-term functional requirement, paired with clear milestones toward broader FHIR adoption, although several other commenters expressed opposition to a
( printed page 67956)
functional requirement. Another commenter recommended adding a FHIR-based standard to the requirements in § 170.315(f)(7) in addition to the current CDA-based standard. Some commenters recommended that ONC establish a clear transition path to FHIR-based reporting, with guidance on retaining CDA-based capabilities during transition and alternative accountability mechanisms.
Response.
We appreciate these concerns regarding FHIR-readiness and perceived premature removal of the certification criterion in § 170.315(f)(7). We understand that currently CDA-based standards are used in a number of settings for public health reporting. After considering the concerns expressed by commenters, we have decided not to finalize the proposal to remove the certification criterion in § 170.315(f)(7). However, we also agree with comments expressing support for movement toward FHIR-based reporting in the future, and we anticipate significant advancements toward FHIR in this space. In the Proposed Rule, we noted CDC priorities around data modernization and encouraging the use of FHIR-based approaches for public health reporting (90 FR 60994). We intend to continue to monitor and support the progression of FHIR-based standards for health care surveys.
Comments.
Several commenters expressed concern that the proposal would disrupt recent progress in standardizing public health reporting. Some commenters stated that public health reporting has made meaningful progress through standards-based exchange and that removal of this criterion could reverse that progress. Several commenters stated that moving away from standards-based certification could increase variability, fragmentation, and uneven implementation.
Response.
We appreciate these comments regarding the recent progress in standardizing public health reporting, and we understand the importance of ensuring continued participation in, and reporting of, health care surveys. We have not finalized the proposed removal of the certification criterion in § 170.315(f)(7), but we will continue to monitor and support the progression of FHIR-based standards for healthcare reporting.
Comments.
A number of commenters expressed concern about burden. Some commenters stated that the proposal could shift burden and costs downstream to providers and public health agencies. Commenters stated that removal of the certification requirement could result in burden for providers and PHAs regarding tracking, custom integration, manual work, and other operational issues. Some commenters stated that burden on health IT developers, healthcare organizations and public health agencies could increase because removal of standards-based transmission requirements may result in increased variability and capabilities in EHR systems. Another commenter stressed that while removal may allow room for industry innovation, public health would not have the resources to actually innovate.
Response.
We appreciate these comments regarding the potential for burden shifting due to the proposed removal of the certification criterion in § 170.315(f)(7). We acknowledge that commenters identified burden-reduction benefits related to certification to this criterion. We have not finalized the proposed removal of the certification criterion in § 170.315(f)(7).
Comments.
Several commenters expressed concerns that new certified products might no longer support survey submission if the criterion is removed and that this would harm the reporting ecosystem. Some commenters stated that vendor investment and maintenance could erode without the certification requirement in place and that the resulting degradation in CDA document exchange could disrupt public health reporting. Another commenter recommended that where certification requirements are removed, ONC should take steps to prevent these functions from becoming optional vendor add-ons and prevent shifting disproportionate burden onto provider organizations.
Response.
We thank commenters for expressing these concerns regarding a potential lack of support for health care surveys in certified health IT as a result of the proposed removal of the certification criterion in § 170.315(f)(7). We have not finalized the proposed removal of the certification criterion in § 170.315(f)(7).
Comments.
Several commenters questioned the burden-reduction rationale for the proposal. They stated that the current capability is already well established and retaining it would not impose meaningful additional burden.
Response.
We thank commenters for their comments regarding burden reduction. We appreciate that for well-established functionality there may not be significant burden related to maintaining the certification criterion in § 170.315(f)(7), however we note that there would still be burden related to certifying to this criterion.
Comments.
Some commenters expressed support for our proposal to remove the certification criterion in § 170.315(f)(7). Commenters stated that the proposal would reduce burden where survey submission is infrequent or lacks a clear, consistent submission pathway. Another commenter stated that providers are rarely asked to submit data and that significant development investment has yielded minimal public health benefits.
Response.
We thank commenters for these comments in support of our proposal. We understand the importance of reducing burden on developers of certified health IT as well as the need to ensure that burden reduction does not negatively impact core Certification Program policy priorities around interoperability. We have not finalized the proposed removal of the certification criterion in § 170.315(f)(7).
Comments.
Several comments were out of scope. These included comments regarding Certification Program oversight, redundant requirements, Conditions of Participation alignment, enhanced real-world testing, testing tools, third-party testing, and structured attestation.
Response.
We thank commenters for these comments. However, these comments were outside the scope of this rulemaking.
7. Design and Performance Certification Criteria
a. Automated Numerator Recording
As discussed in the Proposed Rule, the certification criterion in § 170.315(g)(1) requires the capability to create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the numerator of a percentage-based measure in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program (90 FR 60994).
In the Proposed Rule, we proposed to remove the “automated numerator recording” certification criterion and reserve § 170.315(g)(1) with an effective date of January 1, 2027. We stated in the Proposed Rule that we reviewed and evaluated the certification criterion in § 170.315(g)(1), seeking to identify ways to reduce burden while still supporting our policy goals. We explained that we believe that developers now have significant experience with implementing CMS measure requirements in the Promoting
( printed page 67957)
Interoperability programs, and they will continue to ensure that the measures are recorded in a fashion that meets CMS requirements to ensure that their customers can successfully participate in the absence of additional testing requirements under the Certification Program. (90 FR 60994).
Comments.
We received a number of comments that expressed concern that the removal of § 170.315(g)(1) would reduce reliable and transparent assurance of accurate calculation for Health IT Modules. These commenters stated that without the certification criterion in § 170.315(g)(1), customers would not have assurance that the metrics for Health IT Modules are accurate. Some commenters suggested that the removal of § 170.315(g)(1) would shift burden to health care providers who would need to conduct their own testing to verify the metrics for Health IT Modules. Several commenters also asserted that new health IT developers may not conform to the standard without the requirement of certifying to § 170.315(g)(1) affecting the functionality of Health IT Modules.
Response.
We appreciate commenters' concerns about the lack of assurance of accurate calculation for measures in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category if § 170.315(g)(1) is removed. We note that developers now have more time and experience with CMS programs than when this certification criterion was first adopted. We believe that health IT developers will continue to ensure that patients or actions included in a measure's numerator are recorded in a fashion that supports accurate calculation to meet CMS requirements without needing to certify to § 170.315(g)(1). We further note that CMS has previously clarified, under the EHR Incentive Programs which preceded the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category, that while CEHRT must include this capability, program participants may use a separate, non-certified system to calculate numerators and denominators and to generate reports on the measures.[45]
Comments.
We received a number of comments that expressed concern that the removal of § 170.315(g)(1) would create a lack of alignment with the requirements that CMS maintains in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. Some commenters questioned if the removal of § 170.315(g)(1) would reduce burden for health IT developers if CMS maintains its requirements in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. Many commenters requested that we work with CMS to provide clear guidance and address alignment issues regarding the transition to remove § 170.315(g)(1). Several commenters also suggested that we delay the removal of § 170.315(g)(1) to allow time to address CMS alignment with the removal of the certification criterion.
Response.
We appreciate the comments about alignment with the requirements in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. In the FY 2027 IPPS/LTCH PPS proposed rule, we note that CMS proposed to remove the cross-reference to § 170.315(g)(1) in 42 CFR 495.4, which is applicable to the Medicare Promoting Interoperability Program for eligible hospitals and CAHs, effective January 1, 2027 (91 FR 19620). CMS finalized this proposal in the FY 2027 IPPS/LTCH PPS final rule which appeared in the
Federal Register
on August 4, 2026 (91 FR 50033). CMS has made a similar proposal with respect to the MIPS Promoting Interoperability category in the CY 2027 PFS proposed rule (91 FR 44170). We believe that CMS' final and proposed revisions to the definition of CEHRT in 42 CFR 495.4 and 42 CFR 414.1305 allow for alignment with our timeline for the removal of the certification criterion in § 170.315(g)(1). We will continue to coordinate with CMS as it seeks to implement and finalize these proposals.
We also noted in the Proposed Rule that if we ultimately finalized the removal of § 170.315(g)(1), we would work with CMS to ensure relevant guidance and materials for existing measures are consolidated as part of the informational materials that CMS maintains regarding measures in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category (90 FR 60994). We believe that this coordination will minimize any burden for program participants.
Comments.
We received a number of comments that expressed support for our proposal to remove the certification criterion. These commenters stated that the removal of § 170.315(g)(1) would reduce burden from testing to certify to the certification criterion for health IT developers because the testing requirements for certification to § 170.315(g)(1) were difficult to assess and burdensome to conduct for health IT developers. Another commenter also asserted that the numerator/denominator measurement model supported by the certification criterion in § 170.315(g)(1) is obsolete in the current health IT industry.
Response.
We appreciate the comments we received about the burden. We have finalized the removal of § 170.315(g)(1) with an effective date of January 1, 2027, as proposed. We look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.
b. Automated Measure Calculation
As discussed in the Proposed Rule, the certification criterion in § 170.315(g)(2) requires the capability to record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable measure in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category (90 FR 60994).
In the Proposed Rule, we proposed to remove the “automated measure calculation” certification criterion and reserve § 170.315(g)(2) with an effective date of January 1, 2027. We explained in the Proposed Rule that we reviewed and evaluated the certification criterion in § 170.315(g)(2), seeking to identify ways to reduce burden while still supporting our policy goals. As with the automated numerator recording certification criterion discussed above, health IT developers that facilitate customer participation in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category have been supporting the calculation of measures in the program and its previous iterations for many years. We explained that we believe that developers now have significant experience with implementing the CMS measure requirements, and that they will continue to ensure that the measures are calculated in a fashion that meets CMS requirements to ensure that their customers can successfully participate in these programs in the absence of additional testing requirements under the Certification Program (90 FR 60995).
Comments.
We received a number of comments that expressed concern that the removal of § 170.315(g)(2) would reduce reliable and transparent assurance of accurate calculation for Health IT Modules. These commenters stated that without the certification criterion in § 170.315(g)(2), customers
( printed page 67958)
would not have assurance that the metrics for Health IT Modules are accurate. Some commenters suggested that the removal of § 170.315(g)(2) would shift burden to health care providers who would need to conduct their own testing to verify the metrics for Health IT Modules. Several commenters also asserted that new health IT developers may not conform to the standard without the requirement of certifying to § 170.315(g)(2) affecting the functionality of Health IT Modules.
Response.
We appreciate commenters' concerns about the lack of assurance of accurate calculation for measures in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category if § 170.315(g)(2) is removed. We note that developers now have more time and experience with CMS programs than when this certification criterion was first adopted. We believe that health IT developers will continue to ensure that Health IT Modules provide the capability to record the numerator and denominator and to create a report including the numerator, denominator, and resulting percentage in a fashion that supports accurate calculation to meet CMS requirements without needing to certify to § 170.315(g)(2). We further note that CMS has previously clarified that its programs do not specify that this capability must be used to calculate numerators and denominators for the measures. Eligible clinicians, eligible hospitals, and CAHs, may currently use a separate, non-certified system to calculate numerators and denominators and to generate reports on the measures.[46]
Comments.
We received a number of comments that expressed concern that the removal of § 170.315(g)(2) would create a lack of alignment with the requirements that CMS maintains in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. Some commenters questioned if the removal of § 170.315(g)(2) would reduce burden for health IT developers if CMS maintains its requirements in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. Many commenters requested that we work with CMS to provide clear guidance and address alignment issues regarding the transition to remove § 170.315(g)(2). Several commenters also suggested that we delay the removal of § 170.315(g)(2) to allow time to address CMS alignment with the removal of the certification criterion.
Response.
We appreciate the comments about alignment with the requirements in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. In the FY 2027 IPPS/LTCH PPS proposed rule, we note that CMS proposed to remove the cross-reference to § 170.315(g)(2) in 42 CFR 495.4, which is applicable to the Medicare Promoting Interoperability Program for eligible hospitals and CAHs, effective January 1, 2027 (91 FR 19620). CMS subsequently finalized this proposal in the FY 2027 IPPS/LTCH PPS final rule which appeared in the
Federal Register
on August 4, 2026 (91 FR 50033). CMS has made similar proposals with respect to the MIPS Promoting Interoperability category (91 FR 44170). We believe that CMS' final and proposed revisions to the definition of CEHRT in 42 CFR 495.4 and 42 CFR 414.1305 allow for alignment with our timeline for the removal of the certification criterion in § 170.315(g)(2). We will continue to coordinate with CMS as they seek to implement and finalize these proposals.
We also noted in the Proposed Rule that if we ultimately finalized the removal of § 170.315(g)(2), we would work with CMS to ensure relevant guidance and materials for existing measures are consolidated as part of the informational materials that CMS maintains regarding measures in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category (90 FR 60994). We believe that this coordination will minimize any burden for program participants.
Comments.
We received a number of comments that expressed support for our proposal to remove the certification criterion. These commenters stated that removing § 170.315(g)(2) would reduce burden from testing to certify to the criterion for health IT developers because the testing requirements for certification to § 170.315(g)(2) were difficult to assess and burdensome to conduct for health IT developers. Another commenter also asserted that the numerator/denominator measurement model supported by the certification criterion in § 170.315(g)(2) is obsolete in the current health IT industry.
Response.
We appreciate the comments about the burden. We have finalized the removal of § 170.315(g)(2) with an effective date of January 1, 2027, as proposed. We look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.
c. Safety-Enhanced Design
In the Proposed Rule (90 FR 60995), we proposed to remove the “safety-enhanced design” (SED) certification criterion in § 170.315(g)(3) and the reference to this certification criterion in § 170.550(g)(1) as of the effective date of this final rule. The safety-enhanced design certification criterion specifies the user-centered design testing that must be applied to certain health IT capabilities submitted for certification. Certification to this certification criterion is conditional as its scope and applicability depends on the other certification criteria for which a Health IT Module is presented for certification.
As discussed in the Proposed Rule (90 FR 60995 and 60996), we anticipated that removal of this certification criterion would reduce costs and burden for health IT developers and health care providers.
Comments.
The majority of commenters were not supportive of removing the SED certification criterion in § 170.315(g)(3). These commenters stated that the SED certification criterion remains an important patient safety, usability, and human factors engineering safeguard and expressed concerns that removal of this certification criterion would weaken a baseline certification expectation for user-centered design, increase the risk of technology-induced errors, promote inefficiency and inconsistency, and shift responsibility for identifying and mitigating such risks to providers and purchasers. Some commenters noted that if safety verification became the responsibility of providers and purchasers, then smaller, rural, or low-resource practices would incur the most burden, as they may have limited technical resources and expertise to independently evaluate the safety and security of their software systems.
A few commenters who opposed removal of the SED certification criterion expressed concerns that removal may cause health IT developers to revert to engineering-centric interfaces or reduce incentives to prioritize the clinician-user experience and could create a scenario where provider organizations are charged for design techniques that were previously included in health IT products. A few other commenters stated that removal of § 170.315(g)(3) could create an unlevel playing field between established developers and new market entrants, particularly if new entrants are not held to comparable usability and safety expectations. Some commenters who opposed removal also noted that safety-enhanced design and usability testing
( printed page 67959)
may become more important as SI-enabled functionality is incorporated into certified health IT and recommended that safety validation approaches evolve rather than be eliminated.
Some of the commenters who recommended retaining the certification criterion emphasized that the SED certification criterion, and related usability requirements, were originally implemented in response to real-world patient safety incidents and that the certification criterion continues to serve as an important safeguard against technology-induced harm. Another commenter expressed concerns that removal without first putting critical safeguards in place could result in unsafe practices and billing fraud.
Response.
We thank commenters for their feedback. We have not finalized our proposal to remove the SED certification criterion in § 170.315(g)(3) or the reference to this certification criterion in § 170.550(g)(1). Instead, we have finalized § 170.315(g)(3) with revisions, as of the effective date of this final rule. Specifically, we have finalized the revision of § 170.315(g)(3) to an attestation-based certification requirement by removing the requirements in § 170.315(g)(3)(ii), (iv), and (v), making conforming revisions to paragraph (g)(3), and retaining the reference to § 170.315(g)(3) in § 170.550(g)(1).
We acknowledge comments that recommended we retain § 170.315(g)(3) and stated that removal of the SED certification criterion would not be appropriate without a clearly defined replacement mechanism that preserves baseline expectations for user-centered design and safety validation. We also recognize commenters' statements that the SED certification criterion, and related usability requirements, were implemented in response to real-world patient safety incidents and that the certification criterion continues to serve as an important safeguard against technology-induced harm. We agree with these commenters that § 170.315(g)(3) continues to serve an important safety function in the Certification Program by maintaining baseline assurance that developers of certified health IT apply user-centered design processes to certain health IT capabilities.
In the Proposed Rule (90 FR 60995), we proposed to remove the SED certification criterion to reduce costs and burden associated with certification for health IT developers and health care providers. Specifically, we identified the testing and reporting requirements associated with certification to § 170.315(g)(3) as contributing to health IT developers' burden and stated that removal of the SED certification criterion could allow health IT developers to redirect time and resources toward more innovative approaches to support and improve safety-enhanced design in their products (90 FR 60996). In consideration of commenters' explanations for why we should retain the SED certification criterion, we reassessed whether our proposal to completely remove the criterion is necessary to achieve our objective of reducing costs and burden. We determined that revising § 170.315(g)(3) to establish an attestation-based certification requirement addresses these considerations by reducing the testing and reporting requirements associated with certification while retaining the certification expectation for the application of user-centered design practices to certain certified health IT capabilities.
Comments.
Some commenters recommended that if the SED certification criterion was removed, we should adopt alternative mechanisms to support continued usability and safety oversight. A commenter suggested prioritizing the use of post-market data to identify usability failures. A few other commenters recommended that we provide explicit transition guidance for products currently certified to § 170.315(g)(3) to ensure continuity of safety expectations and avoid gaps during any transition. Another commenter recommended that we provide a model risk assessment framework, particularly tailored to rural and low-resource providers, to support evaluation of health IT usability and safety in the absence of this certification requirement.
Response.
We acknowledge commenters who recommended alternatives to our proposal, including prioritizing the use of post-market data to identify usability failures, providing explicit transition guidance, and offering additional tools to support providers in evaluating usability and safety. While we have not adopted these suggested alternatives in this final rule, the revisions that we have finalized to § 170.315(g)(3) take into consideration comments that urged us to continue to support usability and safety oversight certification requirements rather than eliminate them completely.
Comments.
A smaller number of commenters expressed support for removing or streamlining the SED certification criterion. Of the commenters who supported removal of § 170.315(g)(3), most stated that current summative usability testing and related documentation requirements are costly and administratively burdensome, have limited practical value, and divert resources from formative usability testing and other product improvement activities. Additionally, commenters who supported removal of this certification criterion agreed that there is widespread market adoption of safety-enhanced design practices. Other commenters recommended that, rather than remove the certification criterion, we should retain and modernize or streamline it. These recommendations included adopting a lean form of SED by narrowing requirements, focusing on higher-risk workflows, adopting a lighter-weight attestation-based approach, reducing prescriptive reporting, and aligning with recognized usability engineering frameworks such as those defined by the International Electrotechnical Commission (IEC) and the International Organization for Standardization (ISO). Many of these commenters stated that formative usability testing conducted during development is more effective than the required summative testing model and that removing the current certification requirements would allow resources to be redirected toward more impactful usability practices. Another commenter specified that conducting user-centered design testing after development practices limits the ability to incorporate findings into products and that clients rarely access or use the detailed reports required by the SED certification criterion. Another commenter stated that safety-enhanced design features should be decided by markets.
Response.
We thank commenters for their feedback and perspectives on how safety-enhanced design continues to play an important role in supporting safe and effective use of certified health IT but that current summative usability testing and related documentation requirements are costly and administratively burdensome. As discussed above, we have finalized revisions to § 170.315(g)(3) that reduce prescriptive testing and reporting requirements while retaining a meaningful certification expectation for user-centered design. This approach is intended to balance the need to maintain baseline safety and usability expectations with the goal of reducing unnecessary burden and allowing health IT developers to redirect time and resources towards more innovative approaches to support and improve safety-enhanced design in their products. We refer readers to section VII
( printed page 67960)
(Regulatory Impact Analysis) of this final rule for more detailed information on cost estimates of safety-enhanced design and estimated cost savings.
We have determined that the current reporting requirements for the SED certification criterion can be reduced to an attestation-based approach that retains a meaningful certification expectation for SED. Therefore, we have finalized the SED certification criterion in § 170.315(g)(3) to an attestation-based certification requirement by removing the requirements in § 170.315(g)(3)(ii), (iv), and (v), making conforming revisions to paragraph (g)(3), and retaining the reference to § 170.315(g)(3) in § 170.550(g)(1). All revisions to the SED certification criterion are effective as of the effective date of this final rule.
d. Quality Management System
In the Proposed Rule (90 FR 60996), we proposed to remove the “quality management system” (QMS) certification criterion in § 170.315(g)(4) and the reference to this certification criterion in § 170.550(g)(2), as of the effective date of this final rule. The QMS certification criterion states for each capability that a technology includes and for which that capability's certification is sought, the use of a QMS in the development, testing, implementation, and maintenance of that capability must be identified and satisfied in one of the following ways: either the QMS used is established by the Federal Government or a standards development organization (SDO) or the QMS used is mapped to one or more QMS established by the Federal Government or an SDO. Per § 170.550(g), this certification criterion is mandatory for all certified Health IT Modules.
As discussed in the Proposed Rule (90 FR 60996), we proposed to remove this certification criterion because industry and other interested parties now widely implement quality management principles in comparison to when this certification criterion was initially adopted. We determined as a result, that the certification criterion in § 170.315(g)(4), and the related requirement that all Health IT Modules be certified to it, have become duplicative.
Comments.
The majority of commenters were not supportive of removing the QMS certification criterion in § 170.315(g)(4). These commenters expressed concerns that removal would weaken baseline safety, quality, and reliability expectations for certified health IT and shift verification responsibilities from developers to providers and purchasers. Many of these commenters also expressed concerns that removal of the certification criterion could reduce assurances for quality practices, increase the likelihood that immature products enter clinical and operational workflows, and result in inconsistent adoption of quality management practices, including by new market entrants.
Some commenters also noted that removal of this certification criterion could introduce new challenges in evaluating health IT developer safety practices and managing risk, particularly for rural or low-resourced providers with limited technical resources and expertise to independently evaluate the safety, security, and quality of their software systems. Some commenters who opposed removal of the QMS certification criterion recommended that, if the criterion was removed, we provide additional guidance on a replacement approach and how safety, quality, and reliability expectations would be maintained through modernization efforts, including API-based ecosystems and other programmatic mechanisms. Several of these commenters also recommended adopting post-certification oversight and transparency mechanisms to assess the impact of removing this certification requirement and to offer providers information about developers' capabilities and associated costs.
A small number of commenters supported removing the certification criterion or expressed a neutral view, stating that the requirement can be seen as duplicative since many developers already maintain quality management system practices as part of routine operations.
We received mixed comments regarding the level of burden associated with the QMS certification criterion and whether removal of the criterion would meaningfully reduce burden. As noted above, a few commenters who expressed a neutral view or supported removal of this certification criterion stated that many mature development organizations would continue to maintain quality management practices and follow the ISO industry standard regardless of certification requirements. Other commenters noted that the current QMS certification criterion was burdensome for developers and system administrators and recommended that we should modernize or streamline the requirement rather than remove it.
Response.
We thank commenters for their thoughtful feedback. We have not finalized our proposal to remove the quality management system certification criterion in § 170.315(g)(4) or the corresponding reference in § 170.550(g)(2).
After considering the comments we received, we believe § 170.315(g)(4) continues to serve an important function in the Certification Program by providing a consistent baseline assurance that developers of certified health IT identify and use a quality management system in the development, testing, implementation, and maintenance of certified health IT capabilities. We recognize that many developers of certified health IT already maintain quality management principles and processes as part of routine operations. However, we believe that maintaining a baseline certification requirement at this time is important to ensure continuity of safety and quality practices and to promote consistent expectations across the market, including for new entrants. We recognize that quality management expectations may continue to evolve as part of broader health IT modernization efforts and that the QMS certification criterion continues to support providers and purchasers that rely on certification as a meaningful signal of developer quality management practices. Our decision to retain § 170.315(g)(4) also supports consistency with the Certification Program's broader approach to transparency and public reporting regarding the quality management processes used by developers for certified health IT.
Comments.
Some commenters who opposed removal of the QMS certification criterion expressed concerns about coordination with CMS program timelines and recommended delaying removal of the certification criterion to align with CMS program requirements and reduce potential provider compliance risks.
Response.
We acknowledge commenters' concerns regarding coordination with CMS program timelines and related provider compliance activities. However, while the QMS certification criterion in § 170.315(g)(4) impacts certified health IT used by health care providers for compliance with CMS programs, we are not aware of any direct requirements for adoption or use of certified health IT certified to the QMS certification criterion. For instance, with respect to the Promoting Interoperability program and the MIPS Promoting Interoperability performance category, CMS has not specified the criterion in § 170.315(g)(4) as required to support any of the current measures in the program as part of the definitions of CEHRT in 42 CFR 495.4 or 42 CFR 414.1305. Our decision not to finalize
( printed page 67961)
removal of § 170.315(g)(4) is not based on CMS program dependency, but rather that this certification criterion continues to serve an important role within the Certification Program as a baseline quality management and assurance expectation, as well as to support transparency and maintain consistent adoption of QMS practices over time. Therefore, we have not finalized our proposal to remove the quality management system certification criterion in § 170.315(g)(4) or the corresponding reference in § 170.550(g)(2).
e. Accessibility-Centered Design
In the Proposed Rule (90 FR 60997), we proposed to remove the “accessibility-centered design” (ACD) certification criterion in § 170.315(g)(5) and the corresponding reference to this certification criterion in § 170.550(g)(3) as of the effective date of this final rule. This certification criterion requires that all developers of Health IT Modules identify and use a health IT accessibility-centered design standard or law in the development, testing, implementation, and maintenance of each capability for which certification is sought. We stated that, if finalized, removal of this certification criterion would not exempt health IT developers and providers from their independent obligations under applicable Federal civil rights laws, including Section 504 of the Rehabilitation Act, Section 1557 of the Affordable Care Act, and the Americans with Disabilities Act.
Comments.
Most commenters were not supportive of the removal of the ACD certification criterion in § 170.315(g)(5). These commenters expressed concerns that removal of this certification criterion could reduce accessibility and equitable access to certified health IT for individuals with disabilities and weaken a measurable certification baseline for accountability. One of these commenters emphasized that accessibility is not static and requires ongoing monitoring, updates, and testing as platforms evolve. Another commenter remarked that the impact of this certification criterion has not diminished and stated that there is no guarantee that health IT developers will ensure accessibility-centered design practices continue if the ACD certification criterion is removed.
Many commenters who opposed our proposal also expressed concerns that removal of the ACD certification criterion could reduce transparency and incentives to maintain accessibility-centered design practices, leading to uneven adoption, particularly among new market entrants, and widening gaps in digital participation. A few commenters also emphasized that accessibility-centered design requirements support standardized, interoperable access to health information and expressed concern that removal of this certification criterion could undermine accessibility in API-based and SI-enabled environments. Multiple commenters cautioned that reducing accessibility and usability requirements could increase the risk of inefficient workflows and could lead to an increase in clinician workload and cognitive burden. Many of these commenters expressed concerns that removal of § 170.315(g)(5) would shift costs, usability barriers, and responsibility for ensuring accessibility to providers, patients, and caregivers, including the potential for developers to charge additional fees for accessibility features previously included as part of certified health IT. Some commenters recommended that, if we were to remove § 170.315(g)(5), we should adopt a replacement accountability mechanism and provide transition guidance.
Several commenters who opposed removal of this certification criterion stated that applicable Federal civil rights laws do not serve the same function or provide the same measurable accountability as a Certification Program requirement. A few other commenters argued that removing the ACD certification criterion would not meaningfully reduce burden because some developers would maintain accessibility practices regardless of the certification requirement.
Response.
We thank commenters for their thoughtful feedback. We have not finalized our proposal to remove the ACD certification criterion in § 170.315(g)(5) or the corresponding reference in § 170.550(g)(3).
We continue to recognize that accessibility-centered design practices are broadly used across industry. However, we determined that this widespread use of accessibility-centered design practices supports retaining, rather than removing, the ACD certification criterion at this time. We have concluded that § 170.315(g)(5) continues to serve an important function in the Certification Program by maintaining a transparent, measurable baseline regarding the use of accessibility-centered design standards or laws by developers for certified health IT capabilities. We also believe that accessibility is not static and that continued certification transparency and accountability remain important.
The requirements in § 170.315(g)(5) support consistency with the Certification Program's broader approach to transparency and public reporting regarding the accessibility-centered design standards or laws used in the development of certified health IT. Additionally, retaining § 170.315(g)(5) helps to reduce the risk of uneven adoption or maintenance of accessibility-centered design practices over time, including among new market entrants. Therefore, we have not finalized our proposal to remove the ACD certification criterion in § 170.315(g)(5) or the corresponding reference in § 170.550(g)(3).
Comments.
A small number of commenters expressed support for or did not object to the removal of this certification criterion. Most of these commenters stated that this certification requirement is redundant given that accessibility requirements continue to apply under applicable Federal civil rights laws. Additionally, these commenters noted that removal of an attestation-based certification criterion would not meaningfully reduce burden or impact the Certification Program and that the current certification criterion is overly broad or limited in practical utility. A commenter noted that removal of the ACD certification criterion is a simplification measure for the Certification Program. Another commenter stated that accessibility-centered design features should be decided by markets. Several commenters recommended, if § 170.315(g)(5) was removed, that we explicitly clarify in the subsequent final rule that accessibility expectations for developers and healthcare organizations would remain subject to Federal civil rights laws.
Response.
We thank commenters for their feedback and continue to believe that § 170.315(g)(5) plays an important role in the Certification Program by providing a transparent and measurable baseline for how health IT developers apply accessibility-centered design standards or laws to certified health IT capabilities. We have not finalized our proposal to remove the ACD certification criterion in § 170.315(g)(5) or the corresponding reference in § 170.550(g)(3).
f. Consolidated CDA Creation Performance
In the Proposed Rule (90 FR 60997), we proposed to remove and reserve the “Consolidated CDA creation performance” certification criterion in § 170.315(g)(6). We also proposed to remove § 170.550(g)(4) which references the certification criterion. We stated that
( printed page 67962)
the certification criterion helps to ensure the proper conformance of Consolidated CDAs (C-CDAs) for transition of care and referral summaries that are sent to and received from external organizations, and that while C-CDA-based standards are still in use, the industry is shifting toward adoption of FHIR-based standards, which are designed to enable greater interoperability and innovation. We stated that we believe that maintaining the current level of support for this and other C-CDA-based criteria, including putting effort and resources toward testing and certification, can detract from industry efforts to move toward FHIR-based solutions, and that removing the certification criterion in § 170.315(g)(6) would contribute to reducing the effort health IT developers and health care providers are focusing on C-CDA support and allow for redirection of efforts toward greater use of FHIR-based standards in health IT. We proposed to remove the Consolidated CDA creation performance certification criterion in § 170.315(g)(6) as of the effective date of this final rule.
Comments.
Of the commenters that specifically commented on this proposal, the majority of commenters were not supportive of removing the Consolidated CDA creation performance certification criterion, primarily because they believed that FHIR-based alternatives were not yet mature, finalized, or adopted at scale and that no equivalent FHIR-based replacement had been clearly identified, adopted, or deployed. Many commenters stressed that the current exchange environment remains hybrid, and C-CDA-based document exchange is still foundational, predominant, or widely used, particularly in under-resourced settings. Multiple commenters noted specific use cases that depend on C-CDA-based document exchange, including Healthcare Effectiveness Data and Information Set (HEDIS), risk adjustment, care management, clinical registries and quality measurement, referrals, transitions of care, longitudinal aggregation, encounter notifications, public health, legacy EHR interoperability, patient event notifications, and certain legal documentation. Several commenters stated that C-CDA-based document exchange is better for patients, caregivers, and complete record sharing. Some commenters stressed that C-CDA-based document exchange helps bridge the transition to FHIR by supporting hybrid exchange, mappings, and longitudinal records. A number of commenters were concerned that removal of C-CDA-based requirements before a FHIR alternative was in place would create a gap and impact interoperability as well as reduce data quality, consistency, predictability, and usability. Several comments warned that removal of C-CDA-based requirements before FHIR-based alternatives are mature and widely adopted could lead to fragmented workflows and increased costs or data exchange burdens for providers.
Response.
We thank commenters for these comments regarding FHIR readiness and the removal of the current C-CDA-based certification criterion in § 170.315(g)(6) prior to having a FHIR alternative in place. We appreciate the concerns expressed by commenters that C-CDA-based document exchange is widely used and there is not a mature FHIR-based alternative available at this time. However, we note that the Consolidated CDA creation performance certification criterion in § 170.315(g)(6) has been a conditional, secondary C-CDA implementation requirement applied to health IT for which certification to a primary C-CDA-based certification criterion is sought. For instance, the transitions of care certification criterion in § 170.315(b)(1) includes C-CDA-based requirements, and each product presented for certification to § 170.315(b)(1) would also need to be certified to § 170.315(g)(6) per its additional conformance requirements. It was this second layer of burden we proposed to remove, and we are finalizing the removal of § 170.315(g)(6). Additionally, as discussed earlier in section III.A.2.a, we have extended the timeline for removing the C-CDA-based standards requirements in § 170.315(b)(1) until January 1, 2030. We believe this addresses commenter concerns regarding the immediate removal of C-CDA-based standards requirements from the Certification Program without a viable FHIR alternative. As stated in section III.A.2.a, we explain that significant advances are occurring in the development and adoption of FHIR-based standards, and we anticipate substantial progress by January 1, 2030. Therefore, we do not believe it is necessary to retain this additional C-CDA-based certification requirement in § 170.315(g)(6) in order to ensure an appropriate transition from C-CDA-based standards to FHIR-based standards in the Certification Program. As such, we have finalized the proposal to remove the Consolidated CDA creation performance criterion in § 170.315(g)(6) as of the effective date of this final rule. We have also finalized the proposal to remove § 170.550(g)(4) as discussed in more detail in section III.E.2.
Comments.
Several commenters expressed concerns about patient safety, including concerns that removal of the certification criterion could disrupt continuity of care, care coordination, patient safety, or patient outcomes. Some commenters noted that certification to the criterion in § 170.315(g)(6) is an important safeguard, accountability mechanism, and testing floor.
Response.
We thank commenters for expressing these concerns about patient safety, and we appreciate the importance of ensuring that health information is exchanged reliably during transitions of care and in referral summaries. However, as already noted, the certification criterion in § 170.315(g)(6) is not the only certification criterion in the Certification Program that requires use of C-CDA-based standards and that helps ensure reliable data exchange during transitions of care. As discussed in section III.A.2.a, we have extended the deadline for removal of C-CDA-based requirements in the transitions of care certification criterion in § 170.315(b)(1). We believe this extension will provide enough time for certified health IT to move from C-CDA-based standards to FHIR-based standards without sacrificing patient safety. In addition, we reiterate that the removal of the certification criterion 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 implementation.
Comments.
A number of commenters expressed concerns about additional burden that the proposal could place on providers, stating that the removal of C-CDA-based exchange requirements could increase manual workflows, reconciliation, quality assurance, testing, normalization, and other administrative burden. Some commented that the proposal could disproportionately burden smaller, rural, safety-net, tribal, post-acute, behavioral health, and similar under-resourced settings. Another commenter stated that the proposal would not reduce developer burden because developers would still need to maintain C-CDA support for the foreseeable future.
Response.
We thank commenters for expressing these concerns about burden, and in particular burden on under-resourced providers and settings. We
( printed page 67963)
appreciate the importance of not imposing additional burden on providers by removing requirements related to C-CDA-based exchange. Again, it is important to understand the context associated with this specific certification criterion, which is secondarily applied to health IT certified to a C-CDA referencing criterion. C-CDA IGs have become more rigorous and less ambiguous, and existing test tools and industry experience with C-CDA is far greater now than when this certification criterion was first introduced. Thus, we believe that the continued need for this certification criterion in the Certification Program has concluded. Regarding the comment about the burden reducing impact of this proposal, we believe that even if a developer maintains C-CDA support, removal of this certification criterion would reduce maintenance efforts for developers, including effort and resources that would be put toward testing and certification to this criterion if the criterion remained part of the Certification Program.
Comments.
Some commenters expressed disagreement with the general rationale that health IT developers would continue to support C-CDA-based exchange after removal of C-CDA-based exchange requirements in the Certification Program. These commenters were concerned that removal might result in developers charging extra for C-CDA-based exchange functionality once that functionality is no longer part of the certification requirements, and several commenters were concerned that fees to maintain C-CDA-based exchange would harm under-resourced providers and settings. Some commenters had concerns that new entrants to the market might omit core capabilities, implement them inconsistently, use proprietary alternatives, or lack the real-world knowledge needed to support C-CDA-based exchange.
Response.
We thank commenters for expressing these concerns about developers, and in particular new entrants to the market, not providing support for C-CDA-based exchange. We appreciate the importance of ensuring that support for this functionality is continued during a transition to FHIR-based exchange, especially for under-resourced providers and settings. As stated above, other certification criteria in the Certification Program also require use of C-CDA-based standards for exchange and can help ensure support during a transition from C-CDA-based exchange to FHIR-based exchange. We have extended the deadline for removal of C-CDA-based requirements in the transitions of care certification criterion in § 170.315(b)(1) until January 1, 2030. We believe this extension will provide enough time for certified health IT to move from C-CDA-based standards to FHIR-based standards without providers being subject to increased fees or reduced developer support for C-CDA-based exchange during the transition. As noted above, we reiterate that removing this certification criterion neither requires removal of the functionality from existing implementations nor prohibits continued use of the referenced standards in new or existing health IT.
Comments.
A number of commenters contended that the timeline was too short and that there was no sufficiently clear phased plan, readiness benchmark, or implementation guidance.
Response.
We thank commenters for sharing these concerns regarding timelines and for expressing a desire for a phased plan for transitioning from C-CDA-based exchange to FHIR-based exchange. As discussed in section III.A.2.a, we have finalized an extension of the deadline for removal of C-CDA-based requirements in the transitions of care certification criterion in § 170.315(b)(1). We believe this extension provides a clear and workable timeline for certified health IT to move from C-CDA-based standards to FHIR-based standards. We note that we provide guidance and resources on all Certification Program requirements on our website at
healthit.gov
and anticipate that future guidance materials and resources will continue to focus as needed on transitioning from C-CDA-based exchange to FHIR-based exchange.
Comments.
Some commenters expressed concerns about alignment with CMS and other Federal or programmatic dependencies, including Promoting Interoperability requirements, measure continuity, reimbursement, and other Federally referenced workflows.
Response.
We thank commenters for these comments and appreciate the importance of aligning with CMS and other programs. We are not aware of any CMS requirements that directly require health care providers to adopt or use health IT certified to the certification criterion in § 170.315(g)(6) and thus do not believe that removal of this criterion will lead to regulatory alignment concerns for health care providers participating in CMS programs. With respect to the requirements of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, the certification criterion in § 170.315(g)(6) is not currently identified as required to support any of the measures in these programs as part of their respective definitions of CEHRT in 42 CFR 495.4 and 42 CFR 414.1305.
Comments.
Some commenters expressed support for removal of the certification criterion in § 170.315(g)(6), stating that the criterion was duplicative or had limited value and that its removal could simplify certification and allow health IT developers to redirect effort toward FHIR-based solutions.
Response.
We thank commenters for these comments in support of our proposal. We agree with commenters that the criterion's impact has waned since it was first adopted, and in particular we note the dependency on the transitions of care certification criterion in § 170.315(b)(1). We agree that removal of the certification criterion in § 170.315(g)(6) will reduce burden on developers of certified health IT and encourage, as well as enable, greater effort to be directed at transitioning to FHIR-based exchange. We have finalized this proposal as proposed.
Comments.
Several commenters identified issues that were out of scope for our proposal such as broader incentives or funding to support FHIR adoption and future revisions to other certification criteria to better accommodate technology-neutral or FHIR-based approaches.
Response.
We thank commenters for these comments, and as they are out of scope, we decline to finalize the suggested changes in this final rule.
g. Application Access—Patient Selection
In the Proposed Rule, we proposed to remove the “application access—patient selection” certification criterion and reserve § 170.315(g)(7) with an effective date of January 1, 2027. We stated that we reviewed and evaluated the certification criterion in § 170.315(g)(7), seeking to identify ways to reduce burden while still supporting our policy goals. As discussed in the Proposed Rule, the application access—patient selection certification criterion in § 170.315(g)(7) includes the capability to receive a request with sufficient information to uniquely identify a patient and return an ID or other token that can be used by an application to subsequently execute requests for that patient's data (90 FR 60997). We explained that since adoption of the HL7® SMART App Launch Implementation Guide in § 170.215(c), all Health IT Modules certified to the standardized API for patient and
( printed page 67964)
population services certification criterion in § 170.315(g)(10) must support the functional requirement described in § 170.315(g)(7)(i) according to the SMART App Launch Implementation Guide. We further explained that we proposed to remove the corresponding certification criterion in § 170.315(g)(9), and that if we finalize the removal of § 170.315(g)(9), the certification criterion in § 170.315(g)(7) would lose its intended utility. We also stated that we believe that reducing compliance burdens for health IT developers that participate in the Certification Program would foster industry innovation and encourage the development of more creative interoperability solutions (90 FR 60998).
Comments.
We received several comments that expressed concern that the removal of § 170.315(g)(7) would undermine the functionality in Health IT Modules without the requirement for health IT developers to certify to the criterion. A commenter also expressed concern that the removal of § 170.315(g)(7) could make implementing SMART App Launch more difficult as health IT developers may not adhere to this functionality without the requirement to certify to § 170.315(g)(7).
Response.
We appreciate the comments we received that were concerned about degraded functionality for Health IT Modules if § 170.315(g)(7) is removed. We note that Health IT Modules certified to the standardized API for patient and population services certification criterion in § 170.315(g)(10) must support the functional requirement described in § 170.315(g)(7)(i), and we believe that health IT developers will continue to ensure health IT products meet the same functional requirement without needing to certify to § 170.315(g)(7).
Comments.
We received several comments that expressed concern that the removal of § 170.315(g)(7) would create a lack of alignment with the requirements that CMS maintains in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. A number of commenters questioned whether the removal of § 170.315(g)(7) would reduce burden for health IT developers if CMS maintains its requirements in these programs. Some commenters requested that we work with CMS to provide clear guidance and address alignment issues regarding the transition to removal of § 170.315(g)(7). A commenter also suggested that we delay the removal of § 170.315(g)(7) to allow time to address CMS alignment with the removal of the criterion.
Response.
We appreciate the comments about alignment with the requirements in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. We noted in the Proposed Rule that the criterion is associated with measures under the Provider to Patient Exchange and Health Information Exchange objectives of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category (90 FR 60998). We do not expect the removal of this criterion to lead to regulatory misalignment with CMS program requirements. Nor do we believe additional time is needed to address CMS alignment. We will coordinate with CMS to update information regarding certification criteria that support measures under these programs to appropriately reflect our final policy to remove the criterion in § 170.315(g)(7).
Comments.
We received a number of comments that expressed support for our proposal to remove the criterion. Commenters asserted that the certification criterion in § 170.315(g)(7) should be removed because the requirement is duplicative with the requirements in § 170.315(g)(10). Several commenters stated that the quality of Health IT Modules certified to § 170.315(g)(7) is unlikely to degrade with the removal of § 170.315(g)(7) because the certification criterion is duplicative.
Response.
We appreciate the comments we received about the certification criterion in § 170.315(g)(7) being duplicative with the requirements in § 170.315(g)(10). We have finalized the removal of § 170.315(g)(7) with an effective date of January 1, 2027, as proposed. We look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.
h. Application Access—All Data Request
In the Proposed Rule, we proposed to remove the “application access—all data request” certification criterion in § 170.315(g)(9) with an effective date of January 1, 2027. As discussed in the Proposed Rule, the application access—all data request certification criterion in § 170.315(g)(9) requires the capability to respond to requests for patient data for all of the data classes expressed in the standards in § 170.213 (90 FR 60998). We stated that we believe that removing the certification criterion in § 170.315(g)(9) will reduce administrative burden as well as burden for health IT developers and health care providers by eliminating the need for developers of certified health IT to certify to the certification criterion in § 170.315(g)(9). We explained that we believe the functionality of the criterion has been widely adopted (as discussed in section III.A) among health IT developers and is not likely to go away as a supported functionality solely because of removal from the Certification Program (90 FR 60998).
Comments.
We received a number of comments that expressed concern that the removal of § 170.315(g)(9) would undermine the functionality in Health IT Modules without the requirement for health IT developers to certify to the criterion. Several commenters expressed concern that the removal of § 170.315(g)(9) would threaten the availability of USCDI data for customers of Health IT Modules if developers did not have to certify to the requirement in § 170.315(g)(9). Some commenters stated that they are particularly concerned that new health IT developers might not adhere to the expected functionality even if existing health IT developers are expected to continue to adhere to the requirement.
Response.
We appreciate the comments we received that expressed concern about degraded functionality for Health IT Modules if § 170.315(g)(9) is removed. The Certification Program is moving towards a standards-based approach to supporting this and similar functionality, including with the adoption of the “standardized API for patient and population services” (§ 170.315(g)(10)). We expect that health IT developers will continue to meet the needs of their customers and provide the all data request functionality without needing to certify to § 170.315(g)(9). However, we will continue to monitor the support for the all data request functionality in the health IT industry and access to USCDI data.
Comments.
We received several comments that expressed concern that the removal of § 170.315(g)(9) would create a lack of alignment with the requirements that CMS maintains in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. A number of commenters questioned if the removal of § 170.315(g)(9) would reduce burden for health IT developers if CMS maintains its requirements in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. Some commenters requested that we work with CMS to provide clear guidance and address alignment issues regarding the transition to remove
( printed page 67965)
§ 170.315(g)(9). A commenter also suggested that we delay the removal of § 170.315(g)(9) to allow time to address CMS alignment with the removal of the criterion.
Response.
We appreciate the comments about alignment with the requirements in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. We noted in the Proposed Rule that the criterion is associated with measures under the Provider to Patient Exchange and Health Information Exchange objectives of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category (90 FR 60998). We do not expect the removal of this criterion to lead to regulatory misalignment with CMS program requirements. Nor do we believe additional time is needed to address CMS alignment. We will coordinate with CMS to update information regarding certification criteria that support measures under these programs to appropriately reflect our final policy to remove the criterion in § 170.315(g)(9).
Comments.
We received a number of out of scope comments that requested that we give consideration for strong protections for sensitive data associated with the “application access—all data request” certification criterion or for an alternative certification criterion in the future.
Response.
We will continue to monitor access to USCDI data and concerns about protections for sensitive data in the health IT industry. We will consider how to address access to USCDI data further as the health IT industry evolves and whether to adopt new regulations in future rulemaking.
Comments.
We received a number of comments that expressed support for our proposal to remove the certification criterion. Commenters asserted that the certification criterion in § 170.315(g)(9) should be removed because certification to § 170.315(g)(9) is a significant burden to health IT developers. Several commenters asserted that they expect health IT developers will continue to adhere to the functionality because the functionality is ubiquitous in the health IT industry and expected for customers of Health IT Modules. Some commenters also suggested that the removal of this criterion could encourage health IT developers to certify to the Certification Program without the need to invest in testing and certifying to § 170.315(g)(9).
Response.
We appreciate the comments about the burden. We have finalized the removal of § 170.315(g)(9) with an effective date of January 1, 2027, as proposed. We look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.
8. Transport Methods and Other Protocols Certification Criteria
In the Proposed Rule, we proposed to remove the “transport methods and other protocols” certification criteria in § 170.315(h), including § 170.315(h)(1) “direct project” and § 170.315(h)(2) “direct project, edge protocol, and XDR/XDM” as of the effective date of this final rule and to reserve § 170.315(h) in its entirety (90 FR 60998). We stated in the Proposed Rule that we no longer believe there is added benefit to include conformance testing for this functionality in the Certification Program as the functionality is widely relied on and supported in the healthcare industry and would be incorporated in health IT absent the certification criteria. We further explained that we believe that removing these certification criteria could spur further industry innovation by enabling health IT developers to redirect investment in certification and testing for these criteria to new areas (90 FR 60998). As discussed in the Proposed Rule, the certification criterion in § 170.315(h)(1) includes the capability to send and receive according to the Applicability Statement for Secure Health Transport (the primary Direct Specification), and the § 170.315(h)(2) certification criterion is a variation of the § 170.315(h)(1) certification criterion to accommodate implementation differences that combined three standards conformance requirements (the primary Direct standard, the edge protocol, and XDR/XDM handling) (90 FR 60998), which we collectively refer to as “Direct Specification” in this final rule. We also proposed to remove § 170.550(j) “direct project transport method” to conform with our proposal to remove § 170.315(h) (90 FR 61005).
Comments.
Several commenters supported our proposal to remove the criteria in § 170.315(h). They stated that the testing process for certifying to § 170.315(h) is particularly burdensome for health IT developers. Some commenters also stated that the testing process for § 170.315(h) is prone to technical difficulties that create additional burden for health IT developers certifying Health IT Modules to § 170.315(h). A number of commenters additionally asserted that they would continue to support the Direct Specification functionality if ONC removes the certification criteria in § 170.315(h).
Response.
We appreciate the comments supporting our proposal to remove § 170.315(h). We agree with commenters' concerns about the burden for health IT developers certifying Health IT Modules to § 170.315(h). We have finalized the removal of § 170.315(h) as of the effective date of this final rule, as proposed. We have also finalized the removal of § 170.550(j) to conform with the removal of § 170.315(h). We look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.
Comments
Many commenters expressed concern that the removal of § 170.315(h)(1) would lead to degraded functionality or reduce adoption of Direct Specification in Health IT Modules and create interoperability gaps without the criteria in § 170.315(h). A number of commenters emphasized that Direct Specification is widely relied upon in the health IT industry and asserted that an alternative FHIR-based functionality was not ubiquitous enough in the health IT industry to replace Direct Specification if we removed the criterion in § 170.315(h)(1) as it relates to Direct Specification. Some commenters were concerned that the burden of testing would be shifted to customers of Health IT Modules to verify the standard of functionality without ONC support. Several commenters asserted that new health IT developers would be unlikely to support the Direct Project specification if § 170.315(h) is removed. Some commenters also emphasized that they believed § 170.315(h) is necessary to maintain consistent functionality for Direct Specification. A number of commenters encouraged ONC to adopt a phased timeline for the removal of § 170.315(h)(1) to provide a transition period for the industry.
Response.
We appreciate the comments we received about the continued availability of Direct Specification functionality. We note that, as we have finalized in section III.A.2.a, we are delaying removal of the technical conformance references in § 170.315(b)(1)(i) that would require a Health IT Module to demonstrate its conformance to send and receive transitions of care/referral summaries through a method that conforms to the Direct Specification certification criteria until January 1, 2030. Therefore, we expect that new health IT developers will continue to certify their Health IT Modules to § 170.315(b)(1)(i), and that health IT developers who develop Health IT Modules certified to § 170.315(b)(1)(i) will continue to support the Direct Specification
( printed page 67966)
functionality in accordance with § 170.315(b)(1)(i). By removing the specific certification criteria adopted at § 170.315(h), we have only removed the criteria for the testing and certification process used by health IT developers that seek to perform the core health information service provider services for the transport standard aspects of the Direct Specification. With the widespread adoption and support of Direct Specification in the health IT industry and the continued adoption of § 170.315(b)(1)(i), we expect that health IT developers performing the capabilities that had been adopted at § 170.315(h) will continue to support Direct Specification without the need for dedicated certification criteria to support industry adoption. Therefore, we expect that customers of Health IT Modules will not be significantly burdened by the removal of § 170.315(h), and we believe that the burden for health IT developers associated with § 170.315(h) is unnecessary to continue in the Certification Program.
Comments.
We received several comments that expressed concern that the removal of § 170.315(h) would create a lack of alignment with certain CMS program requirements. Some commenters requested that the removal of § 170.315(h) be coordinated to align with CMS program requirements. A commenter suggested that we delay the removal of § 170.315(h) to align ONC and CMS requirements.
Response.
We appreciate the comments we received about alignment with CMS program requirements. The CMS definitions of CEHRT in 42 CFR 495.4 and 42 CFR 414.1305 require use of EHR technology certified to the criteria in the ONC-adopted Base EHR definition. These definitions are applicable to certain CMS programs, including the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. When we issued the Proposed Rule, in order to meet the Base EHR definition, EHR technology was required to be certified to either § 170.315(h)(1) or (h)(2). However, the § 170.315(h) criteria are not independently required to support any measures in either the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. Under the CMS CEHRT definitions, changes to the Base EHR definition, including certification criteria referenced therein, are incorporated into the CEHRT definitions via references in those definitions to the “Base EHR definition (as defined at 45 CFR 170.102).” Further, we coordinated with CMS on our proposal to remove the criteria in § 170.315(h). Therefore, we do not believe additional coordination with CMS is required in order to ensure the regulatory alignment of program requirements for programs that incorporate the CEHRT definitions, including the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, with our final policy to remove and reserve § 170.315(h).
B. Standards and Implementation Specifications for Health Information Technology
1. Standards and Implementation Specifications
As discussed in the Proposed Rule, we proposed to remove or revise certain certification criteria in the Certification Program in an effort to reduce burden, offer flexibility to both developers and health care providers, as well as to support innovation. Included in certain certification criteria are references to standards. In those instances where we proposed to remove the criterion, we also generally proposed to remove the standard that is referenced from the CFR. Where the certification criterion is not removed as of the effective date of this final rule but allows time for transition until January 1, 2027, we generally proposed to also remove those referenced standards on January 1, 2027. Only in limited circumstances do we retain a standard that is referenced in a certification criterion proposed for removal. We also specifically requested comment on whether we should retain any of the standards and implementation specifications proposed for removal because the standard or implementation specification should be required for purposes of health IT alignment, for instance, when acquiring, implementing or upgrading health IT systems and products consistent with sections 13111 and 13112 of the HITECH Act. In certain instances, we did not propose to remove a standard even though we proposed to remove the certification criterion where the standard is referenced. As noted, under section 3004 of the PHSA, we may adopt standards independently of associated criteria in the Certification Program. Standards adopted in 45 CFR 170 subpart B may be referenced by other HHS programs and policies besides the Certification Program. For example, standards adopted in 45 CFR 170 subpart B, regardless of whether they are associated with health IT certification criteria, are also required for use under sections 13111 and 13112 of the HITECH Act when acquiring, implementing or upgrading health IT systems and products in certain instances.
We did not propose to remove the standard in § 170.205(o), data segmentation for privacy, because some developers still rely on these standards, which allow health care providers to tag healthcare documents with privacy metadata. We also did not propose to remove the Direct Project transport standard in § 170.202(a)(2) since we realize that the Direct Project standards are widely utilized in various use cases and emphasized that developers may still use these standards even if they are removed from certification criteria.
We proposed a minor revision to § 170.205(d)(2) to add the full name of the HL7 Messaging Standard Version 2.5.1 standard. Lastly, we requested comments on retaining the “Applicability Statement for Secure Health Transport” requirement found in § 170.315(h)(1)(i).
Comments.
While many commenters expressed support for the direction and objectives of the Proposed Rule, we also received many comments that expressed concerns with the proposed compliance timelines and transition dates. Some commenters stated that having different removal and transition dates for the majority of certification criteria risks creating discontinuities for providers, potential compromises to operational stability and patient safety, uncertainty, and functional gaps.
Multiple commenters expressed that the proposed timelines were too compressed and did not provide an adequate transition time. Many of these commenters provided suggestions and alternatives that they believed would better reflect vendor development cycles, implementation requirements, workforce constraints, and Federal mandates. Other suggestions included having a single sunset date for all removed criteria at least 24-36 months after publication of a final rule and aligned to the beginning of a calendar year, extending particular criteria removals that impact LTPAC systems, CMS provider mandates, or other providers facing feasibility challenges to 2028, and maintaining C-CDA linked or other legacy related requirements until a defined date in the future. A commenter recommended we “grandfather” existing certifications and allow sufficient time for developers and customers to plan upgrades, contracting, and validation before any criteria are retired, as well as ensure standards remain available through the full transition to avoid compliance gaps.
Response.
We thank commenters for their feedback on the proposed
( printed page 67967)
compliance and transition dates. In response to concerns with timelines and compliance gaps, for several certification criteria, we have either revised the effective dates or have not finalized our proposal, such as § 170.315(b)(1), (f)(4), and (f)(7). We refer readers to their respective sections of this final rule for further details. In response to concerns with risks creating discontinuities for providers and functional gaps, we note that the removal of a standard does not require reissuance of a certificate in the Certification Program and the standard can still remain in the product. The removal of a standard from the Certification Program does not necessitate the removal of health IT functions using that standard or preclude the continued use of that standard in Health IT Modules. In future rulemaking when a new standard or a new set of standards are adopted, in particular FHIR-based standards, we intend to consider appropriate timelines for developers to adopt and implement these new standards in any future rulemaking establishing new requirements for the Certification Program.
We have finalized the removal of the following standards as of the effective date of this final rule because they would no longer be referenced in certification criteria in the CFR: transport standards in § 170.202(b), (c) and (e); and functional standards in § 170.204. Because vocabulary standards for representing electronic health information in § 170.207(r) and (s) are referenced in § 170.315(c)(4), which we have finalized our proposal to remove effective January 1, 2027, as discussed in section III.A.3.b., we have also finalized the removal of § 170.207(r) and (s), effective January 1, 2027. We have finalized the removal of the following standards as of the effective date of this final rule since we have finalized the revisions of the associated certification criterion requirements to no longer reference the given standard: the content and exchange standard in § 170.205(r)(1), including the specific document templates in § 170.205(r)(1)(i) through (iii).
We have finalized the removal of content exchange standards and implementation specifications referenced in certification criteria requirements that have expired in § 170.205(k)(1) and (2) from the CFR. We have finalized the removal of API standards that expire on January 1, 2026, in § 170.215(b)(1)(i) and (c)(1), and we also finalized to remove and reserve outdated vocabulary standards in § 170.207(f)(2) and (m)(1).
We have finalized the removal of certain vocabulary standards in order to eliminate outdated standards that are no longer referenced or have expired. Therefore, we have removed vocabulary standards in § 170.207(a)(4), (c)(3), (e)(3) and (4). We also finalized the removal of vocabulary standards in § 170.207(d)(1)(ii) and (d)(1)(iii), from the CFR and reserved these paragraphs.
We have also finalized a minor revision to § 170.205(d)(2) to add the full name of the HL7 Messaging Standard Version 2.5.1 standard.
C. Terms and Definitions
We proposed in the Proposed Rule to remove certain certification criteria from § 170.315 and therefore, we proposed to make conforming edits to the terms and definitions in § 170.102 (90 FR 61001).
1. Base EHR
We proposed to make conforming revisions to the Base EHR definition in § 170.102 based on our proposals to remove certification criteria from the CFR that are currently referenced in § 170.102 (90 FR 61001). In section (3)(i) of the Base EHR definition, we proposed to remove references to § 170.315(a)(14), (g)(7) and (9), and (h)(1) and (2). We proposed to remove these certification criteria from the Base EHR definition because we have proposed to remove those certification criteria from the CFR. We also proposed to move § 170.315(b)(11) to section (3)(i) of the definition and remove and reserve section (3)(ii) and remove section (3)(iii) because the transition date has passed.
Comments.
The majority of commenters were supportive of revising the Base EHR definition to remove references to certification criteria proposed for elimination and to streamline related definitions, stating that it would have the benefit of improving clarity and consistency for participants in the Certification Program and reducing confusion associated with outdated or obsolete terminology. Commenters noted that our proposal for revising the Base EHR definition would require additional guidance on transition timing and alignment with CMS CEHRT definitions and CMS payment program requirements that rely on certified functionality.
A commenter urged ONC to ensure that interested parties were aware that privacy and security protections are expected despite no longer being enumerated in the definition. Another commenter recommended including certification criteria to enable baseline functionality aligned with the Centers for Medicare and Medicaid (CMS) Interoperability and Prior Authorization Rule (CMS-0057-F) and future CMS rulemaking expectations, particularly to ensure accountability for enabling bi-directional data exchange between payer systems and provider electronic health records. Other commenters cautioned that changing the Base EHR definition by removing or weakening capabilities could create operational risk including delays and added costs for procurements and contracts. Another commenter urged ONC to provide explicit clarification regarding CAH applicability and to evaluate whether transition timelines, phased implementation, or rural impact assessments are appropriate.
Response.
We thank commenters for their support of us making conforming edits in § 170.102. We have finalized some of the proposed revisions to § 170.102. Specifically, in section (3)(i) of the Base EHR definition, we have finalized the removal of references to § 170.315(g)(7) and (9), and (h)(1) and (2). We have finalized the removal of these certification criteria from the Base EHR definition because we have removed these certification criteria from the CFR. Because we did not finalize our proposal to remove the IDL certification criterion in § 170.315(a)(14), we did not finalize our proposal to remove § 170.315(a)(14) from the Base EHR definition. We have finalized the proposal to move § 170.315(b)(11) to section (3)(i) of the definition and remove and reserve section (3)(ii) and remove section (3)(iii) because the transition date has passed. As we discussed in the Proposed Rule, the Base EHR definition provides a baseline assurance that certified health IT has been developed to possess, at a minimum, a key set of capabilities. We note the Base EHR definition is based on the “Qualified EHR” definition in section 3000(13) of the PHSA (77 FR 54262). As we noted recently, we have generally sought to limit the Base EHR definition to elements required for the Qualified EHR definition in PHSA section 3000 (90 FR 37145).
We are working closely with CMS on timing and alignment. We note that the removal of criteria from the Base EHR definition does not require eligible clinicians, eligible hospitals, and CAHs participating in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category to cease use of these health IT functionalities and standards, nor does it require health IT developers to remove them from certified health IT. CMS Program requirements generally do not prohibit the use of functionalities or standards that are not certified; rather they focus on the use of technologies
( printed page 67968)
that are certified to support specific Promoting Interoperability objectives and measures. Where any of the criteria we have finalized for removal are required to support a CMS program objective or measure, we have taken that use into account in setting transition timelines.
We also want to clarify that the Base EHR definition does not include specific privacy and security-related criteria. However, we have not finalized the removal of the privacy and security related criteria in § 170.315(d)(1) through (13). For commenters' concerns related to contracts, we direct them to the ONC resource, titled “EHR Contracts Untangled.” [47]
2. Common Clinical Data Set
We proposed to remove the term Common Clinical Data Set in § 170.102.
Comments.
The majority of commenters were supportive of removing the Common Clinical Data Set (CCDS) definition. Some commenters supported relying on the USCDI as the single standardized baseline for certification and data exchange expectations, noting that maintaining both CCDS and USCDI contributes to unnecessary complexity and that a single baseline could improve alignment across programs and support predictable updates.
Response.
We have finalized as proposed the removal of the term Common Clinical Data Set in § 170.102. As we discussed in the Proposed Rule, we finalized in the Cures Act Final Rule that the CCDS would no longer be applicable for certified Health IT Modules 24 months after the publication date of the Cures Act Final Rule (85 FR 25671), and then extended that date to December 31, 2022, in the interim final rule titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70073). Because § 170.315(b)(6)(ii)(A), which also referenced CCDS, was available for the period before December 31, 2023, we did not propose to remove the definition of CCDS in § 170.102 at that time. However, now that the date of December 31, 2023, has passed and we finalized the removal of § 170.315(b)(6) in the HTI-2 Final Rule (89 FR 101776) and there are no longer any references to CCDS in 45 CFR part 170, we have finalized the removal of the term Common Clinical Data Set in § 170.102.
3. Global Unique Device Identification Database and Production Identifier
Because we proposed to remove the “implantable device list” (IDL) certification criterion in § 170.315(a)(14) (90 FR 60983), we also proposed to remove the associated definitions of Global Unique Device Identification Database and Production Identifier in § 170.102.
Comments.
The majority of commenters were supportive of the proposed updates to terms and definitions (including removing the definitions of Global Unique Device Identification Database and Production Identifier). Commenters stated that it would streamline terminology, reduce confusion from obsolete constructs, and improve clarity/regulatory clarity.
Response.
We appreciate commenters' support but because we did not finalize our proposal to remove the IDL certification criterion in § 170.315(a)(14), we have not finalized our proposals to remove the terms Global Unique Device Identification Database and Production Identifier from § 170.102. In section A.1.c of this final rule, we have discussed the IDL certification criterion in § 170.315(a)(14). The IDL certification criterion requires Health IT Modules certified to § 170.315(a)(14) to exchange, record, and allow a user to access a list of Unique Device Identifiers (UDIs) associated with a patient's implantable devices. The only references to the Global Unique Device Identification Database and Production Identifier in 45 CFR part 170 are in § 170.315(a)(14). Because we have not finalized the removal of § 170.315(a)(14), we have also not finalized the removal of the definitions Global Unique Device Identification Database and Production Identifier in § 170.102 as the terms are still referenced in 45 CFR part 170.
D. Conditions and Maintenance of Certification Requirements for Health IT Developers
1. Assurances
Because the transition dates in § 170.402(b)(2)(i) and (ii) had passed, we proposed to revise the Maintenance of Certification requirements in § 170.402(b)(2) to remove the transition dates and only include that a health IT developer that must comply with the requirements of § 170.402(a)(4) must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10) (90 FR 61001).
We also proposed additional conforming edits to § 170.402(b). Because we proposed to remove the requirements in § 170.315(b)(11)(iv) and (v) regarding source attribute support, access, and modification and in § 170.315(b)(11)(vi) regarding intervention risk management for predictive DSIs (90 FR 60987), we also proposed to remove § 170.402(b)(4), which requires health IT developers to review and update as necessary source attribute information and intervention risk management practices (90 FR 61001 and 61002).
Comments.
The majority of commenters supported the proposed conforming edits to the Assurances Maintenance of Certification requirements, stating that the proposed revisions would have the benefit of reducing certification/compliance burden and streamlining certification obligations. Some commenters also supported specific technical updates within the Assurances provisions, including removing outdated references related to EHI Export.
Commenters were generally evenly split on supporting or opposing the proposed removal of the Assurances Maintenance requirement in § 170.402(b)(4), with those in support noting that removal of § 170.402(b)(4) would avoid retaining a maintenance requirement for provisions that no longer exist in the related certification criterion. Commenters that opposed the removal of the Assurances Maintenance requirement in § 170.402(b)(4) recommended retaining the associated Assurances Maintenance of Certification requirement in § 170.402(b)(4), consistent with their recommendations for retaining requirements under the DSI criterion for providing source attributes and intervention risk management practices, as described in section III.A.2.e. of this final rule.
Response.
We appreciate commenters' support for our proposal to make conforming edits to the Assurances Conditions and Maintenance of Certification requirements and we finalize, as proposed, the revisions. Because the transition dates in § 170.402(b)(2)(i) and (ii) have passed, we have finalized in the Maintenance of Certification requirements in § 170.402(b)(2) the removal of the transition dates and only include that a health IT developer that must comply with the requirements of § 170.402(a)(4) must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10).
With respect to the comments regarding the DSI criterion, we have finalized, as proposed, the removal of § 170.402(b)(4), which requires health IT
( printed page 67969)
developers to review and update as necessary source attribute information and intervention risk management practices. As discussed in section III.A.2.e. of this final rule, we have finalized removal of source attribute information transparency for evidence-based and predictive decision support interventions in § 170.315(b)(11)(iv), as well as removal of source attribute access and modification requirements and intervention risk management requirements in § 170.315(b)(11)(v) and (vi), Because we have finalized the removal of certain requirements in § 170.315(b)(11), we no longer believe that a maintenance requirement is necessary under § 170.402(b)(4). Therefore, we disagree with commenters who recommended that we retain § 170.402(b)(4), and we have also finalized the removal of § 170.402(b)(4).
2. Application Programming Interfaces
In the Proposed Rule, we explained that because the transition dates in § 170.404(b)(2), (3), and (4) have passed, we proposed to revise the Maintenance of Certification requirements in § 170.404(b) (90 FR 61002). We proposed to revise § 170.404(b)(2) to remove the date, and we proposed to remove paragraphs (b)(3) and (b)(4) entirely as they are outdated and, in the case of (b)(4) because it refers to certification criteria that we also proposed to remove. We proposed to revise § 170.404(c) to update certification criteria referenced in the “Certified API technology” definition. We proposed to remove the reference to “§ 170.315(g)(7) through” and only keep § 170.315(g)(10) in the “Certified API technology” definition because we proposed to remove § 170.315(g)(7) through (9).
Comments.
The majority of commenters supported our proposed conforming edits and streamlining of the API Conditions and Maintenance of Certification requirements, stating that they would have the benefit of reducing unnecessary burden while focusing on currently relevant, standards-based APIs and a limited set of meaningful interoperability signals.
Some commenters stated that our proposal for updating these requirements would require additional guidance of how key API transparency, availability, and documentation expectations will be retained and implemented consistently, including clarity on responsibilities and accountability when certified exchange pathways fail.
A commenter requested that we remove the transparency requirement that certified developers publish their service base URLs publicly in § 170.404(b)(2). The commenter argued that a published URL list could reveal a developer's customer footprint, the identity of its customers, its approximate market position and growth, and where an emerging competitor is gaining traction. Another commenter opposed eliminating the references to, and functionality associated with, the certification criteria in § 170.315(g)(7) and (g)(9). Another commenter opposed any practical weakening of the API Conditions and Maintenance of Certification requirements, stating that third-party application developers already encounter substantial barriers despite the existing requirements.
Response.
We thank commenters for their support of our proposals to make conforming revisions in § 170.404. We also appreciate the concerns raised by commenters regarding continued API transparency, availability, documentation, and accountability. The revisions we have finalized in § 170.404 remove expired transition provisions and obsolete cross-references; they do not reduce or otherwise alter the substantive requirements in § 170.404(a) or the continuing Maintenance of Certification requirements in § 170.404(b)(1) and (2).
We disagree with the commenter who urged us not to retain the public service base URL publication requirement. We did not propose to eliminate the requirement in § 170.404(b)(2). We recognize that publication of service base URLs and related organization details may reveal customer relationships and permit inferences about a developer's market presence. Nevertheless, public endpoint information enables patients and applications to identify the appropriate deployed API and connect without special effort. The requirement is limited to the service base URLs and related organization details specified in § 170.404(b)(2). The patient access, transparency, and interoperability benefits of endpoint publication outweigh the competitive concerns identified by the commenter, and we, therefore, retain the requirement.
We also disagree that the conforming revision to the definition of “Certified API technology” in § 170.404(c) eliminates or requires discontinuation of the functionality associated with former § 170.315(g)(7) and (g)(9). The revision aligns the definition with the certification criteria that remain in the CFR; it does not independently remove functionality. We agree with the commenter that stated that third-party application developers should not face practices that impermissibly impede access to or use of certified API technology. We disagree, however, that the conforming revisions finalized in § 170.404 weaken the API Condition and Maintenance of Certification requirements in practice.
Accordingly, we have finalized these proposals as proposed. Because the transition dates in § 170.404(b)(2), (3), and (4) have passed, we have finalized a revision to the Maintenance of Certification requirements in § 170.404(b). We have finalized a revision in § 170.404(b)(2) to remove the date, and we have finalized the removal of paragraphs (b)(3) and (b)(4) entirely as they are outdated and, in the case of (b)(4) because it refers to certification criteria that we have removed. We also finalized a revision in § 170.404(c) to update certification criteria referenced in the “Certified API technology” definition. We have finalized the removal of the reference to “§ 170.315(g)(7) through” and only keep the reference to § 170.315(g)(10) in the “Certified API technology” definition because we have finalized the removal of § 170.315(g)(7) through (9).
3. Real World Testing
Consistent with the “Real World Testing Condition and Maintenance of Certification Requirements Enforcement Discretion Notice” [48]
issued on June 30, 2025, we proposed three deregulatory actions for the Real World Testing (RWT) Condition and Maintenance of Certification requirements under 45 CFR 170.405 (90 FR 61002). First, we proposed to remove the requirement to submit real world testing plans for all real world testing certification criteria (§ 170.405(b)(1)). Second, we proposed to limit full real world testing results reporting (§ 170.405(b)(2)) to only Health IT Modules that are certified to the API certification criteria, which are “standardized API for patient and population services” (§ 170.315(g)(10)); “provider prior authorization API—coverage requirements discovery” (§ 170.315(g)(31)); “provider prior authorization API—documentation templates and rules” (§ 170.315(g)(32)); and “provider prior authorization API—prior authorization support” (§ 170.315(g)(33)). Specifically, we proposed that developers would be expected to report on all health IT certified to any of the certification criteria in § 170.315(g) as of January 1 of the year in which they must complete real world testing. Developers would
( printed page 67970)
also need to report on all health IT certified to any of the certification criteria in § 170.315(g) that undergo updates via Inherited Certified Status during the real world testing year. Finally, we proposed to revise the Standards Version Advancement Process (SVAP). For the API-focused certification criteria identified as § 170.315(g) criteria in § 170.405(a), the real world testing SVAP reporting requirements would not change under § 170.405(b). For health IT certified to the remaining RWT certification criteria identified in § 170.405(a), developers would only need to identify in their RWT results their voluntary updates (health IT products, certification criteria, and standards/implementation specifications) to standards and implementation specifications that the National Coordinator has approved through SVAP, which would be consistent with current requirements under 45 CFR 170.405(b)(2)(ii)(C). For clarity, we proposed to capture the SVAP requirement separately in proposed 45 CFR 170.405(b)(2)(iv). We also proposed a revision to § 170.405(b)(8) to cross-reference paragraph (a) of § 170.405 instead of paragraph (b) due to our proposed revisions.
Comments.
A few commenters requested clarification regarding whether full RWT obligations remain applicable to certification criteria outside the API-focused criteria under § 170.405(a), and recommended revisions to the regulation text to remove ambiguity.
Response.
The proposed revised text for § 170.405(a) maintained the requirement that health IT developers with one or more Health IT Module(s) certified to any one or more of the Certification Criteria for Health IT in § 170.315(b), (c), (e), (f), (g), and (j) must, on an annual basis, successfully test the real world use of those Health IT Module(s). Therefore, consistent with our proposal, the § 170.405(a) obligation to conduct RWT remains as to the specified criteria in our finalized § 170.405(a), which includes criteria beyond the API-focused criteria. As we noted in the Proposed Rule, certain certification criteria would be fully removed from real world testing requirements by virtue of their proposed removal from the Certification Program (90 FR 61002). We further explained that if, in this final rule, we determined to keep any of the criteria proposed for removal and they are currently identified in the RWT Condition of Certification (45 CFR 170.405(a)), they would also remain part of the RWT Condition of Certification. As discussed earlier in this preamble, we have retained the following RWT certification criteria that were originally proposed for removal from the Certification Program: “clinical information reconciliation and incorporation” (§ 170.315(b)(2)), “transmission to cancer registries” (§ 170.315(f)(4)), and “transmission to public health agencies—health care surveys” (§ 170.315(f)(7)). Further, we retained the safety-enhanced design (§ 170.315(g)(3)), quality management system (§ 170.315(g)(4)), and accessibility-centered design (§ 170.315(g)(5)) certification criteria. Due to the retention of these three certification criteria, we have slightly modified the proposed regulation text for § 170.405(a) to identify the specific (g) criteria included in RWT comparative to our proposal to include all of the (g) criteria. The (g) certification criteria we retained were not previously included in RWT, and we have never proposed to include them in RWT.
Section 3001(c)(5) of the PHSA (42 U.S.C. 300jj-11) (section 4002 of the Cures Act) requires, as a Condition and Maintenance of Certification under the Certification Program, that health IT developers have successfully tested the real world use of the technology for interoperability in the type of setting in which such technology would be marketed. Section 4003(a)(2) of the Cures Act defines interoperability as health information technology that enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user; allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law; and does not constitute information blocking as defined in section 3022(a) of the Cures Act, as added by section 4004 of the 21st Century Cures Act (42 U.S.C. 300jj-52(a)). This definition for interoperability was codified in 45 CFR 170.102. As noted in the Proposed Rule, we finalized the implementation of the statute's real world testing requirements through identification of certification criteria for RWT in 45 CFR 170.405(a). Developers remain obligated to conduct RWT for health IT certified to certification criteria identified in § 170.405(a). Therefore, even with consideration of the removal of certification criteria by this final rule, there is no reason to amend the regulatory text of § 170.405(a) beyond how we have finalized it compared to our proposal (
i.e., specifying the (g) criteria within scope).
Removal of RWT Plan Submission and Reduced RWT Results Reporting
Comments.
Several commenters supported our proposal to remove the RWT plan submissions and reduce RWT results reporting, particularly by narrowing reporting obligations to FHIR-based API criteria. These commenters generally argued that the current RWT framework imposes significant administrative and compliance burdens while providing limited practical value. Commenters described the annual testing plans as largely formulistic endeavors that consume resources without meaningfully improving interoperability outcomes. These commenters also emphasized that focusing RWT oversight on key API certification criteria—such as § 170.315(g)(10) and the “prior authorization” API criteria—better aligns with ONC's “FHIR-forward” strategy and concentrates on the interoperability functions most critical to real-world EHI exchange.
A majority of commenters opposed our proposal to remove the RWT plan submissions and reduce RWT results reporting. Commenters asserted that our proposals would weaken developer accountability, interoperability assurance, and patient safety protections (
e.g., identifying missing meds, incomplete data). Commenters stressed that publicly available RWT plans and results provide important transparency for healthcare organizations making purchasing and implementation decisions and help smaller providers, rural organizations, and public health agencies assess whether products will function effectively. Commenters argued that reducing RWT reporting to API criteria was premature because there is not yet a fully mature and stable FHIR-based ecosystem. Commenters also argued that the proposed approach could leave important interoperability gaps undetected, such as with public health reporting.
Response.
We thank commenters for expressing both their supporting and opposing viewpoints. We have finalized the removal of the RWT plan requirement and the reduced RWT results reporting as proposed. We agree with commenters who stated that the previously codified RWT plans and results reporting requirements created significant burden without meaningful results. An API-focused approach will align with our overall strategy for the Certification Program and support interoperability. Considering the
( printed page 67971)
planned API and FHIR-forward future approach for the Certification Program, we believe that future results reporting will provide the transparency and interoperability assurance advocated for by commenters. For example, as we propose, and should we adopt, more API and FHIR-based certification criteria,[49]
we anticipate that there would continue to be RWT results reporting for those criteria that can provide insights into the interoperability of certified health IT.
While we appreciate commenters' statements that RWT results may be used to inform decisions regarding the purchasing and licensing certified health IT, we believe that, based on our interactions with health care providers and their executives, it is only one of a multitude of factors that they consider. Further, we believe that the current RWT results reporting and anticipated future RWT results reporting related to APIs will provide information that health care providers may find useful in making certified health IT purchasing and licensing decisions.
We also believe that the Certification Program, through conformance testing, ONC-ACB surveillance and corrective action, and ONC direct review, provides the requisite developer accountability and program oversight to provide assurances to consumers and users of certified health IT. These same processes also support patient safety, including through retention of the revised safety-enhanced designed certification criterion (§ 170.315(g)(3)).
SVAP
Comments.
We received significant support from commenters for our proposal to streamline the SVAP reporting process, with only a few commenters expressing indirect opposition to the proposal based on their belief that our proposals would reduce overall oversight of the Certification Program. Commenters requested clarification on when SVAP standards must be reported in RWT results reports for non-API criteria, including whether reporting applies to all SVAP standards on the CHPL listing, only those implemented during the applicable calendar year, or only newly added SVAP standards not previously reported. Another commenter questioned the burden of requiring RWT Results Reports solely to restate SVAP information already available on CHPL. A few commenters requested that we provide clear expectations and transition guidance if RWT requirements change during the 2026-2027 implementation period.
Response.
We have finalized with modification our proposed revisions of SVAP. SVAP is a voluntary process that requires affirmative actions by developers to adopt and certify their health IT to a newer version of a standard or implementation specification that is included in certification criteria that are specified in RWT under § 170.405(a). Ultimately, through attestations under 45 CFR 170.406, a developer attests that their certified health IT is conformant to the “SVAP” version of the standard or implementation specification as part of their overall attestation to compliance with 45 CFR 170.405.
Except as follows, we have finalized as proposed our proposed modifications to SVAP. In consideration of the regulatory version updating and attestation processes outlined above and public comment noting that SVAP standards are identified via the CHPL for certified health IT, we have not finalized our proposal to require, as part of RWT results reporting, the identification of any SVAP updates to health IT certified to the non-API RWT certification criteria identified in § 170.405(a) (the non-(g) certification criteria). We believe sufficient assurances and transparency will be provided by the aforementioned attestation and CHPL listings. As a result, there is no need for developers to identify in their RWT results their voluntary updates (health IT products, certification criteria, and standards/implementation specifications). This approach avoids redundancies and further reduces burden. We have, however, finalized our proposal that the RWT SVAP reporting requirements would not change for API-focused certification criteria identified as (g) criteria in § 170.405(a). This is because we proposed that all provisions under § 170.405(b) would still apply to health IT certified to API-focused certification criteria, and we expect such RWT and reporting to occur, including with SVAP versions of standards and implementation specifications, as applicable. For clarity, we have still finalized the proposed revision to § 170.405(b)(8) to cross-reference paragraph (a) of § 170.405 instead of paragraph (b). This will provide the availability of SVAP for all health IT certified to certification criteria identified in § 170.405(a), which supports advancing interoperability. All revisions will be effective upon the effective date of this final rule. As such, we will implement this approach for the attestation period that begins on January 1, 2027.
Comments.
A commenter requested clarification and reconsideration of proposed timelines tied to certification as of January 1 of the testing year, including retention of the existing August 31 threshold date.
Response.
We did not propose nor have we finalized any changes to the regulatory timeframes for RWT results reporting.
Comments.
Commenters asked what mechanisms we envisioned to ensure ongoing monitoring of SI performance, model evolution, and real-world impact if existing oversight mechanisms are removed.
Response.
As the functionality referenced by commenters was removed from the DSI certification criterion through this final rule, it would not be part of RWT. We refer readers to the discussion earlier in the preamble regarding the DSI certification criterion and the final policy determinations (
see
III.A.2.e “Decision Support Interventions”).
Comments.
Commenters asked how we would prevent fraud or “low-quality” certification as RWT requirements are reduced. Another commenter recommended that we move to continuous performance monitoring.
Response.
ONC maintains a robust oversight framework for the ONC Health IT Certification Program, including the ability for ONC to directly review certified health IT as specified in 45 CFR 170.580. We are confident that sufficient regulatory oversight remains in place notwithstanding the policies we have finalized to remove RWT testing plans and RWT results reporting for limited certification criteria.
Comments.
A few commenters provided alternative approaches to RWT than previously codified or proposed in the Proposed Rule. These included suggestions to focus on performance-based metrics such as uptime, latency, error rates, and adoption rates. As one example, a commenter suggested applying a risk-based or scope testing.
Response.
We thank commenters for these suggestions, but they are beyond the scope of this rulemaking.
4. Attestations
Because we proposed to remove § 170.315(g)(7) through (9) in the Proposed Rule (90 FR 60998), we also proposed to remove the references to § 170.315(g)(7) through (9) in § 170.406(a)(4). Further, in § 170.406(a)(5), we also proposed to remove the reference to § 170.315(g)(7) through (9). Additionally, we proposed
( printed page 67972)
to remove the reference to § 170.315(h) in § 170.406(a)(5) because in the Proposed Rule (90 FR 60998 through 60999), we proposed to remove § 170.315(h)(1) and (2), in effect removing the entirety of § 170.315(h) (90 FR 61003).
Comments.
Commenters were supportive of the proposal to make conforming edits to the Attestations Condition of Certification requirements, stating that it would have the benefit of reducing administrative burden, improving clarity, and better aligning requirements with an updated certification framework.
Response.
We appreciate commenters' support. We have finalized as proposed conforming edits to the Attestations Condition of Certification requirements. Because we have finalized the removal of § 170.315(g)(7) through (9), we also have removed the references to § 170.315(g)(7) through (9) in § 170.406(a)(4). In § 170.406(a)(5), we also finalized the removal of the reference to § 170.315(g)(7) through (9). Additionally, we have finalized the removal of the reference to § 170.315(h) in § 170.406(a)(5) because, as we discussed in section III.A.8 of this final rule, we have finalized the removal of § 170.315(h)(1) and (2), in effect removing the entirety of § 170.315(h).
5. Insights
As discussed in the Proposed Rule, the Insights Condition (§ 170.407) includes seven measures on which certain health IT developers under the Certification Program must annually report consistent with specified timelines (90 FR 61003).
We explained in the Proposed Rule that consistent with E.O. 14192, “Unleashing Prosperity Through Deregulation,” [50]
we identified certain regulatory requirements for which the exercise of enforcement discretion may prevent or mitigate the accrual of sunk costs by regulated entities, and on April 29, 2025, we published the “Insights Condition and Maintenance of Certification Enforcement Discretion Notice.” [51]
In the enforcement discretion notice, we stated the enforcement discretion will be in effect beginning on July 1, 2027, and will remain in effect until HHS completes a deregulatory action to remove or revise 45 CFR 170.407 and 170.523(u) (90 FR 61003).
In the Proposed Rule, we proposed to remove the following measures in § 170.407(a)(3):
§ 170.407(a)(3)(i), Individuals' access to electronic health information through certified health IT;
§ 170.407(a)(3)(ii), Consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT;
§ 170.407(a)(3)(iii), Applications supported through certified health IT;
§ 170.407(a)(3)(v), Use of FHIR bulk data access through certified health IT;
§ 170.407(a)(3)(vi), Immunization administrations electronically submitted to immunization information systems through certified health IT; and
§ 170.407(a)(3)(vii), Immunization history and forecasts through certified health IT.
We also proposed to make conforming edits to the list structure in § 170.407(a)(3) by redesignating the provision that was in § 170.407(a)(3)(iv) “use of FHIR in apps through certified health IT” instead as paragraph § 170.407(a)(3)(i), as well as to revise § 170.407(a)(1)(ii)(B) and (C) to remove references to the measures that we proposed to remove from § 170.407(a)(3). In addition, we proposed to remove corresponding references to the removed measures in § 170.407(b), as we only expected that health IT developers would report on the “use of FHIR in apps” measure in the newly designated § 170.407(a)(3)(i), specifically, paragraphs (a)(3)(i)(A) and (B) beginning July of 2027 and (a)(3)(i)(C) beginning in July 2028 (90 FR 61003 through 61004).
In the Proposed Rule, we additionally proposed to revise § 170.407(b)(1) to clarify that a developer must provide an annual response to the Insights Condition of Certification if the developer had at least one actively certified Health IT Module as of January 1 of the reporting period (
i.e., start of the data collection year) (90 FR 61004). We stated that, if a certified Health IT Module does not meet the eligibility criteria as of January 1 of the reporting period, developers are not required to submit a measure response for that Health IT Module for that calendar year. In this scenario, developers would submit an attestation indicating that they are not required to submit a measure response for that reporting period, and the reason why (they were not eligible as of the January 1st cutoff date). For example, if the certified Health IT Module becomes eligible after January 1st of the reporting period, developers are not required to submit a measure response for that Health IT Module for that reporting period; they would submit an attestation as described above instead. The developer would submit a measure response the following reporting period for that certified Health IT Module if the certified Health IT Module meets the applicable eligibility criteria as of January 1st of that reporting period.
Lastly, in the Proposed Rule we proposed to revise the name of § 170.407 (Insights Condition and Maintenance of Certification) to simply “Insights” to ensure consistency and uniformity across all the Conditions and Maintenance of Certification in subpart D of 45 CFR part 170 (90 FR 61004).
Comments.
We received a number of comments that were supportive of our proposal to remove six of the Insights measures. Commenters stated that the preparations for compliance with the reporting requirements for the Insights measures would have been a significant investment burden for eligible health IT developers. A commenter also asserted that there is no clear connection between the accumulation of data and marketplace improvement. Another commenter expressed support for our approach in the selection of measures for removal in comparison to those we did not propose to remove. Specifically, the commenter noted that data from the “use of FHIR in apps” measure, which we did not propose to remove, could be collected directly by health IT developers for reporting the measure and could therefore create less burden than the other Insights measures.
Response.
We thank commenters for their feedback on our proposal to remove six Insights measures. We agree with commenters' perspective that some of the Insights measures would impose significant costs and burden to health IT developers. As we stated in the Proposed Rule, our proposals would ensure that the Insights Condition is aligned with other proposed policies and changes to the Certification Program that prioritize exchange using FHIR-based APIs (90 FR 61004). For the reasons described above regarding the burden to health IT developers and our policies to prioritize exchange using FHIR-based APIs, we have finalized the removal of the following measures as proposed: § 170.407(a)(3)(i) “the individuals' access to electronic health information,” § 170.407(a)(3)(ii) “consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation,” § 170.407(a)(3)(iii) “applications supported,” § 170.407(a)(3)(vi) “immunization administrations electronically submitted to immunization information systems,”
( printed page 67973)
and § 170.407(a)(3)(vii) “immunization history and forecasts.”
As we discuss hereafter, we have decided not to finalize the removal of the “use of FHIR bulk data access” measure in § 170.407(a)(3)(v) as proposed because we believe that retaining the measure aligns with our FHIR-forward future strategy and our other changes finalized in this rule to prioritize exchange using FHIR-based APIs in the Certification Program. We believe that “use of FHIR bulk data access” measure will provide valuable insights related to the implementation and use of FHIR that will not be captured by the “use of FHIR in apps” measure alone (which, as noted, we did not propose to remove). While we did not finalize the removal of the “use of FHIR bulk data access” measure, we have finalized revisions to § 170.407(b)(1)(i)(B) and (C) to provide more time before reporting of this measure is required. Specifically, we are moving the “use of FHIR bulk data access” measure (previously paragraph (a)(3)(v); paragraph (a)(3)(ii) as finalized in this final rule) from § 170.407(b)(1)(i)(B) to (C). In practice, this means health IT developers will have additional time and will now be required to begin reporting responses for the “use of FHIR bulk data access” measure in July 2029, rather than in July 2028. Developers must collect the required reporting data annually during the preceding year and develop and deploy the technology needed to support data collection in client settings. Considering the timing of the publication of this final rule, there would not be sufficient time for health IT developers to complete these activities in preparation for reporting. Accordingly, moving the reporting start date from July 2028 to July 2029 is appropriate to provide sufficient notice and time for health IT developers to prepare for reporting.
We have finalized conforming edits to the list structure in § 170.407(a)(3) to revise the “use of FHIR in apps through certified health IT” as paragraph (i) instead of (iv) and revise the “use of FHIR bulk data access through certified health IT” as paragraph (ii) instead of (v). We have also finalized conforming edits to § 170.407(a)(1)(ii)(B) and (C) to remove references to the measures that we are removing from § 170.407(a)(3) as well.
Additionally, we have finalized a revision, as proposed, to the name of § 170.407 (Insights Condition and Maintenance of Certification) to simply “Insights” to ensure consistency and uniformity across all the Conditions and Maintenance of Certification in subpart D of 45 CFR part 170.
Comments.
We received several comments regarding our proposal to remove the “use of FHIR bulk data access” measure in § 170.407(a)(3)(v). These commenters stated the “use of FHIR bulk data access” measure is necessary for the measurement of large-scale analytics of app traffic. Commenters also emphasized that the data obtained from the “use of FHIR in apps” measure would be an insufficient substitute for the data that would be obtained from the “use of FHIR bulk data access” measure. Another commenter stated that the “use of FHIR bulk data access” measure would require less effort because it requires tracking minimal data. The commenter also noted that the measure would provide information on the inconsistent implementation of bulk access capabilities. Commenters recommended that ONC retain the “use of FHIR bulk data access” measure to preserve access to information on large-scale data interoperability.
Response.
We thank commenters for their feedback regarding our proposal to remove the “use of FHIR bulk data access” measure in § 170.407(a)(3)(v). As discussed above, we have decided to retain the “use of FHIR bulk data access” measure in § 170.407(a)(3)(v) (which we have moved to § 170.407(a)(3)(ii)) and have not finalized the removal of the measure as proposed. We agree with commenters that the “use of FHIR bulk data access” measure should be retained to address gaps in measurement and provide transparency on the use of certified health IT not captured by “the use of FHIR in apps” measure in § 170.407(a)(3)(iv). We adopted the “use of FHIR bulk data access” measure to address gaps in measurement and provide transparency on the use of certified health IT not captured by the “use of FHIR in apps” measure in § 170.407(a)(3)(iv) (88 FR 23840 through 23841). There are a number of reports that the performance of FHIR bulk data access is suboptimal, which could be a result of health IT developers' implementation of the standard.[52 53 54]
Retaining the “use of FHIR bulk data access” measure in § 170.407(a)(3)(v) will allow us to monitor issues that may be limiting the performance of Bulk FHIR data access by providing insights related to implementation and use of the FHIR standard in large-scale app traffic that Bulk FHIR data access supports. This insight is particularly important as innovators throughout the industry continue to advance bulk data use cases for quality measurement, public health reporting, and clinical research purposes. Retaining the “use of FHIR bulk data access” measure also aligns with our other finalized changes in this rule to prioritize exchange using FHIR-based APIs in the Certification Program by providing insights into the implementation and use of FHIR that will not be captured by the “use of FHIR in apps” measure alone.
Comments.
We received a number of comments that broadly opposed our proposal to remove the six identified Insights measures. Commenters stated that the Insights measures would have provided transparency regarding interoperability and FHIR capabilities across health IT products and the health IT industry as a whole. Many commenters emphasized that the data that would have been provided by the Insights measures would be an important tool for accountability in the marketplace for Health IT Modules. Some commenters also suggested that ONC adopt alternative reporting measures that are less burdensome to replace the Insights measures if we finalize the removal of six of the seven Insights measures as proposed.
Response.
We appreciate the comments that we received about our proposal to remove the six identified Insights measures. We understand commenters' concerns about losing access to the data that would have been obtained from the Insights measures that we proposed to remove, but we respectfully disagree with this perspective. We believe that the investment necessary to implement many of the current Insights measures would impose a significant burden on health IT developers that outweighs the benefit we would expect from the data that would have been obtained from the Insights measures for which we have finalized the removal. We clarify that we have not removed the Insights Condition of Certification in its entirety as discussed in detail above. In response to the suggestion that we adopt alternative measures, we will continue to evaluate the Insights measures.
( printed page 67974)
Comments.
We received a comment that supported our proposal to revise § 170.407(b)(1) to clarify that a health IT developer must provide an annual response (consisting of either a measure response or an attestation indicating the developer was not eligible for reporting measurement data to the Insights Condition of Certification) if they had at least one actively certified Health IT Module as of January 1 of the reporting period (
i.e., start of the data collection year) and continue to have certified health IT under the Certification Program at the time of submission (
i.e., July of the following year).
Response.
We appreciate the support and have finalized the revision in § 170.407(b)(1) as proposed. A developer must provide an annual response to the Insights Condition of Certification if the developer had at least one actively certified Health IT Module as of January 1 of the reporting period and the Health IT Module remains certified under the Certification Program at the time of submission.
Comments.
We received a number of comments specific to our proposals to remove the “immunization administrations electronically submitted to immunization information systems through certified health IT” measure in § 170.407(a)(3)(vi) and the “immunization history and forecasts through certified health IT” measure in § 170.407(a)(3)(vii). Some commenters recommended that ONC retain these measures. Commenters emphasized the significant role that immunization information systems play in public health systems and stated that health care providers and patients would benefit from the two measures providing data on utilization of immunization data exchange and access to immunization data exchange. One commenter asserted that the data that would be obtained from the “immunization administrations electronically submitted to immunization information systems through certified health IT” and the “immunization history and forecasts through certified health IT” measures could be used by public health agencies to improve their awareness of and response to public health threats.
Response.
We thank commenters for their feedback. We respectfully disagree with the perspective of the commenters regarding our proposal to remove the “immunization administrations electronically submitted to immunization information systems” measure and “immunization history and forecasts” measure. As we stated in the Proposed Rule, we believe that removing these Insights measures will reduce cost and burden to the public, and we want to ensure that the Insights Condition is aligned with other policies and changes to the Certification Program that prioritize exchange using FHIR-based APIs (90 FR 61004). We believe that the expected burden to health IT developers outweighs the benefit we would expect from the data that would have been obtained from the measures. Further, we believe the value for public health purposes of the data that would have been obtained from these measures is overstated by commenters, as the data reported for the measures is essentially measuring the total function of the certified Health IT Module, and the data would not include the immunization information that is a part of the immunization information system reporting itself. For these reasons and those stated above, we have finalized the removal of the measures in § 170.407(a)(3)(vi) and § 170.407(a)(3)(vii) as proposed.
Technical Updates in Measure Specification Sheets
In the HTI-1 Final Rule (89 FR 1313), we stated that while the substantive requirements for each measure are defined in rulemaking, we determined that measure specification sheets are a logical and accessible method for the public to also view the technical specification that supports those requirements, and that this is consistent with the approach used by other HHS programs related to measure specifications (
e.g., CMS Electronic Clinical Quality Measures (CMS eCQMs)). Additionally, we note that the measure specification sheets provide granular definitions and other information that may be helpful to operationalize the metrics, so they are implemented in a consistent manner across health IT developers.
We also stated that we intend to provide up-to-date measure specification sheets to assist with the regulated community's understanding of the finalized measures and metric calculations (89 FR 1313). In January 2025, we provided developers of certified health IT updated measure specification sheets for certain measures finalized in the HTI-1 Final Rule, with the flexibility to implement either version 2 or version 4 of the measure specification sheets for the first year of reporting.[55]
We noted that this flexibility is only for the first year of reporting (until July 2027) and that we expect developers to comply with the most up to date version of the measure specification sheets provided at
www.healthIT.gov
in subsequent years.
E. ONC Health IT Certification Program Administrative Requirements
1. Principles of Proper Conduct for ONC-ACBs
Under the “principles of proper conduct (PoPCs) for ONC-ACBs” in § 170.523, we require ONC-ACBs to provide ONC a “certified product listing” in § 170.523(f), which is a current list of Health IT Modules that have been certified by the ONC-ACB. In the Proposed Rule (90 FR 61004), we proposed to revise § 170.523(f)(1)(viii) to no longer require ONC-ACBs to provide test data versions used and whether any test data was altered for the certification criterion or criteria to which the Health IT Module has been certified. We noted that with this proposed revision, we would still require the test procedure and test tool version used.
We also proposed to make conforming revisions to the PoPCs for ONC-ACBs in § 170.523 by removing cross-references to certain certification criteria that we proposed to remove in the Proposed Rule. Specifically, we proposed to remove and reserve § 170.523(f)(1)(ix) through (xi) which reference the “privacy and security” certification criteria (§ 170.315(d)), the “quality management system” certification criterion (§ 170.315(g)(4)), and the “accessibility-centered design” certification criterion (§ 170.315(g)(5)). We also proposed to remove and reserve § 170.523(f)(1)(xix), which references the “safety-enhanced design” certification criterion (§ 170.315(g)(3)). We also proposed to remove and reserve § 170.523(f)(1)(xxi) because this section includes a reference to § 170.315(b)(11)(vi) related to intervention risk management practices, and we proposed to remove § 170.315(b)(11)(vi) earlier in the Proposed Rule.
Consistent with the proposals related to the RWT Condition and Maintenance of Certification in § 170.405, we proposed to remove the ONC-ACB review and confirmation process for real world testing plans in § 170.523(p)(1) and the reference to submitting real world testing plans in § 170.523(p)(3).
Comments.
We received a couple of comments expressing support for our proposals. A commenter stated that they support the proposed administrative updates for ONC-ACBs to remove references to the criteria we proposed to remove and agree with the removal of the requirement to provide test data versions used and whether any test data was altered for the certification criterion
( printed page 67975)
or criteria to which the Health IT Module has been certified. The same commenter recommended that ONC and ONC-ACBs communicate that the absence of certain information on the CHPL does not imply those aspects are unimportant and instead reflect Certification Program changes.
Response.
We thank commenters for their support and agree that the absence of certain information on the CHPL does not imply insignificance. As we explained in the Proposed Rule, an analysis of Health IT Modules in the CHPL indicates that the majority of developers do not employ custom data when conducting certification testing but instead utilize the ONC-provided test data, and that due to low user engagement and little variance from the use of ONC-provided test data, documenting the test data provides little value to the public and represents additional administrative burden for both health IT developers and ONC-ACBs. We have finalized our proposal to revise § 170.523(f)(1)(viii) to no longer require ONC-ACBs to provide test data versions used and whether any test data was altered for the certification criterion or criteria to which the Health IT Module has been certified.
We also thank commenters for their support of our proposal to make conforming revisions to the PoPCs for ONC-ACBs by removing cross-references to certain certification criteria that we proposed to remove in the Proposed Rule. We have finalized our proposal to remove and reserve § 170.523(f)(1)(xxi) because this section includes a reference to § 170.315(b)(11)(vi) related to intervention risk management practices, and as discussed in section III.A.2.e, we have finalized our proposal to revise the criterion and remove § 170.315(b)(11)(vi).
We are not finalizing our proposal to remove § 170.523(f)(1)(xix) and instead have finalized a revision to that provision that is consistent with the changes we have finalized for the “safety-enhanced design” certification criteria in § 170.315(g)(3). In section III.A.7.c, we explain that we have not finalized our proposal to remove the safety-enhanced design certification criterion and have determined that the current reporting requirements for the SED certification criterion can be reduced to an attestation-based approach that retains a meaningful certification expectation for safety-enhanced design. Therefore, we have revised § 170.523(f)(1)(xix) to conform with the revisions we have made to the SED certification criterion and eliminated the requirement that each user-centered design element required to be reported must be at a granular level, which aligns with our attestation-based approach.
Since we have not finalized our proposals to remove the following certification criteria (see sections III.A.4, III.A.7.d and e), we have not finalized the proposed conforming revisions of § 170.523(f)(1)(ix) through (xi) which reference the “privacy and security” certification criteria (§ 170.315(d)), the “quality management system” certification criterion (§ 170.315(g)(4)), and the “accessibility-centered design” certification criterion (§ 170.315(g)(5)).
We have also finalized a revision to the introductory paragraph of § 170.523(f) to remove reference to the Assistant Secretary for Technology Policy (ASTP) as we are no longer dually titled (91 FR 16204). We find good cause to waive the notice and comment requirements of the Administrative Procedure Act (APA) to remove these references to ASTP because we believe adherence to these APA requirements would be unnecessary (5 U.S.C. 553(b)(B)) considering that there is no longer an “Assistant Secretary for Technology Policy.” This revision to remove the references to ASTP could also be considered a matter relating to agency management under 5 U.S.C. 553(a)(2) and therefore not subject to the rulemaking requirements in 5 U.S.C. 553. We discuss this in further detail in section IV.
Lastly, consistent with the changes we have finalized related to the RWT Condition and Maintenance of Certification in § 170.405 (see section III.D.3), we have finalized our proposal to remove the ONC-ACB review and confirmation process for real world testing plans in § 170.523(p)(1) and the reference to submitting real world testing plans in § 170.523(p)(3).
Comments.
A commenter provided recommendations that were out of scope for our proposal, including removing the requirements in § 170.523(k) for mandatory disclosures of certain information about certified health IT and removing requirements in § 170.523(m) related to adaptations and updates to certified health IT.
Response.
We appreciate the commenter's feedback, but because we did not propose changes related to these areas in the Proposed Rule, these comments are out of scope and we decline to finalize the recommended changes in this rule.
2. Health IT Module Certification
We proposed to revise the “Health IT Module dependent criteria” in § 170.550(g) by removing § 170.550(g)(1) through (4) to conform with our proposals to remove certain certification criteria related to privacy and security, and design and performance (90 FR 61005). We also proposed renumbering the remaining paragraphs in § 170.550(g)(5) and (g)(6) to (g)(1) and (g)(2), respectively. We proposed to remove § 170.550(h) “privacy and security certification framework” and § 170.550(j) “direct project transport method” to also conform with our proposals to remove certification criteria in § 170.315(d) and § 170.315(h).
Lastly, we proposed to revise § 170.550(e) “standards updates” to correct a cross-reference from “§ 171.405(b)(7) or (8)” to “§ 170.405(b)(7) or (8).”
Comments.
We received no comments on these proposals.
Response.
To conform with the removal of certain certification criteria referenced in § 170.550, we have finalized the removal of § 170.550(g)(4) to remove reference to § 170.315(g)(6) as proposed. We have not finalized our proposal to remove § 170.550(g)(1) through (3), since we did not finalize our proposal to remove § 170.315(g)(3) through (5) (see section III.A.7).
We also proposed to remove § 170.550(h) “privacy and security certification framework” to conform with our proposal to remove certification criteria in § 170.315(d). However, since we did not finalize the removal of certification criteria in § 170.315(d), we have not removed § 170.550(h) as proposed. Instead, we have revised parts of § 170.550(h)(3) to remove references to the certification criteria we have removed from the CFR in this final rule, since they will no longer be referenced in the Certification Program. We have also finalized revisions in § 170.550(h)(3) to remove references to certification criteria that were removed from the Certification Program in past ONC rulemaking but that were inadvertently left unremoved from the regulatory text.[56]
We have finalized the following revisions in § 170.550(h)(3):
(i) removing reference to § 170.315(a)(12);
(ii) removing references to § 170.315(a)(10) and (13);
(iii) removing references to § 170.315(b)(6) through (9);
(vi) removing reference to § 170.315(e)(2) and (3);
(viii) removing references to § 170.315(g)(7) through (9); and
( printed page 67976)
(ix) removing reference to § 170.315(h).
This finalized policy is an exercise of removing outdated references from the current regulatory text, in addition to certification criteria the removal of which we have finalized in this final rule, which the Certification Program will no longer reference. These changes are consistent with, and naturally arise from, our proposals to remove the underlying certification criteria.
In addition, we have finalized the removal of § 170.550(j) “direct project transport method” as proposed to conform with our finalizing the removal of § 170.315(h)(1). We refer readers to section III.A.8 for further details on the removal of § 170.315(h)(1).
Lastly, we have finalized our proposal to revise § 170.550(e) “standards updates” to correct a cross-reference from “§ 171.405(b)(7) or (8)” to “§ 170.405(b)(8) or (9)” since we intended, as indicated by the preamble of the Proposed Rule (90 FR 61005), to adopt the reference to the real world testing requirements in 45 CFR part 170 instead of 45 CFR part 171. The Proposed Rule preamble and regulation text erroneously indicated the cross-reference to “§ 170.405(b)(7)”, which is a reserved section of the CFR. Instead, in § 170.550(e) we meant to reference “§ 170.405(b)(8) or (9)” as the correct cross-reference to the SVAP. These finalized changes are consistent with our proposed intent to reference the SVAP requirements for real-world testing in § 170.405(b)(8) and (9) (90 FR 61005).
3. Certification to Newer Versions of Certain Standards
We proposed to revise § 170.555, “certification to newer versions of certain standards,” by removing references to the term “Complete EHR” as it is no longer relevant in our Certification Program (90 FR 61005).
Comments.
We received no comments on this proposal.
Response.
We have finalized as proposed our proposal to remove references to the term “Complete EHR” in § 170.555(b)(2) as the term is no longer relevant in our Certification Program. As stated in the Proposed Rule (90 FR 61005), retaining the references may cause confusion for the public because the ability to maintain “Complete EHR” certification was only permitted with health IT certified to the 2014 Edition certification criteria, and the “Complete EHR” concept was discontinued for the 2015 Edition (80 FR 62719).
4. Effect of Revocation on the Certifications Issued to Health IT Module(s)
We proposed to revise the title of § 170.570 from “Effect of revocation on the certifications issued to Complete EHRs and EHR Module(s)” to “Effect of revocation on the certifications issued to Health IT Module(s)” (90 FR 61005).
Comments.
We received no comments on this proposal.
Response.
We have finalized as proposed our proposal to revise the title of § 170.570 to “Effect of revocation on the certifications issued to Health IT Module(s).” As discussed in the Proposed Rule, the term “Complete EHRs” is no longer a relevant term in our Certification Program and retaining it may cause confusion for the public. Therefore, we have finalized to revise the title of § 170.570 to further align with our removals of the outdated “Complete EHR” terminology.
IV. Trusted Exchange Framework and Common Agreement—Restoring the Office of the National Coordinator (ONC)
On April 1, 2026, the Department of Health and Human Services (HHS) published a reorganization which reverses the actions that created the management title of Assistant Secretary for Technology Policy (ASTP), removing the title and role from HHS' leadership structure, and restores the Office of the National Coordinator for Health Information Technology as a singularly titled office.[57]
The roles and responsibilities of the HHS Chief Technology Officer, Office of the HHS Chief Super Intelligence Officer (previously Chief Artificial Intelligence Officer) and Office of the HHS Chief Data Officer will no longer be part of ONC. Therefore, we have removed all references to ASTP within part 172 of 45 CFR, and, as discussed previously, the reference in part 170 of 45 CFR. We find good cause to waive the requirement under 5 U.S.C. 553(b) to publish a notice of proposed rulemaking in the
Federal Register
for these changes. We believe adherence to this requirement would be unnecessary, consistent with 5 U.S.C. § 553(b)(B) because the “Assistant Secretary for Technology Policy” no longer exists, and this finalized policy is only removing these now inaccurate and confusing references from the current regulatory text. The revisions to remove the references to ASTP within parts 170 and 172 of 45 CFR could also be considered a matter relating to agency management under 5 U.S.C. § 553(a)(2) and therefore not subject to the rulemaking requirements in 5 U.S.C. § 553.
V. Incorporation by Reference
The Office of the Federal Register has established requirements for materials (
e.g., standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5). Specifically, 1 CFR 51.5(b) requires agencies to discuss, in the preamble of a final rule, the ways that the materials they incorporate by reference are reasonably available to interested parties and how interested parties can obtain the materials, and to summarize, in the preamble of the final rule, the material they incorporate by reference.
Review of the standards proposed for incorporation by reference is available during the public comment period. To make the material we intend to incorporate by reference reasonably available, we provide a uniform resource locator (URL) for the standard. Standards are directly accessible through the URLs provided. As an alternative, a copy of the standard may be viewed for free at the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201.
Under the Paperwork Reduction Act of 1995 (PRA), codified as amended at 44 U.S.C. 3501et seq., agencies are required to provide notice in the
Federal Register
and solicit public comment on a proposed collection of information before it is submitted to the Office of Management and Budget for review and approval. In order to fairly evaluate whether an information collection should be approved by the OMB, section 3506(c)(2)(A) of the PRA requires that we solicit comment on the following issues:
1. Whether the information collection is necessary and useful to carry out the proper functions of the agency,
( printed page 67977)
including whether the information will have practical utility;
2. The accuracy of the agency's estimate of the information collection burden, including the validity of the methodology and assumptions used;
3. The quality, utility, and clarity of the information to be collected; and
4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.
Under the PRA, the time, effort, and financial resources necessary to meet the information collection requirements referenced in this section are to be considered. We explicitly sought, and considered, public comment on our assumptions as they relate to the PRA requirements summarized in this section.
A. ONC-ACBs
As stated in the Proposed Rule (90 FR 61015), we proposed to descope the “Real World Testing” Condition and Maintenance of Certification requirements in § 170.405 with deregulatory actions related to real world testing plans, results, and the use of the standards version advancement process (SVAP). Consistent with these proposals to descope the Real World Testing Condition and Maintenance of Certification requirements, we proposed to make conforming edits in § 170.523(p) to remove the ONC-ACB review and confirmation process for real world testing plans in § 170.523(p)(1), and the submission of real world testing plans in § 170.523(p)(3) which requires ONC-ACBs to collect and report certain information to ONC related to real world testing plans (
e.g., verify that the health IT developer submits an annual, publicly available real world testing plan and perform a completeness check). As noted in the Proposed Rule, our proposals would not add any new collection of information burden and would instead reduce reporting burden associated with the proposed deregulatory actions.
In the 2015 Edition proposed rule (80 FR 16894), we estimated fewer than ten annual respondents for all of the regulatory “collection of information” requirements that apply to the ONC-Approved Accreditor (ONC-AA) and ONC-ACBs, including those previously approved by OMB. In the 2015 Edition Final Rule (80 FR 62733), we concluded that the regulatory “collection of information” requirements for the ONC-AA and the ONC-ACBs were not subject to the PRA under 5 CFR 1320.3(c). We continue to estimate less than ten annual respondents for all of the proposed regulatory “collection of information” requirements for ONC-ACBs under part 170 of title 45, including those previously approved by OMB and proposed in the Proposed Rule. Accordingly, the regulatory “collection of information” requirements under the Certification Program described in this section are not subject to the PRA under 5 CFR 1320.3(c). We welcomed comments on these conclusions and the supporting rationale on which they are based.
Comments.
We did not receive comments specific to the collection of information related to real world testing plans, results, and the use of the standards version advancement process (SVAP).
Response.
We have finalized the conforming edits in § 170.523(p) to remove the ONC-ACB review and confirmation process for real world testing plans in § 170.523(p)(1) and the submission of real world testing plans in § 170.523(p)(3), which requires ONC-ACBs to collect and report certain information to ONC related to real world testing plans (
e.g., verify that the health IT developer submits an annual, publicly available real world testing plan and perform a completeness check). We continue to maintain our past determinations in that we estimate less than ten annual respondents for all the regulatory “collection of information” requirements for ONC-ACBs under part 170 of title 45, including those previously approved by OMB and in this final rule, and that the regulatory “collection of information” requirements under the Certification Program described in this section are not subject to the implementing regulations of the PRA under 5 CFR 1320.3(c). For the cost and burden reduction estimates related to the finalized deregulatory actions, we refer readers to section VII (Regulatory Impact Analysis) of this final rule.
B. Health IT Developers
The “Insights” Condition and Maintenance of Certification requirements in § 170.407 include seven measures that health IT developers under the ONC Health IT Certification Program must annually report on consistent with specified regulatory compliance timelines. In the HTI-1 Final Rule (89 FR 1399), we estimated the total crude upper bound burden to be 1,767,692 hours. In the Proposed Rule, we proposed provisions to remove and descope measures associated in § 170.407 to limit reporting requirements only to the “use of FHIR in apps through certified health IT” measure, which would reduce reporting burden for health IT developers reporting under the Certification Program. We proposed to reduce reporting burden associated with the Insights Condition and Maintenance of Certification requirements and did not propose any new requirements that would add information collection burden.
Comments.
We did not receive comments specific to the collection of information from developers related to the Insights Condition and Maintenance of Certification requirements.
Response.
Although we proposed provisions to remove and descope measures associated in § 170.407 to limit reporting requirements only to the “use of FHIR in apps through certified health IT” measure, we have decided not to finalize the removal of the “use of FHIR bulk data access” measure due to alignment with our policies to prioritize exchange using FHIR-based APIs in the Certification Program. Even though we have retained the “use of FHIR bulk data access” measure, the finalized removal of the other measures will still reduce reporting burden for health IT developers reporting under the Certification Program. For more detailed discussion of burden reduction estimates of these deregulatory actions associated with the Insights Condition and Maintenance of Certification, we refer readers to section VII (Regulatory Impact Analysis) of this final rule.
VII. Regulatory Impact Analysis
A. Statement of Need
ONC continually evaluates the voluntary Certification Program (42 U.S.C. 300jj-11(c)(5)) to improve the interoperability of health IT, while also assessing ways to reduce administrative costs and burden. This final rule is a result of our ongoing evaluation of the Certification Program and aligns with E.O. 14192 on Unleashing Prosperity Through Deregulation. E.O. 14192 was issued January 31, 2025, and sets the Administration's policy to “significantly reduce the private expenditures required to comply with Federal regulations to secure America's economic prosperity and national security and the highest possible quality of life for each citizen.” [58]
This final rule is an E.O. 14192 deregulatory action and removes and revises several regulations and policies to unleash prosperity. We believe the changes will reduce burden on developers of certified health IT, returning time and effort to them, and in turn, enhancing competition, entrepreneurship, and innovation. These deregulatory actions will reduce
( printed page 67978)
barriers to entry for novel technologies and digital health solutions, give time back to developers of certified health IT to focus on the needs and requests of their customers, and, overall, advance progress toward nationwide interoperability and universal patient access to their electronic health information.
B. Overall Impact
We have examined the impacts of this rule as required by E.O. 12866, “Regulatory Planning and Review”; E.O. 13132, “Federalism”; E.O. 13563, “Improving Regulation and Regulatory Review”; E.O. 14192, “Unleashing Prosperity Through Deregulation”; section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532); and the Regulatory Flexibility Act (RFA) (Pub. L. 96-354).
1. Regulatory Planning and Review Analysis
This rule is consistent with the policies outlined in EOs 12866, 13563, and 14192. E.O. 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, and distributive impacts). E.O. 14192, as noted above, focuses on deregulatory actions and cost savings associated with deregulatory actions. This rulemaking is significant under Section 3(f)(1) of E.O. 12866, and we have prepared an RIA.
a. Costs and Benefits
These finalized deregulatory actions provide substantial relief for developers of certified health IT and significant cost savings realized from the revision and removal of certain program requirements. For the purpose of estimating the cost savings of this rulemaking, we have determined that these policies would continue absent this regulatory action. The cost savings have been estimated using the best available data and modeled on the costs estimated and finalized in prior ONC rulemakings. As articulated in the preamble, these deregulatory actions reduce the effort of developers of certified health IT to meet ongoing program requirements and reduce barriers to entry for new program participants. The actions, importantly, return effort back to developers of certified health IT to innovate their technology and focus on the needs of their clients and end users.
Comments.
Multiple commenters argue that the RIA underestimates or overlooks significant downstream costs that may shift to providers, health information exchanges, networks, and patients when certification criteria are removed. They warn that eliminating requirements—particularly in privacy, security, and interoperability—could increase variability, reduce auditability, and force providers to independently validate or maintain capabilities previously ensured through certification. Safety net and resource—constrained organizations expressed concern that weakened Federal baselines may expose them to security risks, added vendor fees, contractual burdens, and additional operational responsibilities they are not equipped to absorb. Several commenters emphasized that these unintended consequences may widen inequities, especially for small clinics and rural providers, unless ONC fully evaluates downstream impacts and implements post-final monitoring to mitigate burden shifting. Collectively, commenters urged ONC to account for patient harms, civil rights risks, and the ongoing need for reliable, standards-based functionality within its cost-benefit analysis.
Response.
This rulemaking and impact analysis examines the continued value of maintaining program requirements weighed against the ongoing cost of that compliance. Our original analysis and public comments helped shape final decisions and economic analyses presented in this finalized impact analysis. The finalized revisions to the Certification Program carefully considered public comments, and, in particular, we have decided not to finalize proposals to remove criteria that enable secure and confidential access and use of patient health information and certain information exchange capabilities. Finalized revisions to the Certification Program largely encompass reductions in the frequency and scope of data reporting and documentation that developers are required to provide to comply with certification, specifically—narrowing requirements for the Real World Testing and Insights Conditions of Certification and removing annual reporting of source attributes for the “decision support interventions” criterion. We proposed to remove 34 criteria and have, instead, finalized the removal of 14 criteria, with some criteria, previously proposed to be removed, revised instead with a narrower scope, retaining essential functionality and standard references to ensure a necessary floor of technical capability are available to all certified health IT users. The decreased regulatory burdens and estimated cost savings presented in this impact analysis relate to the compliance costs associated with testing and certification and do not fully encompass the total costs of implementing the technology by end-users.
We considered the effects of revisions to the Certification Program on end-users as part of our calculus; however, we have limited data on how revisions to program requirements may affect the availability or functionality of certified health IT to these end-users. It is difficult to estimate the wide variation in how certified health IT is ultimately deployed and implemented by end-users, as well as evaluate how those choices are tied to Certification Program requirements or the requirements and specifications of other programs that adopt certified health IT. For example, we finalized removal of the “direct project” criterion in § 170.315(h)(1) but have retained reference to the Direct Messaging standard in § 170.202(a)(2). Survey data from 2025 show that a majority of hospitals often use the Direct Messaging standard to send and receive information with outside organizations.[59]
However, other electronic exchange methods complement or substitute for this messaging protocol, like those used for network-based exchange via State, national, and qualified health information networks, and use of those methods by hospitals now exceed use of Direct Messaging. This change occurred despite the broad certification of Health IT Modules to the criterion and ubiquitous adoption of certified health IT by hospitals.[60]
We would not anticipate removal of the criterion from the Certification Program to alone affect future use of the standard or the messaging functionality, as health information exchange is multi-faceted and can be driven by compliance with Federal requirements, the needs of the marketplace, and changing norms and behaviors among healthcare organizations.
Other finalized revisions, like the removals of the “family health history” in § 170.315(a)(12) and “care plan” in § 170.315(b)(9) reflect policy shifts from
( printed page 67979)
certified health IT's ability to record certain information alone to making those data and documents available and accessible for information exchange via USCDI. In the ONC Cures Final Rule (85 FR 25642), we finalized the removal of criteria—“smoking status” in § 170.315(a)(11), “problem list” in § 170.315(a)(6), and “medication list” in § 170.315(a)(7)—but those data were also adopted as part of USCDI, ensuring that this patient health information is made available and accessible as required by certification to Health IT Modules that cross-reference the USCDI standard. Finalized removals, like those mentioned above, are consistent with this policy shift, ensuring that data made available and accessible for exchange conform to the standards adopted as part of USCDI. Care Plan and Family Health History are adopted USCDI data elements, as of version 6 finalized in July 2026.[61]
In this final rule, and other finalized rulemakings, we acknowledge that regulatory costs incurred by developers of certified health IT may be passed on to end users of certified health IT in the form of increased fees and other costs.[62]
We anticipate that these finalized deregulatory actions will provide immediate relief and reduce ongoing burden on developers of certified health IT, which may result in reduced marginal costs or other cost savings for end users. The monitoring and evaluation of Certification Program requirements and the deployment of certified health IT in real-world settings is a cornerstone of ONC practice. ONC makes nearly all Certification Program data publicly available and searchable via its public website, permitting full transparency about the types of health IT tested and certified by the Certification Program and how that health IT meets specific program requirements. ONC also leads the collection of data via surveys and other instruments about the real-world experiences of health care providers, patients, networks, and digital health companies using or gaining access to certified health IT. This data is also made publicly available and ONC reports extensively on findings in peer-reviewed journals, via its public website, and other venues. ONC's research informed both deregulatory decision-making and the estimated cost savings presented here. ONC will continue to study and evaluate the development and use of certified health IT, as well as the real-world impact of the Certification Program on providers, networks, and patients.
Comments:
Commenters argued that the projected cost savings in the proposed rulemaking are significantly overstated because most certifications involve routine maintenance rather than new development. They note that many features are already implemented, so large claimed savings—such as millions of hours or over a billion dollars—lack evidentiary support. Overall, they believe the RIA misrepresents the true scale of savings by not accounting for the limited effort required to maintain existing capabilities.
Response:
We thank commenters for their input. We agree with the commenters' assessment that most certifications are recertifications that require annual maintenance costs rather than new development or integration costs. This impact analysis took a variety of approaches to estimate cost savings, based on the type of deregulatory action. In all cases, our approach to estimating cost savings calculated maintenance costs as a fraction of new development costs finalized in prior ONC rulemakings to estimate cost savings for the revision or removal of a program requirement. For example, in Table R-1: Panel A “Estimates of Annual Labor Hours Saved for the Removal of Certification Criteria,” average maintenance costs across all removals was 15% with a maximum maintenance cost of 27% of new development costs. As described in our methodology for removed criteria, we leveraged data and information collected from the developer community, as part of the Department's request for public comment on deregulatory actions. The public feedback and discussions with developers and other interested parties provided additional context on the ongoing costs of meeting certain Certification Program requirements, in addition to the overall value of this compliance on end-users and other entities. This data, and information informed methodologies discussed in detail in the following analyses, provide concrete evidentiary support for estimated cost savings from these deregulatory actions. It is worth noting that the majority of estimated cost savings are derived from the revision of three Certification Program requirements: safety-enhanced design, decision support interventions, and real world testing. All three requirements involve regular, typically annual effort for developers to test updated or new modules, provide data and documentation on predictive super intelligence models, and plan, measure, and report on metrics for dozens of certification criteria. These cost savings are also in aggregate across all developers of certified health IT. As of April 1, 2026, there are over 450 developers who participated in the Certification Program. Cost savings are calculated for individual criteria and reporting requirements and reflect the current number of developers and products that adopt the criteria or must comply with a reporting requirement. Therefore, more cost savings may flow to certain developers who currently have Health IT Modules certified to more criteria that will be removed from the Certification Program or who are subject to more extensive reporting requirements that this rule revises. On average, we project that a developer of certified health IT may realize $300,000 to $400,000 in undiscounted savings annually or roughly the equivalent of two data engineer FTEs. Where applicable, we describe estimation methodologies in more detail for individual policy changes.
Employee Assumptions and Hourly Wage
We have made employee assumptions about the level of expertise needed to complete the requirements that are affected by this final rule. Unless indicated otherwise, for wage calculations for Federal employees and ONC-ACBs, we have correlated the employee's expertise with the corresponding grade and step of an employee classified under the General Schedule (GS) Federal Salary Classification, relying on the associated employee hourly rates for the Washington, DC, locality pay area as published by the OPM for 2025.[63]
We have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages. Therefore, we have doubled the employee's hourly wage to account for other indirect costs. We have concluded that a 100% expenditure on benefits and overhead is an appropriate estimate based on research conducted by HHS.[64]
( printed page 67980)
Unless otherwise noted, we have consistently used the May 2024 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics (BLS) to calculate private sector employee wage estimates (
e.g.
, health IT developers, health care providers, HINs, attorneys), as we believe BLS provides the most accurate and comprehensive wage data for private sector positions.[65]
These wage estimates are a national average and we do not consider regional wage variation in our estimates. We also do not consider possible variation in the average wages for software developers in healthcare IT positions versus IT positions, more generally, which the BLS wage estimate is based upon. Just as with the General Schedule Federal Salary Classification calculations, we have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages. We requested comments on our methodology for estimating labor costs, including the effects of any regional or IT sector wage variation on our estimates, and received none.
According to the May 2024 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $69.50. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages, so the hourly wage including other indirect costs for Software Developers is $139.00.
Quantifying the Estimated Number of Health IT Developers and Products
Given the wide range of finalized deregulatory actions, we have not adopted a single, overarching approach to calculate the number of health IT developers and products affected by this rulemaking. We believe, however, that each current developer of certified health IT and participant in the Certification Program will be affected by these finalized actions, but that impact will vary, given the breadth and scope of each developer's participation in the Certification Program. For each set of finalized actions, we describe our methodology for calculating the current number of health IT developers and products affected, and, where applicable, model estimated future counts of developers and products affected. Throughout this impact analysis, we use public Certification Program data to estimate the number of developers and products certified to specific criteria or who must comply with specific requirements. The estimates reflect program data analyzed, as of April 1, 2026. In total 466 unique developers certified 601 unique products across 693 certificate listings, as of that date.[66]
Number of End Users That Might Be Impacted by ONC's Regulations
The breadth and scope of the finalized deregulatory actions create immediate and significant cost savings for developers of certified health IT. As we have finalized in prior ONC rulemakings—Cures Act Final Rule (85 FR 25642) and HTI-1 Final Rule (89 FR 1192)—we assume the regulatory costs imposed by those rules on developers may be passed on to end users of their technology in the form of increased fees and other costs. These deregulatory actions, though scoped to provide immediate relief and reduce ongoing burden on developers of certified health IT, may have downstream impacts on technology end users who may benefit from lower marginal costs to license and update their software; focused developer efforts on emerging end user needs; and other forms of innovation that may lead to unquantified benefits and savings for end users. We assume developers of certified health IT will use the cost savings to invest in innovation and emerging technology, rather than directly reduce costs on their end users, but, overall, believe the cost savings will create a net benefit to end users, if not directly as an immediate financial savings.
Costs
We do not expect costs to be associated with the deregulatory finalized actions. We do, however, estimate the costs to review the rule.
All entities affected by this finalized rule spent time to read and understand the rule, resulting in a one-time cost. The current Preamble and regulatory text together contain approximately 80,0000 words; we use this as a proxy for the length of the final rule. Consistent with HHS and Federal guidelines, we assume that industry reviewers read at the average adult reading speed of approximately 250 words per minute, so the time to read and understand the regulation would be about 5.3 hours per person (80,000/250 = 320 minutes; 320 minutes/60 minutes (1 hour) = 5.3 hours per person). We received 298 total comment submissions but believe the total number of reviewers to be higher, as official comment submissions may represent the combined submissions of multiple developers or entities represented by an industry association or other advocacy organization. We also expect that all health IT developers subject to these regulations will review this final rule. We estimate the total number of reviewers by taking the number of health IT developers and adding an estimated number of medical associations that represent health care providers and health information networks, etc. The counts of developers included in Table R-1 were calculated using publicly available Certification Program data available through the CHPL.[67]
We took the number of developers from Table R-1, which is 466 developers and estimated 150 medical associations, patient groups, third-party app developers, and other interested parties.[68]
We then determined that there would likely be 616 entities that would review the rule. As mentioned above, we used the May 2024 National Occupational Employment and Wage Estimates reported by the BLS to calculate private sector employee wage estimates.[69]
We revised our approach from the proposed review cost projection and identified the “Management Analyst” and “Lawyer” positions as comparable to positions that would review the rule. According to the May 2024 BLS occupational employment statistics, the mean hourly wage for a “Management Analyst” is $55.15 and $84.84 for a “Lawyer”. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages, so the hourly wage including other indirect costs for a Management Analyst is $110.30 and a Lawyer is $169.68. We assume that each position represents 50% of the total review hours per comment submission or an average wage of $139.99. We estimate it took five hours to review the rule by three individuals at an average wage of $139.99 (5 hours * 3 persons * $139.99) or $2,099.85 per reviewer. We multiply this by the total number of reviewers (616) to get the final estimated review cost of this rule—$1,293,508.
Comments:
We received comments that the estimated review cost of the proposed rule of $284,132 may be understated, with commenters providing their review experience as evidence for how the review cost may be revised. In particular, reviewers noted variation in the total number and
( printed page 67981)
range of reviewers who may review the rule from any one organization. One organization may employ one to many reviewers across various occupations to review and provide comment.
Response:
We thank commenters for their input. An analysis of public comments indicates a total of 298 unique comment submissions, but we believe the total reviewer count to be more—an estimated 616 reviewers. It is always difficult to project the interest and contribution from the public on any one rulemaking. We believe the total word count is a reasonable data point to use to project the estimated amount of time needed to review and respond to the rule. Given public comments and an exact understanding of the total submissions and commenters, we have revised the estimated review costs accordingly, increasing the total time spent per organization and the average wage used per submission, as described above.
Benefits
We expect the finalized deregulatory actions to result in significant benefits for health IT developers, health care providers, ONC-ACBs, ONC-ATLs, and ONC. These expected benefits are detailed below. Generally, these benefits are in the form of cost and time savings and reductions in administrative burden to comply with Certification Program requirements. The actions reduce the scope and breadth of program requirements. The Certification Program revisions provide direct cost savings (quantified, below) to developers of certified health IT and their users (
i.e.,
health care providers) through fewer program requirements and lower regulatory barriers, freeing up time for more innovation and meeting customer needs. In turn, the revised program requirements may reduce the implementation effort on ONC-ACBs, ONC-ATLs, and ONC, which works with ACBs and ATLs to implement program requirements. These savings in time and effort to ONC-ACBs, ONC-ATLs, and ONC can be used toward remaining program improvement and implementation efforts, enhancing the operation and management of the Certification Program.
1. Removal
1.1 Removal of Certification Criteria
We initially proposed to remove 34 certification criteria. However, based on feedback from multiple commenters we retained or revised about half of these criteria and finalized the removal of 14 certification criteria. One of the 14 removals is the “clinical decision support” (CDS) certification criterion (§ 170.315(a)(9)), which was finalized for removal from the Certification Program in the HTI-1 final rule (89 FR 1281) but is now being removed from the CFR through this final rule. The RIA below accounts for the removals of the other 13 criteria alone. Of these, we have removed 6 criteria as of the effective date of the final rule and the remaining 7 criteria as of January 1, 2027. We developed a common model for estimating cost savings associated with the removal of all certification criteria, described below.
Table R-1, below, provides criterion-level results of our model for the finalized criteria removals. For each certification criterion we identified the original costs to certify to the functionality from prior rules (the lower and upper bounds of “Total Hours” in Table R-1.) [70 71 72]
We then assumed that the annual cost to maintain certification was a small fraction of the initial costs. We are not aware of any published evidence that would directly inform this calculation, and, therefore, developed a novel approach using various information sources. We defined this fraction (“Final Effort Multiplier” in Table R-1) based on five factors: (1) “Test”: the criterion's certification conformance method, assuming that criteria with a test procedure had additional maintenance costs while those with a conformance method of attestation had no additional cost beyond what was initially incurred; (2) “Stakeholder feedback”: stakeholder feedback received by ONC through meetings, informal conversations, and letters from impacted parties on effort involved in certifying and updating the specific certification criterion; (3) “Complexity of standard”: whether the criterion referenced a standard and an assessment of the complexity involved in maintaining and updating conformance to that standard over time; (4) “Complexity of test procedure”: an assessment of the complexity of the test procedure or evaluative work to support attestation when it was necessary to undertake the certification process; and (5) “General complexity”: an overall assessment of the complexity of maintaining the certification criterion and underlying functionality.
The “Final Effort Multiplier” is a sum of the five factors listed in the table and described above. We then used this multiplier to determine the annual costs of meeting and maintaining the individual criteria by taking the product of the lower and upper bound “Total Hours”, described above, and this multiplier. We then estimated the lower and upper bounds of “Hours saved” by multiplying the “Annual” hours by the number of products that certify each criterion. The counts of developers and products included in Table R-1 are current as of April 1, 2026. The counts were calculated using publicly available Certification Program data available through the CHPL.[73]
Although we primarily use the count of products to estimate “Hours saved”, the count of developers is included for reference and comparison.
( printed page 67982)
For the 13 certification criteria finalized for removal in Table R-1, we estimate the total annual hours saved to range from 172,257 to 278,812, among 466 developers of certified health IT and 601 certified products (Table R-1). Using the hourly labor rate ($139), described above, we estimate the total undiscounted annual cost savings to range from $23,943,723 to $38,754,868. We received no direct comments on the proposed methodology and the accuracy and validity of the model's estimates. We did receive comments responded to elsewhere on the overall cost saving projections and responded to those by pointing to the specific analyses, which provide the specific methodologies, assumptions, and evidence used to estimate these cost savings.
( printed page 67983)
2. Revisions
2.1 Revision of Certification Criteria
We have finalized the revision of 5 certification criteria, 2 of which were proposed for removal. For each revised certification criterion, we have estimated the annual savings generated by the finalized revisions.
2.1.1 § 170.315(b)(1) Transitions of Care
We have finalized revisions to the certification criterion in § 170.315(b)(1) to reduce burden on developers of health IT by removing the “send and receive via edge protocol” C-CDA requirement and “create” C-CDA requirement in the criterion and by simplifying the remaining criterion requirements to focus solely on validating receipt of C-CDA documents. We originally proposed to revise the certification criterion with an effective date of January 1, 2027. We have finalized the criterion revisions to be effective as of January 1, 2030. We believe that these revisions remove a substantial proportion of the ongoing effort required to maintain and update the functional requirement of the certification criterion, but we acknowledge that it does not remove requirements to support the C-CDA standard or to update functionality to receive C-CDA documents. We assume that this reduces the overall ongoing cost for this certification criterion by 60%. Following the methodology described for removed criterion, we considered annual maintenance of § 170.315(b)(1) to represent high complexity equivalent to 15% of the initial development costs annually. We note from an analysis of current Certification Program data that 254 developers have certified 294 products to § 170.315(b)(1) and that the initial developer hours estimated to implement the criterion had a lower bound of 3,000 hours and an upper bound of 4,000 hours in the 2015 Edition Final Rule (80 FR 62602).[74]
We therefore estimate that the revision of this criterion will reduce effort to maintain the criterion annually by 9% annually or between 270 and 360 hours per product and 79,380 to 105,840 hours across all products. We estimate the total undiscounted annual cost savings to range from $11,033,820 to $14,711,760, beginning in 2030.
2.1.2 § 170.315(b)(2) Clinical Information Reconciliation and Incorporation
We proposed to remove the certification criterion in § 170.315(b)(2). We have not finalized as proposed, and, instead, have revised the certification criterion in § 170.315(b)(2) to reduce burden on developers of health IT by removing the standards-based requirements while maintaining the capability to reconcile and incorporate patient health information electronically. Following the methodology described for removed criterion, we consider § 170.315(b)(2) to represent high complexity equivalent to 28% of the initial development costs annually, of which 8% of this maintenance effort is attributable to the complexity of the test procedure and 10% is attributable to the complexity of the referenced standard. We note from an analysis of current Certification Program data that 217 developers have certified 255 products to § 170.315(b)(2) and that the initial developer hours estimated to implement the criterion had a lower bound of 200 hours and an upper bound of 600 hours. We therefore estimate that the revision of this certification criterion will reduce effort to maintain the criterion annually by 18% annually or between 44 and 132 hours per product and 11,220 to 33,660 hours across all products. We estimate the total undiscounted annual cost savings to range from $1,559,580 to $4,678,740.
2.1.3 § 170.315(b)(11) Decision Support Interventions
We have finalized as proposed to remove all requirements related to source attribute support for predictive DSIs and evidence-based DSIs, requirements for source attribute access and modification, and requirements to manage risks related to the development of predictive DSIs.
In the HTI-1 Final Rule, we indicated that the costs to implement § 170.315(b)(11) ranged from 2,200 hours to 4,600 hours, that updating source attribute information annually would cost an additional 0 to 800 hours annually, depending on the number of DSIs the developer supplied, and that engaging in risk management and updating information would result in an additional 0 to 285 hours annually. Without this revision, we estimate that annual maintenance costs for this criterion would represent 12% of initial development costs. We believe these changes reduce these costs by 80% and would eliminate annual costs to update information for source attributes and risk management.
In total, we estimate that the revision will reduce maintenance costs by 211 to 1,527 hours per product. We note that 251 products developed by 206 developers were certified to § 170.315(b)(11) resulting in an annual reduction of 52,961 to 383,277 labor hours. We estimate the total undiscounted annual cost savings to range from $7,361,579 to $53,275,503.
We have finalized as proposed revisions to § 170.315(c)(3) to remove expired standards references. These revisions are considered de minimis and do not create net new cost savings.
2.1.5 § 170.315(e)(1) View, Download and Transmit to a 3rd Party
We have finalized as proposed to revise § 170.315(e)(1) to remove the standards referenced in § 170.315(e)(1)(i), Web Content Accessibility Guidelines (WCAG) 2.0, and § 170.315(e)(1)(ii), Network Time Protocol (NTP) standard. We believe that the requirement to demonstrate conformance to the WCAG standard creates substantial burden for developers. We received feedback from developers that licensing a tool for WCAG assessments costs thousands of dollars annually. We acknowledge that the current referenced standards are old and do not easily work with newer versions of both the standard itself as well as testing tools to determine compliance. Thus, we expect these changes will reduce unnecessary burden associated with maintaining current conformance requirements as part of certification. In total, we estimate that the annual maintenance burden associated with the WCAG standard represented 2% of the initial development costs of the VDT criterion. We note that 212 developers have certified 248 products to § 170.315(e)(1) and that the initial developer hours estimated to implement the criterion had a lower bound of 1,300 hours and an upper bound of 2,000 hours in the 2015 Edition Final Rule which included the updated WCAG requirement. We therefore estimate that the revision of this criterion will reduce effort to maintain the criterion annually by 2% annually or between 26 and 40 hours per product and 6,448 to 9,920 hours across all products. We estimate the total undiscounted annual cost savings to range from $896,272 to $1,378,880.
( printed page 67984)
2.1.6 § 170.315(f)(6) Transmission to Public Health Agencies—Antimicrobial Use and Resistance Reporting
We have finalized as proposed to remove the standards-based requirements in § 170.315(f)(6) that were adopted in the 2015 Edition Final Rule and revise this criterion to be a functional criterion. We received stakeholder feedback that the CDA-based standards cited in this criterion are not required for users to submit antimicrobial use and resistance (AUR) data to the CDC's National Healthcare Safety Network (NHSN), creating a disconnect between the criterion and what is used in practice. We expect the removal of standards-based requirements to better align with the NHSN's goals for reporting and reduce the burden on developers to meet this requirement. Following the methodology described for removed criteria, we considered annual maintenance of § 170.315(f)(6) to represent medium complexity equivalent to 20% of the initial development costs annually. We estimate that removal of standards-based requirements will reduce annual maintenance costs to 10% of initial development costs, resulting in a 50% reduction in effort.
Currently, 29 developers and 46 products are certified to § 170.315(f)(6). The initial developer hours estimated to implement the criterion had a lower bound of 1,000 hours and an upper bound of 1,400 hours in the 2015 Edition. We therefore estimate that the revision of this criterion will reduce effort to maintain the criterion annually by 10% or between 100 to 140 hours per product and 4,600 to 6,440 hours across all products. We estimate the total undiscounted annual cost savings to range from $639,400 to $895,160.
2.1.7 170.315(g)(3) Safety-Enhanced Design
In the Proposed Rule, we proposed to remove the § 170.315(g)(3) “safety-enhanced design (SED)” certification criterion, but we have decided to revise the criterion rather than remove it from the Certification Program. The revised criterion, however, removes much of the original effort involved in meeting the criterion's objectives. The impact analysis, below, provides an updated estimate of the total time savings associated with this removal and effort retained to meet revised criterion requirements.
In the 2015 Edition Final Rule, we estimated that developers would spend 300 to 400 hours implementing the SED criterion at a cost of $63 per hour and that 266 developers would certify to SED. This resulted in a final cost estimate ranging from $5,027,400 to $6,703,200 in 2014 dollars. Since the finalization of that policy, we have received substantial input from developers of certified health IT that the cost estimates specified in that rule were an under-estimate of the initial and recurring costs associated with the SED certification criterion. In contrast to those estimates, we understand from conversations and fact-finding from developers of certified health IT that individual developers may incur recurring costs greater than $200,000 to recruit participants and conduct testing specified by the SED certification criterion. In response to input from the impacted community, we have revised our estimates of the costs of SED and potential cost savings that can be realized from the revision of the SED certification criterion in this final rule.
The SED certification criterion is required for all developers seeking certification to § 170.315(a)(1) through (5), (9) (for the period before January 1, 2025), (a)(14), (b)(2), (b)(3) or (b)(11). Developers must recruit at least ten participants, conduct testing, and submit metrics for each of the criterion for which they seek certification that is referenced within § 170.315(g)(3). Thus, we believe cost savings from the removal of SED are incremental per the number of dependent criteria certified because there are additional costs per product associated with SED testing and data reporting. Based on stakeholder input and because developers can certify multiple products each with up to ten criteria that require SED, we believe an estimated annual cost of between $8,000 and $12,000 per product per certification criterion that requires SED testing is appropriate. This estimate represents the effort to design tests, recruit participants, conduct testing, document that testing, and report results to the ONC-ACB in the required format. These costs are borne by both developers presenting a product for the first time and by those developers who must re-certify currently certified products, which may occur on an annual basis.
To estimate the total costs of SED, we estimated the number of products that will be certified to SED and the number of SED criteria each product will certify. We report those costs in Table R-2. The count of products that are certified to SED and number of SED criteria each product certifies in the table are current as of April 1, 2026. The counts were calculated using publicly available Certification Program data available through the CHPL.[75]
( printed page 67985)
In total, 366 products are certified to SED and at least one SED certification criterion. Based on Table R-2, we estimate the total undiscounted annual cost savings from removing these SED certification criterion requirements to be between $21,240,000 and $31,860,000. We estimate the total estimated hours saved to range from 153,000 to 229,000 annually across all 366 products or approximately 400 to 600 hours saved per product. In this rule, we decided to revise and retain this criterion, rather than fully remove it from the Certification Program. Specifically, we have finalized the revision of § 170.315(g)(3) to an attestation-based certification requirement. The total cost savings estimated above reflect the effort on developers to recruit participants, plan and conduct testing, and submit results. Those requirements are now removed as of the effective date of this rule. However, there remains some effort on developers to complete and submit their required attestation. We estimate this new attestation-based requirement would range from 40 to 80 hours of effort per product, modeling the total cost to implement similar to other attestation-based criteria. Multiplying the hourly effort by the total number of products (366) and wage rate of $139, we estimate that this level of effort will equal between $2,034,960 to $4,069,920 annually. Subtracting this from the total cost savings estimated for the removal of the criterion's other requirements, we estimate net annual undiscounted cost savings for the revision of the SED criterion to range from $19,205,040 to $27,790,080. We estimate the total estimated net hours saved to range from 138,000 to 200,000 annually across all 366 products or approximately 360 to 520 hours saved per product.
In Tables R-2 and R-3, we estimate the combined total annual hours saved from the finalized criteria revisions to range from 292,775 to 739,321 among 323 developers of certified health IT and 399 certified products. Using the labor rate of $139, described above, we estimate the total undiscounted annual cost savings to range from $40,695,691 to $102,765,568. We received no direct comments on the proposed methodology and the accuracy and validity of the model's estimates. We did receive comments responded to elsewhere on the overall cost saving projections and responded to those by
( printed page 67986)
pointing to the specific analyses that provide the methodologies and assumptions used to estimate these cost savings.
2.2 Revisions to Standards and Implementation Specifications for Health Information Technology
We have finalized no revisions to standards and implementation specifications that create new costs or cost savings.
2.3 Revisions to the ONC Health IT Certification Program Administration
Unless noted differently, finalized revisions to Certification Program administration conform to revisions finalized elsewhere related to Certification Program requirements. We do not assess net new cost savings or costs to program administration for these conforming revisions. We did not receive comments on whether these conforming revisions create net new cost savings or costs.
2.3.1 Principles of Proper Conduct for ONC-ACBs
Under the principles of proper conduct for ONC-ACBs, we have finalized as proposed to revise the “certified product listing” principle in § 170.523(f)(1)(viii) to remove requirements for ONC-ACBs to include the test data version used and whether any test data was altered for the certification criterion or criteria to which the Health IT Module has been certified. This finalized revision is meant to reduce the overall effort for ONC-ACBs for this principle, as our analysis shows that these data elements for the “certified product listing” are of low value. We determined that the cost savings to ONC-ACBs are de minimis and did not receive comments on this analysis. In addition, we have finalized as proposed conforming revisions to the principles of proper conduct for ONC-ACBs. These conforming revisions do not create net new cost savings to developers of certified health IT, ONC, or ONC-ACBs. These conform to revisions made elsewhere to Certification Program requirements, and cost savings, if applicable, are assessed elsewhere in this impact analysis.
2.3.2 Principles of Proper Conduct for ONC-ATLs
We have finalized conforming revisions to the principles of proper conduct for ONC-ATLs. These conforming revisions do not create net new cost savings to developers of certified health IT, ONC, or ONC-ATLs. These conform to revisions made elsewhere to Certification Program requirements, and cost savings, if applicable, are assessed elsewhere in this impact analysis.
2.3.3 Health IT Module Certification
We have finalized conforming revisions to Health IT Module certification. These conforming revisions do not create net new cost savings to developers of certified health IT, ONC, or ONC-ACBs. These conform to revisions made elsewhere to Certification Program requirements, and cost savings, if applicable, are assessed elsewhere in this impact analysis.
( printed page 67987)
2.3.4 Certification to Newer Versions of Certain Standards
We have finalized conforming revisions to certification to newer versions of certain standards. These conforming revisions do not create net new cost savings to developers of certified health IT, ONC, or ONC-ACBs. These conform to revisions made elsewhere to Certification Program requirements, and cost savings, if applicable, are assessed elsewhere in this impact analysis.
2.3.5 Effect of Revocation on the Certifications Issued to Health IT Module(s)
We have finalized conforming revisions that do not create net new cost savings.
2.4 Revisions to Conditions and Maintenance of Certification Requirements for Health IT Developers (Subpart D)
2.4.1 Assurances Condition of Certification
We have finalized updates to the Code of Federal Regulations (CFR) that do not create net new cost savings.
2.4.2 Application Programming Interfaces Condition of Certification
We have finalized updates to the CFR that do not create net new cost savings.
2.4.3 Real World Testing Condition of Certification
We have finalized as proposed revisions to the Real World Testing Condition of Certification that de-scope reporting requirements and codify what was previously guidance for the Certification Program and an exercise of enforcement discretion for the Condition of Certification.[76]
As finalized in the Cures Act Final Rule (85 FR 25642), real world testing would be applicable for specific criteria—at the time of finalization, 23 criteria in all. This deregulatory action revises the Real World Testing Condition of Certification to apply reporting to only the API criteria adopted by the Certification Program. This revision creates cost savings to developers of certified health IT, as developers would no longer be required to plan, collect, and report on real world testing results for the full originally finalized set of criteria. We explain below the rationale and methodology that informed the cost savings for these finalized revisions to real world testing.
The finalized revisions to real world testing would take effect beginning in 2027. Cost savings to developers for ongoing compliance are, therefore, estimated beginning in 2027. Any costs for 2024 and 2025 are considered sunk. Beginning in the 2026 reporting year, as permitted in the real world testing enforcement discretion, only developers of certified APIs would be required to report for real world testing, specifically developers who certify Health IT Modules to the standardized API for patient and population services certification criterion, § 170.315(g)(10).[77]
Cost savings calculations beginning in 2027 reflect the decreased burden on developers of certified health IT to comply with the condition of certification minus requirements that remain in place for developers who certify Health IT Modules to the applicable API-based criteria.
As of the end of 2024, using publicly available Certification Program data, we calculated that 336 developers had submitted real world testing plans for 2025 collection and 2026 reporting.[78]
That is 93 fewer developers required to report for real world testing than estimated in the Cures Act Final Rule—a decrease of about 19 developers per year.[79]
Calculating developer exits during this time period, after the Cures Act Final Rule took effect and prior to this finalized rule's effective date, is important to assess the estimated number of developers expected to comply with the remaining real world testing requirements, as finalized.
Beginning in 2026, we calculated an expected count of developers who we estimated would be required to report for real world testing in 2026 and beyond. This count assumes attrition from the original count of developers required to report for real world testing as finalized in the Cures Act Final Rule, as we described above for years prior to 2026. But given the changed program dynamics, in that real world testing would be required only for developers of certified APIs, the attrition rate beyond 2026 is harder to estimate. Given that current requirements are applicable for over 20 criteria adopted in the Certification Program and our attrition rate is based on participant exits from the Certification Program (for developers who certify Health IT Modules to any of these criteria), we assume that attrition rate is likely more profound than exits for developers of certified APIs alone. We therefore estimate a new rate of developers who would be required to report for real world testing in total (n=320), beginning in 2026.
In our RIA for the HTI-4 Final Rule (included in the FY2026 IPPS/LTCH PPS final rule (90 FR 36536) as an ancillary provision), we estimated that beginning in 2027, approximately 189 developers would certify an electronic prior authorization API. The 189 count is a proxy measure, representing our estimation of the number of developers that would certify Health IT Modules to the § 170.315(g)(10) certification criterion in 2027.
Given that the revised Real World Testing Condition of Certification would only be associated with developers of certified APIs, we estimate beginning in 2026 that approximately 189 developers would be subject to the revised real world testing requirements. We used this count (189) to determine the net number of developers who would have been required to report for real world testing under the original requirements (inclusive of those who would have reported § 170.315(g)(10) testing results under the original requirements).
At the end of 2024, of the 336 developers required to report for real world testing, 198 developers of Health IT Modules certified to the § 170.315(g)(10) certification criterion or 59% of all developers. Using this rate, we estimate that beginning in 2026, approximately 320 developers would be subject to real world testing requirements, as finalized by the Cures Act Final Rule.[80]
In 2026, however, only 189 developers would be subject to revised real world testing requirements—our estimate of the number of developers who would be subject to revised real world testing requirements (API only). This considers some attrition but at a different rate than used for years prior to 2026, as explained above.
Total savings beginning in 2027 are considered consistent and do not decrease due to future unknown attrition; however, we consider these cost savings to be realized by developers when the revised requirements take effect. If they were to exit the Certification Program in a year beyond 2027, these are still cost savings to be realized today from requirements they do not need to meet in all future years.
Beginning in 2027, cost savings are calculated by totaling the cost to all
( printed page 67988)
developers who certify Health IT Modules to real world testing applicable certification criteria to meet current real world testing requirements as finalized in the Cures Act Final Rule and revised in subsequent rulemakings (the HTI-1 Final Rule and the HTI-4 Final Rule) and subtracting the remaining cost for developers of certified APIs to comply with revised real world testing requirements. We estimate that, per developer, the cost of collecting and reporting real world testing data on § 170.315(g)(10) would be on average $4,400 annually. We estimate this by calculating the average cost per criterion to meet real world testing requirements as finalized by the Cures Act Final Rule ($109,557/23 = $4,763) and decrease that by the proposed eliminated effort to submit annual testing plans (estimated to be 8% of total annual testing effort).[81]
This is congruent with our methodology finalized in the HTI-4 Final Rule about the average per criterion cost to plan, collect, and report for real world testing.[82]
The total cost of the remaining requirement to test for § 170.315(g)(10) would be subtracted from the total original program cost, as finalized by the Cures Act Final Rule, to estimate this deregulatory action's annual cost savings.
Beginning in 2027, we also assume that developers of certified APIs would need to meet requirements for § 170.315(g)(10), as well as for § 170.315(g)(31), (g)(32), and (g)(33), as finalized in the HTI-4 Final Rule.[83]
Real world testing requirements for the certification criteria adopted in § 170.315(g)(31), (g)(32), and (g)(33) were finalized in the HTI-4 Final Rule and would be a net new cost minus revisions to real world testing for developers not to submit annual testing plans. Furthermore, we also updated real world testing requirements in the HTI-4 Final Rule to include the new § 170.315(b)(4) certification criterion, which created net new costs to developers for real world testing. This deregulatory action now removes the § 170.315(b)(4) real world testing requirement and so we also assess the cost savings from that revision beginning in 2027 as well.
For costs savings, beginning in 2027 and in perpetuity, we estimate that together, (original real world testing costs + § 170.315(b)(4) costs) minus ((g)(10) + (g)(31) + (g)(32) + (g)(33) revised costs) equals the estimated annual undiscounted cost savings of $33.6 million.
2.4.4 Attestations
We have finalized updates to the CFR that do not create net new cost savings.
2.4.5 Insights Condition of Certification
We have not finalized as proposed revisions to the Insights Condition of Certification. In the HTI-1 Final Rule (89 FR 1192), we finalized requirements for developers to report on the Insights Condition of Certification, a set of uniform measures collected and reported by developers of certified health IT about the performance of their certified technology.[84]
Applicable developers would be required to begin data collection January 1, 2026, for “Year 1” measures, with results reported in July 2027 and with “Year 2” measures set to begin collection January 1, 2027. Effort to plan and develop capabilities for these finalized measures was estimated to begin after the effective date of the HTI-1 Final Rule in January 2024. Effort to plan and develop the measurement capabilities for measures required to be collected in 2026 (“Year 1”) would be completed by January 1, 2026, and effort to plan and develop the measurement capabilities for measures required to be collected for the first time in 2027 (“Year 2”) would be completed by January 1, 2027, etc. We estimated developers would face annual data collection and reporting costs beginning in 2026 and in perpetuity. As we finalized in the HTI-1 Final Rule, the large majority of costs to developers of certified health IT would be costs to plan and develop for initial data collection of the finalized measures (effort largely expended from 2024-2026 in our original analysis).
ONC exercised enforcement discretion in April 2025 with respect to Insights requirements except for a single measure—“Use of FHIR”—a “Year 1” measure.[85]
We have finalized proposed revisions to the Insights Condition of Certification with one change to the proposal. In this final rule, in addition to retaining requirements for applicable developers of certified health IT to collect data on and report the “Use of FHIR” measure, we did not finalize our proposal to remove the “Use of Bulk FHIR” measure. Therefore, developers will continue to be required to collect data on and report on the “Use of Bulk FHIR” measure. We explain below the rationale and methodology that informed the cost savings for these proposed revisions to Insights.
To calculate cost savings associated with the proposed revisions to the Insights Condition of Certification, we subtracted the estimated amount for developers to report for the remaining two Insights measures (“Use of FHIR” and “Use of Bulk FHIR”) from the estimated cost for developers to meet the Insights Condition of Certification, as finalized in the HTI-1 Final Rule. In Table 35 of the HTI-1 Final Rule, we estimated that the upper bound cost for all developers to report on the “Use of FHIR” and “Use of Bulk FHIR” measures over a ten-year period was $72.8 million.[86]
The total upper bound cost to report on all measures for all developers over a ten-year period was $218.7 million. Therefore, we estimate the measures to be 34% of all estimated Insights costs.
In Table R-4 we show the undiscounted revised cost savings for the finalized changes to the Insights Condition of Certification. We estimated, on average, that the HTI-1 Final Rule costs for Insights would be $158.5 million. We estimated that the cost for developers to begin implementing Insights in 2024 (toward effort to collect and report on measures in 2026 and 2027) would on average, total $46.4 million. This included initial planning and development costs for all measures with more assumed effort toward completing work to prepare for “Year 1” measures set to begin collection January 1, 2026. We consider these costs as sunk. The Insights enforcement discretion, however, reduced effort for ongoing planning and development work for 2025 and after. We include the reduced effort to meet these requirements in years 2027 and after to be a net cost savings to developers, as Table R-4 shows. The total undiscounted cost savings, beginning in 2025, are $73.3 million (Table R-4).
( printed page 67989)
b. Accounting Statement and Table
This finalized rule is an E.O. 14192 deregulatory action. The finalized policies remove or reduce requirements on developers of certified health IT. No finalized policies create net new requirements or additional burden to comply with existing requirements. However, we do estimate some costs for reviewers who review this rule. We estimate those costs to be $1,293,508 in total for 616 reviewers. As articulated in the preamble, these finalized deregulatory actions reduce the effort of developers of certified health IT to meet ongoing program requirements and reduce barriers to entry for new program participants, generating benefits to developers of certified health IT in the form of time back to them to innovate their technology and focus on the needs of their clients and end users. We do not, however, quantify these benefits, and instead rely on our calculation of cost savings to developers of certified health IT to quantify in dollars the time and effort developers would have expended had these requirements remained in effect in perpetuity. We estimate that these proposals do generate significant cost savings for developers of certified health IT.
To calculate the cost savings associated with this finalized rulemaking, we replicate the analysis of prior finalized rulemakings and align those with current data, adopting, where necessary, novel methodologies and models to assess the current costs to developers of certified health IT of the finalized revisions to the Certification Program. As shown in Table R-5, we present the undiscounted cost savings over ten years and in Table R-6 we present the discounted cost savings associated with these finalized policies for ten years. In Table R-6, we adopt a 3% and 7% discount rate consistent with Circular A-4 (2003).[87]
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 as shown in Table R-7.[88]
( printed page 67990)
C. Regulatory Flexibility Act
The Regulatory Flexibility Act (RFA) requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities. The Small Business Administration (SBA) establishes the size of small businesses for Federal Government programs based on average annual receipts or the average employment of a firm.[89]
The entities that are likely to be directly affected by the requirements in this finalized rule are health IT developers.
While health IT developers that pursue certification of their health IT under the Certification Program represent a small segment of the overall information technology industry, we believe that many health IT developers impacted by the requirements in this final rule most likely fall under the North American Industry Classification System (NAICS) code 513210 “Software Publishers.”
OMB advised that the Federal statistical establishment data published for reference years beginning on or after January 1, 2022, should be published using the 2022 NAICS United States codes.[90]
The SBA size standard associated with this NAICS code is set at $47 million annual receipts or less. There is enough data generally available to establish that over 90% of entities that are categorized under the NAICS code 513210 are under the SBA size standard. We also note that with the exception of aggregate business information available through the U.S. Census Bureau and the SBA related to NAICS code 513210, it appears that many health IT developers that pursue certification of their health IT under the Certification Program are privately held or owned and do not regularly, if at all, make their specific annual receipts publicly available. As a result, it is difficult to locate empirical data related to many of these health IT developers to correlate to the SBA size standard. However, HHS program data provide approximate counts of health care
( printed page 67991)
providers who use specific certified Health IT Modules.[91 92 93]
In combination with public market research about the average annual cost of a hospital or physician licensing an EHR, we can estimate projected annual receipts for each developer of certified health IT and determine if they are under the $47 million threshold.[94 95]
Using a licensing cost of $15,000 per bed for hospital customers and $8,000 per provider for ambulatory practice sites, we multiplied these amounts by the number of hospital beds and ambulatory providers who report use of each developer's certified health IT. We then increased the number of ambulatory providers who report each developer by 50% to reflect that the Medicare Promoting Interoperability is not fully representative of the full outpatient provider population and that data alone may undercount developers' true customer base. Additional customer data available via public API endpoint lists were used to adjust estimates of each developer's customer counts. We also considered per customer licensing fees as only a 75% share of each developer's projected annual receipts. Therefore, based on this methodology, any developer with projected licensing revenue less than $35.25 million was considered a small business. Among 466 developers, we estimate that approximately 64 (or 14%) are not considered small businesses. We, therefore, estimate that approximately 86% of developers of certified health IT are small businesses, close to the overall industry estimate of “Software Publishers” (90%).
With the exception of rule review costs, this finalized rulemaking is deregulatory and does not create new requirements on developers of certified health IT, including small businesses. We believe the finalized deregulatory actions will create net cost savings for developers and would create a significant positive economic impact on small entities who participate directly in the Certification Program as a developer of certified health IT or as an entity who interoperates with certified health IT. Finalized revisions reduce burdens on small developers to meet ongoing reporting and documentation requirements, as well as support for redundant standards and functionalities—which can weigh heavier on smaller developers with smaller developer and engineering teams. As the finalized revisions largely reflect reduced effort to meet annual reporting, other recurring program requirements, and ongoing maintenance of Health IT Modules, we assume the projected cost savings in this final rule may be shared equally across developers, both small and large. This means that up to 86% of cost savings (or $93 million annualized net quantified cost savings) could be realized by small developers of certified health IT.
In the proposed rule, we requested comment on whether there are small entities that currently pursue certification of health IT under the Certification Program (and how many); what products they certify; whether there are any negative or unintended costs for small entities from the proposals included in this rule; and whether small entities will significantly benefit from the proposals included in this rule. We received no comments in response.
E.O. 13132 establishes certain requirements that an agency must meet when it promulgates a finalized rule that imposes substantial direct requirement costs on State and local governments, preempts State law, or otherwise has Federalism implications. Nothing in this finalized rule imposes substantial direct compliance costs on State and local governments, preempts State law, or otherwise has Federalism implications. We are not aware of any State laws or regulations that are contradicted or impeded by any of the policies in this finalized rule. We welcomed comments on this assessment and received no response.
E. Unfunded Mandates Reform Act of 1995
Section 202 of the Unfunded Mandates Reform Act of 1995 requires that agencies assess anticipated costs and benefits before issuing any rule that imposes unfunded mandates on State, local, and Tribal governments or the private sector requiring spending in any one year of $100 million in 1995 dollars, updated annually for inflation. The current inflation-adjusted statutory threshold is approximately $187 million in 2025. This finalized rule is deregulatory, and, therefore, the estimated potential cost effects of this finalized rule do not reach the statutory threshold. This finalized rule does not impose unfunded mandates on State, local, and Tribal governments, or the private sector.
Comments.
Multiple commenters expressed concern that our proposals impose unfunded mandates on State, local, and tribal governments and the private sector. Commenters were concerned that de-regulation shifts the burden of assessing health IT functionality and standards adoption to end users. Two commenters expressed their concerns specifically with the downstream effects of our public health-related proposals (§ 170.315(f)(4), § 170.315(f)(5), § 170.315(f)(6) and § 170.315(f)(7)) which sought to remove the standards-based requirements for electronic case reporting and antimicrobial use and resistance reporting and remove the requirements to support cancer registry reporting and creation of health care survey information.
Response.
We thank commenters for their input. The changes in § 170.315(f)(4), § 170.315(f)(5), and § 170.315(f)(7) have not been finalized as proposed—we are maintaining requirements to support cancer registry reporting and creation of health care survey information and keeping electronic case reporting as a standards-based criterion. We have finalized as proposed the removal of standards-based requirements in § 170.315(f)(6), which have not kept pace with reporting requirements and therefore we believe this change will not impose downstream costs on end-users to submit AUR data NHSN. Given these final decisions, we do not anticipate any significant downstream costs or burdens to be shifted on public health entities. In response to broader concerns that our proposals impose unfunded mandates or that de-regulation shifts the burden of assessing health IT and standards adoption to end users, we have chosen to finalize 14 of 34 criteria proposed for removal from the CFR, with many of those removals consisting of criteria with low adoption rates overall. Furthermore, the reduced scope of conditions and maintenance of certification reflect the prioritization of reporting and documentation requirements to focus developer efforts on API criteria and associated requirements, as these are less mature and evolving requirements which necessitate focused developer efforts to monitor and evaluate these functionalities in real world settings. These are necessary program improvements that will enhance the overall performance of the Certification Program and allow it to evolve to meet emerging needs that will benefit the nation as a whole.
For the reasons set forth in the preamble, 45 CFR subtitle A, subchapter D, is amended as follows:
PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY
1. The authority citation for part 170 continues to read as follows:
Certain material is incorporated by reference into this subpart with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. All approved incorporation by reference (IBR) material is available for inspection at the U.S. Department of Health and Human Services (HHS) and at the National Archives and Records Administration (NARA). Contact HHS at: U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201; call ahead to arrange for inspection at (202) 690-7151. For information on the availability of this material at NARA, visit
www.archives.gov/federal-register/cfr/ibr-locations
or email
fr.inspection@nara.gov. The material may be obtained from the following sources:
(a) ASTM International, 100 Barr Harbor Drive, P.O. Box C700, West Conshohocken, PA 19428-2959; phone (610) 832-9585; website
www.astm.org/.
(1) ASTM E2147-18 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems, approved May 1, 2018; IBR approved for § 170.210(h).
(2) [Reserved]
(b) Centers for Disease Control and Prevention, 2500 Century Parkway, Mailstop E-78, Atlanta, GA 30333; phone: (800) 232-4636); website:
www.cdc.gov/cdc-info/index.html.
(1) ELR 2.5.1 Clarification Document for EHR Technology Certification, July 16, 2012, IBR approved for § 170.205(g).
(2) PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, Release 2.0, April 21, 2015; IBR approved for § 170.205(d).
(3) Erratum to the CDC PHIN 2.0 Implementation Guide, August 2015; Erratum to the CDC PHIN 2.0 Messaging Guide, April 2015 Release for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings; IBR approved for § 170.205(d).
(4) HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5, October 1, 2014; IBR approved for § 170.205(e).
(5) HL7 Version 2.5.1 Implementation Guide for Immunization Messaging (Release 1.5)—Addendum, July 2015; IBR approved for § 170.205(e).
(6) HL7® Standard Code Set CVX—Vaccines Administered, dated June 15, 2022; IBR approved for § 170.207(e).
(7) National Drug Code Directory (NDC)—Vaccine NDC Linker, dated July 19, 2022; IBR approved for § 170.207(e).
(8) CDC Race and Ethnicity Code Set version 1.2 (July 08, 2021); IBR approved for § 170.207(f).
(c) Centers for Medicare & Medicaid Services, Office of Clinical Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland 21244; phone: (410) 786-3000; website:
www.cms.gov.
(1) CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting Implementation Guide for 2020; published December 3, 2019; IBR approved for § 170.205(h).
(2) CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs Implementation Guide for 2020; published April 30, 2020; IBR approved for § 170.205(k).
(3) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy; April 2, 2015, IBR approved for § 170.207(r).
(4) Medicare Provider and Supplier Taxonomy Crosswalk, 2021; IBR approved for § 170.207(r).
(d) Council of State and Territorial Epidemiologists, 2635 Century Parkway NE, Suite 700, Atlanta, GA 30345; phone: (770) 458-3811; website:
www.cste.org/.
(1) Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID:
( printed page 67993)
2.16.840.1.114222.4.11.7508, Release March 29, 2022; IBR approved for § 170.205(t).
(2) [Reserved]
(e) Health Level Seven, 455 E Eisenhower Parkway, Suite 300 #025, Ann Arbor, MI 48108; phone: (734) 677-7777; website:
www.hl7.org/.
(1) Health Level Seven Messaging Standard Version 2.5.1 (HL7 2.5.1), An Application Protocol for Electronic Data Exchange in Healthcare Environments, February 21, 2007; IBR approved for § 170.205(d).
(2) HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) HL7 Version 2.5.1: ORU-R01, HL7 Informative Document, February 2010; IBR approved for § 170.205(g).
(3) HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for Trial Use July 2012; IBR approved for § 170.205(a).
(4) HL7 Clinical Document Architecture, Release 2.0, Normative Edition, May 2005; IBR approved for § 170.205(i).
(5) HL7 v2.5.1 IG: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 Errata and Clarifications, September 29, 2011; IBR approved for § 170.205(g).
(6) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Volume 1—Introductory Material, Release 2.1, August 2015; IBR approved for § 170.205(a).
(7) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Volume 2—Templates and Supporting Material, Release 2.1, August 2015; IBR approved for § 170.205(a).
(8) HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 1—Introductory Material, June 2015; IBR approved for § 170.205(h).
(9) HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 2—Templates and Supporting Material, June 2015; IBR approved for § 170.205(h).
(12) HL7 Version 3 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1, Part 1: CDA R2 and Privacy Metadata Reusable Content Profile, May 16, 2014; IBR approved for § 170.205(o).
(13) HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 1—Introductory Material, December 2014; IBR approved for § 170.205(s).
(14) HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 2—Templates and Supporting Material, December 2014; IBR approved for § 170.205(s).
(15) HL7 Version 3 (V3) Standard, Value Sets for AdministrativeGender and NullFlavor, published August 1, 2013; IBR approved for § 170.207(n) and (o).
(16) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2-US Realm, October 2019; IBR approved for § 170.205(a).
(17) HL7 FHIR® Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1), August 22, 2019; IBR approved for § 170.215(a).
(18) HL7 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, Version 4.0.1: R4, October 30, 2019, including Technical Correction #1, November 1, 2019; IBR approved for § 170.215(a).
(19) HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 (US Realm) Standard for Trial Use, Specification Version: 4.1.1, June 2023 (including appendices A and B); IBR approved for § 170.205(a).
(20) HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm, Version 2.1.0—STU 2 US (HL7 FHIR eCR IG), August 31, 2022; IBR approved for § 170.205(t).
(21) HL7 CDA® R2 Implementation Guide: Public Health Case Report—the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1—US Realm (HL7 CDA eICR IG), July 2022, volumes 1 and 2; IBR approved for § 170.205(t).
(22) HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG), July 2022, volumes 1 through 4; IBR approved for § 170.205(t).
(23) HL7 FHIR US Core Implementation Guide Version 6.1.0—STU 6, June 19, 2023; IBR approved for § 170.215(b).
(24) HL7 FHIR® SMART App Launch [Implementation Guide], 2.0.0—Standard for Trial Use, November 26, 2021; IBR approved for § 170.215(c).
(25) HL7 FHIR® Da Vinci—Coverage Requirements Discovery IG [Implementation Guide], Version 2.2.1-STU 2.2, Generated March 27, 2026; IBR approved for § 170.215(j).
(26) HL7 FHIR® Da Vinci—Documentation Templates and Rules Implementation Guide, Version 2.2.0-STU 2.2, Generated March 27, 2026; IBR approved for § 170.215(j).
(27) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.2.1-STU 2.2, Generated March 27, 2026; IBR approved for § 170.215(j).
(28) HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) [Implementation Guide], Version 2.2.0-STU 2.2, Generated March 27, 2026; IBR approved for § 170.215(k).
(29) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.1.0—STU 2.1, June 18, 2025; IBR approved for § 170.215(k).
(30) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.1.0-STU 2.1, Generated February 26, 2025; IBR approved for § 170.215(m).
(31) HL7 FHIR® Da Vinci PDex [Payer Data Exchange] Plan Net Implementation Guide, Version 1.2.0-STU 1.2, Generated February 25, 2025; IBR approved for § 170.215(n).
(32) HL7 FHIR® Subscriptions R5 Backport Implementation Guide, Version 1.1.0—Standard for Trial Use, draft as of January 11, 2023; IBR approved for § 170.215(h).
(33) HL7 FHIR® CDS Hooks Implementation Guide, Version 2.0.1—STU 2 Release 2, March 12, 2025; IBR approved for § 170.215(f).
(34) HL7 FHIR® Da Vinci Clinical Data Exchange (CDex) IG [Implementation Guide], Version 2.1.0-STU 2.1, Generated February 11, 2025; IBR approved for § 170.215(k).
(g) Integrating the Healthcare Enterprise (IHE), 820 Jorie Boulevard, Oak Brook, IL; phone: (630) 481-1004; website:
www.ihe.net/.
(1) IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-2b), Transactions Part B—Sections 3.29—3.43, Revision 7.0, August 10, 2010; IBR approved for § 170.205(p).
(2) [Reserved]
( printed page 67994)
(h) Internet Engineering Task Force (IETF), IETF Administration LLC, 1000 N West Street, Suite 1200, Wilmington, DE 19801, phone (302) 319-3421; email:
support@ietf.org;
website:
www.ietf.org/.
(1) Request for Comment (RFC) 5646, Tags for Identifying Languages, September 2009, copyright 2009; IBR approved for § 170.207(g).
(2) [Reserved]
(i) International Telecommunication Union (ITU), Place des Nations, 1211 Geneva 20 Switzerland; phone: (41) 22 730 511; website:
www.itu.int/en/pages/default.aspx.
(1) ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation—General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001; IBR approved for § 170.207(q).
(2) ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation—Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010; IBR approved for § 170.207(q).
(j) National Council for Prescription Drug Programs (NCPDP), Incorporated, 9240 E Raintree Drive, Scottsdale, AZ 85260-7518; phone (480) 477-1000; fax: (480) 767-1042; website:
www.ncpdp.org.
(1) NCPDP SCRIPT Standard, Implementation Guide, Version 2017071, ANSI-approved July 28, 2017; IBR approved for § 170.205(b).
(2) NCPDP SCRIPT Standard, Implementation Guide, Version 2023011, ANSI-approved January 17, 2023; IBR approved for § 170.205(b).
(3) NCPDP Real-Time Prescription Benefit Standard, Implementation Guide, Version 13, ANSI-approved May 19, 2022; IBR approved for § 170.205(c).
(4) NCPDP Formulary and Benefit Standard, Implementation Guide, Version 60, ANSI-approved April 12, 2023; IBR approved for § 170.205(u).
(k) National Institute of Standards and Technology (NIST), Information Technology Laboratory, National Institute of Standards and Technology, 100 Bureau Drive, Gaithersburg, MD 20899-8930; website
csrc.nist.gov/projects/cryptographic-module-validation-program.
(1) Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Draft, January 27, 2010; IBR approved for § 170.210.
(2) Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Draft, May 30, 2012; IBR approved for § 170.210.
(3) FIPS PUB 180-4, Secure Hash Standard (August 2015); IBR approved for § 170.210(c).
(l) Office of the National Coordinator for Health Information Technology (ONC), 330 C Street SW, Washington, DC 20201; phone: (202) 690-7151; website:
healthit.gov.
(m) Regenstrief Institute, Inc., LOINC® c/o Regenstrief Center for Biomedical Informatics, Inc., 410 West 10th Street, Suite 2000, Indianapolis, IN 46202-3012; phone: (317) 274-9000; website:
loinc.org/
and
ucum.org/ucum.
(1) Logical Observation Identifiers Names and Codes (LOINC®) Database Version 2.72, February 2022; IBR approved for § 170.207(c).
(2) The Unified Code for Units of Measure, Version 2.1, November 21, 2017; IBR approved for § 170.207(m).
(n) The Direct Project, c/o the Office of the National Coordinator for Health Information Technology (ONC), 330 C Street SW, Washington, DC 20201; email:
ONC.Request@hhs.gov;
website:
healthit.hhs.gov.
(1) Applicability Statement for Secure Health Transport, Version 1.2, August 2015; IBR approved for § 170.202(a).
(2) [Reserved]
(o) U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894; phone (301) 594-5983; website:
www.nlm.nih.gov/.
(1) SNOMED CT® [SNOMED Clinical Terms] U.S. Edition, March 2022 Release; IBR approved for § 170.207(a).
(2) RxNorm, December 4, 2023, Full Update Release; IBR approved for § 170.207(d).
(p) Public Health Data Standards Consortium, 111 South Calvert Street, Suite 2700, Baltimore, MD 21202; phone: (801) 532-2299; website:
www.nahdo.org/sopt.
(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011); IBR approved for § 170.207(s).
(2) Users Guide for Source of Payment Typology, Version 9.2, December 2020; IBR approved for § 170.207(s).
(i)
Send and receive via edge protocol.
The requirements in this paragraph (b)(1)(i) expire on January 1, 2030.
* * * * *
(ii)
Validate and display—
(A)
Validate C-CDA conformance—system performance.
Demonstrate the ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with the standards specified in § 170.205(a)(4) and (6) for the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates. This includes the ability to:
(
1) Parse each of the document types.
(
2) Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in § 170.205(a)(4) and (6).
(
3) Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standards adopted in § 170.205(a)(4) and (6).
(
5) Record errors encountered and allow a user through at least one of the following ways to:
(
i) Be notified of the errors produced.
(
ii) Review the errors produced.
(B)
Display.
Display in human readable format the data included in transition of care/referral summaries received and formatted according to the standards specified in § 170.205(a)(4) and (6). The requirements in this paragraph (b)(1)(ii)(B) expire on January 1, 2030.
(C)
Display section views.
Allow for the individual display of each section (and the accompanying document header information) that is included in a transition of care/referral summary received and formatted in accordance with the standards adopted in § 170.205(a)(4) and (6) in a manner that enables the user to do the following. The requirements in this paragraph (b)(1)(ii)(C) expire on January 1, 2030.
(
1) Directly display only the data within a particular section;
(
2) Set a preference for the display order of specific sections; and
(
3) Set the initial quantity of sections to be displayed.
(iii)
Create.
Enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in § 170.205(a)(4) and (6) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum the following. The requirements in this paragraph (b)(1)(iii) expire on January 1, 2030.
* * * * *
(2)
Clinical information reconciliation and incorporation.
Technology must demonstrate the following, in at least one applicable workflow, which could include upon receipt of a transition of care/referral summary:
(i) Properly match information received from another source with the correct patient for whom the information is intended to be reconciled.
(ii) Create a single reconciled list of each of the following: Medications, Allergies and Intolerances, and Problems.
(iii) Enable a user to review and validate the accuracy of a final set of data.
(iv) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standards:
(A) Medications. At a minimum, the version of the standard specified in § 170.213;
(B) Allergies and intolerance. At a minimum, the version of the standard specified in § 170.213; and
(C) Problems. At a minimum, the version of the standard specified in § 170.213.
* * * * *
(11) * * *
(iii)
Decision support intervention selection.
Enable a limited set of identified users to select (
i.e., activate) electronic decision support interventions that are:
* * * * *
(B) Predictive Decision Support Interventions and use any data in paragraph (b)(11)(iii)(A) of this section as well as Clinical Notes and Assessment and Plan of Treatment expressed in the standards for this data in § 170.213.
(c) * * *
(3)
Clinical quality measures—report.
Enable a user to electronically create a data file for transmission of clinical quality measurement data in accordance with the applicable implementation specifications specified by the CMS implementation guides for Quality Reporting Document Architecture (QRDA), Category I, for inpatient measures in § 170.205(h)(3) and CMS implementation guide for QRDA, Category III for ambulatory measures in § 170.205(k)(3).
* * * * *
(e) * * *
(1)
View, download, and transmit to 3rd party
—(i)
General.
Patients (and their authorized representatives) must be able to use internet-based technology to view, download, and transmit their health information to a 3rd party in the manner specified in this paragraph (e)(1)(i).
(A)
View.
Patients (and their authorized representatives) must be able to use health IT to view, at a minimum, the following data:
(
1) [Reserved]
(
2) The data classes expressed in the standards in § 170.213 (which should be in their English (
i.e., non-coded) representation if they associate with a vocabulary/code set), and in accordance with § 170.205(a)(4) and (6), and paragraphs (e)(1)(i)(A)(
3)(
i) through (
iii) of this section.
(
3) The following data classes:
(
i)
Assessment and plan of treatment.
In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).
(
ii)
Goals.
In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).
(
iii)
Health concerns.
In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).
(
iv)
Unique device identifier(s) for a patient's implantable device(s).
In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standards specified in § 170.205(a)(4).
(
4) For ambulatory settings only provider's name and office contact information.
(
5) For inpatient settings only: admission and discharge dates and locations; discharge instructions; and reason(s) for hospitalization.
(B)
Download.
(
1) Patients (and their authorized representatives) must be able to use technology to download an ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) in the following formats:
(
i) Human readable format; and
(
ii) The format specified in accordance with the standard specified in § 170.205(a)(4) and (6) and following the CCD document template.
(
2) When downloaded according to the standard specified in § 170.205(a)(4) and (6) following the CCD document template, the ambulatory summary or inpatient summary must include, at a minimum, the following data (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set):
(
i)
Ambulatory setting only.
All of the data specified in paragraphs (e)(1)(i)(A)(
1), (
2), (
4), and (
5) of this section.
(
ii)
Inpatient setting only.
All of the data specified in paragraphs (e)(1)(i)(A)(
1) and (
3) through (5) of this section.
(
3) Patients (and their authorized representatives) must be able to download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the certification criterion specified in paragraph (b)(1) of this section).
( printed page 67996)
(C)
Transmit to third party.
Patients (and their authorized representatives) must be able to:
(
1) Transmit the ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) created in paragraph (e)(1)(i)(B)(
2) of this section in accordance with both of the following ways:
(
i) Email transmission to any email address; and
(
ii) An encrypted method of electronic transmission.
(
2) Transmit transition of care/referral summaries (as a result of a transition of care/referral as referenced by paragraph (e)(1)(i)(B)(
3) of this section) of this section selected by the patient (or their authorized representative) in both of the ways referenced in paragraphs (e)(1)(i)(C)(
1)(
i) and (
ii) of this section).
(D)
Timeframe selection.
With respect to the data available to view, download, and transmit as referenced paragraphs (e)(1)(i)(A) through (C) of this section, patients (and their authorized representatives) must be able to:
(
1) Select data associated with a specific date (to be viewed, downloaded, or transmitted); and
(
2) Select data within an identified date range (to be viewed, downloaded, or transmitted).
(ii)
Activity history log.
(A) When any of the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section are used, the following information must be recorded and made accessible to the patient (or his/her authorized representative):
(
1) The action(s) (
i.e., view, download, transmission) that occurred;
(
2) The date and time each action occurred;
(
3) The user who took the action; and
(
4) Where applicable, the addressee to whom an ambulatory summary or inpatient summary was transmitted.
(B) [Reserved]
(iii)
Request for restrictions.
Patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. Conformance with this paragraph is required by January 1, 2026.
* * * * *
(f) * * *
(6)
Transmission to public health agencies—antimicrobial use and resistance reporting.
Create antimicrobial use and resistance reporting information for electronic transmission.
* * * * *
(g) * * *
(3)
Safety-enhanced design.
(i) User-centered design processes must be applied to each capability technology includes that is specified in the following certification criteria: paragraphs (a)(1) through (5), and (14) and (b)(2), (3), and (11) of this section.
(ii) One of the following must be submitted on the user-centered design process used:
(A) Name and/or publication citation for an industry or Federal Government standard.
(B) Name the process(es), provide an outline of the process(es), a short description of the process(es), and an explanation of the reason(s) why use of any of the existing user-centered design standards was impractical.
(2) A health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10).
* * * * *
14. Amend § 170.404 by:
a. Revising the introductory text and paragraph (b)(2) introductory text;
b. Removing paragraphs (b)(3) and (4); and
c. Revising the definition for “Certified API technology” in paragraph (c).
The following Condition and Maintenance of Certification requirements apply to developers of Health IT Modules certified to any of the certification criteria adopted in § 170.315(g)(10) and (31) through (33) unless otherwise specified in this section.
* * * * *
(b) * * *
(2)
Service base URL publication.
For all Health IT Modules certified to § 170.315(g)(10), a Certified API Developer must publish, at no charge, the service base URLs and related organization details that can be used by patients to access their electronic health information. This includes all customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. These service base URLs and organization details must conform to the following:
* * * * *
(c) * * *
Certified API Technology
means the capabilities of Health IT Modules that are certified to any of the API-focused certification criteria adopted in § 170.315(g)(10), (31), (32), and (33).
15. Amend § 170.405 by:
a. Revising paragraph (a);
b. Removing and reserving paragraph (b)(1);
c. Revising and republishing paragraph (b)(2); and
(a)
Condition of Certification requirement.
A health IT developer with one or more Health IT Module(s) certified to any one or more of the Certification Criteria for Health IT in § 170.315(b), (c), (e), (f), (g)(10) and (31) through (33), and (j) must, on an annual basis, successfully test the real world use of those Health IT Module(s) for interoperability (as defined in 42 U.S.C. 300jj(9) and § 170.102) in the type of setting in which such Health IT Module(s) would be/is marketed.
(b) * * *
(2)
Real world testing results reporting.
(i) If in the course of conducting real world testing the developer discovers one or more non-conformities with the full scope of any certification criterion under the Program, the developer must report that non-conformity to the ONC-ACB within 30 days.
(ii) For real world testing activities conducted during the immediately preceding calendar year, a health IT developer must submit to its ONC-ACB an annual real world testing results report that:
(A) Addresses each of its certified Health IT Modules that were certified to, including through Inherited Certified Status, the § 170.315(g) certification criteria referenced in paragraph (a) of this section in the year preceding the real world testing calendar year reporting period;
(B) Includes the newer versions of certified Health IT Modules that include
( printed page 67997)
the § 170.315(g) certification criteria referenced in paragraph (a) of this section that were updated using Inherited Certified Status during the real world testing reporting period; and
(C) Is submitted by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the results report on the CHPL no later than March 15 of each calendar year, beginning in 2023.
(iii) The real world testing results must report the following for each of the § 170.315(g) certification criteria identified in paragraph (a) of this section that are included in the Health IT Module's scope of certification:
(A) The method(s) that was used to demonstrate real world interoperability;
(B) The care setting(s) that was tested for real world interoperability;
(C) The voluntary updates to standards and implementation specifications that the National Coordinator has approved through the Standards Version Advancement Process;
(D) A list of the key milestones met during real world testing;
(E) The outcomes of real world testing including a description of any challenges encountered during real world testing; and
(F) At least one measurement/metric associated with the real world testing.
(iv) For each Health IT Module certified to any certification criterion specified in paragraph (a) of this section, other than the § 170.315(g) certification criteria (see paragraph (b)(2)(iii) of this section for requirements), identify the voluntary updates to standards and implementation specifications that the National Coordinator has approved through the Standards Version Advancement Process.
* * * * *
(8)
Standards Version Advancement Process
—
voluntary updates of certified health IT to newer versions of standards and implementation specifications.
A health IT developer of certified health IT subject to paragraph (a) of this section is permitted to update Health IT Module(s) certified to any one or more of the certification criteria referenced in paragraph (a) of this section to a newer version of any adopted standard or implementation specification included in the criterion, provided that newer version is approved by the National Coordinator for use in certifications issued under the ONC Health IT Certification Program. A developer that pursues such updates to its certified Health IT Module(s) must:
* * * * *
16. Amend § 170.406 by revising paragraphs (a)(4) and (5) to read as follows:
(4) Section 170.404 if the health IT developer has a Health IT Module(s) certified to any of the certification criteria adopted in § 170.315(g); and such health IT developer must also ensure that health IT allows for health information to be exchanged, accessed, and used, in the manner described in § 170.404; and
(5) Section 170.405 if a health IT developer has a Health IT Module(s) certified to any one or more ONC Certification Criteria for Health IT set forth in § 170.405(a).
* * * * *
17. Amend § 170.407 by:
a. Revising the section heading and paragraphs (a)(1)(ii)(B) and (C) and (a)(3); and
(B) Have health IT certified to the certification criteria specified in each measure in paragraph (a)(3) of this section; or
(C) Have any users using the certified health IT specified in each measure in paragraph (a)(3) of this section for each reporting period.
* * * * *
(3)
Measures
—(i)
Use of FHIR in apps through certified health IT.
If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses on the number of requests made to distinct certified health IT deployments that returned FHIR resources, number of distinct certified health IT deployments active at any time, the number of distinct deployments active at any time that returned FHIR resources in response to API calls from apps connected to certified health IT, including stratifying responses by the following:
(A) User type;
(B) FHIR resource; and
(C) US Core Implementation Guide version.
(ii)
Use of FHIR bulk data access through certified health IT.
If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses for the total number of FHIR bulk data access requests completed through the certified health IT, and the number of distinct deployments of the certified health IT active at any time overall, and by whether at least one bulk data download request was completed.
(b)
Maintenance of Certification.
(1) A health IT developer must provide responses to the Insights Condition of Certification specified in paragraph (a) of this section annually for any Health IT Module that has or has had an active certification as of January 1 for each reporting period under the ONC Health IT Certification Program:
(i) A health IT developer must provide responses for measures specified in:
(A) Paragraphs (a)(3)(i)(A) and (B) of this section beginning July 2027.
(B) Paragraph (a)(3)(i)(C) of this section beginning July 2028.
(C) Paragraph (a)(3)(ii) of this section beginning July 2029.
(ii) [Reserved]
(2) [Reserved]
18. Amend § 170.523 by:
a. Revising introductory text of paragraph (f);
b. Revising paragraphs (f)(1)(viii) and (xix);
c. Removing and reserving paragraphs (f)(1)(xxi) and (p)(1); and
(f)
Certified product listing.
Provide the Office of the National Coordinator for Health Information Technology (ONC), no less frequently than weekly, a current list of Health IT Modules that have been certified that includes, at a minimum:
(1) * * *
(viii) The certification criterion or criteria to which the Health IT Module has been certified, including the test procedure and test tool version used;
* * * * *
(xix)
Where applicable,
and for each applicable certification criterion, all of the information required to be submitted by Health IT Module developers to meet the safety-enhanced design certification criterion.
* * * * *
(p) * * *
(3) Submit real world testing results by March 15 of each calendar year to ONC for public availability.
* * * * *
19. Amend § 170.550 by:
a. Revising paragraph (e);
b. Revising and republishing paragraphs (g) and (h)(3); and
( printed page 67998)
(e)
Standards updates.
ONC-ACBs must provide an option for certification of Health IT Modules consistent with § 170.405(b)(8) or (9) to any one or more of the criteria referenced in § 170.405(a) based on newer versions of standards included in the criteria which have been approved by the National Coordinator for use in certification.
* * * * *
(g)
Health IT Module dependent criteria.
When certifying a Health IT Module to the ONC Certification Criteria for Health IT, an ONC-ACB must certify the Health IT Module in accordance with the certification criteria at:
(1) Section 170.315(g)(3) if the Health IT Module is presented for certification to one or more listed certification criteria in § 170.315(g)(3);
(2) Section 170.315(g)(4);
(3) Section 170.315(g)(5);
(4) Section 170.315(b)(10) when a health IT developer presents a Health IT Module for certification that can store electronic health information at the time of certification by the product, of which the Health IT Module is a part; and
(5) Section 170.315(b)(4) if the Health IT Module is presented for certification to the certification criteria in § 170.315(b)(3).
(h) * * *
(3)
Applicability.
(i) Section 170.315(a)(1) through (3), (5), (14), and (15) are also certified to the certification criteria specified in § 170.315(d)(1) through (7), (12), and (13).
(ii) Section 170.315(a)(4) and, on and after January 1, 2028, (b)(11), are also certified to the certification criteria specified in § 170.315(d)(1) through (3), (5) through (7), and (12), and, for the time period up to and including December 31, 2027, (d)(13).
(iii) Section 170.315(b)(1) through (3) are also certified to the certification criteria specified in § 170.315(d)(1) through (3), (5) through (8), (12), and (13);
(iv) Section 170.315(c) is also certified to the certification criteria specified in § 170.315(d)(1); (d)(2)(i)(A), (B); (d)(2)(ii) through (v); (d)(3), (5), (12), and (13);
(v) Section 170.315(e)(1) is also certified to the certification criteria specified in § 170.315(d)(1) through (3), (5), (7), (9), (12), and (13);
(vi) [Reserved]
(vii) Section 170.315(f) is also certified to the certification criteria specified in § 170.315(d)(1) through (3), (7), (12), and (13); and
(viii) Section 170.315(g)(10) is also certified to the certification criteria specified in § 170.315(d)(1), (9), (12), and (13); and (d)(2)(i)(A) and (B); (d)(2)(ii) through (v); or (d)(10).
(ix) [Reserved]
* * * * *
20. Amend § 170.555 by revising and republishing paragraph (b)(2) to read as follows:
Certification to newer versions of certain standards.
* * * * *
(b) * * *
(2) A certified Health IT Module may be upgraded to comply with newer versions of standards identified as minimum standards in subpart B of this part without adversely affecting its certification status, unless the Secretary prohibits the use of a newer version for certification.
21. Amend § 170.570 by revising the section heading to read as follows:
24. Amend § 172.102 in the definition of “Applicant QHIN” by removing the text “Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology” and adding in its place “Office of the National Coordinator for Health Information Technology”.
Robert F. Kennedy, Jr.,
Secretary, Department of Health and Human Services.
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).
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 www.healthit.gov/topic/hhs-health-it-alignment-program.
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)
www.federalregister.gov/d/2026-07203/p-2659.
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.
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.
doi.org/10.2196/42507.
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.
doi.org/10.1055/s-0043-1769924.
43.
For information on CDC's National Healthcare Safety Network (NHSN) antimicrobial use and resistance reporting options see
www.cdc.gov/nhsn/psc/aur/index.html.
52.
Jones, J, et al. Real world performance of the 21st Century Cures Act population-level application programming interface. Journal of the American Medical Informatics Association. Vol. 31, Issue 5, 1144-1150. May 2024. Available at
doi.org/10.1093/jamia/ocae040.
62.
Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS). 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (85 FR 25642).
64.
See U.S. Department of Health and Human Services, Office of the Assistant Secretary for Planning and Evaluation (ASPE), Guidelines for Regulatory Impact Analysis, at 28-30 (2016), available at
aspe.hhs.gov/reports/guidelines-regulatory-impact-analysis.
89.
The SBA references that annual receipts mean “total income” (or in the case of a sole proprietorship, “gross income”) plus “cost of goods sold” as these terms are defined and reported on Internal Revenue Service tax return forms.
42 U.S.C. 300jj-11(c)(5)
45 CFR part 170
www.healthIT.gov
www.hl7.org/implement/standards/product_brief.cfm?product_id=144
www.archives.gov/federal-register/cfr/ibr-locations
www.astm.org/
www.cdc.gov/cdc-info/index.html
www.cms.gov
www.cste.org/
www.ihe.net/
www.ietf.org/
www.itu.int/en/pages/default.aspx
www.ncpdp.org
csrc.nist.gov/projects/cryptographic-module-validation-program
healthit.gov
isp.healthit.gov/sites/default/files/2020-10/USCDI-Version-1-July-2020-Errata-Final_0.pdf
loinc.org/
ucum.org/ucum
healthit.hhs.gov
www.nlm.nih.gov/
www.nahdo.org/sopt
www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation
modelcontextprotocol.io/introduction
www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0955-AA10
hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core
www.crisphealth.org/consent-tool/
www.hca.wa.gov/about-hca/programs-and-initiatives/clinical-collaboration-and-initiatives/electronic-consent-management
www.shiftinterop.org/our-work/the-shift-sandbox/
doi.org/10.2196/42507
chpl.healthit.gov
www.hhs.gov/press-room/hhs-crackdown-health-data-blocking.html
uscdiplus.healthit.gov/uscdiplus?id=uscdi_record&table=x_g_sshh_uscdi_domain&sys_id=71df78228745b95098e5edb90cbb3527&view=sp
stacks.cdc.gov/view/cdc/118849#:~:text=July%2027%2C%202021,2021%20Export%20RIS%20Citation%20Information
good-neighbor.smarthealthit.org/case-studies/re-imagining-public-health-monitoring-with-bulk-fhir
www.trially.ai/blog/bulk-fhir-in-the-real-world-trially-ceo-kyle-mcallister-shares-what-works
www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/2025/general-schedule/
aspe.hhs.gov/reports/guidelines-regulatory-impact-analysis
data.bls.gov/oes/#/industry/000000
www.ama-assn.org/house-delegates/hod-organization/member-organizations-ama-house-delegates
trumpwhitehouse.archives.gov/sites/whitehouse.gov/files/omb/circulars/A4/a-4.pdf
www.whitehouse.gov/wp-content/uploads/2025/02/M-25-20-Guidance-Implementing-Section-3-of-Executive-Order-14192-Titled-Unleashing-Prosperity-Through-Deregulation.pdf
www.sba.gov/article/2022/feb/01/guidance-using-naics-2022-procurement
www.practiceehr.com/blog/how-much-does-ehr-software-cost-pricing
softwarefinder.com/resources/cost-to-implement-a-top-emr