Tap any paragraph to write a margin note. Your notes collect in the Desk below the text and file under cases with @. The side-by-side margin rail opens on a larger screen.

§
Marginalia
Code · REGISTER · 2025-12-29 · Assistant Secretary for Technology Policy (ASTP)/Office of the National Coordinator for Health Information Technology (ONC) (collectively, ASTP/ONC), Department of Health and Human Services (HHS) · Rules and Regulations

Rules and Regulations. Proposed rule

64,500 words·~293 min read·/register/2025/12/29/2025-23896·

A research copy — for the controlling text, always check the official state or federal source. Not legal advice.

BILLING CODE 9111-97-P 90 245 Monday, December 29, 2025 Proposed Rules Part III Department of Health and Human Services Office of the Secretary 45 CFR Parts 170 and 171 Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions To Unleash Prosperity; Proposed Rule DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Parts 170 and 171 RIN 0955-AA09 Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions To Unleash Prosperity AGENCY: Assistant Secretary for Technology Policy (ASTP)/Office of the National Coordinator for Health Information Technology
(ONC)(collectively, ASTP/ONC), Department of Health and Human Services (HHS). ACTION: Proposed rule. SUMMARY: This proposed rule focuses on deregulatory actions identified in HHS regulations regarding Health information technology standards, implementation specifications, and certification criteria and certification programs for health information technology, and information blocking. This proposed rule seeks to reduce burden, offer flexibility to both developers and providers, and support innovation through the removal and revisions of certain certification criteria and regulatory provisions. This proposed rule also seeks to address reported misuse and abuse of information blocking definitions and exceptions. DATES: To be assured consideration, written or electronic comments must be received at one of the addresses provided below, no later than 5 p.m. Eastern Time on February 27, 2026. ADDRESSES: You may submit comments, identified by RIN 0955-AA09, by any of the following methods (please do not submit duplicate comments). Because of staff and resource limitations, we cannot accept comments by facsimile
(FAX)transmission. • *Federal eRulemaking Portal:* Follow the instructions for submitting comments. Attachments should be in Microsoft Word, Microsoft Excel, or Adobe PDF; however, we prefer Microsoft Word. *http://www.regulations.gov.* • *Regular, Express, or Overnight Mail:* Department of Health and Human Services, Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology, Attention: Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions to Unleash Prosperity Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one original and two copies. • *Hand Delivery or Courier:* Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology, Attention: Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions to Unleash Prosperity Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one original and two copies. (Because access to the interior of the Mary E. Switzer Building is not readily available to persons without federal government identification, commenters are encouraged to leave their comments in the mail drop slots located in the main lobby of the building.) *Inspection of Public Comments:* All comments received before the close of the comment period will be available for public inspection, including any personally identifiable or confidential business information that is included in a comment. Please do not include anything in your comment submission that you do not wish to share with the general public. Such information includes, but is not limited to, the following: a person's social security number; date of birth; driver's license number; state identification number or foreign country equivalent; passport number; financial account number; credit or debit card number; any personal health information; or any business information that could be considered proprietary. We will post all comments that are received before the close of the comment period at *http://www.regulations.gov.* *Docket:* For access to the docket to read background documents, comments received, or the plain-language summary of the proposed rule of not more than 100 words in length required by the Providing Accountability Through Transparency Act of 2023, go to *http://www.regulations.gov* or the Department of Health and Human Services, Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201 (call ahead to the contact listed below to arrange for inspection). FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy, Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology, 202-690-7151. SUPPLEMENTARY INFORMATION: Table of Contents I. Executive Summary A. Purpose of Deregulatory Action 1. Administration Deregulatory Priorities 2. ASTP/ONC Implementation a. Certification Program and Information Blocking b. America's FHIR-Forward Future B. Summary of Major Provisions 1. Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology (Part 170) a. Certification Criteria for Health Information Technology b. Standards and Implementation Specifications for Health Information Technology c. Terms and Definitions d. Conditions and Maintenance of Certification Requirements for Health IT Developers e. ONC Health IT Certification Program Administrative Requirements 2. Information Blocking (Part 171) C. Severability D. Costs and Benefits II. Background A. Statutory Basis 1. Standards, Implementation Specifications, and Certification Criteria 2. Health IT Certification Program B. Regulatory History III. Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology (Part 170) A. Certification Criteria for Health Information Technology 1. Clinical Certification Criteria a. Patient Demographics b. Clinical Decision Support c. Family Health History d. Implantable Device List 2. Care Coordination Certification Criteria a. Transitions of Care b. Clinical Information Reconciliation and Incorporation c. Security Tags—Summary of Care d. Care Plan e. Decision Support Interventions 3. Clinical Quality Measures Certification Criteria a. Clinical Quality Measures—Report b. Clinical Quality Measures—Filter 4. Privacy and Security Certification Criteria 5. Patient Engagement Certification Criteria a. View, Download, and Transmit to a 3rd Party b. Patient Health Information Capture 6. Public Health Certification Criteria a. Transmission to Cancer Registries b. Transmission to Public Health Agencies—Electronic Case Reporting c. Transmission to Public Health Agencies—Antimicrobial Use and Resistance Reporting d. Transmission to Public Health Agencies—Health Care Surveys 7. Design and Performance Certification Criteria a. Automated Numerator Recording b. Automated Measure Calculation c. Safety Enhanced Design d. Quality Management System e. Accessibility-centered Design f. Consolidated CDA Creation Performance g. Application Access—Patient Selection h. Application Access—All Data Request 8. Transport Methods and Other Protocols Certification Criteria a. Direct Project b. Direct Project, Edge Protocol, and XDR/XDM B. Standards and Implementation Specifications for Health Information Technology 1. United States Core Data for Interoperability Version 3.1 Update (USCDI v3.1) a. National Technology Transfer and Advancement Act b. “Reasonably Available” to Interested Parties 2. Standards and Implementation Specifications C. Terms and Definitions 1. Base EHR 2. Common Clinical Data Set 3. Global Unique Device Identification Database and Production Identifier D. Conditions and Maintenance of Certification Requirements for Health IT Developers 1. Assurances 2. Application Programming Interfaces 3. Real World Testing 4. Attestations 5. Insights E. ONC Health IT Certification Program Administrative Requirements 1. Principles of Proper Conduct for ONC-ACBs 2. Health IT Module Certification 3. Certification to Newer Versions of Certain Standards 4. Effect of Revocation on the Certifications Issued to Health IT Module(s) IV. Information Blocking (Part 171) A. “Access” and “Use” Definitions B. Infeasibility Exception Revisions 1. Third Party Seeking Modification Use Condition 2. Manner Exception Exhausted Condition C. Manner Exception D. Removal of Subpart D Exception and Other Provisions Specific to TEFCA V. Incorporation by Reference VI. Response to Comments VII. Collection of Information Requirements A. ONC-ACBs B. Health IT Developers VIII. Regulatory Impact Analysis A. Statement of Need B. Overall Impact 1. Regulatory Planning and Review Analysis a. Costs and Benefits b. Accounting Statement and Table C. Regulatory Flexibility Act D. Executive Order 13132—Federalism E. Unfunded Mandates Reform Act of 1995 I. Executive Summary A. Purpose of Deregulatory Action 1. Administration Deregulatory Priorities On January 31, 2025, President Trump issued Executive Order (E.O.) 14192 “Unleashing Prosperity Through Deregulation,” 1 which states that it is the policy of the Administration to significantly reduce the private expenditures required to comply with Federal regulations to secure America's economic prosperity and national security and the highest possible quality of life for each citizen. ASTP/ONC is issuing this proposed rule in an effort to streamline and reduce administrative burdens on health care providers, health information technology
(IT)developers, and the health IT community overall. This proposed rule would also improve patient and health care provider access to electronic health information
(EHI)and promote health IT and health care market competition with proposals to revise the information blocking regulations. 1 *https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation.* In order to implement the President's deregulatory initiatives, and to better promote the health and well-being of the American people, HHS intends to dramatically expand its deregulatory efforts. An important component of Making America Healthy Again is making sure that health care providers and caretakers can focus on preventing and treating chronic diseases. By proposing to remove duplicative and unnecessary requirements of the ONC Health IT Certification Program (Certification Program), we will support providers in caring for their patients. Developers of certified health IT will have more time to support providers' specific technological needs. Providers may also have more health IT choices to meet their needs through increased competition in the certified health IT market that may come from reduced barriers to entry for the certification of health IT. Further, proposed revisions to the information blocking regulations would support health care providers in using innovative third-party software with their EHRs as well as their access, exchange, and use of patients' EHI. 2. ASTP/ONC Implementation a. Certification Program and Information Blocking Since the inception of the Certification Program, ASTP/ONC has aimed to implement and administer the Certification Program in the least burdensome manner that supports an administration's policy goals. Throughout the years, we have worked to improve the Certification Program with a focus on ways to reduce burden, offer flexibility to both developers and providers, and support innovation. Over the past 15 years, we have established a set of regulatory requirements that have provided a foundation for our voluntary Certification Program. As we look to the future, there is an opportunity to review the existing requirements and make updates as needed. Through both formal notice and comment rulemaking and informal engagements, we have received suggestions on how to update the Certification Program to meet current market needs. This proposed rule proposes deregulatory actions that: take into consideration these suggestions; account for the current and future state of technology; reduce burden by eliminating redundant requirements; and promote innovation for health IT developers, providers, and other interested parties. We have also evaluated the information blocking regulations and propose the removal of one exception, removal and revisions of conditions of other exceptions, and revisions of definitions to better promote EHI access, exchange, and use. Together, these efforts directly align with Administration goals as outlined in E.O. 14192 (Unleashing Prosperity through Deregulation) 2 and E.O. 14267 (Reducing Anti-Competitive Regulatory Barriers). 3 2 *https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation.* 3 *https://www.federalregister.gov/documents/2025/04/15/2025-06463/reducing-anti-competitive-regulatory-barriers.* b. America's FHIR-Forward Future Background In 2012, Health Level Seven (HL7®) first published for industry feedback what is now called the Fast Healthcare Interoperability Resources (FHIR®) 4 standard. FHIR aimed to build on prior HL7 work, including well-established messaging and document standards ( *e.g.,* HL7 Version 2, Clinical Document Architecture (CDA)). It also sought to improve developer usability and ease of implementation by leveraging internet‐scale tooling common to modern web services. Rooted in a RESTful architectural style, 5 FHIR organizes data into granular “resources” ( *e.g.,* Patient, Observation, MedicationRequest) that can be created, read, updated, or deleted through standard HTTP operations and expressed in formats such as JSON. FHIR was designed to help reduce implementer variation, allow for widespread web security conventions to be layered in ( *e.g.,* OAuth 2.0, OpenID Connect, and TLS), and facilitate more incremental adoption through modularity. 4 *https://hl7.org/fhir/summary.html.* 5 *https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf.* Since FHIR Draft Standard for Trial Use
(DSTU)1 was officially published in September 2014, HL7 has iteratively advanced FHIR through a comprehensive ballot process that combines industry pilots, Connectathons, and formal community review. In 2015, ONC released the “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record
(EHR)Definition, and ONC Health IT Certification Program Modifications” Final Rule (2015 Edition Final Rule) (80 FR 62602), which among other requirements, adopted non-standards-based, functional application programming interface
(API)certification criteria (45 CFR 170.315(g)(7), (8), and (9)). The adoption of these certification criteria combined with the data elements specified in the “common clinical data set”
(CCDS)helped catalyze the industry to focus on developing a consistent implementation guide for FHIR-based API deployment in the United States (US). This industry-led effort resulted in the “Argonaut Data Query Implementation Guide” based on FHIR DSTU 2, which became commonly deployed in production and used as the basis to build early versions of patient access applications with the potential for nationwide scale. 6 6 *See https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019;* and also *https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/.* In parallel to this wave of standards development and industry implementation, API-focused interoperability policy also advanced. The 21st Century Cures Act (Cures Act) (Pub. L. 114-255) was signed into law at the end of 2016 and ASTP/ONC subsequently engaged in rulemaking to implement its provisions. This included, among other new policies, the adoption of a FHIR-based API certification criterion (45 CFR 170.315(g)(10)) and the establishment of an API Condition of Certification, which focused on the publication of APIs that would allow EHI “to be accessed, exchanged, and used without special effort . . . including providing access to all data elements of a patient's electronic health record . . .”. On May 1, 2020, ONC published the “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” Final Rule (Cures Act Final Rule) (85 FR 25642), which adopted a suite of FHIR-based requirements in the Certification Program. This final rule required support for HL7's FHIR US Core Implementation Guide
(IG)(based on FHIR Release 4 and consistent with United States Core Data for Interoperability (USCDI) v1 data elements), FHIR Bulk Data Access Implementation Guide, and HL7® SMART Application Launch Framework Implementation Guide. We stated that developers of certified health IT certified to the applicable criteria were required to upgrade certified health IT to these FHIR API standards and provide them to their customers by no later than May 2, 2022, in the Cures Act Final Rule (85 FR 25948). We then extended the compliance date to December 31, 2022, in the “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency Interim” Final Rule (85 FR 70072). In the years since the Cures Act Final Rule, ASTP/ONC and industry established an iterative, annual cycle whereby a new USCDI version is released that then helps inform further data element constraints for a new version of the FHIR-based US Core IG. This predictable, consistent, and collaborative approach has been transformative for standards development and FHIR-based policy making. It has also positioned the US as a world leader in FHIR adoption and use. Other federal agencies, such as the Centers for Medicare & Medicaid Services (CMS), Centers for Disease Control and Prevention (CDC), Food and Drug Administration (FDA), Health Resources and Services Administration (HRSA), and National Institutes of Health
(NIH)have also pursued FHIR-oriented regulatory policy and program implementations based on this foundation. Resetting the Certification Program for a FHIR-Enabled Future America's interoperability arc in health care has bent decisively toward FHIR-based APIs. An open, interoperable health data ecosystem invites entrepreneurship, drives innovation, and cements American leadership and competitiveness in the expanding digital health marketplace. As discussed in this deregulatory proposed rule, we propose to aggressively reduce and remove long-standing functionality-oriented and non-FHIR-based certification criteria from the Certification Program. While this approach would directly and rapidly reduce compliance burdens for health IT developers that participate in the Certification Program, more broadly, it enables ASTP/ONC to reset the Certification Program's regulatory scope and establish a new foundation on which to build FHIR-based API requirements in the future. This would allow more creative artificial intelligence (AI)-enabled interoperability solutions that combine FHIR with newer standards to emerge, such as Model Context Protocol
(MCP)which “standardizes how applications provide context to Large Language Models (LLMs)”, 7 and further embrace the Cures Act's reference to “. . . successor technology or standards . . .” in the API Condition of Certification. 8 7 *https://modelcontextprotocol.io/introduction.* 8 42 U.S.C. 300jj-11(c)(5)(D)(iv). While FHIR provides the potential for better, faster, and more consistent ways to address emerging market needs and policy imperatives, more work is needed for certain use cases. We intend to continue to fully engage industry and our federal partners, such as CMS, to rapidly advance FHIR specifications for regulatory readiness. We also intend to sharpen the Certification Program's future focus to prioritize FHIR-based APIs that:
(1)enhance automation and API performance;
(2)move beyond read-only interactions; and
(3)expand the scope of data available to support clinical efficiency, patient-centered care, and timely reporting ( *e.g.,* public health, quality, government programs) use cases. The transition to a FHIR-based API ecosystem is a strategic imperative and an investment in the US's interoperability future. To execute this vision, it will require a collective commitment from policymakers, software developers, clinicians, payers, and patients alike. Together, we can build interoperable solutions that meet today's challenges and anticipate tomorrow's opportunities. In this proposed rule, our proposals remove or revise certain certification criteria that are consistent with our drive toward and our support for the FHIR standard, as discussed above. The push toward universal adoption of FHIR is not just important for secure, streamlined data access, it is a critical step toward modernizing our health care system with the ultimate goal of Making America Healthy Again. B. Summary of Major Provisions 1. Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology (Part 170) a. Certification Criteria for Health Information Technology We have identified certification criteria for proposed removal or revision. The removal or revision of the identified certification criteria would reduce burden and costs for health IT developers and clinicians, for reasons including but not limited to, eliminating the need to design and meet specific certification functionalities; prepare, test, and certify health IT in certain instances; and maintain conformance to certification requirements. We do not anticipate that the proposed removals or revisions would alter behavior across product implementations by health IT developers for the capabilities that have thus far been included as part of certification criteria in the Certification Program. We have observed over time that certification is likely no longer a primary factor driving improvements or compliance in particular areas, such as with respect to privacy and security. Generally, at the time of certification, developers have (in some cases for over a decade) consistently demonstrated for many certification criteria that their certified health IT can perform required functionalities in a conformant manner. 9 Throughout this proposed rule, we have included proposed revisions and removals of certification criteria that, among other factors, we believe are no longer necessary to advance interoperability and no longer provide a strong market driver for initial adoption and implementation of the certified functionalities. 9 *https://chpl.healthit.gov/.* In total, out of the 60 certification criteria that are currently in effect, we propose to remove 34 and revise seven. Of the revised criteria, one of the proposed revisions would reduce the scope of the “decision support interventions” certification criterion to fully remove the artificial intelligence
(AI)“model card” requirements. We intend to retain and make no changes to 19 certification criteria, which include new and revised certification criteria that were adopted in the Health Data, Technology, and Interoperability: Electronic Prior Authorization and Real-Time Prescription Benefit (HTI-4) Final Rule (90 FR 37130). This final rule was published as a part of the “Medicare Program; Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals
(IPPS)and the Long-Term Care Hospital Prospective Payment System and Policy Changes and Fiscal Year
(FY)2026 Rates; Changes to the FY 2025 IPPS Rates Due to Court Decision; Requirements for Quality Programs; and Other Policy Changes; Health Data, Technology, and Interoperability: Electronic Prescribing, Real-Time Prescription Benefit and Electronic Prior Authorization” (FY2026 IPPS/LTCH PPS) Final Rule, which was published by CMS on August 4, 2025 (90 FR 36536). b. Standards and Implementation Specifications for Health Information Technology In some instances where we propose to remove or revise a certain certification criterion, we also propose to remove the standard(s) that is referenced by the certification criterion. In some cases, we propose to remove standards consistent with a certification criterion transition period until January 1, 2027. In very limited circumstances, we retain a standard referenced in a certification criterion proposed for removal for purposes of health IT interoperability alignment. 10 We also propose to remove standards that are outdated and no longer referenced in the Certification Program. Lastly, we propose to adopt USCDI v3.1 in § 170.213. 10 Section 13111 and 13112 of the HITECH Act requires health IT systems and products to utilize standards adopted under section 3004 of the PHSA in specified circumstances. The HHS Health IT Alignment Program, led by ASTP/ONC builds upon the HITECH to advance interoperability across HHS investments. *See https://www.healthit.gov/topic/hhs-health-it-alignment-program.* c. Terms and Definitions Because of the proposed removal of certain certification criteria as discussed above, we propose to make conforming edits to the terms and definitions in § 170.102. We propose to revise the definition of “Base EHR” to remove references to criteria that we have proposed to remove from the Code of Federal Regulations (CFR). We also propose to remove the definitions of “Common Clinical Data Set,” “Global Unique Device Identification Database (GUDID),” and “Production Identifier” because these terms are no longer referenced in 45 CFR part 170. d. Conditions and Maintenance of Certification Requirements for Health IT Developers We propose to make conforming edits for several Conditions and Maintenance of Certification requirements, including the “Assurances” (§ 170.402), “Application Programming Interfaces” (§ 170.404), and “Attestations” (§ 170.406) Conditions and Maintenance of Certification requirements. In addition to conforming edits, we also propose to descope the “Real World Testing” Condition and Maintenance of Certification requirements (§ 170.405) with deregulatory actions related to real world testing plans, results, and the use of the standards version advancement process (SVAP). These proposals are consistent with the enforcement discretion notice we issued on June 30, 2025. 11 Lastly, we propose to remove and descope measures associated with the “Insights” Condition and Maintenance of Certification requirements (§ 170.407), consistent with the enforcement discretion we issued on April 29, 2025, 12 to limit reporting requirements only to the “use of FHIR in apps through certified health IT” measure. 11 *https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement.* 12 *https://www.healthit.gov/topic/insights-condition-and-maintenance-certification-enforcement-discretion-notice.* e. ONC Health IT Certification Program Administrative Requirements We propose to make conforming edits, to remove references to certification criteria that we propose to remove in this proposed rule, in subpart E of 45 CFR part 170. Specifically, in §§ 170.523, 170.550, 170.555, and 170.570. 2. Information Blocking (Part 171) We propose to revise the § 171.102 “access” and “use” definitions to emphasize that the definitions include automated means of access, exchange, or use of EHI—including, without limitation, autonomous AI systems. As an alternative proposal, we propose, in addition to updating the “access” and “use” definitions, to revise the “exchange” definition in a similar manner. We propose to remove the *third party seeking modification use* condition from the Infeasibility Exception (§ 171.204(a)(3)). This condition is susceptible to misuse by actors withholding EHI to unnecessarily inhibit access, exchange, and use of EHI by third parties that patients and health care providers want. Where any requested access, exchange, or use of EHI poses concerns such as specific threats to the confidentiality, integrity, or availability of the EHI involved, this condition is unnecessary. Activities reasonable and necessary to address those concerns are covered by other exceptions. We propose to revise or, in the alternative, remove the *manner exception exhausted* condition (§ 171.204(a)(4)) from the Infeasibility Exception. Similar to the *third party seeking modification use* condition (§ 171.204(a)(3)), we believe this condition as currently codified is susceptible to misuse by actors holding EHI to unnecessarily inhibit access, exchange, and use of EHI. The revisions we propose to the *manner exception exhausted* condition (§ 171.204(a)(4)) would narrow its application to better align with our intent for this condition and reduce the risk of an actor misusing it. In the alternative, we propose to remove the entire condition to address our concerns. We propose to revise the Manner Exception's *manner requested* condition (§ 171.301(a)) to ensure that it is clear that the Manner Exception cannot be met with contracts that are not market rate, are contracts of adhesion, or are contracts containing unconscionable terms. We propose to remove subpart D from 45 CFR part 171, which includes the Trusted Exchange Framework and Common Agreement TM (TEFCA TM ) Manner Exception (§ 171.403) and associated definitions. Based on TEFCA's continued implementation, maturation, and public comments received—including those received in response to the CMS-ASTP/ONC Request for Information; Health Technology Ecosystem (90 FR 21034) (CMS-ASTP/ONC RFI)—we believe the removal of the TEFCA Manner Exception (§ 171.403) is appropriate. C. Severability It is our intent that if any provision of this rule were, if or when finalized, held to be invalid or unenforceable facially, or as applied to any person, plaintiff, or stayed pending further judicial or agency action, such provision shall be severable from other provisions of this rule, and from rules and regulations currently in effect, and not affect the remainder of this rule. It is also our intent that, unless such provision shall be held to be utterly invalid or unenforceable, it be construed to give the provision maximum effect permitted by law including in the application of the provision to other persons not similarly situated or to other, dissimilar circumstances from those where the provision may be held to be invalid or unenforceable. In this rule, we propose provisions that are intended to and will operate independently of each other, even if multiple of them serve the same or similar general purpose(s) or policy goal(s). Where a provision is necessarily dependent on another, the context generally makes that clear (such as by cross-reference to a particular standard, requirement, condition, or pre-requisite). Where a provision that is dependent on one that is stayed or held invalid or unenforceable (as described in the preceding paragraph) is included in a subparagraph, paragraph, or section within part 170 or 171 of 45 CFR, we intend that other provisions of such subparagraph(s), paragraph(s), or section(s) that operate independently of said provision would remain in effect. For example, if any proposed revision of any section or paragraph of part 170, if finalized, were stayed or held utterly invalid or unenforceable, we would intend for all other finalized revisions in part 170 that do not depend upon the stayed or invalidated revision to remain in full effect. To illustrate, if a removal of a certification criterion were to be finalized and then held to be entirely invalid or unenforceable, any corresponding removal of a cross-reference to that provision would depend on that revision and would be affected by the holding of invalidity or unenforceability. But in direct contrast, any revision to any other certification criterion or other Certification Program requirement or provision codified in part 170 that is not made based specifically on the removal of the certification criterion for which removal was held invalid or unenforceable, is intended to remain in full effect even if both revisions were proposed in this same proposed rule and were to be finalized in a single final rule. To provide another example, if we were to finalize the proposed removal of paragraph (a)(3) from § 171.204 (the Infeasibility Exception), and the removal of this paragraph was stayed or held facially invalid or unenforceable in whole or in part, we would intend for other finalized revisions in part 171, including without limitation the proposed revision or, in the alternative, removal of paragraph (a)(4) from § 171.204 (the Infeasibility Exception) to continue in effect. Each of the conditions (subparagraphs) within § 171.204(a) is designed to stand independent of any and every other subparagraph in § 171.204(a). Moreover, each information blocking exception is intended and designed to stand independent of any and every other exception unless any specific provision of an exception might explicitly reference another exception. Likewise, any dependency on cross-referenced provision(s) is intended to be limited to the exact provision, or function of such provision, that relies upon the cross-reference. For example, paragraph (a)(4) in § 171.204 cross-references subparagraphs (1)(i) and (1)(ii) in § 171.301(b) (the Manner Exception's *alternative manner* condition). If either § 171.301(b)(1)(i) or
(ii)were to be held facially invalid or unenforceable, paragraph (a)(4) in § 171.204 as currently codified is intended to remain in effect, including with respect to its cross-references to § 171.301(b) as a whole and to whichever of the cross-referenced paragraphs ((i) or (ii)) in § 171.301(b)(1) was not held facially invalid or unenforceable. If any revision to any provision of part 170 or 171 (such as the removal or revision of a specific condition within one information blocking exception in part 171 or a revision to a certification criterion in part 170) were stayed or held to be invalid or unenforceable as applied to any person, plaintiff, or circumstance, it is our intent that such provision—and any section or paragraph of part 171 or 170 that may reference such provision—be construed to give the provision maximum effect permitted by law including in the application of the provision to other persons not similarly situated or to other, dissimilar circumstances from those where the provision may be held to be invalid or unenforceable. D. Costs and Benefits The Regulatory Impact Analysis
(RIA)includes an updated analysis of the costs and benefits associated with the proposals in this proposed rule. The proposed deregulatory actions provide substantial relief for developers of certified health IT and significant cost savings realized from the revision and removal of certain Certification Program requirements. The cost savings have been estimated using the best available data and modeled on the costs estimated and finalized in prior ASTP/ONC rulemakings. The proposed deregulatory actions reduce the effort of developers of certified health IT to meet ongoing Certification Program requirements and reduce entry barriers for new Certification Program participants. The proposed actions, importantly, return effort back to developers of certified health IT to innovate with their technology, improve interoperability and third-party integration, and focus on the needs of their customers. We do not expect costs to be associated with these deregulatory proposals. We expect the proposed deregulatory actions to result in significant benefits for health IT developers, providers, ONC-Authorized Certification Bodies (ONC- ACBs), ONC-Authorized Testing Laboratories (ONC-ATLs), and ASTP/ONC. Generally, these benefits are in the form of cost and time savings and reductions in administrative burden to comply with Certification Program requirements. The proposed actions reduce the scope and breadth of Certification Program requirements. The analysis included in this proposed rule indicates that the proposed updates to the Certification Program would result in $0 in implementation costs on developers of certified health IT. However, we do estimate some costs for reviewers who review this proposed rule. We estimate those costs to be $284,132 in total for an estimated 644 reviewers, which include developers and medical associations. We do not quantify benefits for this proposed rule and instead rely on our calculation of cost savings to developers of certified health IT to quantify in dollars the time and effort developers would have expended had these requirements remained in effect in perpetuity. In total, this proposed rulemaking would result in a present value of cost savings of $1.53 billion in 2024 dollars and discounted at a rate of 7%, beginning in 2027 and in perpetuity. II. Background A. Statutory Basis The Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act
(PHSA)and created “Title XXX—Health Information Technology and Quality” (Title XXX) to improve health care quality, safety, and efficiency through the promotion of health IT and electronic health information
(EHI)exchange. The 21st Century Cures Act (Pub. L. 114-255) (Cures Act) was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, through Title IV—Delivery, amended the HITECH Act by modifying or adding certain provisions to the PHSA relating to health IT. 1. Standards, Implementation Specifications, and Certification Criteria The HITECH Act established two Federal advisory committees, the Health IT Policy Committee (HITPC) and the Health IT Standards Committee (HITSC). Each was responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria. Section 4003(e) of the Cures Act amended sections 3002 and 3003 of the PHSA by replacing, in an amended section 3002, the HITPC and HITSC with one committee named the Health Information Technology Advisory Committee (Health IT Advisory Committee or HITAC). Section 3002(a) of the PHSA, as added by the Cures Act, establishes that the HITAC recommends to the National Coordinator policies and standards, implementation specifications, and certification criteria, relating to the implementation of a health information technology infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1) of the PHSA, this includes recommending to the National Coordinator a policy framework to advance interoperable health information technology infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) of the PHSA specifies that in general, the HITAC shall recommend to the National Coordinator for purposes of adoption under section 3004, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Like the process previously required of the former HITPC and HITSC, section 3002(b)(5) of the PHSA requires the HITAC to develop a schedule, updated annually, for the assessment of policy recommendations, which the Secretary publishes in the **Federal Register** . Section 3004 of the PHSA establishes a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1), the Secretary is required, in consultation with representatives of other relevant federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator in section 3001(c) and subsequently determine whether to propose the adoption of such standards, implementation specifications, or certification criteria. Section 3004(a)(3) requires the Secretary to publish all such determinations in the **Federal Register** . Section 3004(b)(3) of the PHSA, titled, Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the HITAC. We consider this provision in the broader context of the HITECH Act and Cures Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria. 2. Health IT Certification Program Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of health IT. Section 3001(c)(5)(A) specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted in section 3004 of the PHSA. The certification program(s) must also include, as appropriate, testing of the technology in accordance with section 13201(b) of the HITECH Act. Overall, section 13201(b) of the HITECH Act requires that, with respect to the development of standards and implementation specifications, the Director of NIST shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. The HITECH Act also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non-federal laboratories to perform testing. Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which requires the Secretary, through notice and comment rulemaking, to require conditions of certification and maintenance of certification for the Certification Program. Specifically, the health IT developers or entities with technology certified under the Certification Program must, in order to maintain such certification status, adhere to certain conditions and maintenance of certification requirements concerning information blocking; assurances regarding appropriate exchange, access, and use of electronic health information; communications regarding health IT; APIs; real world testing; attestations regarding certain conditions and maintenance of certification requirements; and submission of reporting criteria under the EHR Reporting Program in accordance with section 3009A(b) of the PHSA. B. Regulatory History The Secretary issued an interim final rule with request for comments on January 13, 2010, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (the “S&CC January 2010 Interim Final Rule”) (75 FR 2014), which adopted an initial set of standards, implementation specifications, and certification criteria. On March 10, 2010, the Secretary issued a proposed rule, “Proposed Establishment of Certification Programs for Health Information Technology” (75 FR 11328), that proposed both temporary and permanent certification programs for the purposes of testing and certifying health IT. A final rule establishing the temporary certification program was published on June 24, 2010, “Establishment of the Temporary Certification Program for Health Information Technology” (75 FR 36158), and a final rule establishing the permanent certification program was published on January 7, 2011, “Establishment of the Permanent Certification Program for Health Information Technology” (76 FR 1262). After consideration of the comments received on the S&CC January 2010 Interim Final Rule, a final rule was issued to complete the adoption of the initial set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for the EHR Incentive Programs Stage 1, titled “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 44590, July 28, 2010) (2011 Edition Final Rule). The 2011 Edition Final Rule also established the first version of the certified electronic health record technology (CEHRT) definition. Subsequent to the 2011 Edition Final Rule, on October 13, 2010, we issued an interim final rule “Health Information Technology: Revisions to Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” with a request for comment to remove certain implementation specifications related to public health surveillance that had been previously adopted in the 2011 Edition Final Rule (75 FR 62686). The standards, implementation specifications, and certification criteria adopted by the Secretary in the 2011 Edition Final Rule established the capabilities that CEHRT must include in order to, at a minimum, support the achievement of EHR Incentive Programs Stage 1 by eligible professionals (EPs), eligible hospitals, and critical access hospitals
(CAHs)under the “Medicare and Medicaid Programs; Electronic Health Record Incentive Program” final rule (75 FR 44314, July 28, 2010) (EHR Incentive Programs Stage 1 Final Rule). On March 7, 2012, the Secretary issued a proposed rule with request for comments titled “Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology” (77 FR 13832) (2014 Edition Proposed Rule), which proposed new and revised standards, implementation specifications, and certification criteria. After consideration of the comments received on the 2014 Edition Proposed Rule, a final rule titled “Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology” (77 FR 54163) (2014 Edition Final Rule) was issued on September 4, 2012, to adopt the 2014 Edition set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for the EHR Incentive Programs Stage 2, as well as Stage 1 revisions. The 2014 Edition Final Rule adopted a proposal to change the Permanent Certification Program's name to the “ONC HIT Certification Program,” revised the process for permitting the use of newer versions of “minimum standard” code sets, modified the certification processes ONC-ACBs need to follow for certifying EHR Modules in a manner that provides clear implementation direction and compliance with the new certification criteria, and eliminated the certification requirement that every EHR Module be certified to the “privacy and security” certification criteria. The standards, implementation specifications, and certification criteria adopted by the Secretary in the 2014 Edition Final Rule established the capabilities that CEHRT must include in order to, at a minimum, support the achievement of the EHR Incentive Programs Stage 2 by EPs, eligible hospitals, and CAHs under the “Medicare and Medicaid Programs; Electronic Health Record Incentive Program—Stage 2” final rule (77 FR 53968, September 4, 2012) (EHR Incentive Programs Stage 2 Final Rule). On December 7, 2012, an interim final rule with a request for comment, titled “Health Information Technology: Revisions to the 2014 Edition Electronic Health Record Certification Criteria; and Medicare and Medicaid Programs; Revisions to the Electronic Health Record Incentive Program” (77 FR 72985), was jointly issued and published by ONC and CMS to update certain standards that had been previously adopted in the 2014 Edition Final Rule. The interim final rule also revised the EHR Incentive Programs by adding an alternative measure for the Stage 2 objective for hospitals to provide structured electronic laboratory results to ambulatory providers, corrected the regulation text for the measures associated with the objective for hospitals to provide patients the ability to view online, download, and transmit information about a hospital admission, and made the case number threshold exemption policy for clinical quality measure
(CQM)reporting applicable for eligible hospitals and CAHs beginning with FY 2013. In addition, the interim final rule provided notice of CMS's intent to issue technical corrections to the electronic specifications for CQMs released on October 25, 2012. On September 4, 2014, a final rule “Medicare and Medicaid Programs; Modifications to the Medicare and Medicaid Electronic Health Record
(EHR)Incentive Program for 2014 and Other Changes to the EHR Incentive Program; and Health Information Technology: Revisions to the Certified EHR Technology Definition and EHR Certification Changes Related to Standards” (79 FR 52910) was published adopting these proposals. On November 4, 2013, the Secretary published an interim final rule with a request for comment titled “2014 Edition Electronic Health Record Certification Criteria: Revision to the Definition of `Common Meaningful Use
(MU)Data Set' ” (78 FR 65884) to make a minor revision to the Common MU Data Set definition. This revision was intended to allow more flexibility with respect to the representation of dental procedures data for EHR technology testing and certification. On February 26, 2014, the Secretary published a proposed rule titled “Voluntary 2015 Edition Electronic Health Record
(EHR)Certification Criteria; Interoperability Updates and Regulatory Improvements” (79 FR 10880) (“Voluntary Edition Proposed Rule”). The proposed rule proposed a voluntary edition of certification criteria that was designed to enhance interoperability, promote innovation, and incorporate “bug fixes” to improve upon the 2014 Edition. The Voluntary Edition Proposed Rule also included proposals that focused on improving regulatory clarity, simplifying the certification of EHR Modules that are designed for purposes other than meeting requirements of the EHR Incentive Programs, and discontinuing the use of the Complete EHR definition. A correction notice was published for the Voluntary Edition Proposed Rule on March 19, 2014, entitled “Voluntary 2015 Edition Electronic Health Record
(EHR)Certification Criteria; Interoperability Updates and Regulatory Improvements; Correction” (79 FR 15282). This correction notice corrected the preamble text and gap certification table for four certification criteria that were omitted from the list of certification criteria eligible for gap certification for the 2015 Edition EHR certification criteria. On September 11, 2014, a final rule was published titled “2014 Edition Release 2 Electronic Health Record
(EHR)Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities, Improvements, and Enhanced Health Information Exchange” (79 FR 54430) (2014 Edition Release 2 Final Rule). The final rule adopted a small subset of the original proposals in the Voluntary Edition Proposed Rule as optional and revised 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. It also finalized administrative proposals ( *i.e.,* removal of regulatory text from the CFR) and proposals for the ONC HIT Certification Program that provide improvements. We issued the 2014 Edition Release 2 Final Rule to complete the rulemaking for the Voluntary Edition Proposed Rule. The 2014 Edition Release 2 Final Rule discontinued the “Complete EHR” certification concept beginning with the proposed 2015 Edition, adopted an updated standard (ISO/IEC 17065) for the accreditation of ONC-ACBs, and adopted the “ONC Certified HIT” certification and design mark for required use by ONC-ACBs under the Certification Program. On May 23, 2014, CMS and ONC jointly published a proposed rule titled “Medicare and Medicaid Programs; Modifications to the Medicare and Medicaid Electronic Health Record Incentive Programs for 2014; and Health Information Technology: Revisions to the Certified EHR Technology Definition” (79 FR 29732). The proposed rule proposed to update the EHR Incentive Programs Stage 2 and Stage 3 participation timeline. It proposed to revise the CEHRT definition to permit the use of EHR technology certified to the 2011 Edition to meet the CEHRT definition for FY/CY 2014. It also proposed to allow EPs, eligible hospitals, and CAHs that could not fully implement EHR technology certified to the 2014 Edition for an EHR reporting period in 2014 due to delays in the availability of such technology to continue to use EHR technology certified to the 2011 Edition or a combination of EHR technology certified to the 2011 Edition and 2014 Edition for the EHR reporting periods in CY 2014 and FY 2014. On September 4, 2014, a final rule titled “Medicare and Medicaid Programs; Modifications to the Medicare and Medicaid Electronic Health Record
(EHR)Incentive Program for 2014 and Other Changes to the EHR Incentive Program; and Health Information Technology: Revisions to the Certified EHR Technology Definition and EHR Certification Changes Related to Standards” (CEHRT Flexibility Final Rule) was published (79 FR 52910) adopting these proposals. On March 30, 2015, the Secretary published a proposed rule titled “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record
(EHR)Definition, and ONC Health IT Certification Program Modifications” (80 FR 16804) (2015 Edition Proposed Rule). The 2015 Edition Proposed Rule proposed revisions to the Certification Program with a revised edition of certification criteria that was designed to enhance interoperability. On October 16, 2015, the Secretary published a final rule titled “2015 Edition Health Information (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record
(EHR)Definition, and ONC Health IT Certification Program Modifications” (80 FR 62602) (2015 Edition Final Rule). The 2015 Edition Final Rule established a new edition of certification criteria (2015 Edition) and a new 2015 Edition Base EHR definition. CMS subsequently established the 2015 Edition Base EHR definition as encompassing the minimum capabilities and the related minimum standards and implementation specifications that CEHRT would need to include to support the achievement of “meaningful use” by eligible clinicians, eligible hospitals, and CAHs under the Medicare and Medicaid EHR Incentive Programs (the predecessors to the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category under the Merit-based Incentive Payment System (MIPS)). The final rule also adopted a proposal to change the Certification Program's name to the “ONC Health IT Certification Program” from the ONC HIT Certification Program, modified the Certification Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised Principles of Proper Conduct
(PoPC)for ONC-ACBs. A final rule making corrections and clarifications was published for the 2015 Edition Final Rule (80 FR 76868) on December 11, 2015, to correct preamble and regulatory text errors and clarify requirements of the CCDS, the 2015 Edition privacy and security certification framework, and the mandatory disclosures for health IT developers. After issuing a proposed rule on March 2, 2016, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 11056), we published a final rule by the same title (81 FR 72404) (EOA Final Rule) on October 19, 2016. The EOA Final Rule finalized modifications and new requirements under the Certification Program, including provisions related to our role in the Certification Program. The EOA Final Rule created a regulatory framework for our direct review of health IT certified under the Certification Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Certification Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The final rule also set forth processes for us to authorize and oversee accredited testing laboratories under the Certification Program. In addition, it included provisions for expanded public availability of certified health IT surveillance results. On March 4, 2019, the Secretary published a proposed rule titled “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (84 FR 7424) (Cures Act Proposed Rule). The proposed rule proposed to implement certain provisions of the 21st Century Cures Act (Cures Act) that would advance interoperability and support the access, exchange, and use of electronic health information. On May 1, 2020, the Cures Act Final Rule was published in the **Federal Register** (85 FR 25642). The final rule implemented certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health IT developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. The final rule also implemented certain parts of the Cures Act to support patients' access to their electronic health information (EHI), and the implementation of information blocking policies that support patient electronic access. Additionally, the final rule modified the 2015 Edition health IT certification criteria and Certification Program in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as to improve patient and health care provider access to EHI and promote competition. On November 4, 2020, the Secretary published an interim final rule with comment period titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70064) (Cures Act Interim Final Rule). The interim final rule extended certain compliance dates and timeframes adopted in the Cures Act Final Rule to offer the health care system additional flexibilities in furnishing services to combat the COVID-19 pandemic, including extending the applicability date for information blocking provisions to April 5, 2021. On April 18, 2023, the Secretary published a proposed rule titled “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (88 FR 23746) (HTI-1 Proposed Rule). The HTI-1 Proposed Rule proposed to implement the EHR Reporting Program provision of the Cures Act by establishing new Conditions and Maintenance of Certification requirements for health IT developers under the Certification Program. The HTI-1 Proposed Rule also proposed several updates to certification criteria and implementation specifications recognized by the Certification Program, including revised certification criteria for: “clinical decision support,” “patient demographics and observations,” and “electronic case reporting.” The HTI-1 Proposed Rule also proposed to establish a new baseline version of the USCDI. Additionally, the HTI-1 Proposed Rule also proposed enhancements to support information sharing under the information blocking regulations. On January 9, 2024, the Secretary issued the “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” final rule (HTI-1 Final Rule), which implemented the EHR Reporting Program provision of the 21st Century Cures Act and established new Conditions and Maintenance of Certification requirements for health IT developers under the Certification Program (89 FR 1192). The HTI-1 Final Rule also made several updates to certification criteria and standards recognized by the Certification Program. The Certification Program updates included revised certification criteria for “decision support interventions” (DSIs), “patient demographics and observations,” and “electronic case reporting,” as well as adopted a new baseline version of the USCDI standard, USCDI Version 3 (v3). Additionally, the HTI-1 Final Rule provided enhancements to support information sharing under the information blocking regulations. Through these provisions, we sought to advance interoperability, improve algorithm transparency, and support the access, exchange, and use of EHI. The HTI-1 Final Rule also updated numerous technical standards in the Certification Program to advance interoperability, enhance health IT certification, and reduce burden and costs for health IT developers and users of health IT. On August 5, 2024, the Secretary published a proposed rule titled “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (89 FR 63498) (HTI-2 Proposed Rule). The HTI-2 Proposed Rule sought to advance interoperability, improve transparency, and support the access, exchange, and use of EHI through proposals for: standards adoption; adoption of certification criteria to advance public health data exchange; expanded uses of certified APIs, such as for electronic prior authorization, patient access, care management, and care coordination; and information sharing under the information blocking regulations. Additionally, the HTI-2 Proposed Rule proposed to establish a new baseline version of the USCDI standard and proposed to update the Certification Program to enhance interoperability and optimize certification processes to reduce burden and costs. The HTI-2 Proposed Rule also proposed to implement certain provisions related to TEFCA, which would support the reliability, privacy, security, and trust within TEFCA. On December 16, 2024, the Secretary issued the “Health Data, Technology, and Interoperability: Trusted Exchange Framework and Common Agreement (TEFCA)” final rule (89 FR 101772) (HTI-2 Final Rule) which implemented advancements to interoperability, improved transparency, and supported the access, exchange, and use of electronic health information. The HTI-2 Final Rule codified definitions of certain TEFCA terms in § 171.401 of the information blocking regulations and finalized the 45 CFR part 172 TEFCA provisions. On December 17, 2024, the Secretary issued the “Health Data, Technology, and Interoperability: Protecting Care Access” final rule (89 FR 102512) (HTI-3 Final Rule). The HTI-3 Final Rule finalized certain proposals from the HTI-2 Proposed Rule to support the access, exchange, and use of EHI. The final rule amended the information blocking regulations to revise two existing information blocking exceptions and established an additional reasonable and necessary activity that does not constitute information blocking referred to as the Protecting Care Access Exception. On July 31, 2025, ASTP/ONC finalized the “Health Data, Technology, and Interoperability: Electronic Prescribing, Real-Time Prescription Benefit and Electronic Prior Authorization” final rule (90 FR 37130) (HTI-4 Final Rule), as a part of the FY2026 IPPS/LTCH PPS Final Rule, published by CMS on August 4, 2025 (90 FR 36536). The HTI-4 Final Rule finalized a limited subset of the proposals in the HTI-2 Proposed Rule (89 FR 63498) and focused on improving care delivery and reducing administrative burden through the exchange of clinical and administrative information. The HTI-4 Final Rule updated the ONC Health IT Certification Program to add several new certification criteria that advance health care providers' ability to engage in electronic prescribing, real-time prescription benefit checks, and electronic prior authorization. III. Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology (Part 170) Reading This Proposed Rule In this preamble, we present our proposals in an order that begins with the certification criteria we propose to remove and subsequently the standards, definitions, and other related Certification Program provisions proposed for removal or revision. This approach should make it easier for readers to follow our proposed Certification Program removals, in part, due to the natural cascading effects of proposing to remove or revise a certification criterion. For example, we propose to remove the “application access—all data request” certification criterion in 45 CFR 170.315(g)(9), the referenced HL7 CDA R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion guide, Release 2-US Realm, October 2019 (45 CFR 170.205(a)(5)), and the “application access—all data request” certification criterion from the Base EHR definition. In some cases, we propose to remove a standard consistent with a certification criterion transition period until January 1, 2027. In very limited circumstances, we retain a standard that is cross-referenced in a certification criterion that we propose to remove. We do this because the standard is cross-referenced in another criterion and/or supports health IT interoperability alignment. For example, although we propose to remove the “transport methods and other protocols” certification criteria in § 170.315(h), we propose to retain the Direct Project transport standard adopted in § 170.202(a)(2) because we believe keeping the primary Direct Project standard would acknowledge the current utilization of the Direct standard, while removing the certification criteria in § 170.315(h) recognizes the ongoing technological advancements related to transport, including movement toward FHIR-based standards, and would encourage and provide space for further innovation and market competition in this area. We also propose to remove the certification criteria in § 170.315(h) from the “Base EHR” definition. Additionally, we solely propose to remove standards when they are no longer referenced by existing certification criteria. Further, as noted above, we propose to remove certain Conditions and Maintenance of Certification requirements and other Certification Program requirements. RFI Feedback Recently, the Office of Management and Budget (OMB), the Department, and CMS-ASTP/ONC issued requests for information
(RFIs)related to deregulation. We reviewed comments related to ASTP/ONC. In response to the CMS-ASTP/ONC Request for Information; Health Technology Ecosystem (90 FR 21034) (CMS-ASTP/ONC RFI), commenters expressed a strong desire to modernize the Certification Program to be more modular, API-focused, and less centered on specific EHR functionalities. Commenters recommended simplifying the process, reducing costs, and expanding certification requirements to ensure payers and other health IT systems adhere to the same interoperability standards. There was an overwhelming demand to strengthen, expand, and mandate the use of FHIR-based APIs. Commenters strongly advocated for retiring outdated, less efficient standards to reduce complexity. A central theme from commenters was the need for regulatory modernization to reduce administrative and financial burdens on providers and technology developers. Commenters also expressed concern that existing certification requirements are often too rigid, costly, and not aligned with emerging care models like value-based care or specialized technologies such as AI and remote monitoring. A commenter that responded to the HHS RFI expressed concerns with the Real World Testing and Insights Conditions of Certification, stating that the requirements are overly burdensome and offer limited value to providers or patients. The commenter also recommended retiring low-value certification criteria requirements that add complexity without improving care. A commenter that responded to the OMB RFI suggested that revisions could be made to the Conditions and Maintenance of Certification requirements that focus on streamlined and meaningful oversight without placing undue demands on developers, especially where those demands offer limited direct benefit to health care provider customers or their patients. The commenter also suggested the removal of “non-interoperability-focused, redundant, or valueless” criteria and focus on promoting standardized and scalable interoperability. ASTP/ONC addresses a number of these comments in the proposals below, specifically the suggestions to remove non-interoperability-focused and redundant certification criteria. Commenters were strongly supportive of our focus on FHIR-based standards. Some commenters, however, included suggestions related to new regulatory actions. These suggestions are out of scope for this proposed deregulatory rule, but we may consider the suggestions for a future rulemaking. A. Certification Criteria for Health Information Technology In this proposed rule we have identified certification criteria for removal or revision. For some of the criteria below, we justify removing the certification criteria because they have been “widely adopted” or “widely implemented.” To determine if the certification criterion is “widely adopted” or “widely implemented,” we considered whether and for how long the certification criterion has been included in the Base EHR definition in § 170.102, or the Certified Electronic Health Record Technology (CEHRT) definitions established by CMS in 42 CFR 495.4 and 414.1305. The CEHRT definitions incorporate the Base EHR definition and may also incorporate certification criteria necessary to report applicable objectives and measures under the Medicare Promoting Interoperability
(PI)Program or the Promoting Interoperability performance category in the Merit-based Incentive Payment System (MIPS), certification criteria determined applicable for an Alternative Payment Model (APM), and other certification criteria as specified. To participate in the Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, eligible hospitals, CAHs, and eligible clinicians must use CEHRT as specified by the applicable definition. In addition, CEHRT is required for the purposes of determinations under 42 CFR 414.1415 and 414.1420 regarding Advanced APM status. ASTP/ONC tracks and publishes data on the adoption and use of health IT, including CEHRT, by US hospitals and office-based physicians. Our most recent survey data from 2021 shows that 96 percent of hospitals and 78 percent of physicians reported having a certified EHR. 13 As discussed in more detail below, we provide this analysis and consider certain certification criteria as “widely adopted” or “widely implemented” because they are included in the Base EHR or CEHRT definitions and adopted by 96 and 78 percent of hospitals and physicians, respectively. Our proposals to remove or revise certain certification criteria are also consistent with our drive toward and our support for the FHIR standard as mentioned above in section I.A and are responsive to comments we received on the recently issued RFIs. We explain our proposals in detail in their respective sections of the preamble and have provided a table (see Table 1) for a list of all proposed certification criteria removals and revisions. 13 *https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.* Table 1—Proposed Removals or Revisions of Certification Criteria Certification criteria Reference Remove/revise Timing Patient demographics and observations § 170.315(a)(5) Revise Effective date of final rule. Clinical decision support § 170.315(a)(9) Remove Effective date of final rule. Family health history § 170.315(a)(12) Remove Effective January 1, 2027. Implantable device list § 170.315(a)(14) Remove Effective date of final rule. Transitions of care § 170.315(b)(1) Revise Effective January 1, 2027. Clinical information reconciliation and incorporation § 170.315(b)(2) Remove Effective January 1, 2027. Security tags—summary of care—send § 170.315(b)(7) Remove Effective date of final rule. Security tags—summary of care—receive § 170.315(b)(8) Remove Effective date of final rule. Care plan § 170.315(b)(9) Remove Effective date of final rule. Decision support interventions § 170.315(b)(11) Revise Effective date of final rule. Clinical quality measures—report § 170.315(c)(3) Revise Effective date of final rule. Clinical quality measures—filter § 170.315(c)(4) Remove Effective January 1, 2027. Authentication, access control, authorization § 170.315(d)(1) Remove Effective date of final rule. Auditable events and tamper-resistance § 170.315(d)(2) Remove Effective date of final rule. Audit report(s) § 170.315(d)(3) Remove Effective date of final rule. Amendments § 170.315(d)(4) Remove Effective date of final rule. Automatic access time-out § 170.315(d)(5) Remove Effective date of final rule. Emergency access § 170.315(d)(6) Remove Effective date of final rule. End-user device encryption § 170.315(d)(7) Remove Effective date of final rule. Integrity § 170.315(d)(8) Remove Effective date of final rule. Trusted connection § 170.315(d)(9) Remove Effective date of final rule. Auditing actions on health information § 170.315(d)(10) Remove Effective date of final rule. Accounting of disclosures § 170.315(d)(11) Remove Effective date of final rule. Encrypt authentication credentials § 170.315(d)(12) Remove Effective date of final rule. Multi-factor authentication § 170.315(d)(13) Remove Effective date of final rule. View, download, and transmit to 3rd party § 170.315(e)(1) Revise Effective data of final rule. Patient health information capture § 170.315(e)(3) Remove Effective January 1, 2027. Transmission to cancer registries § 170.315(f)(4) Remove Effective January 1, 2027. Transmission to public health agencies—electronic case reporting § 170.315(f)(5) Revise Effective date of final rule. Transmission to public health agencies—antimicrobial use and resistance reporting § 170.315(f)(6) Revise Effective date of final rule. Transmission to public health agencies—health care surveys § 170.315(f)(7) Remove Effective January 1, 2027. Automated numerator recording § 170.315(g)(1) Remove Effective January 1, 2027. Automated measure calculation § 170.315(g)(2) Remove Effective January 1, 2027. Safety-enhanced design § 170.315(g)(3) Remove Effective date of final rule. Quality management system § 170.315(g)(4) Remove Effective date of final rule. Accessibility-centered design § 170.315(g)(5) Remove Effective date of final rule. Consolidated CDA creation performance § 170.315(g)(6) Remove Effective date of final rule. Application access—patient selection § 170.315(g)(7) Remove Effective January 1, 2027. Application access—all data request § 170.315(g)(9) Remove Effective January 1, 2027. Direct Project § 170.315(h)(1) Remove Effective date of final rule. Direct Project, Edge Protocol, and XDR/XDM § 170.315(h)(2) Remove Effective date of final rule. 1. Clinical Certification Criteria a. Patient Demographics In the 2014 Edition Final Rule, we included “demographics” in the Base EHR definition in § 170.102 (77 FR 54265). We noted that including demographics in the Base EHR definition aligns with the statutory “Qualified EHR” definition and is intended to facilitate the recording, capture, and access to a patient's demographic data. In the 2015 Edition Final Rule (80 FR 62602), we added the requirement to record, capture, and access a patient's sex, sexual orientation, and gender identity for Health IT Modules certified to the demographics' certification criterion (§ 170.315(a)(5)) (80 FR 62747). The 2015 Edition Final Rule also defined a required set of standardized terminology to represent each of these data elements (80 FR 62618 through 62620). In the HTI-1 Final Rule (89 FR 1428), we adopted USCDI v3, which includes data elements for Sex, Sexual Orientation, and Gender Identity. To ensure consistent capture of these data elements across health IT, we made updates to the data elements in § 170.315(a)(5) to incorporate the newly adopted data elements in USCDI v3. Specifically, these same data elements were adopted as “sex” (§ 170.315(a)(5)(i)(C)), “sexual orientation” (§ 170.315(a)(5)(i)(D)), and “gender identity” (§ 170.315(a)(5)(i)(E)). To ensure consistency with our adoption of USCDI v3, we finalized the name change of the certification criterion in § 170.315(a)(5) from “demographics” to “patient demographics and observations” due to the inclusion of data elements based on clinical observations. Additionally, in the HTI-1 Final Rule, we finalized the replacement of the specific concepts referenced in § 170.315(a)(5)(i)(D) and (E), sexual orientation and gender identity, respectively, with the SNOMED Clinical Terms U.S. Edition (SNOMED CT®) U.S. Edition code set, as referenced in the standard in § 170.207(o)(3). In § 170.315(a)(5)(C), sex, we finalized adoption that a Health IT Module enable sex to be recorded in accordance with the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025; or § 170.207(n)(2). The standards specified in § 170.207(n)(1)
(sex)require that birth sex must be coded in accordance with HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor, up until the adoption of this standard expires January 1, 2026, attributed as follows:
(i)Male. M;
(ii)Female. F;
(iii)Unknown. NullFlavor UNK. The code sets referenced in § 170.207(n)(1), as cross-referenced in § 170.315(a)(5)(i)(C), would expire on January 1, 2026, but we also stated that health IT developers could continue to use the specific codes referenced in § 170.207(n)(1) through December 31, 2025, to provide adequate time for Health IT Modules certified to the relevant certification criteria to transition to the updated terminology standards. Lastly, we finalized the addition of “sex parameter for clinical use” as a new data element in § 170.315(a)(5)(i)(F), “name to use” in § 170.315(a)(5)(i)(G), and “pronouns” in § 170.315(a)(5)(i)(H). After publication of the HTI-1 Final Rule and our adoption of the revisions in § 170.315(a)(5), we began exercising enforcement discretion and issued certification guidance for the Certification Program regarding Health IT Module conformance with certain data elements in the patient demographics and observations certification criterion. 14 In our enforcement discretion notice, we explained that § 170.550 requires an ONC-ACB, when certifying Health IT Modules, to certify in accordance with the applicable certification criteria adopted in regulation. Under this enforcement discretion and certification guidance, we noted that ASTP/ONC will not take any enforcement action under § 170.565 against an ONC-ACB based on non-compliance with § 170.550 for certifying a Health IT Module that is presented for certification to the patient demographics and observations certification criterion (§ 170.315(a)(5)) where the Health IT Module does not demonstrate conformance with any or all of the following data and observations in paragraph (a)(5)(i): sex parameter for clinical use, sexual orientation, gender identity, name to use, and pronouns; or does not demonstrate conformance with any or all of data and observations in § 170.315(a)(5)(i)(D) through (H). We also stated that ASTP/ONC will not take action against Health IT Modules certifying or currently certified to the patient demographics and observations certification criterion in § 170.315(a)(5) that only demonstrate, for conformance with paragraph (a)(5)(i)(C) (sex), that it can record sex in accordance with either the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025, or the SNOMED CT® U.S. Edition codes found in the standard specified in § 170.207(n)(2): 248152002 Female (finding) and 248153007 Male (finding). 15 We noted that we would not exercise our direct review authority under § 170.580 for any non-conformity, potential or actual, that arises solely from a Health IT Module not demonstrating the capabilities specified in our enforcement discretion notice. We stated that the enforcement discretion and certification guidance will remain in effect for 12 months from the date of the notice or until the Department completes a regulatory action to revise the applicable regulations, whichever comes first. 14 USCDI v3 Data Elements Enforcement Discretion *https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion-notice.* 15 *https://www.healthit.gov/test-method/patient-demographics-and-observations.* We have reviewed the requirements in § 170.315(a)(5)(i) and have determined that removal of certain requirements in § 170.315(a)(5)(i) would result in burden reduction for health IT developers and cost savings associated with the
(1)enforcement discretion and
(2)ongoing maintenance costs affected by the proposed updates to the certification criterion. Accordingly, for these reasons and reasons discussed below, we propose the following revisions to § 170.315(a)(5)(i). We propose to revise § 170.315(a)(5)(i)(C) to remove the reference to the standard in § 170.207(n)(1) (HL7 Administrative Gender and NullFlavor). As discussed above, in the HTI-1 Final Rule, we finalized that the adoption of the code sets referenced in § 170.207(n)(1) will expire on January 1, 2026. Beginning January 1, 2026, a Health IT Module certified to § 170.315(a)(5) is required to demonstrate, for conformance with paragraph (a)(5)(i)(C), that it can record sex in accordance with the SNOMED CT® U.S. Edition codes found in the standard specified in § 170.207(n)(2). Given the timing of publication of this proposed rule, the reference to § 170.207(n)(1) in § 170.315(a)(5)(i)(C) is outdated and no longer relevant. Therefore, we propose to remove the cross-reference to § 170.207(n)(1) in § 170.315(a)(5)(i)(C) because retaining the reference may cause confusion for interested parties. Our proposed revision would keep the cross-reference to § 170.207(n)(2) in § 170.315(a)(5)(i)(C). We propose that to demonstrate conformance with § 170.315(a)(5), a Health IT Module would only need to demonstrate that it can record sex in accordance with either the 248152002 Female (finding) or 248153007 Male (finding) SNOMED CT® U.S. Edition codes found in the standard specified in § 170.207(n)(2). A Health IT Module would not need to demonstrate that it can record sex with any other code found in SNOMED CT® U.S. Edition. We have reviewed and evaluated the data elements in § 170.315(a)(5)(i)(D) through
(H)for consistency with our overall deregulatory approach, and we have determined that it is no longer necessary to include the paragraphs specified in § 170.315(a)(5)(i)(D) through
(H)( *i.e.,* patient observations data) as part of the Certification Program. As part of this evaluation, we considered the general statutory requirement of the Qualified EHR definition (further implemented with the “Base EHR” definition in § 170.102) to capture patient demographics, which neither identifies demographic data elements nor requires certain demographic elements to be included in the definition. The removal of these elements would reduce burden by narrowing how many data elements are required for purposes of certification to the criterion and for meeting the Base EHR definition. This would produce cost savings for developers regulated under the Certification Program. Health IT developers would no longer need to support these data elements as part of the voluntary certification process including not only for initial certification but also for ongoing maintenance requirements over time. In this regard, we invite readers to review section VIII (Regulatory Impact Analysis) for a detailed discussion of our estimated impacts and cost savings associated with our proposed revisions in § 170.315(a)(5)(i). In addition, the observational data elements proposed for removal do not support the meeting of specific measures under the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, and therefore, are not essential for inclusion in certified health IT that is used to meet the CEHRT definitions and support meeting measures under those programs. Lastly, we note that the proposed removal of the data elements in § 170.315(a)(5)(i)(D) through
(H)aligns with our proposal related to the removal of data elements from USCDI v3 and reflected in proposed USCDI v3.1 (see section III.B.1). We propose a conforming name change of the certification criterion from “patient demographics and observations” to “patient demographics.” This revision is not a substantive change to certification requirements, but would return the certification criterion's naming convention to as it was prior to the HTI-1 Final Rule, as well as acknowledge that the data described in § 170.315(a)(5) is understood to be demographic information. We note that our proposed revisions are limited to § 170.315(a)(5)(i), and we do not propose to revise the “inpatient setting only” requirements in § 170.315(a)(5)(ii). We welcome comments on these proposals. b. Clinical Decision Support We propose to remove the “clinical decision support”
(CDS)certification criterion and reserve § 170.315(a)(9). In 2012, we established a new set of requirements for Health IT Modules to support CDS. These requirements included capabilities to support evidence-based CDS based on a defined set of data elements; CDS configuration for both inpatient and ambulatory settings; and the display of source attribute or bibliographic citation of CDS (77 FR 54212). In the 2015 Edition Final Rule, we finalized an updated CDS certification criterion in § 170.315(a)(9) (80 FR 62622). In the HTI-1 Proposed Rule, we noted our belief that the continued evolution of decision support software, especially as it relates to AI or machine learning-driven Predictive DSIs, necessitates new requirements for the Certification Program's CDS certification criterion (88 FR 23781). In the HTI-1 Final Rule, we finalized an expiration date of January 1, 2025, for the CDS certification criterion in § 170.315(a)(9) and incorporate certain policies with modifications in the “decision support intervention” certification criterion in § 170.315(b)(11) (89 FR 1237). We finalized a conforming expiration date for the CDS certification criterion in the Base EHR definition in § 170.102. We noted that no action is required for developers relating to the expiration of § 170.315(a)(9) in the Base EHR. However, we also noted that developers with Health IT Modules certified to § 170.315(a)(9) wishing to maintain certification to the Base EHR definition, needed to update to the DSI certification criterion in § 170.315(b)(11) by December 31, 2024. As of January 1, 2025, the CDS certification criterion in § 170.315(a)(9) is no longer available in the Certification Program. Therefore, we propose to remove and reserve § 170.315(a)(9). This proposal would be effective upon the effective date of a subsequent final rule. We welcome feedback on this proposal. c. Family Health History We propose to remove the “family health history” certification criterion and reserve § 170.315(a)(12). 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). This certification criterion is not included in the Base EHR definition but is included in the CEHRT definitions established by CMS for the Medicare Promoting Interoperability Program (42 CFR 495.4) and the MIPS Promoting Interoperability performance category (42 CFR 414.1305). We adopted the family health history certification criterion in the 2015 Edition Final Rule as a revised iteration of the 2014 Edition family health history certification criterion adopted in § 170.314(a)(13) (80 FR 62624). In the 2014 Edition Proposed Rule, we proposed the first iteration of the family health history certification criterion to align with a Meaningful Use Stage 2 proposal (77 FR 13838). We solicited comment on whether we should adopt the HL7 Pedigree standard and/or the Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT® U.S. Edition) terms for familial conditions. We also sought comment on a tool produced by the HHS Office of the Surgeon General for capturing family health histories. In the 2014 Edition Final Rule, we finalized a certification criterion that required, at a minimum, that health IT must enable a user to record, change, and access information about a patient's first degree relative within the said patient's record (see also 77 FR 54174). We also finalized that health IT certified to § 170.314(a)(13) could meet this certification criterion by either being able to capture a patient's family health history in SNOMED CT® U.S. Edition or in the HL7 Pedigree standard. We noted that because the use of SNOMED CT® U.S. Edition was required for meeting several other certification criteria, it would not be a challenge to meet the certification criterion. In the 2015 Edition Proposed Rule, we proposed two separate certification criteria for family health history—one based on functionality according to the SNOMED CT® U.S. Edition standard and one based on functionality according to the HL7 Pedigree standard (80 FR 16822 through 16823). However, we only adopted the family health history certification criterion (§ 170.315(a)(12)) based on SNOMED CT® U.S. Edition, stating that the functionality should be available to providers for more comprehensive patient care (80 FR 62624). In light of our overall deregulatory approach, we have determined that we should remove the family health history certification criterion in § 170.315(a)(12). The functionality of this certification criterion has been part of the Certification Program and associated with the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category (including prior iterations such as the EHR Incentives Programs and the CEHRT definitions) for over 12 years. As such, the functionality is embedded in certified health IT and has been widely adopted by hospitals and physicians due to participation in those programs. 16 Further, similar to what we stated when we adopted the certification criterion, the ability to code to SNOMED® CT U.S. Edition (including the entire adopted version) is required to meet many of the remaining certification criteria, including those referencing the USCDI v3 and those criteria that would include the proposed USCDI v3.1 standard. 17 These certification criteria included criteria that are in the Base EHR definition and not proposed for removal in this proposed rule. Therefore, we expect that many developers of certified health IT will still conform to the SNOMED CT® U.S. Edition and the functionality to code family health history with SNOMED CT® U.S. Edition will remain in certified health IT adopted by hospitals and physicians. Moreover, USCDI v6 includes a new Family Health History data element. 18 We note that health IT developers can use the SVAP to voluntarily implement and become certified using the most recent National Coordinator-approved version of USCDI without waiting for ASTP/ONC to require that newer version via rulemaking (85 FR 25669). While USCDI v6 has not been adopted in regulation at this time, our expectations, as with every prior version of USCDI, are that USCDI v6 would go through the SVAP approval process and be approved for SVAP certification in 2026. 16 *https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.* 17 We discuss USCDI v3.1 in section III.B.1. 18 *https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6.* As noted above, the family health history certification criterion in § 170.315(a)(12) is included in the CEHRT definitions. Therefore, to provide sufficient time for CMS to update the CEHRT definitions to remove reference to the certification criterion, we propose a January 1, 2027, effective date for the removal of this certification criterion. We welcome comments on these proposals. d. Implantable Device List We propose to remove and reserve the “implantable device list” certification criterion in § 170.315(a)(14). The implantable device list 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. However, the implantable device list certification criterion is included in the Base EHR definition, and we propose a conforming revision in § 170.102 to remove § 170.315(a)(14) from the Base EHR definition (please see section III.C.1 of this proposed rule). In the 2015 Edition Final Rule, we adopted § 170.315(a)(14) with the purpose of establishing a baseline functionality to support the exchange and use of UDIs in certified health IT (80 FR 62748). We explained that the need to exchange and have access to this information wherever patients seek care is broadly relevant to all clinical users of health IT, regardless of setting or specialty, so that they may know what devices their patients are using (or have used) and thereby prevent device-related adverse events and deliver safe and effective care (80 FR 62625 through 62627). We also stated that this need is most acute for implantable devices, which by their nature are difficult to detect and identify in the absence of reliable clinical documentation. We acknowledged the challenges of fully implementing UDIs in health IT in the 2015 Edition Final Rule, yet believed our adoption of the certification criterion, as well as including the certification criterion in the 2015 Base EHR definition and a UDI data element in the 2015 CCDS definition, were important steps to support electronic exchange and use of UDIs (80 FR 62625 through 62626). In responding to comments on the 2015 Edition Proposed Rule, we recognized that fully implementing UDIs in health IT will take time and require addressing a number of challenges, so we adopted a certification criterion that focused narrowly on baseline health IT capabilities that developers could feasibly implement. We stated that these capabilities would provide the foundation for broader adoption and more advanced capabilities and use cases. This approach minimized the potential burden while maximizing the impact of this certification criterion for all stakeholders. We have reviewed the implantable device list certification criterion in § 170.315(a)(14) and, as explained below, have determined that we have achieved our policy goals associated with the exchange and use of UDIs. In consideration of this outcome and our overall regulatory goals to reduce burden and offer flexibility to both health IT developers and health care providers, we propose to remove the implantable device list certification criterion and reserve § 170.315(a)(14). First, we have achieved our stated policy goal of broad adoption of § 170.315(a)(14). As we explained in prior rulemakings, we believe in a foundational approach as the first step to broader adoption of health IT capabilities (80 FR 16824, 80 FR 62626). We added the implantable device list certification criterion to the 2015 Edition Base EHR definition in the 2015 Edition Final Rule. The Base EHR definition (2015 Edition and subsequent versions) is part of the CEHRT definitions under the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. 19 As such, health care providers participating in these programs are required to adopt health IT certified to the implantable device list certification criterion. As discussed earlier in this preamble, survey data indicates widespread adoption by hospitals and physicians of certified health IT products meeting the Base EHR definition, which includes Health IT Modules certified to the implantable device list certification criterion. 20 The widespread adoption of the implantable device list functionality is now well-established in health IT products, and we do not believe that removing the certification criterion from the Certification Program will result in health IT developers removing the functionality from their products, which would likely be both a costly endeavor and counter to the interests of their customers ( *i.e.,* hospitals and physicians). 19 42 CFR 495.4 and 42 CFR 414.130. 20 *https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.* Second, our proposed removal of the implantable device list certification criterion would reduce burden and costs. We have historically, where feasible and appropriate, taken measures to reduce burden within the Certification Program and make the Certification Program more effective, flexible, and streamlined. We believe our proposal to remove the implantable device list certification criterion would result in reduced burden, increased flexibility, and cost savings. Developers of certified heath IT would have the flexibility to implement those functionalities supporting the exchange and use of UDIs that best meet the needs of their clients without additional regulatory burden, which could also lead to innovations in these and related functionalities. Third, support for UDIs within certified health IT is incorporated into other Certification Program elements besides the implantable device list certification criterion. For example, UDIs are a required data element in USCDI v3, and the proposed USCDI v3.1 standard, as the “Unique Device Identifier(s) for a patient's implantable device(s)” data element. We believe retaining a functional data capture certification criterion that requires the same information as the USCDI v3 standard supports (as part of key criteria enabling health information exchange) would be duplicative and unnecessary (we refer readers to section III.B.1 of this proposed rule for a discussion on the proposed USCDI v3.1). We also note that in USCDI v6, published in July 2025, we adopted a significantly modified definition of the UDI data element to include non-implantable devices. 21 Health IT developers can use SVAP to voluntarily implement and become certified using the most recent National Coordinator-approved version of USCDI without waiting for ONC to require that newer version via rulemaking (85 FR 25669). While USCDI v6 has not been adopted in regulation at this time, our expectations, as with every prior version of USCDI, are that USCDI v6 would go through the SVAP approval process and be approved for SVAP certification in 2026. 21 *https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6.* Therefore, we believe that some health IT developers may choose to voluntarily update relevant certified Health IT Modules to utilize USCDI v6 with the modified definition of the UDI data element. Such actions would provide for new data exchange capabilities to expand beyond the baseline functionality in § 170.315(a)(14). This proposal, if finalized, would be effective as of the effective date of a subsequent final rule. We welcome comments on this proposal. 2. Care Coordination Certification Criteria a. Transitions of Care We propose to revise the “transitions of care” certification criterion in § 170.315(b)(1) to simplify its requirements, with an effective date of January 1, 2027. We propose to reduce the scope of the criterion to focus on enabling the receipt of a Consolidated CDA (C-CDA) document as a way to position this criterion for a future evolution to receipt of FHIR-formatted data. The transitions of care criterion supports the structured transition of care summaries and referral summaries that help ensure continuity and care coordination as patients move between providers. In the 2014 Edition Final Rule, we finalized adoption of the C-CDA standard for this criterion because it accommodated formatting of a summary care record that included all of the data elements that CMS proposed be available for inclusion in a summary care record (77 FR 54217). We also stressed that an EHR technology's ability to incorporate data for medications, medication allergies, and problems in structured form from a C-CDA document was the minimum necessary to meet this certification criterion and encouraged EHR technology developers to go beyond this minimum (77 FR 54219). Additionally, in the 2014 Edition Final Rule we included § 170.315(b)(1) in the Base EHR definition (77 FR 54265). In the Cures Act Final Rule, we updated the transitions of care criterion's data requirements to include USCDI v1 (85 FR 25667), and in the HTI-1 Final Rule we updated the data requirements to include USCDI v3 (89 FR 1298). We note that the certification criterion in § 170.315(b)(1) is currently associated with several measures under the Health Information Exchange Objective of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. Specifically, the certification criterion in § 170.315(b)(1) is specified as required for the Support Electronic Referral Loops by Sending Health Information and Support Electronic Referral Loops by Receiving and Reconciling Health Information measures and specified as an example of a criterion that may be used to support the actions of the Health Information Exchange
(HIE)Bi-directional Exchange and Enabling Exchange under TEFCA measures. 22 22 *See* the “Medicare and Medicaid Programs; CY 2026 Payment Policies Under the Physician Fee Schedule and Other Changes to Part B Payment and Coverage Policies; Medicare Shared Savings Program Requirements; and Medicare Prescription Drug Inflation Rebate Program” (CY 2026 PFS) Proposed Rule (90 FR 32352) Table 62, available at *https://www.federalregister.gov/d/2025-13271/p-3055andtheFY2026IPPS/LTCH* PPS Final Rule (90 FR 36536) Table X.F.-05 available at *https://www.federalregister.gov/d/2025-14681/p-4161.* We have reviewed and evaluated the transitions of care certification criterion in § 170.315(b)(1) in order to identify ways to reduce burden while still supporting our policy goals. As we noted in the S&CC January 2010 Interim Final Rule, we take an iterative approach to addressing the interoperability of health IT and consider factors such as maturity, market prevalence, and complexity of implementation to inform our adoption of standards and certification criteria (75 FR 2020). Our approach then and now is intended to be “pragmatic, but forward looking” and involves sustainable and incremental steps to harmonize current and future standards, as well as phase out standards and certification criteria when needed (75 FR 2021). Several industry trends have led us to propose revising this certification criterion. First, FHIR supports the functionalities of a contemporary web-based architecture, using technologies such as RESTful APIs, JSON, and XML, making the standard more approachable to software developers and enabling easier integration with web-based and mobile applications than the C-CDA standard. Second, FHIR is a more granular data standard, enabling exchange of more discrete data concepts rather than entire documents. C-CDA is a document-centric standard that does not support retrieval of information at the data element level, which can lead to information overload during transitions of care. Finally, we believe that FHIR supports easier scalability to support real-time data exchange, which will support a broader ecosystem of health IT tools than C-CDA. Various capabilities, such as CDS Hooks, Subscriptions, and SMART Health Links, support new interoperability paradigms that are much more difficult to do using C-CDA. These trends notwithstanding, we remain cognizant that the C-CDA standard is widely adopted, and we anticipate its continued use over the near-term, especially for transitions of care among health care delivery settings, such as in-patient and long-term and post-acute care. In detail, we propose to revise the transitions of care certification criterion in § 170.315(b)(1) as of January 1, 2027. We propose 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 propose to remove the requirements in § 170.315(b)(1)(ii)(B) and (C). We also propose 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 propose to remove the references to § 170.205(a)(3) and to replace the references to § 170.205(a)(5), which expires on January 1, 2026, with references to § 170.205(a)(6). We welcome feedback on these proposals. b. Clinical Information Reconciliation and Incorporation We propose to remove the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) with an effective date of January 1, 2027, and to reserve that section. The clinical information reconciliation and incorporation
(CIRI)certification criterion allows health care providers to reconcile and incorporate patient health information sent from external sources to maintain a more accurate and up-to-date patient record. The CIRI certification criterion is not currently included in the Base EHR definition; however, the criterion is required for the Support Electronic Referral Loops by Receiving and Reconciling Health Information measure and specified as an example of a criterion that may be used to support the actions of the HIE Bi-Directional Exchange and Enabling Exchange under TEFCA measures in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. 23 23 *See* the CY 2026 PFS Proposed Rule Table 62, available at *https://www.federalregister.gov/d/2025-13271/p-3055andtheFY2026IPPS/LTCH* PPS Final Rule Table X.F.-05 available at *https://www.federalregister.gov/d/2025-14681/p-4161.* Our requirements for CIRI in the Certification Program were first established in the S&CC January 2010 Interim Final Rule to enable a user to electronically complete medication reconciliation of two or more medication lists (75 FR 2046). In the 2011 Edition Final Rule, we revised the certification criterion to require that Certified EHR Technology be capable of providing a user with the ability to electronically compare two or more medication lists (75 FR 44613). We expanded these requirements in the 2014 Edition Final Rule to require clinical information reconciliation for problems, medications, and medication allergies (77 FR 54289). In the 2014 Edition Release 2 Final Rule, we added incorporation requirements and adopted the updated CIRI certification criterion as an optional 2014 Edition certification criterion in § 170.314(b)(9) (79 FR 54438). In the 2015 Edition Final Rule, we finalized a revised 2015 Edition CIRI certification criterion in § 170.315(b)(2) (80 FR 62749), and we updated the related C-CDA standards for the certification criterion in § 170.315(b)(2) in both the Cures Act Final Rule (85 FR 25677) and the HTI-1 Final Rule (89 FR 1224). We have reviewed and evaluated the CIRI certification criterion in § 170.315(b)(2), seeking to identify ways to reduce burden while still supporting our policy goals. As we have stressed in prior rulemaking, we take an incremental approach to improving health IT interoperability and performance, relying on factors such as market prevalence and industry readiness to harmonize current and future standards and phase out standards and certification criteria as needed (75 FR 2020). Our review of industry adoption of the CIRI certification criterion indicates widespread adoption. Review also indicates that its capabilities are widely implemented and used in health IT at this time and thus not likely to go away as supported capabilities by developers of certified health IT solely on the basis of removal of the criterion from the Certification Program 24 (see section III.A for a discussion on “widely adopted” and “widely implemented”). We also have seen indications that removing the certification criterion from the Certification Program could spur greater development and innovation in this area. In conversations with developers and implementers, we have seen technology that innovates on CIRI, providing functionality beyond Certification Program requirements that supports direct incorporation of information received from trusted sources. 24 Real World Testing results (accessible via *https://chpl.healthit.gov/* ) for 2024 from three large EHR developers with significant market share in the United States attest to routine clinician use of Clinical Information Reconciliation and Incorporation (§ 170.315(b)(2)): Epic customers reconciled 66 million medications, 7 million allergies, and 40 million problems out of 135 million transition of care CCDs received; Oracle Health clinicians added ~491 k and rejected 2.69 million external medications per month, evidencing active review; and MEDITECH's Expanse product processed 17 million CCD Retrieve Document Set exchanges with a 99.67% success rate. Given that Epic, Oracle (Cerner), and MEDITECH together provide the majority of EHR systems used in the U.S., these findings indicate that CIRI capabilities are broadly adopted and meaningfully used in clinical care. We have concluded that removing the CIRI certification criterion in § 170.315(b)(2) would reduce burden for health IT developers, such as testing and other burden associated with certification to this criterion, while still allowing ASTP/ONC to achieve our policy goals of supporting interoperability and access to quality EHI at the point of care. Additionally, we believe that removing this C-CDA-based certification criterion from the Certification Program would encourage movement toward FHIR-based standards which can further spur innovation and development in this area, improving interoperability and patient care. Because the certification criterion in § 170.315(b)(2) is a requirement for Promoting Interoperability measures, we believe a transition date for removal is needed. We propose a January 1, 2027, effective date for the removal of the CIRI certification criterion in § 170.315(b)(2). We welcome feedback on these proposals. c. Security Tags—Summary of Care We propose to remove the “security tags—summary of care—send” certification criterion in § 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 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 definition. The certification criteria in § 170.315(b)(7) and (b)(8) were originally adopted in the 2015 Edition Final Rule as “data segmentation for privacy”
(DS4P)certification criteria and only required security tagging of C-CDA documents at the document level (80 FR 62646 and 62647). In the Cures Act Final Rule, we updated the requirements to support security tagging of C-CDA documents at the document, section, and entry levels (85 FR 25646). We have reviewed the security tags—summary of care—send certification criterion in § 170.315(b)(7) and the security tags—summary of care—receive certification criterion in § 170.315(b)(8), evaluating how to reduce burden while still addressing policy priorities to support privacy protections in information exchange. As we have stated previously in this proposed rule, we consider factors such as market prevalence and the uptake in implementation of criteria by developers of health IT when making revisions to Certification Program certification criteria. Currently, 35 unique Health IT Modules are certified to the criterion in § 170.315(b)(7), and 36 unique Health IT Modules are certified to the criterion in § 170.315(b)(8), out of a total of 707 active and non-suspended certifications listed on the Certified Health IT Product List (CHPL), a comprehensive listing of all certified health IT successfully tested and certified under the Certification Program. 25 We believe that in this case the low number of Health IT Modules certified to these criteria indicate that the criteria may not be of sufficient value to health IT developers to warrant continued inclusion in the Certification Program. Additionally, as the industry moves toward greater use of FHIR-based standards, the removal of these C-CDA-based criteria in the Certification Program would help spur further innovation and advancement in this area. 25 *https://chpl.healthit.gov/* search conducted June 2025. We have concluded that removing the certification criteria in § 170.315(b)(7) and
(8)would reduce burden for health IT developers and health care providers while still supporting our policy goals to support privacy protections in information exchange. We propose to remove the security tags—summary of care—send certification criterion in § 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 a final rule. We welcome feedback on these proposals. d. Care Plan We propose to remove the “care plan” certification criterion in § 170.315(b)(9) and reserve that section. This criterion helps improve coordination of care by providing a structured format for documenting patient information such as goals, health concerns, health status evaluations, and interventions. The criterion is not currently included in the Base EHR definition. The certification criterion in § 170.315(b)(9) was first adopted in the 2015 Edition Final Rule and required a Health IT Module to enable a user to record, change, access, create, and receive care plan information in accordance with the C-CDA Release 2.1 standard in § 170.205(a)(4) (80 FR 62648). We updated the criterion in the Cures Act Final Rule to also require the HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 standard in § 170.205(a)(5) (85 FR 25943). In the HTI-1 Final Rule, we updated the criterion to require the HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 standard in § 170.205(a)(5) for the time period up to and including December 31, 2025, or the C-CDA Companion Guide Release 4.1 standard in § 170.205(a)(6) (89 FR 1224). We have evaluated the care plan certification criterion in § 170.315(b)(9) with a goal of reducing burden on health IT developers and health care providers while still achieving our policy priorities. Currently, 54 unique Health IT Modules are certified to the criterion in § 170.315(b)(9) out of a total of 707 active and non-suspended certifications listed on the CHPL. We believe this may indicate low interest by health IT developers in certifying to this criterion. 26 As discussed previously in this proposed rule, the industry is moving away from C-CDA-based standards to the use of FHIR-based standards that offer greater flexibility and potential for innovation. ASTP/ONC recently highlighted the development of FHIR-based care plan IGs, including the Multiple Chronic Condition eCare Plan and the Electronic Long Term Services & Support Care Plan IGs, in a January 2025 standards bulletin. 27 Additionally, input from industry has indicated that the care plan document type is less frequently adopted than other C-CDA document types, and where it is utilized, health IT developers are not likely to cease supporting the functionality if the criterion is removed from the Certification Program. 26 *https://chpl.healthit.gov/* search conducted June 2025. 27 *https://www.healthit.gov/topic/standardsbulletin_25-1.* We have concluded that removing the certification criterion in § 170.315(b)(9) would reduce burden for health IT developers and health care providers while still supporting our goals. Additionally, as discussed previously, moving away from C-CDA-based requirements in the Certification Program would help promote greater innovation and advancement in this area. We propose to remove the care plan certification criterion in § 170.315(b)(9) as of the effective date of a final rule. We welcome feedback on these proposals. e. Decision Support Interventions We propose to revise the “decision support interventions”
(DSI)certification criterion in § 170.315(b)(11). The DSI certification criterion ensures that users can leverage health IT for clinical decision-making by supporting their selection of both evidence-based and predictive DSIs and enabling users' access to transparent information on DSI performance and quality. In the HTI-1 Final Rule, we adopted the DSI certification criterion in § 170.315(b)(11) as both an update and replacement criterion for the CDS certification criterion in § 170.315(a)(9) (89 FR 1236). We also added § 170.315(b)(11) to the Base EHR definition in the HTI-1 Final Rule (89 FR 1197). When we finalized the DSI certification criterion in the HTI-1 Final Rule, we cited E.O. 14091 on Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government (February 16, 2023), which addressed bias in AI, and E.O. 14110 on Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence (October 30, 2023), which addressed the risks of AI (89 FR 1232). These EOs were revoked in E.O. 14148 on Initial Rescissions of Harmful Executive Orders and Actions (January 20, 2025). We have reviewed and evaluated the DSI certification criterion in § 170.315(b)(11), focusing on ways to reduce burden while still supporting our policy priorities. As we have noted previously in this proposed rule and in prior rulemakings, we consider factors such as standards maturity, market adoption, and complexity of implementation when adopting, revising, or phasing out standards and certification criteria (75 FR 2020). Currently, the requirements in § 170.315(b)(11) reference data expressed in the USCDI standards in § 170.213. We have received feedback from developers of certified health IT that requiring support of predictive DSIs that use *any* data element in one of the USCDI standards in § 170.213 has proven burdensome and costly to implement, with questionable value. While many USCDI data elements are routinely used in decision support and would be important inputs to predictive DSI, other USCDI data elements, such as phone number and phone number type data elements, are not likely to be used as inputs. We propose to revise the DSI certification criterion in § 170.315(b)(11) as detailed below as of the effective date of a subsequent final rule. We propose 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). As described above in section III.A.2.b, we propose to remove § 170.315(b)(2), which is a C-CDA-based criterion, from the Certification Program completely as of January 1, 2027. Thus, we propose to remove the requirement in § 170.315(b)(11)(ii)(B), which references § 170.315(b)(2), as well. We also propose to redesignate the certification criterion currently in § 170.315(b)(11)(ii)(C) as § 170.315(b)(11)(ii)(B). We propose to remove the parenthetical reference in § 170.315(b)(11)(iii) to “drug-drug and drug-allergy contraindication checking” upon the effective date of a final rule. We have retained the “drug-drug, drug-allergy interaction checks for CPOE” certification criterion in § 170.315(a)(4), and in order to simplify overall Certification Program requirements, we do not believe it is necessary to reference this capability as part of decision support functionality in § 170.315(b)(11)(iii). We note that this reference was initially included as part of the revisions made to the Certification Program's decision support certification criterion (then referenced in § 170.314(a)(8)) in 2012 (see 77 FR 54215). Since this time, the Certification Program has taken deliberate actions to support a more modular marketplace for health IT (see 84 FR 7428, 89 FR 63567 through 63568, and 90 FR 37158). Removal of this specified capability within § 170.315(b)(11) to support drug-drug and drug-allergy contraindication checking furthers this goal of modularity without precluding support for such interaction checks, due to the retention of requirements in § 170.315(b)(11)(iii)(A)( *2* ) and ( *3* ) regarding enabling evidence-based DSIs that include “Medications” and “Allergies and Intolerances,” respectively, as data types. Additionally, we propose 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. While we originally wanted to apply the requirements of this certification criterion to any data expressed in the standards in § 170.213 in order to reflect our focus on the USCDI and the variety of data for which DSIs may be enabled, we believe a number of USCDI data elements are not likely to be used as inputs, as mentioned above. We believe that revising the requirements to focus on fewer data elements would significantly reduce burden for health IT developers without diminishing users' ability to select ( *i.e.,* activate) a wide variety of predictive DSIs that use remaining USCDI data elements as inputs. Finally, we propose to remove the requirements in § 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. In addition to reducing burden, removal of these requirements would comply with E.O. 14179 on Removing Barriers to American Leadership in Artificial Intelligence (January 23, 2025). E.O. 14179 calls for the review of regulations and other actions taken pursuant to revoked E.O. 14110, and any actions taken that are inconsistent with the policy set forth in E.O. 14179 to “sustain and enhance America's global AI dominance in order to promote human flourishing, economic competitiveness, and national security” 28 shall be suspended, revised, or rescinded as appropriate and consistent with applicable law. 29 Despite proposing source attribute information transparency and intervention risk management more than six months prior to issuance of E.O. 14110, 30 we note that many of our fundamental assumptions and objectives were aligned with the stated goals of E.O. 14110 to advance “safe, secure, and trustworthy development and use of artificial intelligence.” 28 *https://www.federalregister.gov/d/2025-02172/p-3.* 29 **Federal Register** : Removing Barriers to American Leadership in Artificial Intelligence (90 FR 8741). 30 *https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and.* Additionally, we note several factors supporting the proposal to modify the DSI certification criterion. First, developers of certified health IT have reported that during care delivery, most clinical users lack the time or technical background to engage with source attribute information for either evidence-based DSIs or predictive DSIs supplied by the developer of certified health IT. 31 Despite having access to source attribute information since the beginning of 2025, when Health IT Modules certified to § 170.315(b)(11) began to be first deployed, we have no publicly available evidence indicating that a single doctor, nurse, or administrator has accessed, recorded, or modified a single source attribute. Further, we have no publicly available evidence that transparency requirements in § 170.315(b)(11) have led to positive impacts on patient care, such as removing deficient or untested algorithms, or testing a deployed algorithm on local data. We believe that the underlying assumption that source attribute information would be valuable to health care delivery organizations and health care professionals when deciding whether to implement or use a DSI (as stated in the HTI-1 Final Rule) 32 was incorrect. 31 *See* letter to Acting Assistant Secretary for Technology Policy, Acting National Coordinator for Health Information Technology Posnack, April 16, 20215: *https://www.ehra.org/sites/ehra.org/files/EHR%20Association%20Letter%20to%20ASTP-ONC%20-%20Certification%20Program%20Deregulatory%20Suggestions.pdf#page=7.* 32 *See* 88 FR 23780 at *https://www.federalregister.gov/d/2023-07229/p-547.* Second, transparency regarding how a predictive or generative AI application was designed, developed, tested, evaluated, and should be used may not have the savings and benefits we anticipated. As described in the regulatory impact analysis
(RIA)to the HTI-1 Final Rule, we estimated considerable benefits from this policy (89 FR 1411), noting that transparency into AI applications would result in health care delivery organizations selecting and using more accurate AI applications. We quantified associated benefits for two illustrative cases, sepsis detection and ambulatory care sensitive admissions (89 FR 1412 through 1414), estimating that our policies would result in a 10-year savings of up to $3 billion for the sepsis use case through increased application of more sensitive predictive models for this condition. We have not encountered supporting evidence or published research indicating that source attribute transparency requirements in § 170.315(b)(11)(iv) have improved health care delivery organizations' evaluation and effective use of AI. We understand that the benefits articulated in the HTI-1 Final Rule impact analysis are not being realized. Third, developers of certified health IT have reported an inconsistent approach to oversight of other parties producing similar, health-based AI systems. 33 They note that “[t]he current model of imposing rigorous requirements [( *i.e.,* algorithmic transparency and risk management)] on certified health IT but not the many other tech companies working in this space is simply unacceptable and needs to be remedied.” 34 While we attempted to encourage more consistent and ubiquitous transparency requirements across similar applications in our April 2023 proposals for predictive DSI in the HTI-1 Proposed Rule (88 FR 23782), and have worked with federal partners on alignment with similar policy objectives since finalization of the HTI-1 Final Rule in January 2024, 35 36 we acknowledge that our authorities have limitations that inhibit our collective efforts to treat similar technologies similarly under a single Department-wide policy. 33 *https://www.ehra.org/sites/ehra.org/files/EHR%20Association%20Letter%20to%20ASTP-ONC%20-%20Certification%20Program%20Deregulatory%20Suggestions.pdf#page=7.* 34 Ibid. 35 *See* 89 FR 1264 for discussion of alignment with FDA policies. 36 *See* 89 FR 37643 for discussion of alignment with OCR policies. Finally, in order to promote innovation of AI in health care, we propose to remove transparency and risk management requirements established in the HTI-1 Final Rule. Additionally, we have heard from health IT developers that the requirements are burdensome and detrimental to such innovation and growth, which is the opposite of our stated policy intent to optimize the ubiquitous use of high-quality AI in health care. For these and the aforementioned reasons, we propose to remove all requirements related to source attributes in § 170.315(b)(11)(iv), their access in § 170.315(b)(11)(v)(A), and their modification in § 170.315(b)(11)(v)(B), as well as requirements to manage risks related to the development and deployment of predictive DSIs supplied by health IT developers as part of their product in § 170.315(b)(11)(vi). We welcome comments on these proposals. 3. Clinical Quality Measures Certification Criteria a. Clinical Quality Measures—Report We propose to revise the “clinical quality measures—report” certification criterion in § 170.315(c)(3) as of the effective date of a final rule. We propose to remove the requirement in § 170.315(c)(3)(ii), as this provision may no longer be used to support certification to the criterion. In the Cures Act Interim Final Rule, we revised § 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 in § 170.205(k)(1) and (2), for the period before December 31, 2022 (85 FR 70075, 70083). We propose to remove paragraph § 170.315(c)(3)(ii) because that transition time period has elapsed. We also propose to move the requirements in § 170.315(c)(3)(i) to § 170.315(c)(3), thus removing all subparagraphs and including all criterion requirements in the main paragraph for § 170.315(c)(3). We welcome comments on our proposal. b. Clinical Quality Measures—Filter We propose to remove the “clinical quality measures—filter” certification criterion in § 170.315(c)(4) with an effective date of January 1, 2027. This certification criterion assesses whether a Health IT Module can filter quality data based on a set of standardized data elements for electronic clinical quality measures
(eCQM)calculated using certified health IT. In the Voluntary Edition Proposed Rule, we proposed a new certification criterion in § 170.315(c)(4) that would require health IT to record structured data allowing CQM results to be grouped by patient characteristics (79 FR 10903 and 10904). 37 We proposed this capability to support eCQM reporting by group practice or accountable care organization (ACO). We also proposed capturing patient characteristics that support identification of health disparities, that help providers identify gaps in quality, and that support delivery of specialized care to needful patient subgroups. We did not adopt this certification criterion in the 2014 Edition Release 2 Final Rule as we received comments recommending refinement of the use cases and performance of more analysis on which data elements are being captured in standardized ways (79 FR 54462). 37 Practice site and address; Tax Identification Number (TIN), National Provider Identifier (NPI), and TIN/NPI combination; diagnosis; primary and secondary health insurance, including identification of Medicare and Medicaid dual eligible; demographics including age, sex, preferred language, education level, and socioeconomic status. In the 2015 Edition Proposed Rule (80 FR 16844) we proposed to add § 170.315(c)(4) as a new certification criterion for CQM filtering based on the rationale that health IT should support an organization's ability to filter individual and aggregate eCQM results in ways that support administrative reporting, identification of health disparities, and identification of gaps in care. In the 2015 Edition Final Rule, we adopted the “CQMs—filter” certification criterion in § 170.315(c)(4), along with three other CQM certification criteria: “CQMs—record and export” (§ 170.315(c)(1)), “CQMs—import and calculate” (§ 170.315(c)(2)), and “CQMs—report” (§ 170.315(c)(3)) (80 FR 62649 through 62655). Together, these four criteria were adopted to support providers' quality improvement activities and to support reporting to programs such as the EHR Incentive Programs, Quality Payment Program, and Comprehensive Primary Care plus initiative. The 2015 Edition Final Rule adopted § 170.315(c)(4) as a new 2015 Edition certification criterion that supports the capability of a clinician to filter eCQM results using data captured for quality improvement and quality reporting purposes. We finalized that Health IT Modules certified to § 170.315(c)(4) must be able to: record data and filter CQM results at both patient and aggregate levels; filter by any combination of the data elements established as part of the criterion with associated vocabulary standards; create a data file of the filtered data in accordance with the QRDA Category I and Category III standards; and display the filtered data in a human readable format. This certification criterion is not included in the Base EHR definition in § 170.102 but is included in the CEHRT definition for MIPS in 42 CFR 414.1305 as an optional criterion. While we recognize the value of this functionality, we propose to remove this criterion for multiple reasons. We reviewed and evaluated existing regulations to identify deregulatory actions that would reduce administrative burden, and the private expenditures required for compliance with federal regulations. We have identified that the administrative costs of certification for the CQMs—filter certification criterion are no longer offset by the benefits of advancing the specific functionality supported by the criterion. Further, we do not believe that quality measure filtering functionality would be removed from health IT systems because of our proposal to remove this criterion. Quality reporting programs, such as those required by states and CMS programs, require broader supplemental data and capabilities beyond what we currently require for certification. In addition, health IT developers have widely implemented technology solutions that expand beyond the baseline requirements of the certification criterion (see section III.A for a discussion on “widely implemented”). Through listening sessions with a wide range of health care provider types and sites of service, public correspondence, and CHPL data, we understand that the use of the CQMs—filter certified functionality is fairly low relative to the other certification criteria that support clinical quality measure capabilities. According to CHPL data, as of August 2025, there are 340 active Health IT Modules certified to § 170.315(c)(1), (2), or (3), but only 71 active Health IT Modules certified to § 170.315(c)(4). Among the feedback we have received, health care providers participating in CMS alternative payment models, as well as health IT developers supporting quality initiatives, have reported that they have different options to filter eCQM results, including using customized systems and/or the support of third parties to support innovative, specialty-specific quality measurement and reporting tailored to their particular needs. We therefore believe the value of maintaining this certification criterion is minimal as health IT developer time and resources would be better spent on quality data system modernization efforts leveraging FHIR-based APIs for quality data exchange. We therefore propose to remove the certification criterion in § 170.315(c)(4) as of January 1, 2027. 4. Privacy and Security Certification Criteria We propose to remove all the privacy and security certification criteria in § 170.315(d) and the associated Privacy and Security Certification Framework under § 170.550(h) as of the effective date of a subsequent final rule. We first adopted a version of the privacy and security certification criteria currently found in § 170.315(d) (and associated standards) in the 2011 Edition through an interim final rule (75 FR 2033 through 2035). These certification criteria originated from HIT Policy Committee and HIT Standards Committee recommendations. The criteria generally focused on basic technical capabilities that could be included in the development of Health IT Modules that would be certified. We used the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule (45 CFR 164 parts 160 and 164, subparts A and C) as the starting point for the Certification Program's privacy and security certification criteria, with the intent of ensuring that Certified EHR Technology (now referred to as “certified health IT”) included at least one capability to assist a HIPAA covered entity with complying with HIPAA Security Rule requirements. The initial criteria also included a certification criterion (“accounting of disclosures”) to support entities regulated under HIPAA that must provide an accounting of disclosures of protected health information 38 made in certain circumstances. 39 We noted, however, that the interim final rule strictly focused on the capabilities of Certified EHR Technology and did not change existing HIPAA Privacy Rule or Security Rule requirements, guarantee compliance with those requirements, or absolve an eligible professional, eligible hospital or other health care provider from having to comply with any applicable provision of the HIPAA Privacy or Security Rules. In addition, we stated that, while the capabilities provided by Certified EHR Technology may assist an eligible professional, eligible hospital in improving their technical safeguards, the use of Certified EHR Technology alone does not equate to compliance with the HIPAA Privacy or Security Rules. We stated that the capabilities provided by Certified EHR Technology do not in any way affect the analysis that an entity regulated by HIPAA is required to perform by 45 CFR 164.306(b) and
(d)(75 FR 2035). 38 45 CFR 160.103 (definition of “protected health information”). 39 42 U.S.C. 17935(c), sec. 13405(c) of the American Recovery and Reinvestment Act of 2009, Public Law 111-5, 123 Stat. 265 (Feb. 17, 2009); 45 CFR 164.528. With the 2014 Edition, we included the privacy and security certification criteria in the Base EHR definition in an attempt to provide both developers and health care providers more flexibility in meeting Certification Program requirements, while still providing health care providers with basic technical options that could support compliance with parts of the HIPAA Privacy and Security Rules (77 FR 54265). Based on recommendations from the HIT Standards Committee, we established a third privacy and security certification approach under § 170.550(h) for the new 2015 Edition so that each certification criterion also had a set of separate privacy and security certification criteria attributed to them that were applicable to the criterion's functionality (80 FR 62705 through 62707). In doing so, we established the current Privacy and Security Certification Framework, which has been in place for the past 10 years. Under this framework, health IT developers have two options for meeting requirements: build the capabilities themselves natively into their certified health IT; or provide system documentation to demonstrate that the certified health IT could integrate (via service interfaces) with required privacy and security capabilities (80 FR 62707). We have come to the conclusion that, despite the Certification Program providing various certification flexibilities and approaches to accommodate the privacy and security certification criteria ( *i.e.,* different approaches for the 2011, 2014 and 2015 Editions), the costs and burden of these Certification Program requirements far exceed their intended purpose and benefits. First, we have found that health IT developers have changed their development processes to build in privacy and security capabilities to meet these certification requirements rather than attempting to demonstrate that their technology could interface with other health IT that provides these capabilities. This has led to negative experiences for health care providers who have sought to use a best-of-breed, non-certified security technology to work across their deployed enterprise ( *e.g.,* a third-party audit log). Second, as certified health IT (which is generally EHR-focused technology) is often implemented in enterprise-wide settings ( *e.g.,* group practices, large health care systems, multi-provider cloud-supported services), such certified health IT cannot in isolation, or independently, provide the necessary privacy and security capabilities for HIPAA Security Rule compliance across all relevant technologies of the enterprise-wide setting. Third, while certified health IT has always been “linked” to the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, those programs have not required participating health care providers to use or implement the privacy and security capabilities included in certified health IT for purposes of meeting the security risk analysis measure. Rather, the health care providers must “have” such certified health IT. As such and as discussed in more detail below, health care providers participating in the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category are required to adopt certified capabilities that they may not use because, for example, they may prefer a non-certified security health IT product to meet their overall security needs under relevant HIPAA Security Rule requirements. Fourth, many stakeholders have overinterpreted the Certification Program's limited scope and policy purpose with respect to health IT security and instead assumed that the Certification Program assessed discrete specific security capabilities at significant depths, such as when and how the capabilities are implemented in health care provider or system settings. For example, stakeholders have expressed incorrect expectations of certified health IT and developers, such as expectations that the Certification Program required health IT developers of certified health IT to implement and conduct penetration testing of certified health IT or ensure that certified authentication and authorization capabilities protect against known or unknown vulnerabilities. In contrast, and to allow for significant scalable deployment flexibility, certified heath IT must only, for example, demonstrate support for basic authentication and role-based access control. Finally, there remains a disconnect between health IT certified to the privacy and security certification criteria under the Certification Program and the implementation and compliance responsibilities of most purchasers and users of certified health IT with the HIPAA Privacy and Security Rule requirements. This disconnect has led to the introduction of unnecessary regulatory burden and duplication, as well as unwarranted opportunity costs for innovation. As we noted above and in our rulemakings related to the privacy and security certification criteria, the adoption of health IT certified to the privacy and security certification criteria does not guarantee compliance with the HIPAA Privacy and Security Rule requirements. Further, the adoption of health IT certified to the privacy and security certification criteria does not serve as an affirmative defense, has not been identified as a mitigating factor in assessing HIPAA civil money penalties, and does not exempt a HIPAA-regulated entity from having to comply with any applicable provision of the HIPAA Privacy or Security Rules. These facts alone have created unnecessary burden for health care providers that adopt certified health IT and health IT developers of certified health IT that also meet the definition of a covered entity or business associate, respectively, and are subject to the HIPAA Privacy and Security Rules. 40 In fact, we have heard from stakeholders both arguing that our certification requirements go beyond the HIPAA Security Rule requirements (75 FR 44619, 80 FR 62707) or do not go far enough in meeting HIPAA Privacy Rule and Security Rule requirements (80 FR 62691, 62706). As such, our Certification Program requirements are diverting financial resources and efforts from innovative, agile, and comprehensive solutions that can address the threats faced by health care providers and meet their regulatory obligations under the HIPAA Privacy and Security Rules. By removing the privacy and security certification requirements under the Certification Program, we will provide health IT developers with the flexibility to innovate in this area and to develop new solutions to address the needs of their customers. Such an approach should also spur competition and give health care providers, including small practices, the opportunity to choose the best privacy and security technologies that fit their needs at the best price versus being forced to accept those capabilities included in certified health IT that may not fit their health information privacy and security needs for various reasons. 40 45 CFR 160.103 (definitions of “covered entity” and “business associate”). We will continue to collaborate with our colleagues in HHS to promote privacy and security and to strengthen the nation's critical health care infrastructure. Equally, we are not completely foregoing the adoption of privacy and security capabilities within the Certification Program. Instead, going forward, we intend to prioritize the adoption of privacy and security capabilities that are fit for purpose, use case specific, and deliver much needed technical consistency in the market when paired with specific conformance requirements. For example, as we pursue more API-focused certification criteria, if the standards and implementation guides adopted for them do not specify or leave optional specific security requirements, we may look to add further constraints ( *e.g.,* multi-factor authentication support). But in all cases, we intend to make security capability conformance a built-in part of a certification criterion's conformance and not the separate and stand-alone conformance assessment that it is today. With this planned approach in mind, we also request comment on an alternative proposal as discussed below. In lieu of removing, on the effective date of a subsequent final rule, all of the privacy and security certification criteria in § 170.315(d) and the associated Privacy and Security Certification Framework under § 170.550(h), we would retain the “auditable events and tamper resistance” (§ 170.315(d)(2)), “audit report(s)” (§ 170.315(d)(2)), and “auditing actions on health information” (§ 170.315(d)(10)) certification criteria and associated Privacy and Security Certification Framework certification requirements. These certification criteria and included functionality may serve to help identify fraud and abuse. The functionality may also support health care provider compliance obligations and investigations by relevant entities, including both civil and criminal matters at the federal and state levels. Identifying and addressing fraud and abuse increases confidence in the nation's health care system, reduces inappropriate and wasteful spending, and protects taxpayer dollars when it comes to government spending on health care. We welcome feedback on these proposals. 5. Patient Engagement Certification Criteria a. View, Download, and Transmit to a 3rd Party We propose to revise the “view, download, and transmit to 3rd party”
(VDT)certification criterion in three ways as described below. These proposed revisions, if finalized, would be effective as of the effective date of a subsequent final rule. We first included the Web Content Accessibility Guidelines (WCAG 2.0) standard as a requirement of the view, download, and transmit to 3rd party
(VDT)certification criterion (§ 170.315(e)(1)) in the 2014 Edition. Specifically, the VDT certification criterion viewing capability required conformance to WCAG Level A (77 FR 54179). This provided an accessibility baseline for health IT certified to the criterion. With the 2015 Edition, we proposed compliance with WCAG Level AA (as we did for the 2014 Edition) but finalized a policy that gave developers the option of demonstrating conformance with either Level A or Level AA to meet the certification requirements (80 FR 62660). We now propose to remove the WCAG conformance requirement from the certification criterion (found in § 170.315(e)(1)(i)). As noted above, the WCAG baseline certification standard of Level A was adopted with the 2014 Edition in 2012 and has been part of the VDT certification criterion since that time. The functionality is now sufficiently widespread among certified health IT and health care providers who adopt such technology. This is true because the VDT certification criterion has been part of the CEHRT definitions and specifically supports the patient access measure under the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category since the 2014 Edition. By removing the WCAG certification requirement, health IT developers of health IT currently certified to § 170.315(e)(1) will have the opportunity to consider other innovative ways to provide patients with the viewing functionality. To this point, commenters noted in response to the 2014 Edition WCAG proposals that most patients want functions and content provided in a more visually appealing manner than the WCAG standard allows. Further, as we noted in the 2011 Edition Interim Final Rule and again in response to comments on the 2011 Edition Interim Final Rule, in providing patients with access to their online health information, the accessibility requirements of the Americans with Disabilities Act of 1990 and Section 504 of the Rehabilitation Act of 1973 still apply to entities covered by these federal civil rights laws (75 FR 2036, 75 FR 44643). In addition, Section 1557 of the Patient Protection and Affordable Care Act (Affordable Care Act) prohibits covered entities from subjecting individuals to certain forms of discrimination, including on the grounds prohibited by Section 504 of the Rehabilitation Act, in any health program or activity. 41 Health IT developers and other health programs or activities who receive Federal financial assistance under the Certification Program or other federal programs likely qualify as covered entities 42 under Section 1557 and would be required to comply with applicable accessibility requirements. Under Section 504 of the Rehabilitation Act, recipients of financial assistance from HHS must conform to certain accessibility requirements, including but not limited to using the WCAG 2.1 AA success criteria for web content and mobile applications, as detailed in 45 CFR 84.82 through 84.89. Additionally, under Section 508 of the Rehabilitation Act (Pub. L. 93-112; Sep. 26, 1973), HHS must ensure the information and communication technology it develops, procures, maintains, or uses, allows comparable access and use for people with disabilities, including by conforming to the success criteria of WCAG 2.0 AA. See 29 U.S.C. 794d; 36 CFR part 1194. As such, we expect health IT developers will continue to meet these requirements and provide the necessary accessibility within their products certified to the VDT certification criterion. 41 *https://www.ecfr.gov/current/title-45/part-92#p-92.4(Health%20program%20or%20activity).* 42 *https://www.ecfr.gov/current/title-45/part-92#p-92.4(Covered%20entity).* We also propose to remove the VDT requirement in § 170.315(e)(1)(ii)(A)( *2* ) to conform with any Network Time Protocol
(NTP)standard for purposes of “date and time each action occurred” under the activity log. In the HTI-1 Final Rule, we revised the requirement from conformance with the Network Time Protocol v4 of the RFC 5905 standard to compliance with *any* Network Time Protocol standard (89 FR 1283; § 170.210(g)). As a result, health IT could be certified by demonstrating that it could use any NTP to synchronize clocks for time accuracy. However, we have received feedback over the years from developers stating that the requirement should not be part of certification because the functionality was not native to the EHR technology (rather part of the operating system within which the EHR technology runs) and was unnecessary for certification because EHRs use of underlying operating system clocks is commonplace (88 FR 23811). Consistent with our overall goal to reduce regulatory burden, we agree that there is currently little value, and unnecessary burden, in maintaining the conformance requirement as part of certification. We do not expect that developers will stop using NTP with their certified health IT. Rather, we expect that developers will continue to use NTPs, such as Microsoft's MS-SNTP, due to ongoing evolution in the industry. We propose to remove and reserve § 170.315(e)(1)(i)(A)( *1* ) because the requirement has an expiration date of December 31, 2025, which expires by the time a subsequent final rule will be issued. Additionally, we similarly propose to revise § 170.315(e)(1)(i)(B)( *1* ) and ( *2* ) to remove references to § 170.205(a)(5) because the standard codified in this paragraph also has an expiration date of December 31, 2025. Finally, we propose to provide a heading for the paragraph at § 170.315(e)(1)(i), which would be “general.” This would align the paragraph with similar level paragraphs that have headings (§ 170.315(e)(1)(ii) and (iii)) and would be compliant with the Office of the Federal Register Drafting Handbook. We welcome comments on these proposals. b. Patient Health Information Capture We propose to remove the “patient health information capture” certification criterion in § 170.315(e)(3) with an effective date of January 1, 2027, and to reserve that section. The patient health information capture certification criterion allows health care providers to incorporate unstructured patient generated health data or data from a non-clinical setting into a patient record. The criterion is not currently included in the Base EHR definition; however, the criterion is included in CEHRT definitions established by CMS for the Medicare Promoting Interoperability Program (42 CFR 495.4) and the MIPS Promoting Interoperability performance category (42 CFR 414.1305). The patient health information capture certification criterion was first adopted in the 2015 Edition Health IT Certification Criteria, 2015 Edition Base Electronic Health Record
(EHR)Definition, and ONC Health IT Certification Program Modifications Final Rule (80 FR 62602). The criterion replaced the § 170.314(a)(17) advance directives and applied to various patient health information documents (80 FR 62661). In the 2015 Edition Final Rule, we stated that a Health IT Module would need to enable a user to:
(1)identify ( *e.g.,* label health information documents as advance directives and birth plans), record (capture and store) and access (ability to examine or review) patient health information documents;
(2)reference and link to patient health information documents; and
(3)record and access information directly and electronically shared by a patient. This criterion was specifically included in the CEHRTdefinition to ensure, at a minimum, providers participating in the EHR Incentive Programs (now the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category) had this capability. The intent of the criterion is to establish at least one means for accepting patient health information directly and electronically from patients in the most flexible manner possible (80 FR 62662). The criterion did not define the types of health information that could be accepted as we believed it should be as broad as possible and could be documents or health information from devices or applications. The devices and applications could include home health or personal health monitoring devices, fitness and nutrition applications, or a variety of other devices and applications. In addition, patient health information could be accepted directly and electronically through a patient portal, an API, or even email (80 FR 62662). As adopted, we anticipated health IT developers would develop innovative and efficient ways to meet this criterion and simultaneously support providers accepting health information from patients. We have reviewed and evaluated the patient health information capture certification criterion in § 170.315(e)(3), seeking to identify ways to reduce burden while still supporting our policy goals. As we have stressed in prior rulemaking, we take an incremental approach to improving health IT interoperability and performance, relying on factors such as market prevalence and industry readiness to harmonize current and future standards and phase out standards and certification criteria as needed (75 FR 2021). Our review of industry adoption of the patient health information capture certification criterion has found that the capabilities described in the criterion are widely implemented (as discussed above in section III.A) and used in health IT at this time, suggesting that these capabilities will remain in health IT products even if the corresponding criterion is removed from the Certification Program. We also have seen indications that removing the criterion from the Certification Program could spur greater development and innovation in this area. We have concluded that removing the patient health information capture certification criterion in § 170.315(e)(3) on January 1, 2027, would reduce administrative burden as well as burden for health IT developers of certified health IT and health care providers while still allowing us to achieve our policy goals. There are other certification criteria that support patient engagement, such as the 2015 Edition view, download, and transmit to 3rd party and “API” certification criteria. We have seen developers integrate the functionality in the patient health information capture certification criterion as part of other patient engagement features, such as patient portals. With these considerations in mind, we believe removing this criterion from the Certification Program will help reduce burden and costs, while also spurring further innovations in patient engagement. Because the certification criterion in § 170.315(e)(3) is a requirement for CEHRT definitions established by CMS, we believe a transition date is needed. Therefore, we propose to remove the patient health information capture certification criterion in § 170.315(e)(3) effective January 1, 2027. We welcome feedback on this proposal. 6. Public Health Certification Criteria a. Transmission to Cancer Registries We propose to remove the “transmission to cancer registries” certification criterion in § 170.315(f)(4) with an effective date of January 1, 2027, and reserve that section. This criterion assesses whether a Health IT Module can properly create and format cancer case information for electronic transmission according to a CDA-based implementation specification for reporting to public health agencies. In the 2014 Edition Final Rule, we expanded the public health-related standards and certification criteria to include a criterion for transmission to cancer registries in § 170.314(f)(6) that we designated as optional for Complete EHR certification (77 FR 54195). We stated that we proposed this criterion to support a new meaningful use objective and measure for reporting cancer cases to cancer registries (77 FR 54194). In the 2015 Edition Final Rule, we finalized a revised transmission to cancer registries criterion in § 170.315(f)(4) which was no longer labeled as optional and required updated standards (80 FR 62666), and in the HTI-1 Final Rule we further updated the associated vocabulary standards (89 FR 1208). The standards currently referenced in the criterion include the Health Level 7 (HL7®) Implementation Guide for CDA® Release 2: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1, April 2015 in § 170.205(i)(2), the SNOMED CT®, U.S. Edition, March 2022 Release in § 170.207(a)(1), and the Logical Observation Identifiers Names and Codes (LOINC®) Database Version 2.72, February 16, 2022 in § 170.207(c)(1). In the Meaningful Use Stage 3 Final Rule, the transmission to cancer registries certification criterion was identified as one of the criteria that eligible professionals could utilize to report the Public Health Registry measure in the EHR Incentive Programs (80 FR 62882). Subsequently, CMS stated that this criterion could be used to report on the Public Health Registry measure that was included in the MIPS Advancing Care Information performance category (later renamed the MIPS Promoting Interoperability performance category) (81 FR 77236). Currently, MIPS eligible clinicians that report on the Public Health Registry measure may earn optional bonus points for submitting this data. 43 43 *See* the CY 2026 PFS Proposed Rule Table 60, available at *https://www.federalregister.gov/d/2025-13271/page-32744.* We have reviewed and evaluated the transmission to cancer registries certification criterion in § 170.315(f)(4), seeking to identify ways to reduce burden while still supporting our policy goals. We recognize trends within the industry that support removal of this criterion. Of note, there is specific work being done to move cancer registry reporting from CDA to FHIR through the Helios FHIR Accelerator and updates to the Central Cancer Registry Reporting IG in support of more efficient tumor abstract completion and supportive harmonization and standardization of data elements through USCDI+ Cancer. 44 Given the movement toward these promising modernization efforts that rely on FHIR rather than CDA, we anticipate health IT developers will find maintaining CDA development support to be both duplicative and a significant burden. 44 *https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/index.html.* We believe that removing the certification criterion in § 170.315(f)(4) would reduce burden and encourage the ongoing evolution in cancer registry reporting by offering health IT developers space to move toward FHIR standards and modern reporting solutions, further encouraging innovation. We propose a January 1, 2027, effective date for the removal of the transmission to cancer registries certification criterion in § 170.315(f)(4). We welcome feedback on these proposals. b. Transmission to Public Health Agencies—Electronic Case Reporting We propose to revise the “transmission to public health agencies—electronic case reporting”
(eCR)certification criterion in § 170.315(f)(5). This criterion enables a user to create case reports that can be transmitted electronically to public health agencies. In the 2015 Edition Final Rule, we included a new certification criterion in § 170.315(f)(5) with functional requirements to support the electronic transmission of case reporting information to public health agencies (80 FR 62667). When we originally proposed this criterion, we highlighted several goals, including linking EHR data with other data in a structured way in order to improve quality, safety, population health, and research, as well as making case reporting from providers to public health agencies more efficient (80 FR 16855). In the 2015 Edition Final Rule, we noted commenter concerns with the proposed standards and recommendations that case reporting continue as a public health reporting option for the EHR Incentive Programs, but without a requirement to use a particular standard (80 FR 62667). We further noted ongoing advancements in FHIR standards and stated that in order to permit flexibility and accommodate evolution, we would not finalize a required standard (80 FR 62667). In the HTI-1 Final Rule, we finalized a policy to require support for either a FHIR or CDA standard in order to provide technical design flexibility while still supporting the existing CDA-based landscape, and we established a transition period from functional requirements to standards-based requirements (89 FR 1227). Specifically, we finalized requirements in § 170.315(f)(5)(ii) to create case reports consistent with either the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA eICR IG in § 170.205(t)(2), and to receive, consume, and process a case report response formatted to either the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA RR IG in § 170.205(t)(3) (89 FR 1227). We stated that we would continue monitoring the development of standards for case reporting, and that as FHIR-based standards advanced we intended to transition solely to a FHIR-based approach for case reporting in future rulemaking (89 FR 1227). We also stated in the HTI-1 Final Rule, in response to comments that technology used by public health agencies may not be able to accept incoming FHIR-based reports, that we understood commenters' “concerns related to performance, scalability, and maintenance, and will monitor standards development and implementation to inform future rulemaking” (89 FR 1229). Consistent with E.O. 14192, ASTP/ONC published the “Electronic Case Reporting Certification Criterion Enforcement Discretion Notice” on July 31, 2025. 45 The enforcement discretion notice stated that for calendar year 2025, ASTP/ONC will not exercise its direct review authority for any non-conformity arising solely from certified health IT not complying with the standards in § 170.315(f)(5) as long as the health IT remains conformant with either § 170.315(f)(5)(i) or with requirements in § 170.315(f)(5)(ii) as specified in the notice. The requirements in § 170.315(f)(5)(ii) specified in the enforcement discretion notice include requirements to: consume and process case reporting trigger codes and identify a reportable patient visit or encounter based on a match with a trigger code value set ( *e.g.,* table); create a case report; receive, consume, and process a case report response; and, transmit a case report electronically to a system capable of receiving a case report. Additionally, the enforcement discretion notice stated that for calendar year 2025, ASTP/ONC will not take any enforcement action against an ONC-ACB for certifying a Health IT Module that is presented for certification to § 170.315(f)(5) where the Health IT Module demonstrates and maintains conformance with § 170.315(f)(5)(i) or the requirements in § 170.315(f)(5)(ii) as specified above. For calendar year 2026, the enforcement discretion notice stated that ASTP/ONC will not exercise its direct review authority for any non-conformity arising solely from certified health IT not complying with the standards in § 170.315(f)(5)(ii) as long as the health IT remains conformant with the requirements in § 170.315(f)(5)(ii) as specified above. The enforcement discretion notice also stated that for calendar year 2026, ASTP/ONC will not take any enforcement action against an ONC-ACB for certifying a Health IT Module that is presented for certification to § 170.315(f)(5) where the Health IT Module demonstrates and maintains conformance to the requirements in § 170.315(f)(5)(ii) as specified above. The enforcement discretion notice stated that it remains in effect until December 31, 2026, or until the Department completes a deregulatory action to revise § 170.315(f)(5). 45 *https://www.healthit.gov/topic/electronic-case-reporting-certification-criterion-enforcement-discretion-notice.* We have reviewed and evaluated the transmission to public health agencies—electronic case reporting certification criterion in § 170.315(f)(5) with a focus on reducing burden while still supporting our policy priorities. We understand from developers of certified health IT that there may be issues with readiness to adopt these standards as well as concerns regarding the performance, scalability, or maintenance of these standards. We also note that the § 170.315(f)(5) certification criterion is required to complete the Electronic Case Reporting measure in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. 46 We note that in the CY 2026 PFS Final Rule, CMS finalized a policy to suppress the measure for performance for MIPS eligible clinicians meeting the requirements of the MIPS Promoting Interoperability performance category for the CY 2025 performance period, and eligible hospitals and CAHs participating in the Medicare Promoting Interoperability Program for the EHR reporting period in CY 2025 (90 FR 49892). 46 *See* the CY 2026 PFS Proposed Rule Table 62, available at *https://www.federalregister.gov/d/2025-13271/p-3055* and the FY2026 IPPS/LTCH PPS Final Rule Table X.F.-05 available at *https://www.federalregister.gov/d/2025-14681/p-4161.* We propose to revise the eCR certification criterion to be a functional requirement in order to reduce burden and allow for industry innovation. In particular, we propose to rescind the expiration date for the functional requirements defined in § 170.315(f)(5) as of the effective date of a subsequent final rule. We propose to revise the introductory text of the criterion to enable a user to create a case report for electronic transmission meeting the functional requirements described in paragraph (f)(5)(i) of this section. Additionally, we propose to remove the standards-based requirements defined in § 170.315(f)(5)(ii) as of the effective date of a subsequent final rule and reserve that section. We welcome feedback on these proposals. c. Transmission to Public Health Agencies—Antimicrobial Use and Resistance Reporting We propose to revise the “transmission to public health agencies—antimicrobial use and resistance reporting” certification criterion in § 170.315(f)(6). This criterion assesses whether Health IT Modules can create and properly format an antimicrobial use and resistance report for electronic transmission, following specified sections of a CDA-based implementation guide. In the 2015 Edition Final Rule, we expanded the public health-related standards and certification criteria to include a new criterion for transmission of antimicrobial use and resistance reporting data to public health registries (80 FR 62668). We stated in the 2015 Edition Final Rule that the antimicrobial use and resistance reporting data is only collected by CDC rather than at the jurisdictional level (80 FR 62668). The transmission to public health agencies—antimicrobial use and resistance reporting certification criterion currently references the Health Level 7 (HL7®) Implementation Guide for CDA® Release 2—Level 3: Healthcare Associated Infection
(HAI)Reports, Release 1, U.S. Realm, August 2013 standard in § 170.205(r)(1) and only requires conformance to certain sections of the implementation guide. The § 170.315(f)(6) certification criterion is required for completing the Antimicrobial Use Surveillance and Antimicrobial Resistance Surveillance measures in the Medicare Promoting Interoperability Program for eligible hospitals and CAHs. 47 47 See the FY2026 IPPS/LTCH PPS Final Rule Table X.F.-05 available at *https://www.federalregister.gov/d/2025-14681/p-4161.* We have reviewed and evaluated the transmission to public health agencies—antimicrobial use and resistance reporting certification criterion in § 170.315(f)(6) with a focus on achieving burden reduction while still supporting our policy goals. We have identified trends within the industry regarding a shift in reporting approach that supports revision of this criterion. 48 As CDC works to move reporting to FHIR-based standards, 49 we believe maintaining an outdated CDA-based standard in the criterion would impose regulatory burden on health IT developers that are seeking to support FHIR-based approaches to reporting. We propose to revise the criterion requirements to be functional only and remove the reference to the standard in § 170.205(r)(1) as of the effective date of a subsequent final rule. This would reduce administrative and development burden by allowing progress in line with other use cases, the use of more recent standards, and modern approaches to reporting. We note that, as with other criteria that include solely functional requirements, use of a specific standard would not be required to meet the proposed requirements of the criterion. 48 *https://stacks.cdc.gov/view/cdc/118849#:~:text=July%2027%2C%202021,2021%20Export%20RIS%20Citation%20Information.* 49 For information on CDC's National Healthcare Safety Network
(NHSN)antimicrobial use and resistance reporting options see *https://www.cdc.gov/nhsn/psc/aur/index.html.* We believe that revising the certification criterion in § 170.315(f)(6) to functional requirements only would reduce burden and allow for standards advancement and adoption of FHIR-based reporting to move more quickly. We welcome feedback on these proposals. d. Transmission to Public Health Agencies—Health Care Surveys We propose to remove the “transmission to public health agencies—health care surveys” certification criterion in § 170.315(f)(7) with an effective date of January 1, 2027. This criterion supports the transmission of health care surveys directly to the CDC. In the 2015 Edition Final Rule, we expanded the public health-related standards and certification criteria to include a new criterion for transmission of health care surveys to public health agencies (80 FR 62669). We clarified in the 2015 Edition Final Rule that the finalized implementation guide for this criterion is intended for the transmission of survey data for both the National Ambulatory Medical Care Survey (NAMCS) and the National Hospital Ambulatory Medical Care Survey (NHAMCS) (80 FR 62668). We also clarified that templates included in the implementation guide align with the CDA standard (80 FR 62668). We stated in the 2015 Edition Final Rule that data covered by this criterion will only be collected by the CDC rather than at the jurisdictional level (80 FR 62669). The certification criterion in § 170.315(f)(7) currently references the Health Level 7 (HL7®) Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, Draft Standard for Trial Use, December 2014 standard in § 170.205(s)(1). We note that the § 170.315(f)(7) certification criterion is optional to complete the Public Health Registry measures in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. 50 50 *See* the CY 2026 PFS Proposed Rule Table 62, available at *https://www.federalregister.gov/d/2025-13271/p-3055* and the FY2026 IPPS/LTCH PPS Final Rule Table X.F.-05 available at *https://www.federalregister.gov/d/2025-14681/p-4161.* We have reviewed and evaluated the transmission to public health agencies—health care surveys certification criterion in § 170.315(f)(7) with a goal of reducing burden while still supporting our policy priorities. We are also seeking to align with CDC priorities around data modernization and encouraging the use of FHIR-based approaches. The removal of this criterion would encourage industry to modernize and scale their reporting approach alongside CDC's efforts. We believe that removing the certification criterion in § 170.315(f)(7) would reduce burden while at the same time honor our policy goals to ensure health IT interoperability and functionality. Hospitals and clinicians have been actively submitting these surveys for over a decade and continue to meet the technical requirements set by CDC, even when these requirements outpace the certification criteria. 51 We propose a January 1, 2027, effective date for the removal of the transmission to public health agencies—health care surveys criterion in § 170.315(f)(7). We welcome feedback on these proposals. 51 *See https://build.fhir.org/ig/HL7/fhir-health-care-surveys-reporting-ig/.* 7. Design and Performance Certification Criteria a. Automated Numerator Recording In the 2015 Edition Final Rule (80 FR 62669), we adopted a certification criterion in § 170.315(g)(1) that requires the capability to create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the numerator of a percentage-based measure in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We first adopted this capability for the 2014 edition in § 170.314(g)(1) to complement the “automated measure calculation” certification criterion to support the associated meaningful use objectives in the EHR Incentive Programs. In the Cures Act Final Rule (85 FR 25708), we updated the references to the EHR Incentive Programs in the criterion to reflect CMS' updates to the name of the Programs, which are now the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. We propose to remove the “automated numerator recording” certification criterion and reserve § 170.315(g)(1). We have reviewed and evaluated the certification criterion in § 170.315(g)(1), seeking to identify ways to reduce burden while still supporting our policy goals. Health IT developers that facilitate customer participation in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category have been supporting the recording of numerator data associated with the measures and its previous iterations for many years. CMS establishes the measures and provides any additional information about how the numerator should be recorded through rulemaking and subsequent communications. ASTP/ONC uses the measure specifications established by CMS to develop testing procedures for health IT developers to certify their products to the automated numerator recording certification criterion. Certification of health IT to record the actions of the numerator has played an important role in ensuring health IT developers consistently implemented the measures established by CMS. However, we believe that developers now have significant experience with implementing CMS requirements, and they will continue to ensure that the measures are recorded in a fashion that meets CMS requirements to ensure that their customers can successfully participate in the absence of additional testing requirements under the ONC Health IT Certification Program. If our removal of the automated numerator recording certification criterion is finalized as proposed, we will work with CMS to ensure relevant guidance and materials for existing measures is consolidated as part of the informational materials that CMS maintains regarding measures in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. We believe that removing the certification criterion in § 170.315(g)(1) will reduce administrative burden, as well as burden for health IT developers and health care providers while still allowing us to achieve our policy goals. Because the certification criterion in § 170.315(g)(1) is specified in the definitions of CEHRT established by CMS for the Medicare Promoting Interoperability Program (42 CFR 495.4) and the MIPS Promoting Interoperability performance category (42 CFR 414.1305), we believe that a transition date is needed. Therefore, we propose to remove the automated numerator recording certification criterion as of January 1, 2027, and reserve § 170.315(g)(1). We welcome comments on this proposal. b. Automated Measure Calculation In the 2015 Edition Final Rule (80 FR 62669 through 62670), we adopted the “automated measure calculation” certification criterion in § 170.315(g)(2) that requires the capability to record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable measure in the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. This capability was first adopted as a 2011 Edition certification criterion to support the associated meaningful use stage 1 objectives and subsequently adopted in the 2014 Edition in § 170.314(g)(2) (77 FR 54184). In the Cures Act Final Rule (85 FR 25708), we updated the references to the EHR Incentive Programs in the certification criterion to reflect CMS' updated names for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. In the HTI-2 Final Rule (89 FR 101809), we inadvertently removed and reserved § 170.315(g)(2) due to an amendatory instruction drafting error. We corrected this error through a technical correction in the HTI-4 Final Rule published on August 4, 2025, which was included in the CY26 CMS IPPS/LTCH PPS Final Rule as a rider (90 FR 37182). We now propose to remove the “automated measure calculation” certification criterion and reserve § 170.315(g)(2) with an effective date of January 1, 2027. We have 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. CMS establishes these measures and provides any additional information about how the measures should be calculated through rulemaking and subsequent program communications. ASTP/ONC uses the measure specifications established by CMS to develop testing procedures for health IT developers to certify their products to the automated measure calculation certification criterion. Certification of health IT for measure calculation has played an important role in ensuring health IT developers consistently implemented the measures established by CMS. However, we believe that developers now have significant experience with implementing CMS requirements, and that they will continue to ensure that the measures are calculated in a fashion that meets CMS requirements to ensure that their customers can successfully participate in the absence of additional testing requirements under the Certification Program. If our removal of the automated measure calculation certification criterion is finalized as proposed, we will work with CMS to ensure relevant guidance and materials for existing measures is consolidated as part of the informational materials that CMS maintains regarding measures in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. We believe that removing the certification criterion in § 170.315(g)(2) will reduce administrative burden for health IT developers that support customer participation in the Medicare Promoting Interoperability Program and MIPS Promoting Interoperability performance category. Because the certification criterion in § 170.315(g)(2) is specified in the definitions of CEHRT in 42 CFR 414.1305 and 495.4 and currently required for reporting of Promoting Interoperability measures, we believe that a transition date is needed. Therefore, we propose to remove and reserve the automated measure calculation certification criterion in § 170.315(g)(2) as of January 1, 2027. We welcome comments on this proposal. c. Safety Enhanced Design We propose to remove the “safety-enhanced design” certification criterion in § 170.315(g)(3) and the reference to this certification criterion in § 170.550(g)(1) as of the effective date of a final rule for this proposed rule. The safety-enhanced design certification criterion specifies the user-centered design
(UCD)testing that must be applied to certain health IT capabilities submitted for certification. Certification to this certification criterion is conditional as its scope and applicability depends on the other certification criteria for which a Health IT Module is presented for certification. Section 170.315(g)(3) prescribes specific requirements for how certified capabilities are designed or made available to users. For example, during the design and development of certified health IT, developers are required to apply UCD processes to the capabilities reference in § 170.315(g)(3). This certification criterion is not included in the Base EHR definition in § 170.102 or the definition of CEHRT established by CMS in 42 CFR 414.1305 and 42 CFR 495.4. In the 2014 Edition Proposed Rule (77 FR 13842), we provided an overview of the International Organization for Standardization's
(ISO)definition of usability and outlined that EHR technology certification could introduce some improvements that we believed would enhance both the safety and efficiency of CEHRT. This position mirrored statements made by interested parties regarding a gap between optimal usability and the usability offered by some EHR technologies at that time. In November 2011, the Institute of Medicine
(IOM)called on the Secretary of HHS to specify the quality and risk management process requirements that health IT vendors must adopt, with a particular focus on human factors, safety culture, and usability. In the 2014 Edition Proposed Rule, we proposed to focus on the process of UCD to improve overall usability. We prioritized eight certification criteria 52 and associated capabilities to which the proposed certification criterion would require UCD to be applied. We chose these eight because we believed they posed the greatest risk for patient harm, and therefore, the greatest opportunity for error prevention. We also noted that the methods for how an EHR technology developer could employ UCD are well defined in documents and requirements such as ISO 9241-11, ISO 13407, ISO 16982, and NISTIR 7741. Our proposed approach sought to enable EHR technology developers to choose their UCD approach and not to prescribe specific UCD processes that would be required to meet this certification criterion. We also proposed in the 2014 Edition Proposed Rule (77 FR 13843), that testing to this certification criterion would require EHR technology developers to document that their UCD incorporates all the data elements defined in the Customized Common Industry Format Template for EHR Usability Testing (NISTIR 7742). 53 We noted that with respect to demonstrating compliance with this certification criterion that this information would need to be available to an ONC-ACB for review. Finally, we indicated that this documentation would become a component of the publicly available testing results on which a certification is based. 52 § 170.314(a)(1) (CPOE); § 170.314(a)(2) (drug-drug, drug-allergy interaction checks); § 170.314(a)(6) (medication list); § 170.314(a)(7) (medication allergy list); § 170.314(a)(8) (clinical decision support); § 170.314(a)(16) (electronic medication administration record); § 170.314(b)(3) (electronic prescribing); and § 170.314(b)(4) (clinical information reconciliation). 53 *http://www.nist.gov/manuscript-publication-search.cfm?pub_id=907312.* In the 2014 Edition Final Rule (77 FR 54187 through 54190), we adopted § 170.314(g)(3) as proposed, specifying that UCD must be applied to each capability of an EHR technology that is associated with the eight certification criteria named in the safety-enhanced design certification criterion. In addition, we finalized that the information from the NISTIR 7742 was required to be submitted for each of the criteria specified in the 2014 Edition safety-enhanced design certification criterion. In the 2014 Edition Release 2 Final Rule, we revised the safety-enhanced design certification criterion in to include three CPOE certification criteria (79 FR 54436) and the clinical information reconciliation and incorporation
(CIRI)certification criterion (79 FR 54439). In the 2015 Edition Proposed Rule (80 FR 16856), we proposed to adopt a 2015 Edition safety-enhanced design certification criterion that reflected updates to the 2014 Edition safety-enhanced design criterion. We proposed to include 17 certification criteria (seven of which were new) in the 2015 Edition safety-enhanced design certification criterion. For each of the referenced certification criteria and their corresponding capabilities presented for certification, we proposed to require that UCD processes must be applied to satisfy the certification criterion. For the 2015 Edition safety-enhanced design criterion, we further proposed to add more specificity around requirements for the information that must be provided to demonstrate compliance with this certification criterion. For instance, we proposed in § 170.315(g)(3)(ii) that information must be submitted on the specific UCD processes used. We further proposed in § 170.315(g)(3)(iii) that a health IT developer must submit information about and findings of the UCD testing conducted for each of the criteria specified in the 2015 Edition safety-enhanced design certification criterion. We proposed that this information would become part of the test results publicly available on CHPL. In the 2015 Edition Final Rule (80 FR 62670), we adopted the proposed safety-enhanced design certification criterion with modifications. Modifications included adopting a reduced list of criteria for inclusion in the safety-enhanced design certification criterion 54 and adopting the requirement that ONC-ACBs certify Health IT Modules to § 170.315(g)(3) consistent with the requirements included in the certification criterion. 54 § 170.315(a)(1) computerized provider order entry—medications; § 170.315(a)(2) computerized provider order entry—laboratory; § 170.315(a)(3) computerized provider order entry—diagnostic imaging; § 170.315(a)(4) drug-drug, drug-allergy interaction checks; § 170.315(a)(5) demographics; § 170.315(a)(6) problem list; § 170.315(a)(7) medication list; § 170.315(a)(8) medication allergy list; § 170.315(a)(9) clinical decision support; § 170.315(a)(14) implantable device list; § 170.315(b)(2) clinical information reconciliation and incorporation; and § 170.315(b)(3) electronic prescribing. We anticipate the removal of this criterion would reduce costs and burden for health IT developers and health care providers. For example, when pursuing certification, health IT developers must recruit a minimum of ten participants, conduct the necessary testing, and submit metrics for each certification criterion, for which they seek certification, that is refenced within § 170.315(g)(3). We refer readers to section VIII (Regulatory Impact Analysis) of this proposed rule for more detailed information on cost estimates of safety-enhanced design and potential cost savings. In addition to reducing costs and burden for health IT developers, we anticipate that removing this certification criterion would allow health IT developers to redirect time and resources towards more innovative approaches to support and improve safety-enhanced design in their products. Additionally, we no longer believe that this certification criterion provides the same benefit to the regulatory burden profile that it did when first adopted over ten years ago. In contrast, its presence in the Certification Program has led to instances where administrative processes to fulfill its requirements have delayed health IT developers from achieving product certifications without added improvements in user-centered design. In short, this certification criterion's impact has diminished since it was first adopted. Moreover, compared to its burden, we have seen little use of the transparent reporting associated with this certification criterion (§ 170.523(f)(1)(xix)). Consistent with E.O. 14192, “Unleashing Prosperity Through Deregulation,” and the reasons we stated above, we believe it is appropriate to remove this certification criterion. Therefore, we propose to remove the safety-enhanced design certification criterion in § 170.315(g)(3) and the reference to this certification criteria in § 170.550(g)(1) as of the effective date of a subsequent final rule. We welcome comments on our proposal. d. Quality Management System We propose to remove the “quality management system”
(QMS)certification criterion in § 170.315(g)(4) and the reference to this certification criteria in § 170.550(g)(2) as of the effective date of a final rule for this proposed rule. The QMS certification criterion states for each capability that a technology includes and for which that capability's certification is sought, the use of a QMS in the development, testing, implementation, and maintenance of that capability must be identified and satisfied in one of the following ways: either the QMS used is established by the Federal government or a standards developing organization
(SDO)or the QMS used is mapped to one or more QMS established by the Federal government or SDOs. Per § 170.550(g), this certification criterion is mandatory for all certified Health IT Modules. The 2014 Edition Proposed Rule (77 FR 13842) referenced a report by the Institute of Medicine
(IOM)in which IOM recommended that we “[establish] quality management principles and processes in health IT.” Accordingly, we stated that we were considering including in the final rule an additional certification criterion that would require an EHR technology developer to document how their EHR technology development processes either align with, or deviate from, certain quality management principles and processes (77 FR 13843). In the 2014 Edition Final Rule, we adopted a new quality management system certification criterion in § 170.314(g)(4) that was intended as a first step to focus on QMS and build on it in an incremental fashion (77 FR 54191). We finalized that all EHR technology certified to the 2014 Edition certification criteria would need to be certified to this certification criterion. In addition, we revised § 170.550 to require that, when certifying EHR Modules to the 2014 Edition EHR certification criteria, ONC-ACBs must certify EHR Modules to this certification criterion. In the 2015 Edition Proposed Rule (80 FR 16858), we proposed a revised version of the QMS certification criterion in § 170.315(g)(4). We proposed to require the identification of the QMS used in the development, testing, implementation, and maintenance of capabilities certified under the Certification Program. We proposed that for a Health IT Module to be certified, the identified QMS must be compliant with a quality management system established by the Federal government or an SDO, or mapped to one or more quality management systems established by the Federal government or SDOs. In the 2015 Edition Final Rule (80 FR 62672), we adopted the proposed version of the QMS certification criterion in § 170.315(g)(4). In addition, we revised § 170.550 to require ONC-ACBs to certify Health IT Modules to the new criterion in § 170.315(g)(4) when certifying to the 2015 Edition. When we initially proposed this certification criterion in the 2014 Edition Proposed Rule, we understood that some EHR technology developers already had quality management principles and processes in place, but we did not believe, especially considering the IOM recommendation, that the EHR technology industry consistently followed such processes. Since the adoption of the QMS certification criterion, we find that industry and other interested parties now widely employ quality management principles. As an example, an ISO 9001-certified quality management system provides a structured set of requirements designed to support quality-focused business operations. 55 The ISO Survey 2023 56 showed that 26,833 ISO 9001 certificates were issued in the U.S., demonstrating widespread adoption across diverse industries. Given these advances across industry, we have determined that this certification criterion, and program requirements that all Health IT Modules be certified to the criterion, have become duplicative. Therefore, we propose to remove the criterion in § 170.315(g)(4) and the reference to this certification criterion in § 170.550(g)(2) as of the effective date of a subsequent final rule. We welcome comments on our proposal. 55 *https://amtivo.com/us/resources/insights/iso-9001-meaning-requirements-and-beginners-guide/.* 56 *https://www.iso.org/the-iso-survey.html.* e. Accessibility-Centered Design We propose to remove the “accessibility-centered design”
(ACD)certification criterion in § 170.315(g)(5) and the reference to this certification criteria in § 170.550(g)(3) as of the effective date of a final rule for this proposed rule. This certification criterion requires that all developers of Health IT Modules identify and use a health IT accessibility-centered design standard or law in the development, testing, implementation and maintenance of each capability for which certification is sought. The removal of this certification criterion, if finalized, would not exempt health IT developers and providers from their independent obligations under applicable federal civil rights laws, including Section 504 of the Rehabilitation Act, Section 1557 of the Affordable Care Act, and the Americans with Disabilities Act. The requirements of these civil rights laws include, but are not limited to, providing individuals with disabilities equal access to information and appropriate auxiliary aids and services as provided in the applicable statutes and regulations. In the 2015 Edition Proposed Rule, we proposed a new accessibility-centered design certification criterion in § 170.315(g)(8) (80 FR 16861). We proposed that this criterion would require the identification of user-centered design standard(s) or laws for accessibility that were applied, or complied with, in the development of specific capabilities included in a Health IT Module or, alternatively, the lack of such application or compliance. We proposed to require that for each capability that a Health IT Module includes, and for which that capability's certification is sought, the use of a health IT accessibility-centered design standard or compliance with a health IT accessibility law in the development, testing, implementation, and maintenance of that capability must be identified. We also proposed that the method(s) used to meet this proposed certification criterion would be reported through the open data CHPL and we proposed to revise § 170.550 to require ONC-ACBs to certify all Health IT Modules certified to the 2015 Edition to the accessibility-centered design certification criterion. The 2015 Edition Final Rule adopted the accessibility-centered design
(ACD)certification criterion as proposed, moving it to § 170.315(g)(5) (80 FR 62673). Additionally, we finalized in § 170.550 that ONC-ACBs must certify all 2015 Edition Health IT Modules to the criterion in § 170.315(g)(5). In the 2015 Edition Proposed Rule we explained that the proposed certification criterion would serve to increase transparency around the application of user-centered design standards for accessibility to health IT and the compliance of health IT with accessibility laws (80 FR 16861). We stated that this transparency would benefit health care providers, consumers, government entities, and other stakeholders, and would encourage health IT developers to pursue the application of more accessibility standards and laws in product development that could lead to improved usability for health care providers with disabilities and health care outcomes for patients with disabilities. Since the adoption of this certification criterion, we find that industry and other interested parties have readily adopted this application of user-centered design as an industry standard. For instance, according to CHPL data, as of August 2025, every single active Certified Health IT Module (721 total) was certified to § 170.315(g)(5). The proposed removal of this certification criterion would reduce the effort of health IT developers to meet ongoing program requirements that duplicate widely adopted accessibility-centered design practices, allowing developers to refocus these resources on innovation and meeting the needs of their clients and end users in other areas. Therefore, we propose to remove the accessibility-center design certification criterion in § 170.315(g)(5) and the reference to this certification criterion in § 170.550(g)(3) as of the effective date of a final rule for this proposed rule. As stated earlier, the removal of this certification criterion, if finalized as proposed, would not exempt health IT developers and providers from their independent obligations under applicable federal civil rights laws, including but not limited to, providing individuals with disabilities equal access to information and appropriate auxiliary aids and services. We welcome comments on our proposal. f. Consolidated CDA Creation Performance We propose to remove the certification criterion in § 170.315(g)(6) and reserve that section. We also propose to remove § 170.550(g)(4) which references the criterion, as described elsewhere in this proposed rule. The “Consolidated CDA creation performance” certification criterion helps to ensure the proper conformance of Consolidated CDAs (C-CDAs) for transition of care and referral summaries that are sent to and received from external organizations. In the 2015 Edition Final Rule, we adopted a new Consolidated CDA creation performance certification criterion in § 170.315(g)(6) that assesses a product's C-CDA creation performance if the Health IT Module is presented for certification with C-CDA creation capabilities within its scope (80 FR 62674). In the HTI-1 Final Rule, we updated the associated standards (89 FR 1224). We have stated elsewhere in this proposed rule that while C-CDA-based standards are still in use, the industry is shifting toward adoption of FHIR-based standards, which are designed to enable greater interoperability and innovation. We believe that maintaining the current level of support for this and other C-CDA-based criteria, including putting effort and resources toward testing and certification, can detract from industry efforts to move toward FHIR-based solutions. We believe that removing the Consolidated CDA creation performance certification criterion in § 170.315(g)(6) would contribute to reducing the effort health IT developers and health care providers are focusing on C-CDA support and allow for redirection of efforts toward greater use of FHIR-based standards in health IT. We propose to remove the Consolidated CDA creation performance certification criterion in § 170.315(g)(6) as of the effective date of a subsequent final rule. We welcome feedback on these proposals. g. Application Access—Patient Selection In the 2015 Edition Final Rule (80 FR 62602), we adopted the “application access—patient selection” certification criterion in § 170.315(g)(7) that includes the capability to receive a request with sufficient information to uniquely identify a patient and return an ID or other token that can be used by an application to subsequently execute requests for that patient's data. We propose to remove the application access—patient selection criterion and reserve § 170.315(g)(7) as of January 1, 2027. We have reviewed and evaluated the certification criterion in § 170.315(g)(7), seeking to identify ways to reduce burden while still supporting our policy goals. We refer readers to section I.A.2.b for detailed discussion on “America's FHIR-Forward Future.” Given our increased focus on standards-based APIs in the Certification Program, we believe it is appropriate to remove this functional API criterion at this time. Specifically, since adoption of the SMART App Launch Implementation Guide in § 170.215(c) all 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) according to the SMART App Launch Implementation Guide. Further, we are also proposing elsewhere in this proposed rule to remove a corresponding certification criterion in § 170.315(g)(9). Should we finalize removal of the certification criterion in § 170.315(g)(9), the certification criterion in § 170.315(g)(7) would lose its intended utility. We believe that reducing compliance burdens for health IT developers that participate in the Certification Program would foster industry innovation and encourage the development of more creative interoperability solutions. We have similarly also removed the certification criterion in § 170.315(g)(8) via a technical correction in the HTI-4 Final Rule (90 FR 37182), which was published in tandem with the FY2026 IPPS/LTCH PPS Final Rule (90 FR 36536). We had intended to remove § 170.315(g)(8) in the HTI-2 Final Rule, but mistakenly removed § 170.315(g)(2) instead due to an amendatory instruction drafting instruction error. We corrected this error in the HTI-4 Final Rule. The application access—patient selection certification criterion is included in the Base EHR definition in § 170.102. The criterion is also associated with measures under the Provider to Patient Exchange and Health Information Exchange objectives of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. Accordingly, we believe that a transition date is needed for the removal of this measure, if our proposal is finalized, that would allow CMS to make appropriate program adjustments. Therefore, we propose to remove the application access—all data request certification criterion as of January 1, 2027, and reserve § 170.315(g)(7). We believe that removing the certification criterion in § 170.315(g)(7) will reduce administrative burden as well as burden for health IT developers and health care providers while still allowing us to achieve our policy goals. We welcome comments on this proposal. h. Application Access—All Data Request In the 2015 Edition Final Rule (80 FR 62602), we established the “application access—all data request” certification criterion at § 170.315(g)(9) that requires the capability to respond to requests for patient data for all of the data classes expressed in the standards in § 170.213. In the Cures Act Final Rule (85 FR 25642), we revised § 170.315(g)(9) to add requirements for the USCDI and remove support for the CCDS by a specified date. In the HTI-1 Final Rule (89 FR 1192), we made revisions to support USCDI v2 and v3 updates and changes to data classes and constituent data elements for C-CDA and C-CDA 2.1 Companion Guide. We propose to remove the application access—all data request certification criterion in § 170.315(g)(9) as of January 1, 2027. We have reviewed and evaluated the certification criterion in § 170.315(g)(9), seeking to identify ways to reduce burden for health IT developers and health care providers while still supporting our policy goals. As we have stated in the above section on our proposal to remove § 170.315(g)(7) and in section I.A.2.b of this rule, we are increasing focus on standards-based APIs, and we believe it is appropriate to remove this functional API criterion at this time. We believe the functionality of the criterion has been widely adopted (as discussed in section III.A) among health IT developers and is not likely to go away as a supported functionality solely because of removal from the Certification Program. We also believe that removing this certification criterion could spur further industry innovation and support the development of more creative interoperability solutions. We believe that removing the certification criterion in § 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). Because the certification criterion in § 170.315(g)(9) is associated with measures under the Provider to Patient Exchange and Health Information Exchange objectives of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category, we believe that a transition date is needed. 57 Therefore, we propose to remove the application access—all data request certification criterion as of January 1, 2027 and reserve § 170.315(g)(9). We welcome comments on this proposal. 57 *See* the CY 2026 PFS Proposed Rule Table 62, available at *https://www.federalregister.gov/d/2025-13271/p-3055* and the FY2026 IPPS/LTCH PPS Final Rule Table X.F.-05 available at *https://www.federalregister.gov/d/2025-14681/p-4161.* 8. Transport Methods and Other Protocols Certification Criteria a. Direct Project In the 2015 Edition Final Rule (80 FR 62602), we adopted a revised certification criterion in § 170.315(h)(1) that includes the capability to send and receive according to the Applicability Statement for Secure Health Transport (the primary Direct Project specification). We previously adopted this capability across different certification criteria as the 2014 Edition EHR Certification Criteria were maintained at § 170.314(b)(1), (b)(2), and (h)(1). We propose to remove the “transport methods and other protocols—direct project” certification criterion in § 170.315(h)(1) as of the effective date of a final rule. We have reviewed and evaluated the certification criterion in § 170.315(h)(1), seeking to identify ways to reduce burden while still supporting our policy goals. We believe that because this certification criterion was included as part of the 2014 Base EHR definition, the 2015 Base EHR definition (subsequently renamed the Base EHR definition), the functionality of this certification criterion has been widely adopted (as discussed in section III.A) among health IT developers and is not likely to go away as a supported functionality solely because of removal from the Certification Program. We no longer believe there is added benefit to include conformance testing for this functionality in the Certification Program as it is widely relied on and supported in the health care industry and would be incorporated in health IT absent the certification criterion. We further believe that removing this certification criterion could spur further industry innovation by enabling health IT developers to redirect investment in certification and testing for this criterion to new areas. We believe the removal of this certification criterion will reduce administrative burden and costs associated with certification for health IT developers and health care providers by eliminating the need for developers of certified health IT to certify to the certification criterion in § 170.315(h)(1) without substantially impacting our broader policy goals around interoperability and exchange and will allow for further innovation and development. Therefore, we propose to remove the transport methods and other protocols—direct project certification criterion in § 170.315(h)(1) as of the effective date of a subsequent final rule. We welcome comments on this proposal. b. Direct Project, Edge Protocol, and XDR/XDM In the 2015 Edition final rule we adopted a variation of the § 170.315(h)(1) certification criterion in § 170.315(h)(2) to accommodate implementation differences. This certification criterion combined three standards conformance requirements (the primary Direct standard, the edge protocol, and XDR/XDM handling). We propose to remove the “transport methods and other protocols—Direct Project, Edge Protocol, and XDR/XDM” certification criterion in § 170.315(h)(2) as of the effective date of a subsequent final rule. We have reviewed and evaluated the certification criterion in § 170.315(h)(2), seeking to identify ways to reduce burden while still supporting our policy goals. Similar to § 170.315(h)(1), we believe the functionality of this certification criterion has been widely adopted (as discussed in section III.A) among health IT developers and is not likely to go away as a supported functionality solely because of removal from the Certification Program, since it has been part of the 2014 Edition Base EHR definition, and 2015 Edition Base EHR definition (renamed the Base EHR definition), and the current criterion has not substantively changed since it was adopted in the 2015 Edition Final Rule. We further believe that removing this criterion could spur further industry innovation in this area by allowing for greater flexibility and reduced burden and costs from the need to certify to the certification criterion. Because removing §§ 170.315(h)(1)-(2) would remove all of the certification criteria under § 170.315(h), we propose to remove and reserve § 170.315(h) in its entirety. We welcome comments on this proposal. B. Standards and Implementation Specifications for Health Information Technology 1. United States Core Data for Interoperability Version 3.1 Update (USCDI v3.1) The USCDI standard in § 170.213 is a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. Certain certification criteria in the Certification Program currently require the use of one of the versions of the USCDI standard in § 170.213. We established USCDI as a standard in the Cures Act Final Rule (85 FR 25670), adopting USCDI Version 1 (USCDI v1) in § 170.213 and incorporating it by reference in § 170.299. USCDI is also referenced by HHS programs and used by the health care community to align interoperability requirements and national priorities for health IT across industry initiatives. For the overall structure and organization of USCDI, including data classes and data elements, please see *www.healthIT.gov/USCDI.* We published the “USCDI v3 Data Elements Enforcement Discretion Notice,” 58 on March 21, 2025, which stated that ASTP/ONC is exercising enforcement discretion, and issued certification guidance for the Certification Program. Specifically, under this enforcement discretion notice and certification guidance, we stated that ASTP/ONC will not take any enforcement action under 45 CFR 170.565 against an ONC-ACB based on non-compliance with 45 CFR 170.550 for certifying a Health IT Module that is presented for certification to a certification criterion or criteria in 45 CFR 170.315 that cross-references USCDI v3, where the Health IT Module: 58 *https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion.* 1. Does not demonstrate the capability to categorize data on individuals based on either or both of the following data elements: • Sexual orientation; and • Gender identity; or 2. Only demonstrates the capability to categorize data on individuals for the sex data element in accordance with the following SNOMED CT® codes: • 248152002 Female (finding) |; and • 248153007 Male (finding) |. Additionally, under this enforcement discretion notice and certification guidance, we stated that ASTP/ONC will not take any enforcement action under 45 CFR 170.565 against an ONC-ACB based on non-compliance with 45 CFR 170.550 for certifying a Health IT Module that is presented for certification to the “patient demographics and observations” certification criterion (45 CFR 170.315(a)(5)), where the Health IT Module: 1. Does not demonstrate conformance with any or all of the following data and observations in paragraph (a)(5)(i): sex parameter for clinical use, sexual orientation, gender identity, name to use, and pronouns; or 2. Does not demonstrate conformance with any or all of the following paragraphs of (a)(5)(i):
(D)(“sexual orientation”),
(E)(“gender identity”),
(F)(“sex parameter for clinical use”),
(G)(“name to use”), and
(H)(“pronouns”); or 3. Only demonstrates, for conformance with paragraph (a)(5)(i)(C) (“sex”), that it can record sex in accordance with either the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025, or the following SNOMED CT® codes found in the standard specified in § 170.207(n)(2): • 248152002 Female (finding) |; and • 248153007 Male (finding) |. We stated that ASTP/ONC will not exercise its direct review authority under 45 CFR 170.580 for any non-conformity, potential or actual, that arises solely from a Health IT Module not demonstrating the capabilities specified above or for only demonstrating the limited specified capabilities above, as applicable, for the relevant certification criteria requirements. We also stated that this enforcement discretion notice, and certification guidance will remain in effect for twelve
(12)months from the date of this notice or until HHS completes a regulatory action to revise the applicable regulations, whichever comes first. In June 2025, we published the USCDI v3.1, 59 which removes or updates from USCDI v3 the data elements for Sex, Sexual Orientation, and Gender Identity in the Patient Demographics/Information Data Class. We propose to adopt USCDI v3.1 in § 170.213(a) and incorporate it by reference in § 170.299. The removal of data elements from USCDI v3 reflected in USCDI v3.1 aligns with our other proposals related to § 170.315(a)(5) (see section III.A.1.a), resulting in burden reduction for health IT developers and cost savings associated with the enforcement discretion and ongoing maintenance requirements over time. In addition, these data elements ( *e.g.,* sexual orientation and gender identity) do not support the meeting of specific measures under the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category, and are therefore not essential for inclusion in certified health IT that is used to meet the CEHRT definitions and support meeting measures under those programs. Therefore, we propose to remove USCDI v3 in § 170.213(b) and USCDI v1 in § 170.213(a) which expires on January 1, 2026. The effect of these proposals, if finalized in a subsequent final rule, would be that USCDI v3.1 would be the only version of USCDI in § 170.213. In other words, all Health IT Modules that cross-reference § 170.213 would need to conform to USCDI v3.1 as of the effective date of a subsequent final rule. Given that USCDI v3.1 is a reduction, rather than expansion, of required support for data elements, we do not anticipate that Health IT Modules that cross-reference § 170.213 would require further development to conform to USCDI v3.1. 59 *See https://www.healthit.gov/isp/sites/isp/files/USCDI-Version-3-1_2025_508.pdf.* We welcome comments on our proposals. a. National Technology Transfer and Advancement Act The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 *et. seq.* ) and the Office of Management and Budget
(OMB)Circular A-119 60 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to this general rule, namely when doing so would be inconsistent with applicable law or otherwise impractical. Agencies have the discretion to decline the use of existing voluntary consensus standards if it is determined that such standards are inconsistent with applicable law or otherwise impractical, and instead use a government-unique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A-119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that: meet the agency's regulatory, procurement or program needs; deliver favorable technical and economic outcomes; and are widely utilized in the marketplace. In this proposed rule, we propose to use a government-unique standard which is the USCDI v3.1 standard that we propose to adopt in § 170.213. This standard is a hybrid of government policy ( *i.e.,* determining which data to include in the USCDI) and voluntary consensus standards ( *i.e.,* the vocabulary and code set standards attributed to USCDI data elements). 60 *https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf.* We are not aware of any voluntary consensus standard that could serve as an alternative for the purposes we describe in further detail throughout this proposed rule, including for establishing a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. b. “Reasonably Available” to Interested Parties The Office of the Federal Register has established requirements for materials ( *e.g.,* standards and implementation specifications) that agencies propose to incorporate by reference in the CFR (79 FR 66267: 1 CFR 51.5(a)). To comply with these requirements, in section V (“Incorporation by Reference”) of this preamble, we provide a summary of, and a uniform resource location
(URL)to, the USCDI standard we propose to adopt and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about the standard throughout the relevant sections of the proposed rule. 2. Standards and Implementation Specifications As discussed above, we have proposed to remove or revise certain certification criteria in the Certification Program in an effort to reduce burden, offer flexibility to both developers and health care providers, as well as to support innovation. Included in certain certification criteria are references to standards. In those instances where we have proposed to remove the criterion, we also generally propose to remove the standard that is referenced from the CFR. Where the certification criterion is not removed as of the effective date of a final rule but allows time for transition until January 1, 2027, we generally propose to also remove those referenced standards on January 1, 2027. Only in limited circumstances do we retain a standard that is referenced in a certification criterion proposed for removal. We propose to remove the following standards as of the effective date of a subsequent final rule because they would no longer be referenced in certification criteria in the CFR: transport standards in § 170.202(b) through (e); functional standards in § 170.204; content exchange standards in § 170.205(a)(3) and (5); vocabulary standards for representing electronic health information in § 170.207(r) and (s); and standards for health information technology to protect electronic health information created, maintained, and exchanged in § 170.210. We note that certain standards in § 170.210 may not be removed contingent on whether we finalize the alternative privacy and security proposal (see section III.A.4). We also propose to remove the following standards as of the effective date of a final rule since we propose to revise the associated certification criterion requirements to no longer reference the given standard: the content and exchange standard in § 170.205(r)(1), including the specific document templates in § 170.205(r)(1)(i) through (iii). We propose to remove content exchange standards and implementation specifications referenced in certification criteria requirements that have expired in § 170.205(k)(1) and
(2)from the CFR. We propose to remove API standards that expire on January 1, 2026, in § 170.215(b)(1)(i) and (c)(1), and we also propose to remove and reserve outdated vocabulary standards in § 170.207(f)(2) and (m)(1). Where we propose to remove certain certification criteria after a transition period until January 1, 2027, we also propose to remove those standards from the CFR effective on January 1, 2027. Standards referenced in a certification criterion proposed for removal with a transition date of January 1, 2027, include content exchange standards in § 170.205(i)(2), (t)(1) through (4), and (s)(1). We also propose to remove certain vocabulary standards in order to eliminate outdated standards that are no longer referenced or have expired. Therefore, we propose to remove vocabulary standards in § 170.207(a)(4), (c)(3), (e)(3) and (4). We also propose to remove vocabulary standards in § 170.207(d)(1)(ii), (d)(1)(iii), (n)(1) and (3), and
(o)from the CFR and reserve these subsections. We welcome comments on our proposals. Specifically, we request comment on whether we should retain any of the standards and implementation specifications proposed for removal because the standard or implementation specification should be required for purposes of health IT alignment, for instance, when acquiring, implementing or upgrading health IT systems and products consistent with sections 13111 and 13112 of the HITECH Act. In certain instances, we have not proposed to remove a standard even though we propose to remove the certification criterion where the standard is referenced. As noted, under section 3004 of the PHSA, we may adopt standards independently of associated criteria in the Certification Program. Standards adopted in 45 CFR 170 subpart B may be referenced by other HHS programs and policies besides the Certification Program. For example, standards adopted in 45 CFR 170 subpart B, regardless of whether they are associated with health IT certification criteria, are also required for use under sections 13111 and 13112 of the HITECH Act when acquiring, implementing or upgrading health IT systems and products in certain instances. We do not propose to remove the standard in § 170.205(o), data segmentation for privacy, because some developers still rely on these standards, which allow health care providers to tag health care documents with privacy metadata. We also do not propose to remove the Direct Project transport standard in § 170.202(a)(2). We realize that the Direct Project standards are widely utilized in various use cases and emphasize that developers may still use these standards even if they are removed from certification criteria. We welcome comments on these proposals. We believe that keeping the primary Direct Project standard in § 170.202(a)(2) but removing the other related standards and protocols in § 170.202(b) through
(e)from the Certification Program would acknowledge the current utilization of the Direct Project standard while recognizing the ongoing technological advancements related to transport, including movement toward FHIR-based standards, and would encourage and provide space for further innovation and market competition in this area. We propose a minor revision to § 170.205(d)(2) to add the full name of the HL7 Messaging Standard Version 2.5.1 standard. Lastly, we request comments on retaining the “Applicability Statement for Secure Health Transport” requirement found in § 170.315(h)(1)(i). C. Terms and Definitions Because of the proposed removal of certain certification criteria from § 170.315 discussed above, we propose to make conforming edits to the terms and definitions in § 170.102. 1. Base EHR We propose 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. The Base EHR definition provides a baseline assurance that certified health IT has been developed to possess, at a minimum, a key set of capabilities. We note the Base EHR definition is based on the “Qualified EHR” definition in section 3000(13) of the PHSA (77 FR 54262). As we noted recently, we have generally sought to limit the Base EHR definition to elements required for the Qualified EHR definition in PHSA section 3000 (90 FR 37145). In section (3)(i) of the Base EHR definition, we propose to remove references to § 170.315(a)(14), (g)(7) and (9), and (h)(1) and (2). We propose to remove these certification criteria from the Base EHR definition because we have proposed to remove those certification criteria from the CFR. We also propose to move § 170.315(b)(11) to section (3)(i) of the definition and remove and reserve section (3)(ii) and remove section (3)(iii) because the transition date has passed. We welcome feedback on these proposals. 2. Common Clinical Data Set We finalized in the Cures Act Final Rule that the CCDS would no longer be applicable for certified Health IT Modules 24 months after the publication date of the Cures Act Final Rule (85 FR 25671), and then extended that date to December 31, 2022, in the interim final rule titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70073). Because § 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 § 170.315(b)(6) in the HTI-2 Final Rule (89 FR 101776) and there are no longer any references to CCDS in 45 CFR part 170, we propose to remove the term Common Clinical Data Set in § 170.102. We welcome comments on these proposals. 3. Global Unique Device Identification Database and Production Identifier In section III.A.1.d, we propose to remove the “implantable device list” certification criterion in § 170.315(a)(14) and reserve § 170.315(a)(14). The implantable device list 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 propose to remove § 170.315(a)(14), we propose to remove the definitions of Global Unique Device Identification Database and Production Identifier in § 170.102 too as the terms would no longer be referenced in any other section of 45 CFR part 170. We welcome comments on these proposals. D. Conditions and Maintenance of Certification Requirements for Health IT Developers 1. Assurances Section 3001(c)(5) of the PHSA (42 U.S.C. 300jj-11) (section 4002 of the Cures Act) requires that a health IT developer, as a Condition of Certification requirement under the Certification Program, provide assurances to the Secretary that, unless for legitimate purpose(s) as specified by the Secretary, the developer will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA or any other action that may inhibit the appropriate exchange, access, and use of EHI. In the Cures Act Final Rule (85 FR 25718), we implemented this provision through several Conditions of Certification and accompanying Maintenance of Certification requirements, which are set forth in § 170.402. Because the transition dates in § 170.402(b)(2)(i) and
(ii)have passed, we propose 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). We also propose to make additional conforming edits to § 170.402(b). Because we propose 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, we also propose 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. We welcome feedback on these proposals. 2. Application Programming Interfaces As a Condition of Certification requirement in section 3001(c)(5) of the PHSA (42 U.S.C. 300jj-11) (section 4002 of the Cures Act), health IT developers are required to publish APIs that allow “health information from such technology to be accessed, exchanged, and used without special effort through the use of application programming interfaces or successor technology or standards, as provided for under applicable law.” Section 4002 of the Cures Act also states that a developer must, through an API, “provid[e] access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws.” The Cures Act Final Rule (85 FR 25642) captured both the technical functionality and behaviors necessary to implement the Cures Act API Condition of Certification requirement. Specifically, we adopted new standards, new implementation specifications, a new certification criterion, and modified the Base EHR definition. In addition, we finalized detailed Condition and Maintenance of Certification requirements for health IT developers of certified health IT in § 170.404. Because the transition dates in § 170.404(b)(2), (3), and
(4)have passed, we propose to revise the Maintenance of Certification requirements in § 170.404(b). We propose to revise § 170.404(b)(2) to remove the date, and we propose to remove paragraphs (b)(3) and (b)(4) entirely as they are outdated and, in the case of (b)(4) because it refers to certification criteria that we are proposing to remove. We also propose to revise § 170.404(c) to update certification criteria referenced in the “Certified API technology” definition. We propose 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 are proposing to remove § 170.315(g)(7) through (9). We welcome feedback on these proposals. 3. Real World Testing Section 3001(c)(5) of the PHSA (42 U.S.C. 300jj-11) (section 4002 of the Cures Act) requires, as a Condition and Maintenance of Certification under the Certification Program, that health IT developers have successfully tested the real world use of the technology for interoperability in the type of setting in which such technology would be marketed. Section 4003(a)(2) of the Cures Act defines interoperability as health information technology that enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user; allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state or federal law; and does not constitute information blocking as defined in section 3022(a) of the Cures Act. This definition for interoperability was codified in 45 CFR 170.102. In the Cures Act Final Rule, through the Real World Testing Condition and Maintenance of Certification requirements, we finalized the implementation of the statute's real world testing requirements in 45 CFR 170.405 for health IT certified to the following certification criteria: • The “care coordination” certification criteria in § 170.315(b); • The “clinical quality measures” certification criteria in § 170.315(c)(1) through (c)(3); • The “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1); • The “public health” certification criteria in § 170.315(f); • The certification criteria related to APIs in § 170.315(g)(7) through (g)(10); and • The “transport methods and other protocols” certification criteria in § 170.315(h). However, in that same final rule we replaced the “application access—data category request” certification criterion (§ 170.315(g)(8)) with the “standardized API for patient and population services” certification criterion (§ 170.315(g)(10)). The “application access—data category request” certification criterion was only available for certification until December 31, 2022, and we eventually removed the certification criterion from the CFR (89 FR 101776). In the HTI-4 Final Rule, we finalized six new certification criteria. We clarified that because § 170.405(a) cross references § 170.315(b), the new § 170.315(b)(4) “real-time prescription benefit” certification criterion finalized in HTI-4 would be automatically included within real world testing requirements. Similarly, we included five API-focused certification criteria: § 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” in scope for real world testing. Health IT certified to the identified real world testing certification criteria are eligible for the SVAP under § 170.405(b)(8) and (9). Consistent with the “Real World Testing Condition and Maintenance of Certification Requirements Enforcement Discretion Notice” 61 we issued on June 30, 2025, we now propose the following deregulatory actions:
(1)removing the requirement to submit real world testing plans for all real world testing certification criteria (§ 170.405(b)(1));
(2)limiting full real world testing results reporting (§ 170.405(b)(2)) to only Health IT Modules that are certified to the API certification criteria identified below; and
(3)permitting the use of SVAP for the remaining non-API real world testing certification criteria with minimal reporting requirements. 61 *https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement.* We note that certain certification criteria would be fully removed from real world testing requirements by virtue of their proposed removal from the Certification Program. We have included such an outcome in our proposed revised Real World Testing Condition of Certification (45 CFR 170.405(a)). If, in a subsequent final rule, we determine to keep any of the criteria proposed for removal and they are currently identified in the Real World Testing Condition of Certification (45 CFR 170.405(a)), they would also remain part of the Real World Testing Condition of Certification. Examples of such criteria would be the public health criteria proposed for removal (“transmission to cancer registries” (§ 170.315(f)(4)) and “transmission to public health agencies—health care surveys” (§ 170.315(f)(7)). First, we propose to remove the real world testing plan submission requirement from the Real World Testing Maintenance of Certification requirements (§ 170.405(b)). Second, we propose to revise the results reporting requirements under § 170.405(b)(2) to make clear what health IT developers must include in their real world testing results reporting. Specifically, developers will be expected to report on all health IT certified to any of the certification criteria in § 170.315(g) certification criteria as of January 1 of the year in which they must complete real world testing. Developers must also 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. This is consistent with current requirements to conduct a full calendar year of real world testing (§ 170.405(b)(2)(ii)). We propose to limit real world testing reporting (§ 170.405(b)(2)) to API-focused certification criteria which are, at this time: “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)). This approach aligns with our overall move to focus the Certification Program on APIs (see discussion in section I.A.2) with a particular focus on FHIR-based APIs. SVAP will remain available for all certified health IT subject to the Real World Testing Condition of Certification and Maintenance of Certification requirements. For the API-focused certification criteria identified above, the real world testing SVAP reporting requirements will not change. However, for health IT certified to the remaining real world testing certification criteria identified in § 170.405(a), developers will only need to identify in their real world testing results their voluntary updates (health IT products, certification criteria, and standards/implementation specifications) to standards and implementation specifications that the National Coordinator has approved through SVAP, which is consistent with current requirements under 45 CFR 170.405(b)(2)(ii)(C). This approach will allow developers to continue to voluntarily update to newer versions of standards once approved by the National Coordinator, which supports advancing interoperability. For clarity, we have captured this SVAP requirement separately in proposed 45 CFR 170.405(b)(2)(iv). We also propose a revision to § 170.405(b)(8) to cross-reference paragraph
(a)of § 170.405 instead of paragraph
(b)due to our proposed revisions. 4. Attestations Section 4002(a) of the Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Certification Program, provide to the Secretary an attestation to the Conditions of Certification required in section 3001(c)(5)(D) of the PHSA. In the Cures Act Final Rule, we adopted regulation text implementing the Cures Act's “Attestations” Condition of Certification requirement in § 170.406 (85 FR 25781). Under § 170.406, health IT developers attest twice a year to compliance with the Conditions and Maintenance of Certification requirements. A health IT developer of certified health IT must provide the Secretary an attestation of compliance with § 170.404, the API Conditions and Maintenance of Certification requirements, according to § 170.406(a)(4). Because we discuss the proposal to remove § 170.315(g)(7) through
(9)in section III.A.7 of this proposed rule, we also propose to remove the reference to § 170.315(g)(7) through
(9)in § 170.406(a)(4). In § 170.406(a)(5), we also propose to remove the reference to § 170.315(g)(7) through (9). Additionally, we propose to remove the reference to § 170.315(h) in § 170.406(a)(5) because, as we discussed in section III.A.8, we propose to remove § 170.315(h)(1) and (2), in effect removing the entirety of § 170.315(h). 5. Insights The Cures Act specified requirements in section 4002(c) to establish an EHR Reporting Program to provide transparent reporting on certified health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. In the HTI-1 Final Rule (89 FR 1311), we established the EHR Reporting Program as the “Insights Condition and Maintenance of Certification” (also referred to as the “Insights Condition”) and finalized in § 170.407 the first set of measures to reflect the interoperability category required by section 3009A(a)(3)(A)(iii) of the PHSA. The Insights Condition includes seven measures on which health IT developers under the Certification Program must annually report consistent with specified timelines. We refer readers to the HTI-1 Proposed Rule (88 FR 23831) for detailed background on how we engaged with the health IT community for the purpose of identifying measures that developers of certified health IT would be required to report on as a Condition and Maintenance of Certification under the Certification Program. Consistent with E.O. 14192, “Unleashing Prosperity Through Deregulation,” 62 we identified certain regulatory requirements for which the exercise of enforcement discretion may prevent or mitigate the accrual of sunk costs by regulated entities. On April 29, 2025, we published the “Insights Condition and Maintenance of Certification Enforcement Discretion Notice,” 63 in which we stated we had exercised the following enforcement discretion: 62 *https://www.federalregister.gov/documents/2025/02/06/2025-02345/unleashing-prosperity-through-deregulation.* 63 *https://www.healthit.gov/topic/insights-condition-and-maintenance-certification-enforcement-discretion.* • ASTP/ONC will not exercise its direct review authority under 45 CFR 170.580 for any non-conformity, potential or actual, that arises solely from a health IT developer not complying with 45 CFR 170.407(b) except for reporting requirements related to the “use of FHIR in apps through certified health IT” measure (45 CFR 170.407(a)(3)(iv)). Stated another way, ASTP/ONC only expects that health IT developers will report on the “use of FHIR in apps through certified health IT” measure (§ 170.407(a)(3)(iv)(A) and
(B)beginning in July of 2027 and (a)(3)(iv)(C) beginning in July 2028). • ASTP/ONC will not conclude that an ONC-ACB has failed to adhere to 45 CFR 170.523(u), find a violation of 45 CFR 170.560(a), or take any enforcement action under 45 CFR 170.565 against an ONC-ACB if an ONC-ACB confirms that the only measure under 45 CFR 170.407(b) for which a health IT developer submits responses is the “use of FHIR in apps through certified health IT” measure (45 CFR 170.407(a)(3)(iv)). We stated that this enforcement discretion will be in effect beginning on July 1, 2027, and will remain in effect until HHS completes a deregulatory action to remove or revise 45 CFR 170.407 and 170.523(u). Therefore, in this proposed rule, we propose to remove the following measures in § 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. Note, given this proposal, we propose to make 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). In addition, we propose to remove corresponding references to the removed measures in § 170.407(b) as we only expect that health IT developers would report on the “use of FHIR in apps through certified health IT” measure in the newly designated § 170.407(a)(3)(i), specifically, paragraphs (a)(3)(i)(A) and
(B)beginning July of 2027 and (a)(3)(i)(C) beginning in July 2028. We believe our proposal to remove the measures listed above reduces cost and burden to the public. Our proposals ensure that the Insights Condition is aligned with other proposed policies and changes to the Certification Program that prioritize exchange using FHIR-based APIs. Among the measures that related to FHIR-based APIs, the “use of FHIR in apps through certified health IT” provides the most valuable insights related to implementation and use of FHIR. We welcome comments on these proposals. In the HTI-1 Final Rule (89 FR 1346), we finalized the Insights Condition reporting frequency to annually for any Health IT Module that has or has had an active certification to § 170.407(b)(1) during the prior six months. We propose to revise § 170.407(b)(1) to clarify that a developer must provide an annual response to the Insights Condition of Certification if they had at least one actively certified Health IT Module as of January 1 of the reporting period ( *i.e.,* start of the data collection year) and remain certified under the Certification Program at the time of submission ( *i.e.,* July of the following year). We understand that Health IT Modules can be certified and withdrawn in cycles; however, this proposal would make clear that we expect health IT developers of certified health IT to be accountable for any data collected during the calendar-year
(CY)data collection period, which begins January 1, regardless of how many months the certification remained active. For example, a developer of certified health IT that has a Health IT Module certified to § 170.315(g)(10) for only the first three months of CY 2026 would report data reflecting use during this three-month period even though their Health IT Module was withdrawn or otherwise no longer certified for the remaining nine months of CY 2026. This also applies to newer versions of certified health IT leveraging inherited certified status (ICS). We expect that developers of certified health IT requesting ICS for newer versions would include data for all applicable certified health IT, including newer versions in scope of the Insights Condition requirements as of January 1, at the start of the data collection reporting period. We note that developers of certified health IT would not be expected to separate their certified health IT, in scope of ICS, by versions when submitting their response. This has always been the expectation from what we finalized in the HTI-1 Final Rule (89 FR 1348). We propose to revise the name of § 170.407 (Insights Condition and Maintenance of Certification) to simply “Insights.” This proposed change is intended to ensure consistency and uniformity across all the Conditions and Maintenance of Certification in subpart D of 45 CFR part 170. We welcome comments on our proposals. Technical Updates in Measure Specification Sheets In the HTI-1 Final Rule (89 FR 1313), we stated that while the substantive requirements for each measure are defined in rulemaking, we determined that measure specification sheets are a logical and accessible method for the public to also view the technical specification that supports those requirements, and that this is consistent with the approach used by other HHS programs related to measure specifications ( *e.g.,* CMS Electronic Clinical Quality Measures (CMS eCQMs)). Additionally, the measure specification sheets provide granular definitions and other information needed to operationalize the metrics to ensure they are implemented in a consistent manner across health IT developers. We also stated that we intend to provide up to date measure specification sheets to assist with the regulated community's understanding of the finalized measures and metric calculations (89 FR 1313). In January 2025, we provided developers of certified health IT updated measure specification sheets for certain measures finalized in the HTI-1 Final Rule, with the flexibility to implement either version 2 or version 4 of the measure specification sheets for the first year of reporting. 64 We note that this flexibility is only for the first year of reporting (until July 2027) and that we expect developers to comply with the most up to date version of the measure specification sheets provided at *www.healthIT.gov* in subsequent years. 64 *https://www.healthit.gov/sites/default/files/page/2025-05/insights_measure_spec_sheet_4_fact_sheet_v03.2_508.pdf.* E. ONC Health IT Certification Program Administrative Requirements 1. Principles of Proper Conduct for ONC-ACBs Under the “principles of proper conduct (PoPCs) for ONC-ACBs” in § 170.523, we require ONC-ACBs to provide ASTP/ONC a “certified product listing” in § 170.523(f) which is a current list of Health IT Modules that have been certified. We propose 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. With this proposed revision, we would still require the test procedure and test tool version used. Through our CHPL, we have tracked user access to the test data versions used and have found engagement to be very infrequent. In addition, an analysis of Health IT Modules in the CHPL indicates that the majority of developers do not employ custom data when conducting certification testing but instead utilize the ASTP/ONC-provided test data. Due to low user engagement and little variance from the use of ASTP/ONC-provided test data, we believe documenting the test data provides little value to the public and represents additional administrative burden for both health IT developers and ONC-ACBs. We believe this proposed revision to remove this requirement aligns with our goals to reduce burden for both health IT developers and ONC-ACBs. We propose to make conforming revisions to the PoPCs for ONC-ACBs in § 170.523 by removing cross-references to certain certification criteria that we propose to remove in this proposed rule. Specifically, we propose to remove and reserve § 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 propose to remove and reserve § 170.523(f)(1)(xix), which references the “safety enhanced design” certification criterion (§ 170.315(g)(3)). We also propose 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 propose to remove § 170.315(b)(11)(vi) earlier in this proposed rule. Consistent with the proposals related to the Real World Testing Condition and Maintenance of Certification in § 170.405, we propose to remove the ONC-ACB review and confirmation process for real world testing plans in § 170.523(p)(1) and the reference to submit real world testing plans in § 170.523(p)(3). We welcome comments on our proposals. 2. Health IT Module Certification We propose to revise the “Health IT Module dependent criteria” in § 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. We also propose to renumber the remaining paragraphs in § 170.550(g)(5) and (g)(6) to (g)(1) and (g)(2), respectively. We propose 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 propose 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).” In the Cures Act Final Rule, we adopted § 170.550(e) “standards updates” requiring ONC-ACBs to provide an option for certification of Health IT Modules consistent with SVAP to one or more of the certification criteria referenced in real world testing requirements in § 170.405(a) based on newer versions of standards (85 FR 25952). However, in the regulatory text we erroneously amended § 170.550(e) to require ONC-ACBs provide an option for certification of Health IT Modules consistent with § 171.405(b)(7) or (8). We intended, as indicated by the preamble, to adopt the reference to the real world testing requirements in 45 CFR part 170 instead of 45 CFR part 171 Information Blocking. Therefore, we propose to revise § 170.550(e) to reference the SVAP requirements in § 170.405(b)(7) and (8). We welcome comments on our proposals. 3. Certification to Newer Versions of Certain Standards We propose to revise the “certification to newer versions of certain standards” in § 170.555 by removing references to the term “Complete EHR” as it is no longer relevant in our Certification Program. Retaining the references may cause confusion for the public because the ability to maintain “Complete EHR” certification was only permitted with health IT certified to the 2014 Edition certification criteria, and the “Complete EHR” concept was discontinued for the 2015 Edition (80 FR 62719). The Cures Act Final Rule removed the 2014 Edition certification criteria in § 170.314 and references to “Complete EHR”, and in the HTI-1 Final Rule, we removed the “Complete EHR” language from all reference points in §§ 170.523 and 170.524 (89 FR 1209 through 1210). We continued to remove the remaining references to “Complete EHR” in the HTI-2 TEFCA Final Rule (89 FR 101775) within subpart E of 45 CFR part 170, and we finalized our proposal to remove the term “Complete EHR” including in § 170.555(b)(2). However, we inadvertently excluded amendatory instructions to revise § 170.555(b)(2) in the final rule. Therefore, we propose to revise § 170.555(b)(2) to remove the reference to “Complete EHR.” We welcome comments on our proposal. 4. Effect of Revocation on the Certifications Issued to Health IT Module(s) We propose to revise the title of § 170.570 from “Effect of revocation on the certifications issued to Complete EHRs and EHR Module(s)” to “Effect of revocation on the certifications issued to Health IT Module(s).” As discussed above, the term “Complete EHRs” is no longer a relevant term in our Certification Program and retaining it may cause confusion for the public. Therefore, we propose to revise the title of § 170.570 to further align with our removals of the outdated “Complete EHR” terminology. We welcome comments on our proposal. IV. Information Blocking (Part 171) Comments received in response to the CMS-ASTP/ONC Request for Information; Health Technology Ecosystem (90 FR 21034) (CMS-ASTP/ONC RFI) and other RFIs, such as the Federal Trade Commission's Request for Public Comment Regarding Reducing Anti-Competitive Regulatory Barriers (FTC-2025-0028), expressed concerns about several exceptions to the information blocking rule as well as general concerns about the exceptions. Innovators and patient advocates indicated that some of the exceptions as currently codified may be too broad or are being misused in an anti-competitive or obstructive way. For example, some commenters suggested narrowing or eliminating the exceptions for infeasibility, security, and fees. This proposed rule aims to address several prominent themes among the concerns raised by commenters through proposals below. Each of these proposed revisions to the information blocking regulations would be effective, if finalized, on the effective date of a subsequent final rule. We are also considering further actions such as future rulemaking, guidance, and educational outreach in response to other RFI comments and feedback from stakeholders. A. “Access” and “Use” Definitions In the Cures Act Final Rule, we finalized definitions of “access,” “exchange,” and “use” (85 FR 25805). We explained that the concepts of access, exchange, and use are closely related, and noted that EHI cannot be used unless it can be accessed, and that this often requires that EHI be exchanged among different individuals or entities and through various technological means (85 FR 25805). Our references to various technological means always included access via automated means, such as robotic process automation (commonly referred to as the use of “bots”) 65 and autonomous artificial intelligence systems (“agentic artificial intelligence” or “agentic AI”), 66 but it has come to our attention through RFI comments, our own market observations, and stakeholder interactions that both actors and those who seek to access, exchange, or use EHI would appreciate explicit clarity regarding automated means of access, exchange, or use of EHI, particularly with such means as robotic process automation (commonly referenced as “RPA” or “bots”) and autonomous artificial intelligence systems (commonly referenced in the field as “agentic AI”). 67 Therefore, we propose to add language to the “access” and “use” definitions at 45 CFR 171.102. We propose to explicitly codify that access means the ability or means necessary to make EHI available for exchange or use, including by automation technologies such as robotic process automation and autonomous artificial intelligence systems. Similarly, we propose to explicitly codify that “use” means the ability for EHI, once accessed or exchanged through whatever technological means, to be understood and acted upon, including, without limitation, by automation technologies such as autonomous artificial intelligence systems and robotic process automation. 65 Robotic process automation is software technology in which software “bots” mimic human actions to accomplish computer-based activities, automating otherwise-manual tasks or processes that are structured, repetitive, and follow a set of established rules. Illustrative types of tasks include, without limitation, data retrieval, data entry, and transaction processing ( *e.g.,* customer returns of products, appointment scheduling). *See, e.g.,* Moore, Sara, 2018, “The bots are coming: robotic process automation saves DLA time, money” ( *https://www.dla.mil/About-DLA/News/News-Article-View/Article/1704350/the-bots-are-coming-robotic-process-automation-saves-dla-time-money/* ). 66 Autonomous artificial intelligence systems that are designed to execute complex tasks autonomously or with little human involvement to accomplish pre-determined goals is often referred to a “agentic AI” because these systems' capabilities involve them acting independently or having ability or means (“agency”) to act independently (analogous to a human “having agency” or power to do something) or function as an agent of its user. *See, e.g.,* Merriam-Webster “agentic” ( *https://www.merriam-webster.com/slang/agentic#:~:text=What%20does%20agentic%20mean?,(%E2%80%9Chaving%20agency%22)* ). *See also, e.g.,* Acharya, et al, 2025, “Agentic AI: Autonomous Intelligence for Complex Goals—A Comprehensive Survey,” *IEEEAccess,* Digital Object Identifier 10.1109/ACCESS.2025.3532853 ( *https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10849561* ). 67 We believe “artificial intelligence” is commonly and generally understood to mean a machine-based system that can, for a given set of human-defined objectives, make predictions, recommendations, or decisions influencing real or virtual environments as well as the capability of a computer, computer system, or set of algorithms to imitate intelligent human behavior. *See, e.g.,* National Institute of Standards and Technology Computer Security Research Center glossary entries for “artificial intelligence” ( *https://csrc.nist.gov/glossary/term/artificial_intelligence* ) and “artificial intelligence system” ( *https://csrc.nist.gov/glossary/term/artificial_intelligence_system* ). *See also* Merriam-Webster dictionary definition of “artificial intelligence” ( *https://www.merriam-webster.com/dictionary/artificial%20intelligence* ). In addition to the discussion in the Cures Act Final Rule regarding individuals or entities accessing, exchanging, and using EHI (85 FR 25805), we also discussed the concept of automated access in the HTI-1 Final Rule. Specifically, we noted that some entities may provide data services and that such actions are considered access, exchange, or use regardless of the route used to request, access, or receive data (89 FR 1363). The heterogeneity in how individuals and entities may access, exchange, or use EHI as well as the potential for significantly increased use of automated means to improve efficiency 68 further contributes to a conclusion that actors and those who interact with them would benefit from explicit regulatory text specifying that the access, exchange, and use definitions are not limited to manual processes but apply equally to access, exchange and use of EHI that occurs via automated means including, without limitation, autonomous artificial intelligence systems and that an actor interfering with such access, exchange, or use may implicate the information blocking definition. 68 Moore, Sara, 2018, “The bots are coming: robotic process automation saves DLA time, money” ( *https://www.dla.mil/About-DLA/News/News-Article-View/Article/1704350/the-bots-are-coming-robotic-process-automation-saves-dla-time-money/* ). We are also considering to similarly revise the “exchange” definition in § 171.102. We propose to revise the “exchange” definition in addition to the proposed revisions to the “access” and “use” definitions, as an alternative proposal to only revising the “access” and “use” definitions. Under this alternative proposal, we propose that the meaning of “exchange” includes, without limitation, the ability for EHI to be transmitted, through use of automation technologies ( *e.g.,* robotic process automation, autonomous artificial intelligence systems) or otherwise, between and among different technologies, systems, platforms, or networks. We seek comments on these proposals, including perspectives on whether actors and those who interact with actors would find these explicit regulatory updates helpful. We remind readers that, as we have explained in prior rules, the information blocking regulations are designed to operate in a manner consistent with the framework of the HIPAA Privacy Rule and other laws providing privacy rights for patients (85 FR 25812). Any actor (as defined in 45 CFR 171.102) that is also subject to any provision(s) in 45 CFR parts 160, 162, or 164 must continue to comply with such provision(s) when and to the extent such provisions of the HIPAA Rules are applicable to the actor's conduct (89 FR 1380), such as with providing access, exchange, or use of protected EHI. B. Infeasibility Exception Revisions We propose and seek comments on revisions to two separate conditions of the Infeasibility Exception (45 CFR 171.204). Specifically, we propose to remove the “ *third party seeking modification use”* condition (§ 171.204(a)(3)) and to revise or remove the “ *manner exception exhausted”* condition (§ 171.204(a)(4)). 1. Third Party Seeking Modification Use Condition In the HTI-1 Final Rule, we finalized the “ *third party seeking modification use”* condition of the Infeasibility Exception (§ 171.204(a)(3)). We explained that when this condition applies and the overall exception is met, an actor's practice of not fulfilling a request for use of EHI in order to modify EHI, including but not limited to creation and deletion functionality, will not be considered information blocking (89 FR 1200 and 89 FR 1376 through 1380). As finalized by the HTI-1 Final Rule and currently codified, § 171.204(a)(3) applies to a request to enable use of EHI in order to modify EHI, provided that the request for such use is not from a health care provider that is a HIPAA covered entity (as defined in 45 CFR 160.103) requesting such use from an actor that is its business associate (as defined in 45 CFR 160.103). Thus, the condition is not available when a health care provider that is also a HIPAA covered entity requests (directly, or through another business associate of the health care provider) such use of EHI from an actor who is the health care provider's business associate (88 FR 23866, 89 FR 1380). HTI-1 Proposed Rule commenters expressed concern that certain actors, such as health IT developers of certified health IT, may seek to misuse the proposal to restrict access to EHI in an overly broad manner (89 FR 1377). Of these commenters, some expressed concern that the proposal could potentially inhibit care coordination by making it too easy for an actor holding EHI to simply refuse modification use requests from third parties who also furnish services to the same patient(s) (89 FR 1377). Commenters on the HTI-1 Proposed Rule stated that the limitation to this condition is not broad enough, and that ASTP/ONC should expand the limitation of this condition to also apply when the actor's customers are not HIPAA covered entities; or are not health care providers, but are maintaining EHI in systems licensed by an actor (89 FR 1379). For reasons stated in response to these comments in the HTI-1 Final Rule (89 FR 1379), we did not expand the finalized exclusion from applicability of the condition but noted that we may consider amending the condition in the future (89 FR 1379). In the HTI-2 Proposed Rule, we proposed two revisions to narrow the application and use of the *third party seeking modification use* condition. First, we proposed to narrow the applicability of the condition by changing the words “health care provider” to “covered entity as defined in 45 CFR 160.103” (89 FR 63625), which would expand the circumstances in which the condition could *not* be used. We noted that this proposed expansion of the exclusion would encompass requests from all covered entities to their business associates (89 FR 63625). Second, we also proposed to exclude from applicability of the condition requests from any health care provider (as defined in § 171.102) who is not a HIPAA covered entity (as defined in 45 CFR 160.103) but who is requesting modification use from an actor whose activities would make the actor a business associate of that same health care provider if that health care provider *were* a HIPAA covered entity (89 FR 63625). This was to align with the definition of “actor” under the information blocking regulations. Although comments on the HTI-2 Proposed Rule's potential revisions to the Infeasibility Exception, including but not limited to the *third party seeking modification use* condition, were generally supportive, some commenters once again raised concerns about the potential for actors to misuse the Infeasibility Exception and recommended that we implement measures to mitigate misuse. For example, one commenter suggested requiring an independent review and appeals process for actors' claims of infeasibility as well as the mandated public reporting of all infeasibility claims to hold actors accountable. We received a relatively small number of comments specific to the proposed narrowing of the *third party seeking modification use* condition (§ 171.204(a)(3)). These comments indicate a much more mixed response to this specific proposal than to the Infeasibility Exception. Several commenters supported the proposed narrowing of the *third party seeking modification use* condition's application. Several commenters discussed the proposal as an expansion rather than a contraction of the condition's application, indicating a misunderstanding of the proposal. Several other commenters requested additional clarification to understand the revised condition or even to fully comment on the proposal. For example, one commenter stated that the proposal was vague, and asked ASTP/ONC to clarify the proposal's intended function and scope. Another commenter asked for examples of specific types of scenarios so that they could fully understand the proposal. Several other commenters, both supportive of the proposal's intent and critical of it for various reasons, suggested actors would need extensive guidance to properly implement the *third party seeking modification use* condition. We have evaluated not only our previously proposed revisions to the condition but also the *third party seeking modification use* condition (§ 171.204(a)(3)) in light of: the comments we received in response to the proposal in the HTI-2 Proposed Rule; our observation of the health information ecosystem and health IT market as they stand today; the intent of the information blocking regulations, including what are reasonable and necessary practices for not sharing EHI; and current HHS policy priorities. We now believe the condition as a whole is unnecessary and that removing it will better support the access, exchange, and use of EHI and the goals we set out in the Cures Act Final Rule to unleash innovation and competition for the improvement of health outcomes and lower health care costs for all Americans. In the HTI-1 Proposed Rule, we solicited comment on whether the (then-proposed) *third party seeking modification use* condition should be of limited duration (88 FR 23867). We specifically requested comment on whether ASTP/ONC should consider proposing, in the future, that the condition be eliminated if, at some point, health IT is capable of supporting third-party modification use of EHI by *any* party with a legal right to do so (or no legal prohibition against it), with no or minimal infeasibility or other concerns (88 FR 23867). While the majority of comments on this subject stated either that the proposal should not have a sunset date, or that it would be premature to establish a sunset date at that time, two commenters stated that the condition should or could be eliminated in the future if technology is capable of supporting the aforementioned modification use of EHI, with no or minimal infeasibility or other concerns (89 FR 1378). We agreed in the HTI-1 Final Rule with those commenters who had indicated that it would be premature to establish at that time a sunset date for § 171.204(a)(3) because the appropriateness of eliminating it depended on the continued development of health IT's capability to support lawful third-party modification use of EHI by any party and with no or minimal infeasibility or other concerns (89 FR 1378). However, we also said that if advances in health IT capabilities or other changes in the interoperability and information sharing environment indicated to us that the condition should be modified or sunset, we would anticipate proposing such a change in a future rulemaking (89 FR 1378). We have observed substantial growth in technical approaches that enable efficient, appropriately secure modification use as well as two-way exchange interactions between different developers' systems to support modification use of EHI since HHS announced the HTI-1 Final Rule in December, 2023. 69 These approaches appear to be rapidly maturing. As we increasingly observe modern, innovative approaches efficiently achieving two-way interoperability, we no longer believe it is reasonable or necessary for an actor to dismiss as “infeasible” a request for such use from *any* requestor without engaging in information gathering or analysis to work through the available alternative manners. Thus, we now believe the time is ripe to propose to retire the *third party seeking modification use* condition. Removing the condition in its entirety is also the most efficient option to resolve concerns we have developed from public comments, market observations, and stakeholder interactions. As noted previously, we are concerned that some actors may be misapplying the condition or intentionally abusing customers' and third parties' misunderstandings of the condition or, in the case of business associates, the flexibility we provided for them to confirm whether a third-party modification use request is actually from their HIPAA-regulated health care provider customer. 70 In particular, we are concerned that this condition is being abused by EHR developers to limit third parties, including other actual or potential business associates of the EHR developer's health care provider customer, from accessing or using a health care provider's EHR and relevant EHI. This concern is extremely acute for us in that the ability for health care providers to use other innovative health IT to access and use the EHR has been a fundamental goal for Congress and HHS since we first proposed the information blocking regulations. 69 “HHS Finalizes Rule to Advance Health IT Interoperability and Algorithm Transparency,” news release posted Dec 13, 2023, at *https://www.hhs.gov/about/news/2023/12/13/hhs-finalizes-rule-to-advance-health-it-interoperability-and-algorithm-transparency.html.* Archived content available at: *https://us.pagefreezer.com/en-US/wa/browse/0a7f82bb-be6e-448a-ae11-373d22c37842?find-by-timestamp=2024-01-02T03:56:59Z&url=https:%2F%2Fwww.hhs.gov%2Fabout%2Fnews%2F2023%2F12%2F13%2Fhhs-finalizes-rule-to-advance-health-it-interoperability-and-algorithm-transparency.html&timestamp=2024-01-02T03:43:14Z.* 70 *See* 89 FR 1380 discussion of flexibility for actors to structure communications and operating procedures as well as our statement that, for purposes of § 171.204(a)(3), an actor may choose to verify that the modification use request came from the health care provider themselves or accept the third party's representation of a request as coming from a health care provider of which the actor is a business associate. We are aware that actors may have concerns about third-party modifications relating to the confidentiality, integrity, or availability of EHI, or to the potential risks to patient safety arising from corrupt or misidentified patient data. We remind health care providers, other actors, patients, and others who may have such concerns that we have established exceptions designed for those types of concerns. For example, an actor may choose to satisfy the Security Exception (§ 171.203) where an actor has identified a specific threat that a request for access, exchange, or use poses to the confidentiality, integrity, or availability of EHI in an actor's systems. Similarly, an actor may choose to satisfy the Preventing Harm Exception (§ 171.201) if the actor knows or reasonably suspects specific data a third party seeks to write into the EHI the actor maintains to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason. Actors may choose to satisfy other exceptions, where applicable, regardless of whether we finalize retirement of the *third party seeking modification use* condition of the Infeasibility Exception. We refer readers to subparts B, C, and D of 45 CFR part 171 for the full conditions of each established information blocking exception as currently codified. However, we remind readers that for reasons discussed in Section IV.A.2 of this proposed rule, we propose to revise or remove the *manner exception exhausted* condition from the Infeasibility Exception (§ 171.204) and for reasons discussed in Section IV.D of this proposed rule, we propose to remove subpart D of 45 CFR 171: Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA SM. ). We also remind actors that, if we were to finalize this proposal to remove the *third party seeking modification use* condition, other conditions of the Infeasibility Exception, including the *infeasible under the circumstances* condition would continue to be available to actors. For example, the *infeasible under the circumstances* condition may apply to scenarios where enabling a third party to “write” data to an EHR system would be unduly burdensome on a health IT developer of certified health IT and its health care provider customers. As always, for any practice to be considered information blocking, it must be examined on a case-by-case basis in order to assess the specific facts and circumstances and determine whether the practice meets the information blocking definition ( *see* § 171.103, *see also* IB.FAQ46.1.2022FEB). 71 71 *https://www.healthit.gov/faq/how-would-any-claim-or-report-information-blocking-be-evaluated.* We note again, as we did in the HTI-1 Final Rule, that the *third party seeking modification use* condition does not imply or indicate any change to the HIPAA Rules (89 FR 1380). Any actor that is subject to any provision(s) in 45 CFR parts 160, 162, or 164 must continue to comply with such provision(s) when and to the extent such provisions of the HIPAA Rules are applicable to the actor's conduct (89 FR 1380). To preserve accuracy of references in existing information blocking educational materials to specific conditions of the Infeasibility Exception by CFR citation, we propose to remove and reserve subparagraph
(3)within § 171.204(a). We are not proposing at this time to redesignate any of the other conditions currently codified within § 171.204(a), nor are we proposing to make any other changes to any of these conditions or the *responding to requests* condition in § 171.204(b). We welcome comments on our proposal to remove the *third party seeking modification use* condition of the Infeasibility Exception. 2. Manner Exception Exhausted Condition In the HTI-1 Proposed Rule, we proposed to re-number the “ *infeasible under the circumstances”* condition of the Infeasibility Exception (45 CFR 171.204) and to codify at (a)(4) a new *manner exception exhausted* condition. We stated the proposed *manner exception exhausted* condition would apply where an actor is unable to fulfill a request for access, exchange, or use of EHI despite having exhausted the Manner Exception in § 171.301 by offering all alternative manners in accordance with § 171.301(b), so long as the actor does not currently provide to a substantial number of individuals or entities similarly situated to the requestor the same requested access, exchange, or use of the requested EHI (88 FR 23867). We noted that actors expressed concern about circumstances where the actor's inability to satisfy the Manner Exception's conditions rests solely on the requestor refusing to accept access, exchange, or use in *any* manner consistent with § 171.301 and that fulfilling the request in the manner requested would require substantial technical or financial resources, or both, in the view of the actor, including significant opportunity costs (88 FR 23868). We noted that actors may have been experiencing a problematic level of uncertainty about whether they will be engaging in information blocking if they decline demands from requestors for non-standard, non-scalable solutions that they do not currently support. We noted that an actor might have experienced such uncertainty *even after* that actor had offered to provide access, exchange, or use of EHI in the same manner(s) the actor makes the EHI generally available to its customers or affiliates, *and* through other standards-based manners, consistent with § 171.301—including offering terms for such manners that are consistent with the Fees (§ 171.302) and Licensing (§ 171.303) Exceptions (88 FR 23868). We indicated observing such uncertainty among actors with substantial skills and other resources to develop new, unique or unusual manners of supporting access, exchange, or use of EHI (88 FR 23868). We explained that the proposed *manner exception exhausted* condition would provide actors the option of satisfying the Infeasibility Exception without needing to assess whether they *could* theoretically or technically meet the requestor's particularized demands regarding the manner and/or the terms in which to achieve access, exchange, or use of requested EHI. We proposed that an actor could satisfy the Infeasibility Exception when the actor met the requirements of the § 171.204(b) *responding to requests* condition and the three factors of *manner exception exhausted* condition were true:
(i)The actor could not reach agreement with a requestor in accordance with § 171.301(a) *manner requested* condition (as we have proposed it in this proposed rule) or was technically unable to fulfill a request for electronic health information in the manner requested;
(ii)The actor offered all alternative manners “in accordance with” § 171.301(b) *alternative manner* condition (as we have proposed it in this proposed rule) for the electronic health information requested but could not reach agreement with the requestor; and
(iii)The actor does not provide the same access, exchange, or use of the requested electronic health information to a substantial number of individuals or entities that are similarly situated to the requester (88 FR 23869). We requested comments on all aspects of the proposal. In particular, in regards to the second factor, we asked whether an actor should have to offer access, exchange, or use in manners that would satisfy all three of the alternative manners in § 171.301(b)(1) 72 or if it should be sufficient for an actor to offer to fulfill the request in two manners that use content and transport standards published by the Federal Government or a standards-developing organization accredited by the American National Standards Institute; or by offering fulfillment in at least one such manner *and* an alternative machine-readable format consistent with § 171.301(b)(1)(iii) (88 FR 23869). 72 Here we are referring to § 171.301(b)(2) as it was codified at the time the HTI-1 Proposed Rule published; re-designation of paragraphs within § 171.301 was proposed in that NPRM and finalized in the HTI-1 Final Rule (89 FR 1437, *see also* 89 FR 1372). Regarding the third factor, we asked whether the language provided adequate assurance that actors would not be able to misuse the § 171.204(a)(4) *manner exception exhausted* condition to avoid supplying some particular requestor(s) with manner(s) of access, exchange, or use of the requested EHI that would be more accurately characterized as generally available than as new, unique, or unusual (88 FR 23870). In particular, we noted that the third factor is intended to ensure the condition cannot be satisfied where a manner (mechanisms, interoperability elements) is currently supported for a substantial number of individuals or entities but the responding actor wants to deny that mechanism to particular requestor(s) for inappropriate reasons, such as to discriminate against competitors, potential competitors, or those the responding actor may be concerned could use the resultant access, exchange, or use of EHI to furnish, develop, or facilitate development of products or services that could compete with those of the actor (88 FR 23870). We asked if the flexibility of the “substantial number” factor would better recognize variations in actors' operational contexts, including their organization sizes, as compared to the clarity provided by a simple fixed threshold of “more than one,” or even just one other entity. We also sought comment on whether we should include “similarly situated” requestors or if such a phrase risked allowing actors to discriminate based on requestor size or type (88 FR 23870). In the HTI-1 Final Rule, we finalized the *manner exception exhausted* condition of the Infeasibility Exception (§ 171.204(a)(4)). In finalizing the *manner exception exhausted* condition, we explained that when an actor either technically cannot provide the access, exchange, or use of EHI in the manner requested, or the actor and requestor cannot reach agreeable terms on the manner requested, the actor must attempt to fulfill the request using the alternative manners in § 171.301(b) in order to exhaust the Manner Exception (89 FR 1381). Under the Manner Exception, for any alternative manner, the requestor must either specify the manner they would accept (§ 171.301(b)(1)(i) and (ii)) or specifically agree with the machine-readable format that they would accept (§ 171.301(b)(1)(iii)). We stated that in situations where an actor offers at least two alternative manners and the requestor does not specify or agree to receive the EHI via the offered alternative manners (as may be the case if the requestor does not want to receive the EHI in such a manner or cannot receive the EHI in such a manner), an actor may seek to satisfy the *manner exception exhausted* condition of the Infeasibility Exception (89 FR 1381). In other words, under the *manner exception exhausted* condition, it would not matter whether the requestor specified the alternative manner, which is a requirement to meet the Manner Exception under § 171.301(b)(1)(i) and (ii). And the *manner exception exhausted* condition of the Infeasibility Exception could be met if the requestor did not agree with the actor upon an offered alternative machine-readable format, which is a requirement to meet the Manner Exception under § 171.301(b)(1)(iii). The *manner exception exhausted* condition of the Infeasibility Exception, as finalized in the HTI-1 Final Rule, considers three factors. First, it requires that the actor could not reach agreement with a requestor in accordance with § 171.301(a) or was technically unable to fulfill a request for EHI in the manner requested (§ 171.204(a)(4)(i), 89 FR 1384 through 85). Second, the condition requires that the actor offered at least two alternative manners in accordance with § 171.301(b) (whether or not the requestor identified the alternative manner and/or agreed to it), one of which must use either technology certified to standard(s) adopted in part 170 (§ 171.301(b)(1)(i)) or published content and transport standards consistent with § 171.301(b)(1)(ii) ( *see* § 171.204(a)(4)(ii)). The third factor requires that the actor does not provide the same access, exchange, or use of the requested EHI to a substantial number of individuals or entities that are similarly situated to the requester (§ 171.204(a)(4)(iii), 89 FR 1385 through 86). We explained what “provide” means in this context (89 FR 1385 through 86), as well as “substantial number” (89 FR 1384 through 85) and “similarly situated” (89 FR 1386). Specifically, we noted that “similarly situated” would serve to indicate that different specific individuals or entities within a class of such individuals or entities who are similarly situated to one another should be treated in a consistent and non-discriminatory manner, and that it is not our intent for the “individuals or entities that are similarly situated to the requester” criterion of the condition to be used in a way that differentiates the same access to EHI simply based on the requestor's status, such as an individual ( *e.g.,* a patient) or entity ( *e.g.,* a healthcare system) (89 FR 1386). We explained that, in determining whether a requestor is similarly situated, an actor shall not discriminate based on certain factors, including whether the requestor is an individual as defined in § 171.202(a)(2), the health care provider type and size, and whether the requestor is a competitor of the actor or whether providing such access, exchange, or use, would facilitate competition with the actor (89 FR 1386). We finalized these factors in § 171.204(a)(4)(iv). The *manner exception exhausted* condition of the Infeasibility Exception was intended to provide clarity and flexibility for actors. We did not intend for it to cover any unreasonable or unnecessary practice that would allow an actor to avoid providing the access, exchange, or use of EHI in a manner already supported by that actor. Based on comments received in response to the CMS-ASTP/ONC RFI, questions received through the ASTP/ONC Health IT Feedback and Inquiry Portal, 73 and other stakeholder feedback, we are concerned that actors may be abusing the exception in various ways, including claiming to requestors that the *manner exception exhausted* condition applies when the actor has not, in fact, explored whether they *could* reach agreeable terms to fulfill a request in the manner requested, or has not attempted to fulfill the request in at least two other manners consistent with the § 171.301(b) *alternative manner,* or both. Additionally, we are concerned that certain terms and criteria of the condition ( *i.e.,* “same,” “substantial number” and “similarly situated”) are being misused to deny requestors access to *existing* APIs and other manners of access, exchange, and use that have been granted to other parties. To address these concerns, we now propose to modify the condition to eliminate the potential for misuse and abuse. 73 *https://healthit.gov/feedback.* Specifically, we propose (in § 171.204(a)(4)(ii)) to increase the minimum number of alternative manners required to be considered to have “exhausted” the Manner Exception from two to “all,” in line with the original (HTI-1 Proposed Rule) proposal for the condition. In referring to “all alternative manners,” we do not mean all possible manners of exchange other than the manner requested. Rather, we specifically mean those manners that are set forth in subparagraph (i), (ii), or
(iii)of § 171.301(b)(1). We seek comment on whether, and to what extent, actors and those who request EHI access, exchange, or use from actors would find useful a further reiteration in the text of the condition that each alternative manner must be attempted consistent with § 171.301(b) (the *alternative manner* condition of the Manner Exception) in order to satisfy the *manner exception exhausted* condition of the Infeasibility Exception (§ 171.204(a)(4)). This addition would further reiterate what the regulation text says at present and what has been stated in the preamble of the HTI-1 Final Rule ( *see, e.g.,* 89 FR 1383). Further, we remind actors that a manner that meets any sub-paragraph within § 171.301(b)(1) must be consistent with the entirety of § 171.302(b), which includes § 171.301(b)(2), under which any fees that would be charged by the actor in relation to fulfilling the request must satisfy the Fees Exception (§ 171.302), and § 171.301(b)(3), under which any license of interoperability elements granted by the actor in relation to fulfilling the request satisfy the Licensing Exception (§ 171.303). We also welcome comment on whether revisions to the wording of § 171.204(a)(4)(ii) would help ensure an actor can only claim to a requestor that fulfilling the request is “infeasible” under the *manner exception exhausted* condition when the actor has exhausted the Manner Exception, as we intend. We welcome comment on whether any such revisions could also discourage actors from attempting to abuse the condition. We also propose to incorporate language into the regulation text consistent with the preamble of the HTI-1 Final Rule, as discussed above, to emphasize a distinction between the Manner Exception (§ 171.301) and the *manner exception exhausted* condition (§ 171.204(a)(4)): satisfying the *manner exception exhausted* condition does not require that the requestor identify the alternative manner or agree to it, which is required for actors to be able to fully meet the Manner Exception. In § 171.204(a)(4)(iii), we propose three revisions. First, we proposed to replace “same” with “analogous” as it refers to the access, exchange, or use of EHI. We discussed in the HTI-1 Final Rule how “same” meant the same requested access, exchange, or use, including the “same” manners of EHI access, exchange, or use, as provided to others. We still intend to include the concept of “the same” access, exchange, or use of EHI in consideration of whether the provision is met, but we believe the more expansive term “analogous” is more appropriate. We believe using “analogous” access, exchange, or use in comparison to what the actor provides to other individual(s) or entity(ies) is a basis less subject to manipulation than “same,” which some actors may argue equates to “identical” access, exchange, or use of EHI. We do not intend for “same” to be interpreted in a way that could be limiting and potentially manipulated to deny access, exchange, or use. For example, this condition would not be available to an actor when a requestor requests API access with certain features, such as “write” capabilities or filtering functionality, that the actor provides to other entities. Assuming for the sake of this example that the actor is not prohibited by applicable law from providing the requested access, exchange, or use of the requested EHI to the requestor, 74 the request is not infeasible under any other condition in § 171.204 ( *e.g.,* § 171.204(a)(1) *uncontrollable events* ) and that no other exception in subpart B of part 171 ( *e.g.,* the Privacy Exception) applies to the particular facts and circumstances, we would expect such access would be provided to the requestor without unnecessary delay. In providing such access, exchange, or use, an actor who seeks certainty that their practices in fulfilling the requested access, exchange, or use of EHI via the API with certain features will not be considered information blocking can align their practices with other relevant exception(s), such as the Fees Exception and, as necessary, the Licensing Exception. 75 74 Where applicable law prohibits an actor from fulfilling a requestor's requested access, exchange, or use of requested EHI, the actor need not satisfy an exception to have certainty that complying with the law to which they are subject will not be considered “information blocking.” Where applicable law, such as the HIPAA Privacy Rule, permits use or disclosure (access, exchange, or use) of the requested EHI *only* when certain requirements (“preconditions”) are met, the Precondition Not Satisfied (45 CFR 171.202(b)) sub-exception of the Privacy Exception outlines a framework for actors to follow so that the actors' practices of not fulfilling requests to access, exchange, or use EHI would not constitute information blocking when a precondition of applicable law has not been satisfied. 75 “Interoperability element” is defined in § 171.102. Additional information about this definition is available in the preamble of the Cures Act Final Rule at 85 FR 25806 through 25808. Similarly, the *manner exception exhausted* condition (as § 171.204(a)(4) is currently codified or as we propose in this proposed rule to modify it) would not be available to an actor if the actor makes an API available to entities or individuals and a requestor attempts to access the API through automated means (such as robotic process automation and agentic AI). 76 In such cases, the access achieved by automated means would be the same and analogous to an entity or individual accessing the API using more manual means. Accordingly, we believe replacing “the same” with “analogous” is a better basis for comparing the request with what the actor provides to other individuals or entities, including those who may use different automated means, or may use manual means. We believe this revision aligns more with the intent of the statutory information blocking definition (PHSA section 3022(a)(1)), which focuses on practices “likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information” without any specification of, or limitation to, access, exchange, or use of EHI through particular mechanisms, technologies, or workflows. 76 Please see section IV.A of this preamble, above, for descriptions of robotic process automation and agentic AI. Second and third, we propose: changing the “substantial number” element to “any,” by which we mean at least one individual or entity; and removing consideration of whether such individual or entity is similarly situated to the requestor. The proposed revisions to § 171.204(a)(4)(iii) would explicitly exclude from application of the condition any situation where the actor offers at least one individual or entity the requested access, exchange, or use. These revisions would alleviate concerns that the terms “substantial” and “similarly situated” are being manipulated to deny access, exchange, or use. Further, we do not believe that removal of the terms would undermine the stated overall objective of the condition when it was proposed, which was to provide certainty to actors when they were faced with situations where the request would involve building “one off” access, exchange, or use interfaces. Rather, the condition could still be met if the actor does not provide analogous access, exchange, or use of the requested EHI to any other individual or entity. If we finalize the proposal to retain the § 171.204(a)(4) condition with removal of the “similarly situated” element from § 171.204(a)(4)(iii), instead of our alternative proposal (below) to remove § 171.204(a)(4) in its entirety, we also propose to remove § 171.204(a)(4)(iv). Specifying bases an actor shall not use in determining whether a requestor is “similarly situated” under § 171.204(a)(4)(iii) would be moot upon removal of “substantially similar” from § 171.204(a)(4)(iii). In the alternative to our proposed revisions to the condition above, we propose to remove the § 171.204(a)(4) *manner exception exhausted* condition entirely if public comments we receive on this proposed rule indicate that our proposed revisions would not be sufficient to eliminate or substantially mitigate the misuse or abuse of the condition. We seek comments on this alternative approach. If we were to finalize the alternative proposal to remove the § 171.204(a)(4) *manner exception exhausted* condition, we would reserve subparagraph
(4)within § 171.204(a) to preserve accuracy of references in existing information blocking education materials to specific conditions of the Infeasibility Exception by CFR citation. We are not proposing at this time to redesignate any of the conditions currently codified within § 171.204(a) that would remain in the event we finalize the alternative proposal to remove subparagraph (4), the proposal discussed in section IV.A.1 of this preamble to remove subparagraph
(3)of § 171.204(a), or both. C. Manner Exception In the Cures Act Final Rule, we established the Manner Exception (then referred to as the “Content and Manner” Exception) in § 171.301 (85 FR 25959, *see also* 85 FR 25875 through 25879). In finalizing the exception, we stated our belief that it addressed comments received regarding the breadth of the EHI definition and flexibility in the manner an actor fulfills a request to access, exchange, or use EHI, while providing market participants the ability to reach and maintain market negotiated terms (85 FR 25876). As finalized in the Cures Act Final Rule (85 FR 25642) and the Cures Act Interim Final Rule (85 FR 70085), the information blocking definition (§ 171.103) and the Content and Manner Exception (§ 171.301) were limited for a period of time to a subset of EHI that was narrower than the EHI definition finalized in the Cures Act Final Rule in § 171.102. The narrower subset included only the EHI identified by the data elements represented in USCDI version 1 for the first 18 months (until May 2, 2022) after the applicability date for 45 CFR part 171 (November 2, 2020) (85 FR 25792). The Cures Act Interim Final Rule extended the applicability date of 45 CFR part 171 to April 5, 2021 (85 FR 70069). This extension moved the end of the first 18 months of applicability of 45 CFR part 171 to October 5, 2022 (85 FR 70069). In the HTI-1 Final Rule (effective April 8, 2024), we revised § 171.301 to remove reference to the *content* condition, which had been moot as of October 6, 2022 (89 FR 1372). We also accordingly renumbered the remaining provisions in § 171.301 and simplified the name to the “Manner” Exception (89 FR 1372). Based on comments received in response to the CMS-ASTP/ONC RFI, questions received through the ASTP/ONC Health IT Feedback and Inquiry Portal, 77 and other stakeholder feedback, we are concerned that some actors may be attempting to abuse the exception, and that all participants in the health information ecosystem would benefit from greater certainty that the *manner requested* condition does not apply to any contracts, agreements, or licenses that are for the purposes of accomplishing access, exchange, or use of EHI in the manner requested, but that:
(1)are not at “market” rate (85 FR 25877);
(2)are contracts of adhesion; or
(3)contain unconscionable terms (as defined below). Specifically, we are concerned that some actors may be incorrectly citing the *manner requested* condition to persuade requestors that the exception applies to agreements and terms to which it has never applied. 77 *https://healthit.gov/feedback.* In both the Cures Act Proposed Rule and the Cures Act Final Rule, we recognized the inherent power inequity between EHR developers and various types of requestors ( *see* 84 FR 7520, noting that EHR developers are in a unique position to block access to EHI for use in competing systems or applications). We also specifically address this concept of inequity and how it could impact terms of contracts in the Cures Act Final Rule (85 FR 25812). Foremost, we stated that a contract may implicate the information blocking provision if it included unconscionable terms for the access, exchange, or use of EHI or licensing of an interoperability element, which could include, but not be limited to, requiring a software company that produced a patient access application to relinquish all IP rights to the actor or agreeing to indemnify the actor for acts beyond standard practice, such as gross negligence on the part of the actor. Further, we noted that such terms may be problematic with regard to information blocking in situations involving unequal bargaining power related to accessing, exchanging, and using EHI (85 FR 25812). As currently codified, the Manner Exception's *manner requested* condition (§ 171.301(a)) applies when an actor fulfills a request for EHI in any manner requested that the actor is technically able to fulfill and for which the actor is able to reach agreeable terms with the requestor. As set forth in the Cures Act Final Rule, if the actor fulfills a request to access, exchange, or use EHI in any manner requested, the fees or licensing agreements associated with fulfilling such requests will not be limited by the conditions in the Fees Exception (§ 171.302) or Licensing Exception (§ 171.303). Our rationale was that actors would first attempt to negotiate agreements in any manner requested with terms the actor chooses at the “market” rate—which supports innovation and competition (85 FR 25877). If the actor could not reach agreeable terms by negotiation at the market rate, actors could still fulfill the request in an alternative manner (85 FR 25877). Given the language in the Cures Act Final Rule, we understood “agreeable terms” were those terms agreed upon by actors through arms-length negotiation at market rate (85 FR 25877). Agreeable terms did not incorporate contracts of adhesion or contracts with unconscionable terms. These types of agreements, by their very nature, are either not agreed upon through arm's length negotiation or at market rate. Further, the *manner requested* condition allows the negotiation of market rates and terms for the *manner* of access, exchange, or use only—that is, the requested combination of content and transport standard(s), 78 ability to use an API or portal, or any other requested health IT functionality or technological mechanism that otherwise achieves the requested access, exchange, or use of the requested EHI. 79 The Manner Exception does not apply to an actor's practices in negotiating any aspect of a contract with a requestor *other than* the manner in which access, exchange, or use of requested EHI is achieved and, *if* the request is fulfilled in the *manner requested,* to market fees for items and services provided and market terms for any licensing of interoperability elements needed to fulfill the requested access, exchange, and use of EHI in that manner. 78 In the Cures Act Final Rule preamble discussion of alternative manners using content and transport standards specified by the requestor under what is now codified at § 171.301(b)(1)(ii), such an alternative “manner” includes two distinct components:
(1)content standard; and
(2)transport standard (85 FR 25878). 79 Manners of access, exchange, and use would include, without limitation and where applicable, *modification* use of EHI that may be maintained by the actor (for example, where an actor maintains EHI on behalf of a health care provider and the health care provider wants to use a third-party app or service to add or update data points in various data classes or elements). We reiterate the plain language of the Manner Exception, and particularly the *manner requested* condition, in that the Manner Exception only covers the technical manner of exchange of the requested EHI, and not any other term(s) in any contract or agreement entered or reached between the actor and requestor. Further, such contracts or agreements for access, exchange, and use of EHI cannot be contracts of adhesion or contracts containing unconscionable terms. These types of contracts are not covered by the Manner Exception even if these agreements were styled as, or in fact were, achieving access, exchange, or use of the requested EHI in the requested manner. These types of contracts would also likely constitute an interference (85 FR 25813) under the information blocking regulations. To further explicate the applicability of the Manner Exception where the actor has the technical capability and is able to reach agreement with the requestor to fulfill access, exchange, or use of requested EHI in a manner requested by the requestor, we offer two proposals. First, we propose to revise § 171.301(a)(2) to add a new subparagraph
(iii)to incorporate in regulation text and explicitly state that any contract or agreement related to the access, exchange, or use of EHI:
(1)must be at market rate;
(2)must not be a contract of adhesion; and
(3)must not contain unconscionable terms. As stated in the Cures Act Final Rule, agreements must be negotiated at market rate (85 FR 25877). We propose to define, in § 171.102, “market rate” using paragraph
(1)of the definition of “fair market value” found in the Stark Law regulations at 42 CFR 411.351: “(1) *General.* The value in an arm's-length transaction, consistent with the general market value of the subject transaction” (42 CFR 411.351). We propose to define, in § 171.102, “contract of adhesion” as a contract provided on a standardized form, or on a “take it or leave it basis” without a realistic opportunity to bargain where the desired product, services, access, use, or exchange cannot be provided except by acquiescing to the form contract. We propose to incorporate the Merriam Webster dictionary's definition of “unconscionable” to define, in § 171.102, “unconscionable terms” as those terms that are excessive, unreasonable, or shockingly unfair or unjust. We further explain unconscionable terms by way of examples in this preamble as well as by the examples found in the preamble to the Cures Act Final Rule (85 FR 25811 through 25812). Examples of unconscionable terms related to the access, exchange, or use of EHI would include indemnification waivers, waivers of rights to file claims of wrongdoing with state or Federal authorities, terms that specify unreasonable revenue sharing beyond fair market value (as already prohibited by the Fees Exception), or terms that require surrendering intellectual property rights without fair compensation. An actor's practice that meets the *manner requested* condition of the Manner Exception does not currently, and would not under the first proposed revision, have to also satisfy the Fees Exception (§ 171.302) or the Licensing Exception (§ 171.303) in order for the actor to have certainty the actor's practice specific to charging a fee or licensing interoperability elements for fulfilling the requested EHI access, exchange, or use in the *manner requested* would not be considered information blocking. This proposed approach offers both benefits and some potential challenges. We believe this proposal to define new terms and emphasize the parameters of the condition would offer more certainty to responding actors and to requestors 80 about what types, terms, or provisions of agreements could be covered by the Manner Exception under the *manner requested* condition (§ 171.301(a)). However, we also recognize that actors would not have the same degree of certainty that any fees and licensing terms the actor may seek to institute are covered by an exception under the proposed revision of § 171.301(a) as they would have under the Fees Exception and the Licensing Exception. Similarly, a requestor would not have the clarity and certainty provided by the Fees Exception's (§ 171.302) specifications for the fees it covers, including its exclusion of certain bases for fees ( *e.g.,* § 171.302(b)(3) and (4)), or the requirements in the Licensing Exception (§ 171.303) for an actor's practices in licensing interoperability elements in relation to fulfilling access, exchange, or use of requested EHI in the manner requested. Therefore, we offer another proposal discussed in more detail below. As to this proposal, we seek comments on the proposed provision and proposed definitions, suggestions for alternative definitions, and any missing components that would more explicitly describe excluded contractual terms. For example, should we instead, or in addition, include the definition of “general market value” at 42 CFR 411.351—“with respect to the purchase of an asset, the price that an asset would bring on the date of acquisition of the asset as the result of bona fide bargaining between a well-informed buyer and seller that are not otherwise in a position to generate business for each other.”? 80 Any individual or entity can be a requestor, including without limitation an individual or entity that happens to meet the § 171.102 “actor” definition. For example, a health care provider is often also a requestor seeking access, exchange, or use of EHI from health IT developers of certified health IT, HIN/HIEs, and other health care providers. We recognize the first proposed approach of adding explicit language to § 171.301(a) to ensure fair market rates and exclude certain types of contracts and contractual terms may not fully address all concerns about the misuse of the Manner Exception and may add complexity or ambiguity with new terms. Therefore, we also propose in the alternative to remove paragraph (a)(2) from the *manner requested* condition of the Manner Exception, and explicitly apply the conditions of both the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303) to any agreement an actor makes with a requestor related to fulfilling the request for access, exchange, or use of EHI in any manner requested. Paragraph (a)(2) is where the *manner requested* condition currently states that if an actor fulfills a request for EHI in any manner requested, any fees charged by the actor in relation to fulfilling the request are not required to satisfy the Fees Exception (subparagraph
(i)of paragraph (a)(2)), and any license of interoperability elements granted by the actor in relation to fulfilling the request are not required to satisfy the Licensing Exception (subparagraph
(ii)of paragraph (a)(2)). Under this alternative proposal, we propose that the agreement would need to satisfy the Fees Exception and the Licensing Exception, even when fulfilling the request in any manner requested. This approach would mean that, while the actor and requestor retain flexibility to reach mutually agreeable terms for the actor to fulfill access, exchange, or use of the requested EHI in the manner requested, any fees charged by the actor and any licensing terms for interoperability elements from the actor to the requestor related to fulfilling the request must meet all of the requirements of the Fees Exception and the Licensing Exception for the actor to have certainty that their practice of charging fees or licensing interoperability elements would not constitute information blocking. In addition to simplifying the Manner Exception, this alternative proposal to revise the Manner Exception could promote greater consistency in actors' practices specific to fees and licensing terms for fulfilling EHI access, exchange, and use requests by following specified provisions of regulatory exceptions. Removing paragraph
(2)from § 171.301(a) and applying the Fees and Licensing Exceptions also specifically addresses the concerns related to indemnification terms in contracts, as well as revenue-sharing agreements. Under this alternative proposal, the actor and requestor would retain the flexibility to negotiate and execute specific details related to the requested manner of access, exchange, or use of the requested EHI. This proposal also ensures there is no mistaken belief that the Manner Exception would apply to any other practice of the actor related to fulfilling the request, including any contract or agreement on fees, licensing terms, or any matter other than the specific technical details of what EHI is requested, and how the request to access, exchange, or use the requested EHI will be fulfilled. As noted above, we have heard that actors may be abusing the *manner requested* conditions to convince requestors to accept disagreeable terms that would be considered an interference and likely information blocking. Removing paragraph
(2)from § 171.301(a) and applying the Fees Exception and Licensing Exception would address these issues. We welcome comments on our proposed revisions to the Manner Exception, including each of our proposals. D. Removal of Subpart D Exception and Other Provisions Specific to TEFCA In the HTI-1 Final Rule, we finalized a new TEFCA Manner Exception in 45 CFR 171.403, explaining that an actor's practice of limiting the manner in which it fulfills a request for access, exchange, or use of EHI to providing such access, exchange, or use only via TEFCA would not be considered information blocking when the practice follows certain conditions (89 FR 1387). The conditions include that the actor and requestor are both part of TEFCA, that the requestor is capable of such access, exchange, or use of the requested EHI from the actor via TEFCA, that the request is not made via the standards adopted in 45 CFR 170.215 or version approved pursuant to 45 CFR 170.405(b)(8), and that any fees charged by the actor and the terms for any license of interoperability elements granted by the actor in relation to fulfilling the request satisfy, respectively, the Fees Exception (45 CFR 171.302) and the Licensing Exception (§ 171.303) (89 FR 1388). In the HTI-2 Proposed Rule, we requested further comment on the TEFCA Manner Exception. We noted that the finalized exception differed in two ways from the proposal in the HTI-1 Proposed Rule: by applying the Fees Exception and the Licensing Exception to the TEFCA Manner Exception, and by including the limitation that carves out requests made for access, exchange, or use of EHI via FHIR API standards (89 FR 63643). We also solicited comment on the “FHIR” carve out, specifically for options for revising or sunsetting the condition (89 FR 63643). Having considered comments received, we finalized the exception without changes in the HTI-2 Final Rule (89 FR 101778 through 80). We also proposed in the HTI-2 Proposed Rule (89 FR 63642) and finalized in the HTI-2 Final Rule (89 FR 101777 through 78) the addition of a definitions section (§ 171.401) to Subpart D of part 171: “Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA TM )”. We now propose to remove the TEFCA Manner Exception (§ 171.403) from 45 CFR part 171. Based on TEFCA's continued implementation and maturation and public comments received, including those received in response to the CMS-ASTP/ONC Request for Information; Health Technology Ecosystem (90 FR 21034) (CMS-ASTP/ONC RFI), the removal of the TEFCA Manner Exception (§ 171.403) is appropriate for multiple reasons. The exception was intended to incentivize participation in TEFCA. However, many of the Qualified Health Information Networks (QHINs)—who already participate in TEFCA—were critical of the exception when it was proposed and presumably did not find the exception to be an incentive. Further, we have observed that there is significant private sector investment being made toward TEFCA participation in the health information ecosystem. In comments on the CMS-ASTP RFI, stakeholders representing health care providers, technology innovators, and other perspectives, in addition to QHINs, advocated for continued use and advancement of TEFCA. We therefore believe that it is unnecessary to sustain the TEFCA Manner Exception to incentivize participation in TEFCA. We also believe the TEFCA Exception may be negatively impacting participants in the health information ecosystem due to some entities' potential misunderstanding regarding its purpose and applicability. For example, although we stated when we finalized the exception that an actor responding to a request from an individual ( *e.g.,* a patient or the patient's personal representative) would not be able to make use of this exception, we have observed some ongoing misunderstanding of this exception as shielding actors who are part of TEFCA from information blocking penalties for practices that interfere with individual-access use cases. The exception is also now unnecessary because it describes activities that are, given the robust TEFCA participation we are seeing, still covered by the Manner Exception (§ 171.301) or Infeasibility Exception (§ 171.204). The Manner Exception encourages active negotiation between a requestor and actor toward getting requestors the EHI access, exchange, and use they seek in a manner to which the requestor agrees. Conversely, the TEFCA Manner Exception allows for responding actors to limit a requestor who also participates in TEFCA to receiving EHI only via TEFCA when certain conditions are met by the actor, potentially slowing adoption of more innovative manners of access, exchange, or use than may be generally supported by TEFCA participants at any given point in time. Further, if an actor is unable to provide access, exchange, or use of EHI in the manner requested, the actor may find the Infeasibility Exception applicable to their circumstances, including the “ *manner exception exhausted”* condition. With consideration of comments received in response to the CMS-ASTP/ONC RFI and other RFIs, such as the Federal Trade Commission's Request for Public Comment Regarding Reducing Anti-Competitive Regulatory Barriers (FTC-2025-0028), we have become concerned that the narrow TEFCA Manner Exception (applicable only to certain types of exchange) may create an unintended ceiling on future growth of TEFCA by discouraging participation by new entrants for whom other manners of access, exchange, or use of EHI will more efficiently support their innovative products and services. Instead, TEFCA's future growth will be supported by competition-oriented policies, compliance with applicable laws, and the continual advancement of efficient, interoperable manners of EHI access, exchange, and use of EHI that TEFCA supports. We note that removing the TEFCA Manner Exception would not remove any obligations an actor may have as a QHIN, Participant, or Sub-participant in TEFCA to fulfill TEFCA requirements. The TEFCA Manner Exception does not create, reduce, or otherwise affect any obligations any actor may have as a QHIN, Participant, or Sub-participant in TEFCA to fulfill TEFCA requirements. Finally, we remind readers that removing this exception would *not* mean that a practice that would have been covered by the TEFCA Manner Exception would automatically be considered information blocking. As always, for any practice to be considered information blocking, it must be examined on a case-by-case basis in order to assess the specific facts and circumstances and determine whether the practice meets the information blocking definition ( *see* § 171.103, *see also* IB.FAQ46.1.2022FEB: How would any claim or report of information blocking be evaluated). 81 81 *https://www.healthit.gov/faq/how-would-any-claim-or-report-information-blocking-be-evaluated.* Because the TEFCA Manner Exception (§ 171.403) is the only exception codified in subpart D of part 171, we also propose to remove the entire subpart (subpart D). As currently codified, subpart D includes only three sections: § 171.400; § 171.401; and § 171.403. The removal of § 171.403 would render the remaining two sections unnecessary. Section 171.400, “Availability and effect of exceptions,” mirrors §§ 171.200 and 171.300, stating that a practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in subpart D by meeting all applicable requirements and conditions of the exception at all relevant times (89 FR 1388). Without any exceptions specific to practices related to an actor's participation in TEFCA, § 171.400 would serve no purpose. Similarly, § 171.401 would serve no purpose because it only includes definitions for the subpart via cross-reference to the TEFCA definitions included 45 CFR part 172, “Trusted Exchange Framework and Common Agreement.” We welcome comments on these proposals. V. Incorporation by Reference The Office of the Federal Register has established requirements for materials ( *e.g.,* standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5). Specifically, 1 CFR 51.5(a) requires agencies to discuss, in the preamble of a proposed rule, the ways that the materials they propose to incorporate by reference are reasonably available to interested parties and how interested parties can obtain the materials, and to summarize, in the preamble of the proposed rule, the material it proposes to incorporate by reference. To make the material we intend to incorporate by reference reasonably available, we provide a uniform resource locator
(URL)for the standard. This standard is directly accessible through the URL provided. As an alternative, a copy of the standard may be viewed for free at the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201. Please call
(202)690-7171 in advance to arrange inspection. The NTTAA and the OMB Circular A-119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. As discussed in section III.B.1.a of this preamble, we have followed the NTTAA and OMB Circular A-119 in proposing a standard for adoption, including describing any exceptions in the adoption of the standard. As required by 1 CFR 51.5(a), we provide a summary of the standard we propose to adopt and subsequently incorporate by reference in the CFR. We also provide relevant information about the standard throughout the preamble. United States Core Data for Interoperability—45 CFR 170.213 • *United States Core Data for Interoperability (USCDI), June 2025, Version 3.1 (v3.1)* URL: *https://www.healthit.gov/isp/sites/isp/files/USCDI-Version-3-1_2025_508.pdf* . This is a direct access link. *Summary:* USCDI establishes a minimum set of data classes that are required to be interoperable nationwide and is designed to be expanded in an iterative and predictable way over time. The following standards appear in the amendatory text of this document and have already been approved for the locations in which they appear: —HL7 Messaging Standard Version 2.5.1, —HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition, —HL7 CDA© Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1, Volume 1—Introductory Material and Volume 2—Templates and Supporting Material, —HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 1—Introductory Material and Volume 2—Templates and Supporting Material, —HL7® FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm 2.1.0—STU 2 US (HL7 FHIR eCR IG), —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), —HL7® CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG), and —Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. No changes are proposed to the IBR material. VI. Response to Comments Because of the large number of public comments normally received in response to **Federal Register** documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and when we proceed with a subsequent document, we will respond to the comments in the preamble of that document. VII. Collection of Information Requirements Under the Paperwork Reduction Act of 1995 (PRA), codified as amended at 44 U.S.C. 3501 *et seq.,* agencies are required to provide notice in the **Federal Register** and solicit public comment on a proposed collection of information before it is submitted to the Office of Management and Budget for review and approval. In order to fairly evaluate whether an information collection should be approved by the OMB, section 3506(c)(2)(A) of the PRA requires that we solicit comment on the following issues: 1. Whether the information collection is necessary and useful to carry out the proper functions of the agency; 2. The accuracy of the agency's estimate of the information collection burden; 3. The quality, utility, and clarity of the information to be collected; and 4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques. Under the PRA, the time, effort, and financial resources necessary to meet the information collection requirements referenced in this section are to be considered. We explicitly seek, and will consider, public comment on our assumptions as they relate to the PRA requirements summarized in this section. A. ONC-ACBs We propose to descope the “Real World Testing” Condition and Maintenance of Certification requirements in § 170.405 with deregulatory actions related to real world testing plans, results, and the use of the standards version advancement process (SVAP). Consistent with these proposals to descope the Real World Testing Condition and Maintenance of Certification requirements, we propose to make conforming edits in § 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). Our proposals in this proposed rule would not add any new collection of information burden and would instead reduce reporting burden associated with the proposed deregulatory actions. In the 2015 Edition proposed rule (80 FR 16894), we estimated fewer than ten annual respondents for all of the regulatory “collection of information” requirements that apply to the ONC-Approved Accreditor (ONC-AA) and ONC-ACBs, including those previously approved by OMB. In the 2015 Edition Final Rule (80 FR 62733), we concluded that the regulatory “collection of information” requirements for the ONC-AA and the ONC-ACBs were not subject to the PRA under 5 CFR 1320.3(c). We continue to estimate less than ten annual respondents for all of the proposed regulatory “collection of information” requirements for ONC-ACBs under part 170 of title 45, including those previously approved by OMB and proposed in this proposed rule. Accordingly, the regulatory “collection of information” requirements under the Program described in this section are not subject to the PRA under 5 CFR 1320.3(c). We welcome comments on these conclusions and the supporting rationale on which they are based. For the cost and burden reduction estimates related to these proposed deregulatory actions, we refer readers to section VIII (Regulatory Impact Analysis) of this proposed rule. B. Health IT Developers The “Insights” Condition and Maintenance of Certification requirements in § 170.407 include seven measures that health IT developers under the ONC Health IT Certification Program must annually report on consistent with specified regulatory compliance timelines. In the HTI-1 Final Rule (89 FR 1399), we estimated the total crude upper bound burden to be 1,767,692 hours. In this proposed rule, we propose to remove and descope measures associated in § 170.407 to limit reporting requirements only to the “use of FHIR in apps through certified health IT” measure, which would reduce reporting burden for health IT developers reporting under the Certification Program. In other words, we propose to reduce reporting burden associated with the Insights Condition and Maintenance of Certification requirements, and do not propose any new requirements that would add information collection burden. For more detailed discussion of burden reduction estimates of these deregulatory actions associated with the Insights Condition and Maintenance of Certification, we refer readers to section VIII (Regulatory Impact Analysis) of this proposed rule. VIII. Regulatory Impact Analysis A. Statement of Need E.O. 14192 on Unleashing Prosperity Through Deregulation, issued January 31, 2025, sets the policy to “to significantly reduce the private expenditures required to comply with Federal regulations to secure America's economic prosperity and national security and the highest possible quality of life for each citizen.” 82 To that end, E.O. 14192 requires that “any new incremental costs associated with new regulations shall, to the extent permitted by law, be offset by the elimination of existing costs associated with at least 10 prior regulations.” 83 This proposed rule, if finalized as proposed, is expected to be an E.O. 14192 deregulatory action and includes regulations and policies ASTP/ONC proposes to remove and revise to unleash prosperity. We believe the proposed changes will reduce burden on developers of certified health IT, returning time and effort to them, and in turn, enhancing competition, entrepreneurship, and innovation. These proposed deregulatory actions will reduce barriers to entry for novel technologies and digital health solutions, give time back to developers of certified health IT to focus on the needs and requests of their customers, and, overall, advance progress toward nationwide interoperability and universal patient access to their electronic health information. 82 *https://www.federalregister.gov/d/2025-02345/p-2.* 83 *https://www.federalregister.gov/d/2025-02345/p-6.* B. Overall Impact We have examined the impacts of this proposed rule as required by E.O. 12866, “Regulatory Planning and Review”; E.O. 13132, “Federalism”; E.O. 13563, “Improving Regulation and Regulatory Review”; E.O. 14192, “Unleashing Prosperity Through Deregulation”; section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532); and the Regulatory Flexibility Act
(RFA)(Pub. L. 96-354). 1. Regulatory Planning and Review Analysis This proposed rule implements relevant policy priorities outlined in E.O.s 12866, 13563, and 14192. E.O. 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, and distributive impacts). E.O. 14192 directs agencies to repeal ten existing regulations for each new regulation issued in 2025 and thereafter and to account for cost savings associated with deregulatory actions. This proposed rulemaking, if finalized as proposed, is expected to be an E.O. 14192 deregulatory action, and we have therefore prepared an RIA that to the best of our ability presents the expected significant cost savings to regulated entities generated by the proposed actions. a. Costs and Benefits These proposed deregulatory actions provide substantial relief for developers of certified health IT and significant cost savings realized from the revision and removal of certain program requirements. For the purpose of estimating the cost savings of this proposed rulemaking, we have determined that these policies would continue absent this regulatory action. The cost savings have been estimated using the best available data and modeled on the costs estimated and finalized in prior ASTP/ONC rulemakings. As articulated in the preamble, these proposed deregulatory actions reduce the effort of developers of certified health IT to meet ongoing program requirements and reduce barriers to entry for new program participants. The proposed actions, importantly, return effort back to developers of certified health IT to innovate their technology and focus on the needs of their clients and end users. Employee Assumptions and Hourly Wage We have made employee assumptions about the level of expertise needed to complete the requirements that are affected by this proposed rule. Unless indicated otherwise, for wage calculations for Federal employees and ONC-ACBs, we have correlated the employee's expertise with the corresponding grade and step of an employee classified under the General Schedule
(GS)Federal Salary Classification, relying on the associated employee hourly rates for the Washington, DC, locality pay area as published by the OPM for 2025. 84 We have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages. Therefore, we have doubled the employee's hourly wage to account for other indirect costs. We have concluded that a 100% expenditure on benefits and overhead is an appropriate estimate based on research conducted by HHS. 85 84 *https://www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/2025/general-schedule/.* 85 See U.S. Department of Health and Human Services, Office of the Assistant Secretary for Planning and Evaluation (ASPE), Guidelines for Regulatory Impact Analysis, at 28-30 (2016), available at *https://aspe.hhs.gov/reports/guidelines-regulatory-impact-analysis.* Unless otherwise noted, we have consistently used the May 2024 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics
(BLS)to calculate private sector employee wage estimates ( *e.g.,* health IT developers, health care providers, HINs, attorneys, etc.), as we believe BLS provides the most accurate and comprehensive wage data for private sector positions. 86 These wage estimates are a national average and we do not consider regional wage variation in our estimates. We also do not consider possible variation in the average wages for software developers in health care IT positions versus IT positions, more generally, which the BLS wage estimate is based upon. Just as with the General Schedule Federal Salary Classification calculations, we have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages. We welcome comments on our methodology for estimating labor costs, including the effects of any regional or IT sector wage variation on our estimates. 86 *https://data.bls.gov/oes/#/industry/000000.* According to the May 2024 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $69.50. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages, so the hourly wage including other indirect costs for Software Developers is $139.00. Quantifying the Estimated Number of Health IT Developers and Products Given the wide range of proposed deregulatory actions, we have not adopted a single, over-arching approach to calculate the number of health IT developers and products affected by this rulemaking. We believe, however, that each current developer of certified health IT and participant in the Certification Program will be affected by these proposed actions, but that impact will vary, given the breadth and scope of each developer's participation in the Certification Program. For each set of proposed actions, we describe our methodology for calculating the current number of health IT developers and products affected, and, where applicable, model estimated future counts of developers and products affected. Number of End Users That Might Be Impacted by ASTP/ONC's Proposed Regulations The breadth and scope of the proposed deregulatory actions create immediate and significant cost savings for developers of certified health IT. As we have finalized in prior ASTP/ONC rulemakings—Cures Act Final Rule (85 FR 25642) and HTI-1 Final Rule (89 FR 1192)—we assume the regulatory costs imposed by those rules on developers may be passed on to end users of their technology in the form of increased fees and other costs. These deregulatory actions, though scoped to provide immediate relief and reduce ongoing burden on developers of certified health IT, may have downstream impacts on technology end users who may benefit from lower marginal costs to license and update their software; focused developers efforts on emerging end user needs; and other forms of innovation that may lead to unquantified benefits and savings for end users. We assume developers of certified health IT will use the cost savings to invest in innovation and emerging technology, rather than directly reduce costs on their end users, but, overall, believe the cost savings will create a net benefit to end users, if not directly as an immediate financial savings. Costs We do not expect costs to be associated with the deregulatory action proposals. We do, however, estimate the costs to review the rule. All entities affected by this proposed rule, if finalized, would spend time to read and understand the final rule, resulting in a one-time cost. The current Preamble and proposed regulatory text together contain approximately 64,727 words; we use this as a proxy for the length of the final rule. Consistent with HHS guidelines, we assume that industry reviewers read at the average adult reading speed of approximately 288 (64,727/225) words per minute, so the time to read and understand the regulation would be about 4 hours per person (288*60=17,280) (64,727/17,280=3.75). We estimate the total number of reviewers by taking the number of estimated developers and adding an estimated number of medical associations that represent health care providers and health information networks, etc. The counts of developers included in Table R-1 were calculated using publicly available Certification Program data available through the CHPL. 87 We took the estimated number of developers from Table R-1, which is 444 developers and estimated 200 medical associations. 88 We then determined that there would likely be 644 individuals to review the proposed rule. As mentioned above, we used the May 2024 National Occupational Employment and Wage Estimates reported by the BLS to calculate private sector employee wage estimates. 89 We identified the “Management Analyst” position as comparable to a position that would review the rule. According to the May 2024 BLS occupational employment statistics, the mean hourly wage for a “Management Analyst” is $55.15. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages, so the hourly wage including other indirect costs for a Management Analyst is $110.30. We estimate it will take four hours to review the proposed rule. Therefore, the total cost to review the rule for one reviewer would be $441.20 ($110.30*4). We took the estimated number of individuals to review the rule which is 644 and then multiplied that by $441.20 and calculated the estimated total cost to review the rule to be $284,132 ($441.20*644). 87 *https://chpl.healthit.gov.* 88 *https://www.ama-assn.org/house-delegates/hod-organization/member-organizations-ama-house-delegates?utm_source=chatgpt.com.* 89 *https://data.bls.gov/oes/#/industry/000000.* Benefits We expect the proposed deregulatory actions to result in significant benefits for health IT developers, providers, ONC-ACBs, ONC-ATLs, and ASTP/ONC. These expected benefits are detailed below. Generally, these benefits are in the form of cost and time savings and reductions in administrative burden to comply with Certification Program requirements. The proposed actions reduce the scope and breadth of program requirements. The proposed program revisions provide direct cost savings (quantified, below) to developers of certified health IT and their users ( *i.e.,* providers) through fewer program requirements and lower regulatory barriers, freeing up time for more innovation and meeting customer needs. In turn, the revised program requirements may reduce the implementation effort on ONC-ACBs, ONC-ATLs, and ASTP/ONC, who works with ACBs and ATLs to implement program requirements. These savings in time and effort to ONC-ACBs, ONC-ATLs, and ASTP/ONC can be used toward remaining program improvement and implementation efforts, enhancing the operation and management of the program. 1. Removal 1.1 Removal of Certification Criteria We propose to remove 34 certification criteria. Of these, we propose to remove 24 criteria as of the effective date of any final rule and the remaining ten criteria as of January 1, 2027. We developed a common model for estimating cost savings associated with the removal of all but one certification criterion, described below. For all criteria we assume that the cost savings from these criteria would begin January 1, 2027. Table R-1, below, provides criterion-level results of our model for 32 of the proposed criteria removals. For each certification criterion we identified the original costs to certify to the functionality from prior rules (the lower and upper bounds of “Total Hours” in Table R-1.) 90 91 92 We then assumed that the annual cost to maintain certification was a small fraction of the initial costs. We are not aware of any published evidence that would directly inform this calculation, and, therefore, developed a novel approach using various information sources. We defined this fraction (“Final Effort Multiplier” in Table R-1) based on five factors:
(1)“Test”: the criterion's certification conformance method, assuming that criteria with a test procedure had additional maintenance costs while those with a conformance method of attestation had no additional cost beyond what was initially incurred;
(2)“Stakeholder feedback”: stakeholder feedback received by ASTP/ONC through meetings, informal conversations, and letters from impacted parties on effort involved in certifying and updating the specific certification criterion;
(3)“Complexity of standard”: whether the criterion referenced a standard and an assessment of the complexity involved in maintaining and updating conformance to that standard over time, including through future regulatory requirements to update criteria to support new versions of the USCDI;
(4)“Complexity of test procedure”: an assessment of the complexity of the test procedure or evaluative work to support attestation when it was necessary to undertake the certification process; and
(5)“General complexity”: an overall assessment of the complexity of maintaining the certification criterion and underlying functionality. 90 *https://www.federalregister.gov/documents/2015/10/16/2015-25597/2015-edition-health-information-technology-health-it-certification-criteria-2015-edition-base#p-185.* 91 *https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and.* 92 *https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification.* The “Final Effort Multiplier” is a sum of the five factors listed in the table and described above. We then used this multiplier to determine the annual costs of meeting and maintaining the individual criteria by taking the product of the lower and upper bound “Total Hours”, described above, and this multiplier. We then estimated the lower and upper bounds of “Hours saved” by multiplying the “Annual” hours by the number of products that certify each criterion. The counts of developers and products included in Table R-1 are current as of May 1, 2025. The counts were calculated using publicly available Certification Program data available through the CHPL. 93 Although we primarily use the count of products to estimate “Hours saved”, the count of developers is included for reference and comparison. 93 *https://chpl.healthit.gov.* BILLING CODE 4150-45-P EP29DE25.036 BILLING CODE 4150-45-C Table R-1—Panel B—Annual Undiscounted Cost Savings Estimates for the Removal of Certification Criteria Criterion Name Lower bound Upper bound § 170.315(a)(12) Family health history $248,463 $496,925 § 170.315(a)(14) Implantable device list 1,909,026 5,454,360 § 170.315(b)(2) Clinical information reconciliation and incorporation 5,195,820 6,234,984 § 170.315(b)(7) Security tags—summary of care—send 640,512 1,040,832 § 170.315(b)(8) Security tags—summary of care—receive 620,496 1,008,306 § 170.315(b)(9) Care plan 569,205 813,150 § 170.315(c)(4) Clinical quality measures (CQMs)—filter 838,170 1,257,255 § 170.315(d)(1) Authentication, access control, authorization 315,252 630,504 § 170.315(d)(2) Auditable events and tamper-resistance 341,523 683,046 § 170.315(d)(3) Audit report(s) 537,096 1,074,192 § 170.315(d)(4) Amendments 218,508 437,016 § 170.315(d)(5) Automatic access time-out 69,917 139,834 § 170.315(d)(6) Emergency access 118,428 236,856 § 170.315(d)(7) End-user device encryption 383,779 767,558 § 170.315(d)(8) Integrity 297,391 594,781 § 170.315(d)(9) Trusted connection 914,064 1,828,128 § 170.315(d)(10) Auditing actions on health information 56,295 112,590 § 170.315(d)(11) Accounting of disclosures 125,656 188,484 § 170.315(d)(12) Encrypt authentication credentials 444,175 888,349 § 170.315(d)(13) Multi-factor authentication 242,277 484,554 § 170.315(e)(3) Patient health information capture 1,163,430 1,861,488 § 170.315(f)(4) Transmission to Cancer Registries 538,208 672,760 § 170.315(f)(7) Transmission to PHAs—Health Care Surveys 700,560 980,784 § 170.315(g)(1) Automated numerator recording 462,592 693,888 § 170.315(g)(2) Automated measure calculation 6,116,000 9,785,600 § 170.315(g)(4) Quality management system 409,355 1,309,936 § 170.315(g)(5) Accessibility-centered design 409,355 818,710 § 170.315(g)(6) Consolidated CDA creation performance 4,403,520 9,907,920 § 170.315(g)(7) Application access—patient selection 1,010,808 1,347,744 § 170.315(g)(9) Application access—all data request 2,962,368 3,949,824 § 170.315(h)(1) Direct Project 5,112,976 7,030,342 § 170.315(h)(2) Direct Project, Edge Protocol, and XDR/XDM 480,384 660,528 Total Cost Savings 37,855,816 63,391,228 * The lower and upper bound cost savings estimates use the hourly wage ($139.00) we describe above in “Employee Assumptions and Hourly Wage”. For the 32 certification criteria proposed for removal in Table R-1, we estimate the total annual hours saved to range from 272,344 to 456,052, among 444 developers of certified health IT and 589 certified products (Table R-1). Using the hourly labor rate ($139), described above, we estimate the total undiscounted annual cost savings to range from $37,855,816 to $63,391,228. We welcome comments on the proposed methodology and the accuracy and validity of the model's estimates. 1.2 Removal of Safety-Enhanced Design Cost savings from the proposed removal of § 170.315(g)(3) safety-enhanced design
(SED)is estimated separately from non-SED removed criteria. In the 2015 Edition Final Rule, we estimated that developers would spend 300 to 400 hours implementing the SED criterion at a cost of $63 per hour and that 266 developers would certify to SED. This resulted in a final cost estimate ranging from $5,027,400 to $6,703,200 in 2014 dollars. Since the finalization of that policy, we have received substantial input from developers of certified health IT that the cost estimates specified in that rule were an under-estimate of the initial and recurring costs associated with the SED certification criterion. In contrast to those estimates, we understand that individual developers of certified health IT incur recurring costs greater than $200,000 to recruit participants and conduct testing specified by the SED certification criterion. In response to input from the impacted community, we have revised our estimates of the costs of SED and potential cost savings that can be realized from the proposed removal of the SED certification criterion in this proposed rule. The SED certification criterion is required for all developers seeking certification to § 170.315(a)(1) through (5),
(9)(until the certification criterion's expiration date), (a)(14), (b)(2), (b)(3) or (b)(11). Developers must recruit at least ten participants, conduct testing, and submit metrics for each of the criterion for which they seek certification that is referenced within § 170.315(g)(3). Thus, we believe cost savings from the removal of SED are incremental per the number of dependent criteria certified because there are additional costs per product associated with SED testing and data reporting. Based on stakeholder input and because developers can certify multiple products each with up to ten criteria that requires SED, we believe an estimated annual cost of between $8,000 and $12,000 per product per certification criterion that requires SED testing is appropriate. This estimate represents the effort to design tests, recruit participants, conduct testing, document that testing, and report results to the ONC-ACB in the required format. To estimate the total costs of SED, we estimated the number of products that will be certified to SED and the number of SED criteria each product will certify. We report those costs in Table R-2. The count of products that are certified to SED and number of SED criteria each product certifies in the table are current as of May 1, 2025. The counts were calculated using publicly available Certification Program data available through the CHPL. 94 94 *https://chpl.healthit.gov.* Table R-2—Annual Cost Savings Estimates for Removal of § 170.315( g )(3) Number of SED criteria certified Number of products Lower bound cost per product (hours) Upper bound cost per product (hours) Total lower bound cost ($) Total upper bound cost ($) 1 17 8,000 12,000 136,000 204,000 2 4 8,000 12,000 64,000 96,000 3 7 8,000 12,000 168,000 252,000 4 19 8,000 12,000 608,000 912,000 5 21 8,000 12,000 840,000 1,260,000 6 28 8,000 12,000 1,344,000 2,016,000 7 33 8,000 12,000 1,848,000 2,772,000 8 62 8,000 12,000 3,968,000 5,952,000 9 182 8,000 12,000 13,104,000 19,656,000 373 22,080,000 33,120,000 Note: The lower and upper bound cost estimates use the hourly wage ($139.00) we describe above in “Employee Assumptions and Hourly Wage”. In total, 373 products are certified to SED and at least one SED certification criterion. Based on Table R-2, we estimate the total undiscounted annual cost savings from removing the SED certification criteria to be between $22,080,000 and $33,120,000. We welcome comments on the proposed methodology and the accuracy and validity of the estimates. 2. Revisions 2.1 Revision of Certification Criteria We propose to revise seven certification criteria. For each revised certification criterion, we have estimated the annual savings generated by the proposed revisions. 2.1.1 § 170.315(a)(5) Patient Demographics and Observations We propose to codify certification guidance for the Certification Program exercising our enforcement discretion—specifically, for the “patient demographics and observations” certification criterion in § 170.315(a)(5). 95 We expect this proposed revision to reduce the effort associated with meeting the requirements in § 170.315(a)(5) in the form of reduced maintenance costs. Using the approach described for removed criteria, we estimate that the removal of these requirements will reduce the annual effort of maintaining certification by 5% of the projected development costs estimated in the HTI-1 Final Rule. We note that 288 developers have certified 352 products to § 170.315(a)(5) and that the initial developer hours estimated to implement updates to the criterion in the HTI-1 Final Rule had a lower bound of 720 hours and an upper bound of 1,860 hours. We therefore estimate that the revision of this criterion will reduce effort by between 36 and 93 hours per product and 12,672 to 32,736 hours across all products. We estimate the total undiscounted annual cost savings for reduced maintenance to range from $1,761,408 to $4,550,304. 95 *https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion-notice.* 2.1.2 § 170.315(b)(1) Transitions of Care We propose to revise 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 believe that these revisions remove a substantial proportion of the ongoing effort required to maintain and update the functional requirement of the certification criterion, but we acknowledge that it does not remove requirements to support the C-CDA standard or to update functionality to receive C-CDA documents. We assume that this reduces the overall ongoing cost for this criterion by 60%. Following the methodology described for removed criterion, we considered annual maintenance of § 170.315(b)(1) to represent high complexity equivalent to 15% of the initial development costs annually. We note from an analysis of current Certification Program data that 256 developers have certified 300 products to § 170.315(b)(1) and that the initial developer hours estimated to implement the criterion had a lower bound of 3,000 hours and an upper bound of 4,000 hours in the 2015 Edition Final Rule (80 FR 62602). 96 We therefore estimate that the revision of this criterion will reduce effort to maintain the criterion annually by 9% annually or between 270 and 360 hours per product and 81,000 to 108,000 hours across all products. We estimate the total undiscounted annual cost savings to range from $11,259,000 to $15,012,000. 96 *https://www.federalregister.gov/d/2015-25597/p-1773.* 2.1.3 § 170.315(b)(11) Decision Support Interventions We propose to remove all requirements related to source attributes, their access, and modification and requirements to manage risks related to the development of predictive DSIs. In the HTI-1 Final Rule, we indicated that the costs to implement § 170.315(b)(11) ranged from 2,200 hours to 4,600 hours, that updating source attribute information annually would cost an additional 0 to 1085 hours annually, depending on the number of DSIs the developer supplied, and that engaging in risk management and updating information would result in an additional 0 to 285 hours annually. Without this revision, we estimate that annual maintenance costs for this criterion would represent 12% of initial development costs. We believe these changes reduce these costs by 80% and would eliminate annual costs to update information for source attributes and risk management. In total, we estimate that the revision will reduce maintenance costs by 211 to 1,812 hours per product. We note that 232 products developed by 183 developers were certified to § 170.315(b)(11) resulting in an annual reduction of 48,952 to 420,384 labor hours. We estimate the total undiscounted annual cost savings to range from $6,804,328 to $58,433,376. 2.1.4 § 170.315(c)(3) Clinical Quality Measures (CQMs)—Report We propose revisions to § 170.315(c)(3) to remove expired standards references. These proposed revisions are considered de minimis and do not create net new cost savings. 2.1.5 § 170.315(e)(1) View, Download and Transmit to a 3rd Party We propose 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 215 developers have certified 255 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,630 to 10,200 hours across all products. We estimate the total undiscounted annual cost savings to range from $921,570 to $1,417,800. 2.1.6 § 170.315(f)(5) Transmission to Public Health Agencies—Electronic Case Reporting We propose to codify certification guidance for the Certification Program exercising our enforcement discretion for—specifically, the “Transmission to public health agencies—electronic case reporting” certification criterion in § 170.315(f)(5). 97 We expect this proposed revision to reduce the burden associated with meeting the requirements in the eCR certification criterion in the form of reduced maintenance costs. Following the methodology described for removed criterion, we considered annual maintenance of § 170.315(f)(5), as finalized in the HTI-1 Final Rule and becoming effective on December 31, 2025, to represent high complexity equivalent to 27% of the initial development costs annually. We estimate that removal of standards-based requirements will reduce annual maintenance costs to 10% of initial development costs, a 63% reduction in effort. 97 *http://healthit.gov/topic/electronic-case-reporting-certification-criterion-enforcement-discretion-notice.* Currently, 94 developers and 127 products are certified to § 170.315(f)(5). Eighty-six developers and 112 products are certified to the “functional” requirements in § 170.315(f)(5)(i) alone, while 10 developers and 15 products are certified to the standards-based requirements in § 170.315(f)(5)(ii). The initial developer hours estimated to implement the criterion had a lower bound of 0 hours and an upper bound of 2,160 in the HTI-1 Final Rule. We therefore estimate that the revision of this criterion will reduce annual effort to maintain the criterion by between 0 and 367 labor hours per product and 0 to 46,609 labor hours across all 127 products. We estimate the total undiscounted annual cost savings for reduced maintenance to range from $0 to $6,478,651. 2.1.7 § 170.315(f)(6) Transmission to Public Health Agencies—Antimicrobial Use and Resistance Reporting We propose 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 requirement. We received stakeholder feedback that the CDA-based standards cited in this criterion are not required for users to submit antimicrobial use and resistance
(AUR)data to the CDC's National Healthcare Safety Network (NHSN), creating a disconnect between the criterion and what is used in practice. We expect the removal of standards-based requirements to better align with the NHSN's goals for reporting and reduce the burden on developers to meet this requirement. Following the methodology described for removed criteria, we considered annual maintenance of § 170.315(f)(6) to represent medium complexity equivalent to 20% of the initial development costs annually. We estimate that removal of standards-based requirements will reduce annual maintenance costs to 6% of initial development costs, resulting in a 70% reduction in effort. Currently, 28 developers and 47 products are certified to § 170.315(f)(6). The initial developer hours estimated to implement the criterion had a lower bound of 1,000 hours and an upper bound of 1,400 hours in the 2015 Edition. We therefore estimate that the revision of this criterion will reduce effort to maintain the criterion annually by 14% or between 140 to 196 hours per product and 6,580 to 9,212 hours across all products. We estimate the total undiscounted annual cost savings to range from $914,620 to $1,280,468. In Table R-3, we estimate the total annual hours saved from the proposed criteria revisions to range from 155,834 to 627,141 among 328 developers of certified health IT and 418 certified products. Using the labor rate of $139, described above, we estimate the total undiscounted annual cost savings to range from $21,660,9326 to $87,172,599. We welcome comments on the proposed methodology and the accuracy and validity of the estimates. Table R-3—Panel A—Estimates of Labor Hours Saved for the Revisions of Certification Criteria Criterion citation Total hours LB UB Annual hours LB UB Percent effort Saved Developers certified Products certified Hours saved LB UB § 170.315(a)(5) 720 1,860 36 93 100% 288 352 12,672 32,736 § 170.315(b)(1) 3,000 4,000 450 600 60% 256 300 81,000 108,000 § 170.315(b)(11) Task 1. Annual Maintenance 2,200 4,600 264 552 80% 183 232 48,952 102,544 § 170.315(b)(11) Task 2. Information Updates 0 1,370 0 1,370 100% 183 232 0 317,840 § 170.315(e)(1) 1300 2000 8 24 20% 215 255 6,630 10,200 § 170.315(f)(5) 0 2,160 0 216 63% 94 127 0 46,609 § 170.315(f)(6) 1,000 1,400 60 84 70% 28 47 6,580 9,212 All criteria 328 418 155,834 627,141 Table R-3—Panel B—Annual Cost Savings Estimates for Revisions of Certification Criteria Criterion citation Annual cost savings LB UB § 170.315(a)(5) $1,761,408 $4,550,304 § 170.315(b)(1) 11,259,000 15,012,000 § 170.315(b)(11) 6,804,328 58,433,376 § 170.315(e)(1) 921,570 1,417,800 § 170.315(f)(5) 0 6,478,651 § 170.315(f)(6) 914,620 1,280,468 Total Annual Cost Savings 21,660,926 87,172,599 Note: The lower and upper bound cost estimates use the hourly wage ($139.00) we describe above in “Employee Assumptions and Hourly Wage”. 2.2 Revisions to Standards and Implementation Specifications for Health Information Technology 2.2.1 Revisions to the United States Core Data for Interoperability (USCDI) v3 We propose to codify certification guidance for the Certification Program exercising our enforcement discretion—specifically, for the United States Core Data for Interoperability (USCDI) v3 standard. 98 The action removed or revised data elements from USCDI v3, as finalized in the HTI-1 Final Rule (89 FR 1192). 98 *https://www.healthit.gov/topic/uscdi-v3-data-elements-enforcement-discretion-notice.* As finalized in the HTI-1 Final Rule, developers of certified health IT were required to update and certify their Health IT Modules to adopt USCDI v3 by January 1, 2026. This proposal reduces the effort for developers of certified health IT to adopt the USCDI v3 via the removal or revision of two data elements: sexual orientation and gender identity. We do not estimate reduced effort from ongoing maintenance of these requirements, as the effort is considered part of activities that occurred prior to the effective date of any final rule. We request comments on this approach. 2.3 Revisions to the ONC Health IT Certification Program Administration Unless noted differently, proposed revisions to Certification Program administration conform to revisions proposed elsewhere related to Certification Program requirements. We do not assess net new cost savings or costs to program administration for these conforming revisions. We welcome comments on whether these conforming revisions create net new cost savings or costs. 2.3.1 Principles of Proper Conduct for ONC-ACBs Under the principles of proper conduct for ONC-ACBs, we propose to revise the “certified product listing” principle in § 170.523(f)(1)(viii) to remove requirements on ONC-ACBs to include the test data version used and whether any test data was altered for the certification criterion or criteria to which the Health IT Module has been certified. This proposed revision is meant to reduce the overall effort for ONC-ACBs for this principle, as our analysis shows that these data elements for the “certified product listing” are low value. We determined that the cost savings to ONC-ACBs are de minimis, and welcome comments on this analysis. In addition, we propose conforming revisions to the principles of proper conduct for ONC-ACBs. These conforming revisions do not create net new cost savings to developers of certified health IT, ASTP/ONC, or ONC-ACBs. These conform to revisions made elsewhere to Certification Program requirements, and cost savings, if applicable, are assessed elsewhere in this impact analysis. 2.3.2 Principles of Proper Conduct for ONC-ATLs We propose conforming revisions to the principles of proper conduct for ONC-ATLs. These conforming revisions do not create net new cost savings to developers of certified health IT, ASTP/ONC, or ONC-ATLs. These conform to revisions made elsewhere to Certification Program requirements, and cost savings, if applicable, are assessed elsewhere in this impact analysis. 2.3.3 Health IT Module Certification We propose conforming revisions to Health IT Module certification. These conforming revisions do not create net new cost savings to developers of certified health IT, ASTP/ONC, or ONC-ACBs. These conform to revisions made elsewhere to Certification Program requirements, and cost savings, if applicable, are assessed elsewhere in this impact analysis. 2.3.4 Certification to Newer Versions of Certain Standards We propose conforming revisions to certification to newer versions of certain standards. These conforming revisions do not create net new cost savings to developers of certified health IT, ASTP/ONC, or ONC-ACBs. These conform to revisions made elsewhere to Certification Program requirements, and cost savings, if applicable, are assessed elsewhere in this impact analysis. 2.3.5 Effect of Revocation on the Certifications Issued to Health IT Module(s) We propose conforming revisions that do not create net new cost savings. 2.4 Revisions to Conditions and Maintenance of Certification Requirements for Health IT Developers (Subpart D) 2.4.1 Assurances Condition of Certification We propose updates to the Code of Federal Regulations
(CFR)that do not create net new cost savings. 2.4.2 Application Programming Interfaces Condition of Certification We propose updates to the CFR that do not create net new cost savings. 2.4.3 Real World Testing Condition of Certification We propose revisions to the Real World Testing Condition of Certification that de-scope reporting requirements and codify certification guidance for the Certification Program exercising our enforcement discretion for the Condition of Certification. 99 As finalized in the Cures Act Final Rule (85 FR 25642), real world testing would be applicable for specific criteria—at the time of finalization, 23 criteria in all. This deregulatory action revises the Real World Testing Condition of Certification to apply reporting to only the API criteria adopted by the Certification Program. This revision creates cost savings to developers of certified health IT, as developers would no longer be required to plan, collect, and report on real world testing results for the full originally finalized set of criteria. We explain below the rationale and methodology that informed the cost savings for these proposed revisions to real world testing. 99 *https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement.* The proposed revisions to real world testing would take effect beginning in 2027. Cost savings to developers for ongoing compliance are, therefore, estimated beginning in 2027. Any costs for 2024 and 2025 are considered sunk. Beginning in the 2026 reporting year, as permitted in the real world testing enforcement discretion, only developers of certified APIs would be required to report for real world testing, specifically developers who certify to the standardized API for patient and population services certification criterion, § 170.315(g)(10). 100 Cost savings calculations beginning in 2027 reflect the decreased burden on developers of certified health IT to comply with the condition of certification minus requirements that remain in place for developers who certify to the applicable API-based criteria. 100 *https://www.healthit.gov/topic/real-world-testing-condition-and-maintenance-certification-requirements-enforcement.* As of the end of 2024, using publicly available Certification Program data, we calculated that 336 developers had submitted real world testing plans for 2025 collection and 2026 reporting. 101 That is 93 fewer developers required to report for real world testing than estimated in the Cures Act Final Rule—a decrease of about 19 developers per year. 102 Calculating developer exits during this time period, after the Cures Act Final Rule took effect and prior to this proposed rule's effective date, is important to assess the estimated number of developers expected to comply with the remaining real world testing requirements, as proposed. 101 *https://chpl.healthit.gov/.* 102 *https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification.* Beginning in 2026, we calculated an expected count of developers who we estimated would be required to report for real world testing in 2026 and beyond. This count assumes attrition from the original count of developers required to report for real world testing as finalized in the Cures Act Final Rule, as we described above for years prior to 2026. But given the changed program dynamics, in that real world testing would be required only for developers of certified APIs, the attrition rate beyond 2026 is harder to estimate. Given that current requirements are applicable for over 20 criteria adopted in the Certification Program and our attrition rate is based on participant exits from the Certification Program (for developers who certify for any of these criteria), we assume that attrition rate is likely more profound than exits for developers of certified APIs alone. We therefore estimate a new rate of developers who would be required to report for real world testing in total (n=320), beginning in 2026. In our RIA for the HTI-4 Final Rule (included in the FY2026 IPPS/LTHC PPS Final Rule (90 FR 36536) as an ancillary provision), we estimated that beginning in 2027, approximately 189 developers would certify an electronic prior authorization API. The 189 count is a proxy measure, representing our estimation of the number of developers that would certify the § 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 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. 103 In 2026, however, only 189 developers would be subject to revised real world testing requirements—our estimate of the number of developers who would be subject to revised real world testing requirements (API only.) This considers some attrition but at a different rate than used for years prior to 2026, as explained above. 103 Formula: 189/(1−0.41) = 320. Total savings beginning in 2027 are considered consistent and do not decrease due to future unknown attrition; however, we consider these cost savings to be realized by developers when the revised requirements take effect. If they were to exit the program in a year beyond 2027, these are still cost savings to be realized today from requirements they do not need to meet in all future years. Beginning in 2027, cost savings are calculated by totaling the cost to all developers who certify real world testing applicable criteria to meet current real world testing requirements as finalized in the Cures Act Final Rule and revised in subsequent rulemakings (the HTI-1 Final Rule and the HTI-4 Final Rule) and subtracting the remaining cost for developers of certified APIs to comply with revised real world testing requirements. We estimate that, per developer, the cost of collecting and reporting real world testing data on § 170.315(g)(10) would be on average $4,400 annually. We estimate this by calculating the average cost per criterion to meet real world testing requirements as finalized by the Cures Act Final Rule ($109,557/23 = $4,763) and decrease that by the proposed eliminated effort to submit annual testing plans (estimated to be 8% of total annual testing effort.) 104 This is congruent with our methodology finalized in the HTI-4 Final Rule about the average per criterion cost to plan, collect, and report for real world testing. 105 The total cost of the remaining requirement to test for § 170.315(g)(10) would be subtracted from the total original program cost, as finalized by the Cures Act Final Rule, to estimate this deregulatory action's annual cost savings. 104 Formula: $4,763 × (1−0.08) = $4,382. 105 *https://www.federalregister.gov/d/2025-14681/p-7025.* Beginning in 2027, we also assume that developers of certified APIs would need to meet requirements for § 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. 106 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. 106 *https://www.federalregister.gov/documents/2025/08/04/2025-14681/medicare-program-hospital-inpatient-prospective-payment-systems-for-acute-care-hospitals-ipps-and.* We estimate cost savings for reduced upfront effort in 2027 to be (original real world testing costs + § 170.315(b)(4) planning costs) minus (§ 170.315(g)(10) revised costs), which equal $35.1 million in undiscounted cost savings for 2026. For costs savings, beginning in 2027 and in perpetuity, we estimate that together, (original real world testing costs + § 170.315(b)(4) costs) minus ((g)(10)+(g)(31)+(g)(32)+(g)(33) revised costs) equal the estimated annual undiscounted cost savings of $33.6 million. 2.4.4 Attestations We propose updates to the CFR that do not create net new cost savings. 2.4.5 Insights Condition of Certification In the HTI-1 Final Rule (89 FR 1192), we finalized requirements for developers to report on the Insights Condition of Certification, a set of uniform measures collected and reported by developers of certified health IT about the performance of their certified technology. 107 Applicable developers would be required to begin data collection January 1, 2026, for “Year 1” measures, with results reported in July 2027 and with “Year 2” measures set to begin collection January 1, 2027. Effort to plan and develop capabilities for these finalized measures was estimated to begin after the effective date of the HTI-1 Final Rule in January 2024. Effort to plan and develop the measurement capabilities for measures required to be collected in 2026 (“Year 1”) would be completed by January 1, 2026, and effort to plan and develop the measurement capabilities for measures required to be collected for the first time in 2027 (“Year 2”) would be completed by January 1, 2027, etc. We estimated developers would face annual data collection and reporting costs beginning in 2026 and in perpetuity. As we finalized in the HTI-1 Final Rule, the large majority of costs to developers of certified health IT would be costs to plan and develop for initial data collection of the finalized measures (effort largely expended from 2024-2026 in our original analysis). 107 *https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and.* ASTP/ONC issued enforcement discretion in April 2025 that effectively de-scoped Insights requirements on developers to a single measure—“Use of FHIR”—a “Year 1” measure. 108 The enforcement discretion effectively paused development and planning efforts to collect all Insights measures but one (“Use of FHIR”), reducing sunk costs and creating cost savings to developers by reducing the upfront effort to plan and report for Insights. We propose to codify certification guidance for the Certification Program exercising our enforcement discretion for the Insights Condition of Certification. We explain below the rationale and methodology that informed the cost savings for these proposed revisions to Insights. 108 *https://www.healthit.gov/topic/insights-condition-and-maintenance-certification-enforcement-discretion.* To calculate cost savings associated with the proposed revisions to the Insights Condition of Certification, we subtracted the estimated amount for developers to report for the remaining Insights measure (“Use of FHIR”) from the estimated cost for developers to meet the Insights Condition of Certification, as finalized in the HTI-1 Final Rule. In Table 35 of the HTI-1 Final Rule, we estimated that the upper bound cost for all developers to report on the “Use of FHIR” measure over a ten-year period was $36.3 million. 109 The total upper bound cost to report on all measures for all developers over a ten-year period was $218.7 million. Therefore, we estimate the “Use of FHIR” measure to be 17% of all estimated Insights costs. 109 *https://www.federalregister.gov/d/2023-28857/p-2641.* In Table R-4 we show the undiscounted revised costs for the Insights Condition of Certification. We estimated, on average, that the HTI-1 Final Rule costs for Insights would be $137.9 million. We estimated that the cost for developers to begin implementing Insights in 2024 (toward effort to collect and report on measures in 2026 and 2027) would on average, total $46.4 million. This included initial planning and development costs for all measures with more assumed effort toward completing work to prepare for “Year 1” measures set to begin collection January 1, 2026. We consider these costs as sunk. The Insights enforcement discretion, however, reduced effort for ongoing planning and development work for 2025 and after. We consider this reduced effort in 2025 and 2026 and reduced effort to meet this requirements in years 2027 and after to be a net cost savings to developers, as Table R-4 shows. Cost savings in 2027 and thereafter are considered tied to the reduced effort associated with ongoing planning and reporting for the proposed revised requirements. The total undiscounted cost savings for this reduced ongoing effort, beginning in 2027, are $12.7 million (Table R-4). Table R-4—Revised Insights Undiscounted Cost Savings Year Upfront effort Ongoing effort Total 2024 $0 $0 $0 2025 38,513,661 0 38,513,661 2026 24,814,672 0 24,814,672 2027 0 8,601,676 8,601,676 2028 0 680,593 680,593 Total—Undiscounted 63,328,333 12,685,234 76,013,568 b. Accounting Statement and Table This proposed rule, if finalized as proposed, is expected to be an E.O. 14192 deregulatory action. The proposals remove or reduce requirements on developers of certified health IT. No proposals create net new requirements or additional burden to comply with existing requirements. However, we do estimate some costs for reviewers who review this proposed rule. We estimate those costs to be $284,132 in total for an estimated 644 reviewers, which include developers and medical associations. As articulated in the preamble, these proposed deregulatory actions reduce the effort of developers of certified health IT to meet ongoing program requirements and reduce barriers to entry for new program participants, generating benefits to developers of certified health IT in the form of time back to them to innovate their technology and focus on the needs of their clients and end users. We do not, however, quantify these benefits, and instead rely on our calculation of cost savings to developers of certified health IT to quantify in dollars the time and effort developers would have expended had these requirements remained in effect in perpetuity. We estimate that these proposals do generate significant cost savings for developers of certified health IT. To calculate the cost savings associated with this proposed rulemaking, we replicate the analysis of prior finalized rulemakings and align those with current data, adopting, where necessary, novel methodologies and models to assess the current costs to developers of certified health IT of the proposed revisions to the Certification Program. As shown in Table R-5, we present the undiscounted cost savings over ten years and in Table R-6 we present the discounted cost savings associated with these proposals. In Table R-6, we adopt a 3% and 7% discount rate consistent with Circular A-4 (2003). 110 Cost savings for this proposed rulemaking include savings from reduced ongoing effort to comply with finalized requirements, as shown in Tables R-5 and R-6. In total, this proposed rulemaking would result in a present value of cost savings of $1.53 billion in 2024 dollars and discounted at a rate of 7%, beginning in 2027 and in perpetuity, consistent with analytic guidance on E.O. 14192, as shown in Table R-7. 111 110 *https://trumpwhitehouse.archives.gov/sites/whitehouse.gov/files/omb/circulars/A4/a-4.pdf.* 111 *https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-20-Guidance-Implementing-Section-3-of-Executive-Order-14192-Titled-Unleashing-Prosperity-Through-Deregulation.pdf.* Table R-5—E.O. 12866 Summary Table Non-Discounted Flows [2024 Dollars] Year 1 Year 2 Year 3 Year 4 Year 5 Costs $284,132 Cost Savings 174,843,873.10 $166,922,790.67 $166,922,790.67 $166,922,790.67 $166,922,790.67 Year 6 Year 7 Year 8 Year 9 Year 10 Costs Cost Savings 166,922,790.67 166,922,790.67 166,922,790.67 166,922,790.67 166,922,790.67 Table R-6—E.O. 12866 Summary Table [2024 Dollars] Primary (3%) Primary (7%) Present Value of Quantified Costs $275,856.31 $265,543.93 Present Value of Quantified Cost Savings 2,491,079,993.12 1,775,785,303.03 Present Value of Net Cost Savings 2,490,804,136.81 1,775,519,759.11 Annualized Quantified Costs 18,541.88 25,065.47 Annualized Quantified Cost Savings 167,439,704.42 167,621,570.24 Annualized Net Quantified Cost Savings 167,421,162.54 167,596,504.78 Table R-7—E.O. 14192 Summary Table [2024 Dollars] Primary (7%) Present Value of Quantified Costs $265,543.93 Present Value of Quantified Cost Savings 1,525,278,264.39 Present Value of Net Cost Savings 1,525,012,720.46 Annualized Quantified Costs 25,065.47 Annualized Quantified Cost Savings 143,975,477.95 Annualized Net Quantified Cost Savings 143,950,412.48 C. Regulatory Flexibility Act The Regulatory Flexibility Act
(RFA)requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities. The Small Business Administration
(SBA)establishes the size of small businesses for Federal Government programs based on average annual receipts or the average employment of a firm. 112 112 The SBA references that annual receipts mean “total income” (or in the case of a sole proprietorship, “gross income”) plus “cost of goods sold” as these terms are defined and reported on Internal Revenue Service tax return forms. The entities that are likely to be directly affected by the requirements in this proposed rule are health IT developers. We note that the reasonable and necessary activities identified by the Secretary as not constituting information blocking are themselves exceptions to compliance with the information blocking definition and provide relief for those entities subject to the information blocking regulations. We refer readers to section IV for our information blocking-related proposals and welcome comments on their impacts on small entities. While health IT developers that pursue certification of their health IT under the Certification Program represent a small segment of the overall information technology industry, we believe that many health IT developers impacted by the requirements proposed in this proposed rule most likely fall under the North American Industry Classification System (NAICS) code 541511 “Custom Computer Programming Services.” OMB advised that the Federal statistical establishment data published for reference years beginning on or after January 1, 2022, should be published using the 2022 NAICS United States codes. 113 The SBA size standard associated with this NAICS code is set at $34 million annual receipts or less. There is enough data generally available to establish that between 75% and 90% of entities that are categorized under the NAICS code 541511 are under the SBA size standard. We also note that with the exception of aggregate business information available through the U.S. Census Bureau and the SBA related to NAICS code 541511, it appears that many health IT developers that pursue certification of their health IT under the Certification Program are privately held or owned and do not regularly, if at all, make their specific annual receipts publicly available. As a result, it is difficult to locate empirical data related to many of these health IT developers to correlate to the SBA size standard. However, although not perfectly correlated to the size standard for NAICS code 541511, we do have information indicating that over 60% of health IT developers that have had Complete EHRs and/or Health IT Modules certified to the 2011 Edition have less than 51 employees. 113 *https://www.sba.gov/article/2022/feb/01/guidance-using-naics-2022-procurement.* With the exception of rule review costs, this proposed rulemaking is deregulatory and does not create new requirements on developers of certified health IT, including small businesses. We believe the proposed deregulatory actions will create net cost savings for developers and would not create a significant economic impact on a substantial number of small entities. Additionally, the Secretary proposes to certify that this proposed rule would not have a significant economic impact on a substantial number of small entities. However, we request comments on whether: there are (and how many) small entities that currently pursue certification of health IT under the Certification Program; what products they certify; whether there are any negative or unintended costs for small entities from the proposals included in this proposed rule; and whether small entities will significantly benefit from the proposals include in this proposed rule. D. Executive Order 13132—Federalism E.O. 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on State and local governments, preempts State law, or otherwise has federalism implications. Nothing in this proposed rule imposes substantial direct compliance costs on State and local governments, preempts State law, or otherwise has federalism implications. We are not aware of any State laws or regulations that are contradicted or impeded by any of the proposals in this proposed rule. We welcome comments on this assessment. E. Unfunded Mandates Reform Act of 1995 Section 202 of the Unfunded Mandates Reform Act of 1995 requires that agencies assess anticipated costs and benefits before issuing any rule that imposes unfunded mandates on State, local, and Tribal governments or the private sector requiring spending in any one year of $100 million in 1995 dollars, updated annually for inflation. The current inflation-adjusted statutory threshold is approximately $187 million in 2025. This proposed rule is deregulatory, and, therefore, the estimated potential cost effects of this proposed rule do not reach the statutory threshold. This proposed rule does not impose unfunded mandates on State, local, and Tribal governments, or the private sector. We welcome comments on these conclusions. List of Subjects *45 CFR Part 170* Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Healthcare, Health information technology, Health insurance, Health records, Hospitals, Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, Reporting and record keeping requirements, Public health, Security. *45 CFR Part 171* Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Healthcare, Health care provider, Health information exchange, Health information technology, Health information network, Health insurance, Health records, Hospitals, Privacy, Public health, Reporting and record keeping requirements, Security. For the reasons set forth in the preamble, HHS proposes to amend 45 CFR subtitle A, subchapter D, as follows: PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY 1. The authority citation for part 170 continues to read as follows: Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 552 2. Amend § 170.102 by: a. In the definition of “Base EHR”: i. Revising paragraph (3)(i); and ii. Removing and reserving paragraphs (3)(ii) and (iii); and b. Removing definitions for “Common Clinical Data Set,” “Global Unique Device Identification Database (GUDID),” and “Production Identifier.” The revision reads as follows: § 170.102 Definitions. *Base EHR* * * *
(3)* * *
(i)Section 170.315(a)(1), (2), or (3), (a)(5), (b)(1) and (11), (c)(1), and (g)(10). 3. Revising and republishing § 170.202 to read as follows: § 170.202 Transport standards and other protocols. The Secretary adopts the following transport standard: ONC Applicability Statement for Secure Health Transport, Version 1.2 (incorporated by reference in § 170.299). § 170.204 [Removed and Reserved] 4. Removing and reserving § 170.204. 5. Amend § 170.205 by: a. Removing and reserving paragraphs (a)(3) and (5); b. Revising paragraphs (d)(2) and (i)(2); c. Removing and reserving paragraphs (k)(1) and
(2)and (r)(1); and d. Revising paragraphs (s)(1) and (t)(1) through (4). The revisions read as follows: § 170. 205 Content exchange standards and implementation specifications for exchanging electronic health information.
(d)* * *
(2)*Standard.* HL7 Messaging Standard Version 2.5.1 (incorporated by reference in § 170.299).
(i)* * *
(2)*Standard.* HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in § 170.299). Implementation specifications. HL7 CDA© Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1, Volume 1—Introductory Material and HL7 CDA© Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1 (US Realm), Volume 2—Templates and Supporting Material (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2027.
(s)* * *
(1)*Standard.* 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 and 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 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2027.
(t)* * *
(1)*Standard.* HL7® FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm 2.1.0—STU 2 US (HL7 FHIR eCR IG) (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2027.
(2)*Standard.* 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) (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2027.
(3)*Standard.* HL7® CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG) (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2027.
(4)*Standard.* Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2027. § 170.207 [Amended] 6. Amend § 170.207 by: a. Removing paragraphs (a)(4) and (c)(3); b. Removing and reserving paragraphs (d)(1)(ii) and (iii); c. Removing paragraphs (e)(3) and (4); d. Removing and reserving paragraphs (f)(2), (m)(1), (n)(1) and (3), and (o); and e. Removing paragraphs
(r)and (s). § 170.210 [Removed and Reserved] 7. Removing and reserving § 170.210. 8. Revising § 170.213 to read as follows: § 170.213 United States Core Data for Interoperability. The Secretary adopts the following versions of the United States Core Data for Interoperability standard:
(a)*Standard.* United States Core Data for Interoperability Version 3.1 (USCDI v3.1) (incorporated by reference, see § 170.299).
(b)[Reserved] § 170.215 [Amended] 9. Amend § 170.215 by removing and reserving paragraphs (b)(1)(i) and (c)(1). 10. Revising and republishing § 170.299 to read as follows: § 170.299 Incorporation by reference.
(a)Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(b) and 1 CFR part 51. All approved incorporation by reference
(IBR)material is available for inspection at the U.S. Department of Health and Human Services
(HHS)and at the National Archives and Records Administration (NARA). Contact HHS at: U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201; call ahead to arrange for inspection at 202-690-7151. For information on the availability of this material at NARA, visit *www.archives.gov/federal-register/cfr/ibr-locations* or email *fr.inspection@nara.gov.* The material may be obtained from the sources in the following paragraphs of this section.
(b)Centers for Disease Control and Prevention, 2500 Century Parkway, Mailstop E-78, Atlanta, GA 30333; phone:
(800)232-4636); website: *www.cdc.gov/cdc-info/index.html.* (1)-(3) [ Reserved]
(4)HL7 2.5.1 Implementation Guide for Immunization Messaging Release 1.0, May 1, 2010, IBR approved for § 170.205.
(5)PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data, ADT Messages A01, A03, A04, and A08, HL7 Version 2.5.1 (Version 2.3.1 Compatible), Release 1.1, August 2012, IBR approved for § 170.205.
(6)Conformance Clarification for EHR Certification of Electronic Syndromic Surveillance, ADT MESSAGES A01, A03, A04, and A08, HL7 Version 2.5.1, Addendum to PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data (Release 1.1), August 2012, IBR approved for § 170.205. (7)-(8) [Reserved]
(9)ELR 2.5.1 Clarification Document for EHR Technology Certification, July 16, 2012, IBR approved for § 170.205.
(10)PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, Release 2.0, April 21, 2015, IBR approved for § 170.205(d).
(11)Erratum to the CDC PHIN 2.0 Implementation Guide, August 2015; Erratum to the CDC PHIN 2.0 Messaging Guide, April 2015 Release for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, IBR approved for § 170.205(d).
(12)HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5, October 1, 2014, IBR approved for § 170.205(e).
(13)HL7 Version 2.5.1 Implementation Guide for Immunization Messaging (Release 1.5)—Addendum, July 2015, IBR approved for § 170.205(e). (14)-(16) [Reserved]
(17)HL7® Standard Code Set CVX—Vaccines Administered, dated June 15, 2022; IBR approved for § 170.207(e).
(18)National Drug Code Directory (NDC)—Vaccine NDC Linker, dated July 19, 2022; IBR approved for § 170.207(e).
(19)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 PQRI 2009 Registry XML Specifications, IBR approved for § 170.205.
(2)2009 Physician Quality Reporting Initiative Measure Specifications Manual for Claims and Registry, Version 3.0, December 8, 2008 IBR approved for § 170.205.
(3)[Reserved]
(4)CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting Implementation Guide for 2020; published December 3, 2019, IBR approved for § 170.205(h).
(5)CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs Implementation Guide for 2020; published April 30, 2020, IBR approved for § 170.205(k).
(d)Council of State and Territorial Epidemiologists, 2635 Century Parkway NE, Suite 700, Atlanta, GA 30345; phone:
(770)458-3811; website: *www.cste.org/.*
(1)Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022; IBR approved for § 170.205(t).
(2)[Reserved]
(e)Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104; phone:
(734)677-7777; website: *www.hl7.org/.*
(1)[Reserved]
(2)Health Level Seven Messaging Standard Version 2.5.1 (HL7 2.5.1), An Application Protocol for Electronic Data Exchange in Healthcare Environments, February 21, 2007, IBR approved for § 170.205.
(3)[Reserved]
(4)HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) HL7 Version 2.5.1: ORU-R01, HL7 Informative Document, February, 2010, IBR approved for § 170.205. (5)-(8) [Reserved]
(9)HL7 Clinical Document Architecture, Release 2.0, Normative Edition, May 2005, IBR approved for § 170.205. (10)-(11) [Reserved]
(12)HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture, DTSU Release 2 (Universal Realm), Draft Standard for Trial Use, July 2012, IBR approved for § 170.205.
(13)HL7 v2.5.1 IG: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 Errata and Clarifications, September, 29, 2011, IBR approved for § 170.205. (14)-(17) [Reserved]
(18)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).
(19)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).
(20)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).
(21)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). (22)-(24) [Reserved]
(25)HL7 Version 3 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1, Part 1: CDA R2 and Privacy Metadata Reusable Content Profile, May 16, 2014, IBR approved for § 170.205(o).
(26)[Reserved]
(27)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).
(28)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). (29-30) [Reserved]
(31)HL7 FHIR® Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1), August 22, 2019, IBR approved for § 170.215(a).
(32)HL7 FHIR SMART Application Launch Framework Implementation Guide Release 1.0.0, November 13, 2018, IBR approved for § 170.215(a).
(33)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).
(34)HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1, August 28, 2020, IBR approved for § 170.215(a).
(35)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).
(36)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).
(37)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).
(38)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).
(39)HL7 FHIR US Core Implementation Guide Version 6.1.0—STU 6, June 19, 2023; IBR approved for § 170.215(b).
(40)HL7 FHIR® SMART App Launch [Implementation Guide], 2.0.0—Standard for Trial Use, November 26, 2021; IBR approved for § 170.215(c).
(41)HL7 FHIR® Da Vinci—Coverage Requirements Discovery
(CRD)Implementation Guide, Version 2.0.1—STU 2, January 8, 2024, IBR approved for § 170.215(j).
(42)HL7 FHIR® Da Vinci—Documentation Templates and Rules
(DTR)Implementation Guide, Version 2.0.1—STU 2, January 11, 2024, IBR approved for § 170.215(j).
(43)HL7 FHIR® Da Vinci Prior Authorization Support
(PAS)FHIR Implementation Guide, Version 2.0.1—STU 2, December 1, 2023, IBR approved for § 170.215(j).
(44)HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.0.0—STU 2 US, November 28, 2022, IBR approved for § 170.215(k).
(45)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).
(46)HL7 FHIR® Da Vinci Payer Data Exchange
(PDex)US Drug Formulary Implementation Guide, Version 2.0.1—STU 2, December 1, 2023, IBR approved for § 170.215(m).
(47)HL7 FHIR® Da Vinci Payer Data Exchange
(PDex)Plan Net Implementation Guide, Version 1.1.0—STU 1.1 US, April 4, 2022, IBR approved for § 170.215(n).
(48)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).
(49)HL7 FHIR® CDS Hooks Implementation Guide, Version 2.0.1—ci-build, March 12, 2025, IBR approved for § 170.215(f).
(f)Integrating the Healthcare Enterprise (IHE), 820 Jorie Boulevard, Oak Brook, IL Telephone
(630)481-1004, *http://www.ihe.net/.*
(1)IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-2b), Transactions Part B—Sections 3.29—2.43, Revision 7.0, August 10, 2010, IBR approved for § 170.205(p).
(2)[Reserved]
(g)Internet Engineering Task Force
(IETF)Secretariat, c/o Association Management Solutions, LLC (AMS), 48377 Fremont Blvd., Suite 117, Fremont, CA 94538, Telephone
(510)492-4080, *http://www.ietf.org/rfc.html.* (1)-(2) [Reserved]
(3)Request for Comment
(RFC)5646, “Tags for Identifying Languages, September 2009,” copyright 2009, IBR approved for § 170.207(g).
(h)International Telecommunication Union (ITU), Place des Nations, 1211 Geneva 20 Switzerland, Telephone
(41)22 730 511, *http://www.itu.int/en/pages/default.aspx.*
(1)ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation—General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001, IBR approved for § 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).
(i)National Council for Prescription Drug Programs (NCPDP), Incorporated, 9240 E Raintree Drive, Scottsdale, AZ 85260-7518; phone
(480)477-1000; fax:
(480)767-1042: website: *www.ncpdp.org.*
(1)NCPDP SCRIPT Standard, Implementation Guide, Version 2017071, ANSI-approved July 28, 2017; IBR approved for § 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).
(j)Office of the National Coordinator for Health Information Technology (ONC), 330 C Street SW, Washington, DC 20201; phone:
(202)690-7151; website: *https://healthit.gov.*
(1)United States Core Data for Interoperability (USCDI), Version 3.1 (v3.1), June 2025, IBR approved for § 170.213.
(2)[Reserved]
(k)Public Health Data Standards Consortium, 111 South Calvert Street, Suite 2700, Baltimore, MD 21202; phone:
(801)532-2299; website: *www.nahdo.org/sopt.*
(1)Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011), IBR approved for § 170.207(s).
(2)Users Guide for Source of Payment Typology, Version 9.2, December 2020; IBR approved for § 170.207(s).
(l)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: *https://loinc.org/* and *https://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).
(m)U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894; phone
(301)594-5983; website: *www.nlm.nih.gov/.*
(1)SNOMED CT® [SNOMED Clinical Terms] U.S. Edition, March 2022 Release; IBR approved for § 170.207(a).
(2)RxNorm, Full Update Release, July 5, 2022; IBR approved for § 170.207(d).
(3)RxNorm, December 4, 2023, Full Update Release, IBR approved for § 170.207(d). 11. Amend § 170.315 by: a. Revising and republishing paragraph (a)(5); b. Removing and reserving paragraphs (a)(9), (12), and (14); c. Revising paragraph (b)(1); d. Removing and reserving paragraphs (b)(2) and
(7)through (9); e. Removing paragraph (b)(11)(ii)(B); f. Redesignating paragraph (b)(11)(ii)(C) as paragraph (b)(11)(ii)(B); g. Revising paragraph (b)(11)(iii) introductory text and paragraph (b)(11)(iii)(B); h. Removing and reserving paragraphs (b)(11)(iv) through (vi); i. Revising paragraph (c)(3); j. Removing and reserving paragraphs (c)(4) and (d); k. Revising and republishing paragraph (e)(1); l. Removing and reserving paragraphs (e)(3) and (f)(4); m. Revising paragraph (f)(5) introductory text; n. Removing and reserving paragraph (f)(5)(ii); o. Revising paragraph (f)(6); p. Removing paragraph (f)(7); q. Removing and reserving paragraphs (g)(1) through
(7)and (9); and r. Removing and reserving paragraph (h). The revisions and republication read as follows: § 170.315 ONC certification criteria for Health IT.
(a)* * *
(5)*Patient demographics.*
(i)Enable a user to record, change, and access patient demographic data including race, ethnicity, preferred language, sex, and date of birth.
(A)*Race and ethnicity.* ( *1* ) Enable each one of a patient's races to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify race. ( *2* ) Enable each one of a patient's ethnicities to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify ethnicity. ( *3* ) Aggregate each one of the patient's races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(A)( *1* ) and ( *2* ) of this section to the categories in the standard specified in § 170.207(f)(1).
(B)*Preferred language.* Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g)(2) and whether a patient declines to specify a preferred language.
(C)*Sex.* Enable sex to be recorded in accordance with the standard specified in § 170.207(n)(2).
(ii)Inpatient setting only. Enable a user to record, change, and access the preliminary cause of death and date of death in the event of mortality.
(b)* * *
(1)*Transitions of care—receive and validate* —(i) *Validate C-CDA conformance—system performance.* Demonstrate the ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with the standard specified in § 170.205(a)(6) for the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates. This includes the ability to:
(A)Parse each of the document types.
(B)Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standard adopted in § 170.205(a)(6).
(C)Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standard adopted in § 170.205(a)(6).
(D)Correctly interpret empty sections and null combinations.
(E)Record errors encountered and allow a user through at least one of the following ways to: ( *1* ) Be notified of the errors produced. ( *2* ) Review the errors produced.
(ii)[Reserved]
(11)* * *
(iii)*Decision support intervention selection.* Enable a limited set of identified users to select ( *i.e.,* activate) electronic decision support interventions that are:
(B)Predictive Decision Support Interventions and use any data in paragraph (b)(11)(iii)(A) of this section as well as Clinical Notes and Assessment and Plan of Treatment expressed in the standards for this data in § 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* ) Ambulatory setting only. Provider's name and office contact information. ( *5* ) Inpatient setting only. Admission and discharge dates and locations; discharge instructions; and reason(s) for hospitalization. ( *6* ) Laboratory test report(s). Laboratory test report(s), including: ( *i* ) The information for a test report as specified all the data specified in 42 CFR 493.1291(c)(1) through (7); ( *ii* ) The information related to reference intervals or normal values as specified in 42 CFR 493.1291(d); and ( *iii* ) The information for corrected reports as specified in 42 CFR 493.1291(k)(2). ( *7* ) Diagnostic image report(s).
(B)*Download.* ( *1* ) Patients (and their authorized representatives) must be able to use technology to download an ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) in the following formats: ( *i* ) Human readable format; and ( *ii* ) The format specified in accordance with the standard specified in § 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 paragraph (e)(1)(i)(A)( *1* ), ( *2* ), ( *4* ), and ( *5* ) of this section. ( *ii* ) *Inpatient setting only.* All of the data specified in paragraphs (e)(1)(i)(A)( *1* ) and ( *3* ) through
(5)of this section.
(3)*Inpatient setting only.* Patients (and their authorized representatives) must be able to download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the certification criterion specified in paragraph (b)(1) of this section).
(C)*Transmit to third party.* Patients (and their authorized representatives) must be able to: ( *1* ) Transmit the ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) created in paragraph (e)(1)(i)(B)( *2* ) of this section in accordance with both of the following ways: ( *i* ) Email transmission to any email address; and ( *ii* ) An encrypted method of electronic transmission. ( *2* ) *Inpatient setting only.* Transmit transition of care/referral summaries (as a result of a transition of care/referral as referenced by paragraph (e)(1)(i)(B)( *3* ) of this section) of this section selected by the patient (or their authorized representative) in both of the ways referenced in paragraphs (e)(1)(i)(C)( *1* )( *i* ) and ( *ii* ) of this section).
(D)*Timeframe selection.* With respect to the data available to view, download, and transmit as referenced paragraphs (e)(1)(i)(A) through
(C)of this section, patients (and their authorized representatives) must be able to: ( *1* ) Select data associated with a specific date (to be viewed, downloaded, or transmitted); and ( *2* ) Select data within an identified date range (to be viewed, downloaded, or transmitted).
(ii)*Activity history log.*
(A)When any of the capabilities included in paragraphs (e)(1)(i)(A) through
(C)of this section are used, the following information must be recorded and made accessible to the patient (or his/her authorized representative): ( *1* ) The action(s) ( *i.e.,* view, download, transmission) that occurred; ( *2* ) The date and time each action occurred; ( *3* ) The user who took the action; and ( *4* ) Where applicable, the addressee to whom an ambulatory summary or inpatient summary was transmitted.
(B)[Reserved]
(iii)*Request for restrictions.* Patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. Conformance with this paragraph is required by January 1, 2026.
(f)* * *
(5)*Transmission to public health agencies—electronic case reporting.* Enable a user to create a case report for electronic transmission meeting the requirements described in paragraph (f)(5)(i) of this section.
(6)*Transmission to public health agencies—antimicrobial use and resistance reporting.* Create antimicrobial use and resistance reporting information for electronic transmission. 12. Amend § 170.402 by a. Revising paragraph (b)(2); and b. Removing paragraph (b)(4). The revision reads as follows: § 170.402 Assurances.
(b)* * *
(2)A health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10). 13. 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 revisions read as follows: § 170.404 Application programming interfaces. The following Condition and Maintenance of Certification requirements apply to developers of Health IT Modules certified to any of the certification criteria adopted in § 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). 14. Amend § 170.405 by: a. Revising paragraph (a); b. Removing and reserving paragraph (b)(1); c. Revising and republishing paragraph (b)(2); and d. Revising paragraph (b)(8) introductory text. The revisions and republication read as follows: § 170.405 Real world testing.
(a)*Condition of Certification requirement.* A health IT developer with one or more Health IT Module(s) certified to any one or more of the Certification Criteria for Health IT in § 170.315(b), (c), (e), (f), (g), and
(j)must, on an annual basis, successfully test the real world use of those Health IT Module(s) for interoperability (as defined in 42 U.S.C. 300jj(9) and § 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)in the year preceding the real world testing calendar year reporting period.
(B)Includes the newer versions of certified Health IT Modules that include the § 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) 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: 15. Amend § 170.406 by revising paragraphs (a)(4) and
(5)to read as follows: § 170.406 Attestations.
(a)* * *
(4)Section 170.404 if the health IT developer has a Health IT Module(s) certified to any of the certification criteria adopted in § 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). 16. Amend § 170.407 by: a. Revising the section heading and paragraphs (a)(1)(ii)(B) and
(C)and (a)(3); and b. Revising and republishing paragraph (b). The revisions and republication read as follows: § 170.407 Insights.
(a)* * *
(1)* * *
(ii)* * *
(B)Have health IT certified to the certification criteria specified in each measure in paragraph (a)(3) of this section; or
(C)Have any users using the certified health IT specified in each measure in paragraphs (a)(3) of this section during the reporting period.
(3)*Measures* —(i) *Use of FHIR in apps through certified health IT.* If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses on the number of requests made to distinct certified health IT deployments that returned FHIR resources, number of distinct certified health IT deployments active at any time, the number of distinct deployments active at any time that returned FHIR resources in response to API calls from apps connected to certified health IT, including stratifying responses by the following:
(A)User type;
(B)FHIR resource; and
(C)US Core Implementation Guide version.
(ii)[Reserved]
(b)*Maintenance of Certification.*
(1)A health IT developer must provide responses to the Insights Condition of Certification specified in paragraph
(a)of this section annually for any Health IT Module that has or has had an active certification as of January 1 for each reporting period under the ONC Health IT Certification Program:
(i)A health IT developer must provide responses for measures specified in:
(A)Paragraphs (a)(3)(i)(A) and
(B)of this section beginning July 2027.
(B)Paragraphs (a)(3)(i)(C) of this section beginning July 2028.
(2)[Reserved] 17. Amend § 170.523 by: a. Revising paragraph (f)(1)(viii); b. Removing and reserving paragraphs (f)(1)(ix) through (xi), (xix), and
(xxi)and (p)(1); and c. Revising paragraph (p)(3). The revisions read as follows. § 170.523 Principles of proper conduct for ONC-ACBs.
(f)* * *
(1)* * *
(viii)The certification criterion or criteria to which the Health IT Module has been certified, including the test procedure and test tool version used;
(p)* * *
(3)Submit real world testing results by March 15 of each calendar year to ONC for public availability. 18. Amend § 170.550 by: a. Revising paragraph (e); b. Revising and republishing paragraph (g); and c. Removing and reserving paragraphs
(h)and (j). The revisions and republication read as follows: § 170.550 Health IT Module certification.
(e)*Standards updates.* ONC-ACBs must provide an option for certification of Health IT Modules consistent with § 170.405(b)(7) or
(8)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(b)(10) when a health IT developer presents a Health IT Module for certification that can store electronic health information at the time of certification by the product, of which the Health IT Module is a part.
(2)Section 170.315(b)(4) if the Health IT Module is presented for certification to the certification criteria in § 170.315(b)(3). 19. Amend § 170.555 by revising and republishing paragraph (b)(2) to read as follows: § 170.555 Certification to newer versions of certain standards.
(b)* * *
(2)A certified Health IT Module may be upgraded to comply with newer versions of standards identified as minimum standards in subpart B of this part without adversely affecting its certification status, unless the Secretary prohibits the use of a newer version for certification. 20. Amend § 170.570 by revising the section heading to read as follows: § 170.570 Effect of revocation on the certifications issued to Health IT Module(s). PART 171—INFORMATION BLOCKING 21. The authority citation for part 171 continues to read as follows: Authority: 42 U.S.C. 300jj-52; 5 U.S.C. 552. 22. Amend § 171.102 by: a. Revising definitions of “Access” and “Use”; b. Adding, in alphabetical order, the definitions of “Contract of adhesion”, “Market rate”, and “Unconscionable terms”. The revisions and additions read as follows: § 171.102 Definitions. *Access* means the ability or means necessary to make electronic health information available for exchange or use, including, without limitation, by automation technologies ( *e.g.,* robotic process automation, agentic artificial intelligence). *Contract of adhesion* means a contract provided on a standardized form, or on a “take it or leave it basis” without a realistic opportunity to bargain where the desired product, services, access, use, or exchange cannot be provided except by acquiescing to the form contract. *Market rate* means the value in an arm's-length transaction, consistent with the general market value of the subject transaction. *Unconscionable terms* means contractual terms that are excessive, unreasonable, or shockingly unfair or unjust. *Use* means the ability for electronic health information, once accessed or exchanged through automation technologies or otherwise, to be understood and acted upon, including, without limitation, by automation technologies ( *e.g.,* robotic process automation, autonomous artificial intelligence systems). 23. Amend § 171.204 by: a. Removing and reserving paragraph (a)(3); b. Revising and republishing paragraphs (a)(4)(ii) and (iii); and c. Removing and reserving paragraph (a)(4)(iv). The revisions and republication read as follows: § 171.204 Infeasibility exception—When will an actor's practice of not fulfilling a request to access, exchange, or use electronic health information due to the infeasibility of the request not be considered information blocking?
(a)* * *
(4)* * *
(ii)The actor offered all alternative manners that are set forth in § 171.301(b) in accordance with § 171.301(b), regardless of whether the requestor specified the manner or agreed to it.
(iii)The actor does not provide analogous access, exchange, or use of the requested electronic health information to any other individual or entity. 24. Amend § 171.301 by: a. Removing the word “and” at the end of paragraph (a)(2)(i); b. Removing the period at the end of paragraph (a)(2)(ii) and adding “; and” in its place; and c. Adding paragraph (a)(2)(iii). The addition reads as follows: § 171.301 Manner exception—When will an actor's practice of limiting the manner in which it fulfills a request to access, exchange, or use electronic health information not be considered information blocking?
(a)* * *
(2)* * *
(iii)Any contract or agreement under which the actor and requestor agree to fulfill a request for access, exchange, or use of EHI, and any license from the actor of interoperability elements used in fulfilling the request in the manner requested:
(A)must be at market rate,
(B)must not be a contract of adhesion, and
(C)must not contain unconscionable terms. Subpart D [Removed and Reserved] 25. Remove and reserve subpart D, consisting of §§ 171.400 through 171.403. Robert F. Kennedy, Jr., Secretary, Department of Health and Human Services. [FR Doc. 2025-23896 Filed 12-22-25; 4:15 pm]
Connectionstraces to 13
Traces to 13 documents
50 references not yet in our index
  • 45 CFR 170.315(g)(7)
  • 45 CFR 170.315(g)(10)
  • 45 CFR 170
  • 45 CFR 171
  • Pub. L. 111-5
  • 45 CFR 172
  • 45 CFR 170.315(g)(9)
  • 45 CFR 170.205(a)(5)
  • 42 CFR 495.4
  • 42 CFR 414.1415
  • 42 CFR 414.1305
  • 42 CFR 414.130
  • 45 CFR 164
  • 45 CFR 164.306(b)
  • 45 CFR 160.103
  • 123 Stat. 265
  • 45 CFR 164.528
  • 45 CFR 84.82
  • Pub. L. 93-112
  • 36 CFR 1194
  • 45 CFR 170.565
  • 45 CFR 170.550
  • 45 CFR 170.315
  • 45 CFR 170.315(a)(5)
  • 45 CFR 170.580
  • 45 CFR 170.102
  • 45 CFR 170.405
  • 45 CFR 170.405(a)
  • 45 CFR 170.405(b)(2)(ii)(C)
  • 45 CFR 170.405(b)(2)(iv)
  • 45 CFR 170.407(b)
  • 45 CFR 170.407(a)(3)(iv)
  • 45 CFR 170.523(u)
  • 45 CFR 170.560(a)
  • 45 CFR 170.407
  • 45 CFR 171.102
  • 45 CFR 171.204
  • 45 CFR 171.202(b)
  • 42 CFR 411.351
  • 45 CFR 171.403
+ 10 more
Citation graph
cites case law
Rules and Regulations
Proposed rule
Fed. Reg.Proposed Rules
Pub. L.Public Law 114-255
U.S.C.§ 300jj–11
U.S.C.§ 17935
U.S.C.§ 794d
U.S.C.§ 3701
C.F.R.§ 51.5
U.S.C.§ 3501
U.S.C.§ 1532
Cite45 CFR 170.315(g)(7)
Cite45 CFR 170.315(g)(10)
Cite45 CFR 170
Cites 63 · showing 12Cited by 0 across 0 sources
★   the supreme law of the land   ★
Don't Tread on Me
E Pluribus Unum — out of many, one

"If you don't know your rights, you don't have any."

Marginalia · a citizen's law index
A research desk, not legal advice. Always read the cited source before relying on a summary.
Questions or an issue? support@self-law.org
disclaimerMarginalia is a research index, not a law firm. Nothing on this site is legal, tax, or financial advice and no attorney–client relationship is formed by using it. Statutes, regulations, and case law change; summaries, search results, AI output, and member posts may be incomplete, out of date, or wrong. Any interpretation drawn from material on this site should be validated by a licensed attorney in your jurisdiction before you act on it.