ONC's HTI-5 Proposed Rule: What the Proposed Slash to Certification Criteria Means for Your EHR Environment

In late December 2025, the Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (ASTP/ONC) dropped one of the most significant proposed changes to the ONC Health IT Certification Program in years. The proposed rule, officially titled "Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions to Unleash Prosperity" and known as HTI-5, would eliminate 34 of the existing 60 certification criteria, revise another 7, and fundamentally reset what it means for health IT to be "certified." ASTP/ONC estimates the changes would save certified health IT developers an average of 4,000 compliance hours each in the first year, cutting roughly 1.4 million total hours of certification compliance burden across the industry.

The comment period closed on February 27, 2026, and no final rule has been issued yet. But even as a proposed rule, HTI-5 signals a clear direction: legacy, document-centric certification requirements are going away, FHIR-based APIs are the future, and the entire privacy and security certification framework under 45 CFR 170.315(d) is on the chopping block. For health care IT teams, especially those at smaller organizations where one or two people manage everything, this matters right now. Not because the rule is final, but because what it removes tells you exactly what you need to own independently of your EHR vendor's certification status.

Why ASTP/ONC Is Making These Changes

HTI-5 did not come out of nowhere. It is part of a broader deregulatory push under Executive Order 14192, which directed federal agencies to reduce regulatory burdens. But the motivations go deeper than executive direction. The ONC Health IT Certification Program has accumulated decades of criteria, many of which were built around technologies and workflows that have either been widely adopted or become obsolete. Criteria designed to enforce specific functionality - like requiring certified EHRs to generate Consolidated Clinical Document Architecture (C-CDA) documents in particular formats, or to support Direct Project messaging protocols - made sense when those capabilities were emerging and adoption needed a regulatory push. That is no longer the case for most of them.

ASTP/ONC's argument is straightforward: when a capability has been universally adopted, continuing to mandate it through certification adds compliance cost without measurable benefit. The agency's burden analysis projects more than $1.53 billion in present-value savings (at a 7 percent discount rate) beginning in 2027, with no new implementation costs for developers. The freed capacity, according to ASTP/ONC, should be redirected toward FHIR-based interoperability work, which is where the agency wants the industry to go.

This aligns with the direction already set by HTI-1, which established USCDI v3 as the baseline standard (effective January 1, 2026) and laid the groundwork for FHIR API certification under 45 CFR 170.315(g)(10). HTI-5 accelerates that shift by clearing out the criteria that anchor the program to older, document-centric approaches.

Whether you agree with the pace or think ASTP/ONC is cutting too much too fast, the direction is unmistakable. The certification program is being rebuilt around FHIR APIs, and everything that does not support that direction is being retired or revised.

The Biggest Changes and What They Remove

The proposed removals and revisions span nearly every section of the certification criteria. Here are the changes most likely to affect your daily operations.

Privacy and Security Criteria: All 14 Gone

This is the headline change. HTI-5 proposes to remove all 14 certification criteria under 45 CFR 170.315(d), which currently require certified health IT to demonstrate capabilities including authentication and access control, auditable events and tamper-resistance, audit reports, amendments, automatic access timeout, emergency access, end-user device encryption, integrity verification, trusted connection establishment, accounting of disclosures, multi-factor authentication, and encryption of health information.

ASTP/ONC's rationale is that these certification criteria are redundant with what health care organizations are already required to do under the HIPAA Security Rule (45 CFR 164.308 through 164.312). The thinking is that covered entities and business associates must implement these safeguards regardless of whether their EHR vendor's software is certified for them, and that maintaining separate certification criteria creates a false sense of security - organizations may assume that because their EHR is certified, their security obligations are met. They are not.

We will dig into the HIPAA implications in detail below, because this is where the real risk sits for health care IT teams.

AI Governance: Model Card Requirements Stripped

HTI-5 revises the Decision Support Interventions (DSI) criterion at 45 CFR 170.315(b)(11) to remove the "AI model card" transparency requirements introduced by HTI-1. These requirements obligated certified EHR developers to provide source attribute information for predictive AI tools, including details about the model's intended use, target population, training data, known risks, and validation processes. The revision also removes the associated risk management requirements for predictive DSIs.

ASTP/ONC cited a lack of evidence that these requirements improved patient care. Industry comment data backed this up. Epic reported that 46 percent of its customer organizations had zero users who ever viewed source attribute information in 2025. Oracle's analytics showed source attributes were accessed an average of twice per month per organization.

The practical effect is that responsibility for evaluating AI tools in clinical environments shifts entirely to the covered entity. If your organization uses AI-enabled clinical decision support, you are now fully responsible for understanding what those tools do, how they were built, and what their limitations are. Your EHR vendor will no longer be required to hand you that information through the certification process.

For health care organizations that have adopted or are considering AI-driven tools for sepsis prediction, readmission risk scoring, medication interaction checking, or similar use cases, this shift creates a documentation gap. Previously, your vendor was required to provide structured transparency information. Going forward, you will need to request that information voluntarily, evaluate it against your organization's risk tolerance, and document your assessment as part of your broader risk analysis under 45 CFR 164.308(a)(1)(ii)(A). This is not optional for HIPAA purposes. Any system that processes or makes decisions based on ePHI needs to be assessed as part of your security management process.

Care Coordination, Public Health, and Other Removals

Several other criteria changes are worth tracking. The transitions-of-care criterion is being revised to focus only on receiving and validating clinical documents (with a proposed effective date of January 1, 2027), rather than both sending and receiving. Clinical information reconciliation is proposed for removal. The legacy Clinical Decision Support criterion at 45 CFR 170.315(a)(9) would be retired. Several public health transmission criteria are being removed or revised to focus on functional FHIR-based requirements. The Direct Project transport protocol and related criteria under the (h) series are proposed for removal. Safety-enhanced design, quality management system, and accessibility-centered design criteria under the (g) series would also be removed.

What This Means for Your Daily Operations

If you manage EHR systems at a health care organization, the practical impact of HTI-5 comes down to three things: what your vendor will still be required to certify, what gaps might open up, and what you need to own regardless.

Start with your Certified EHR Technology (CEHRT) status. CEHRT definitions are tied to CMS programs like Promoting Interoperability and MIPS. When HTI-5 removes certification criteria, the criteria that make up your CEHRT designation change too. CMS will need to update its CEHRT definitions to align with the final rule, and those updates are expected in 2026 or 2027 rulemaking. Until those updates happen, there is a gap between what ONC certifies and what CMS requires, and your organization sits in that gap.

For smaller organizations, this raises a very specific concern. If you are a 25-bed Critical Access Hospital running a single EHR platform with a small IT team (or no dedicated IT staff at all), you may have been relying on your EHR vendor's certification to provide a baseline level of functionality around audit logging, access controls, and encryption. If those criteria are removed, your vendor may still provide those features, but they will no longer be required to maintain them to certification standards. You need to ask, and you need to get answers in writing.

The vendor conversation should happen now, not after the final rule. Ask your EHR vendor specifically what their HTI-5 response plan looks like. Which features currently tied to 170.315(d) criteria will they continue to support, and at what level? Will those features remain included in your current licensing, or will they become add-on modules? What is their roadmap for the retained FHIR criteria? Are they investing the freed compliance capacity into interoperability improvements that benefit your organization, or is it just a cost reduction for them?

EHR upgrades and maintenance cycles will also shift. With fewer criteria to certify against, vendors may change their release cadences. Modules that were previously updated on certification timelines may drift to different schedules. If your organization depends on specific functionality that was driven by a now-removed criterion, you need to understand whether that functionality will continue to be maintained.

The removal of Direct Project transport criteria is another area to watch. If your organization currently uses Direct messaging for health information exchange, those protocols will still work, but your EHR vendor will no longer be required to certify against them. Over time, vendor investment in maintaining Direct transport capabilities may decline as the industry moves toward FHIR-based exchange. If you are in a region where Direct messaging is still the primary exchange mechanism, especially in rural areas where health information exchanges (HIEs) are less mature, this transition could leave you in an awkward spot. Start conversations now about what FHIR-based alternatives your vendor plans to support and when they will be available in your environment.

It is also worth noting that HTI-1 requirements with their existing compliance deadlines remain in effect. HTI-5 does not roll back what HTI-1 already finalized. The USCDI v3 baseline, FHIR API requirements under 170.315(g)(10), and the associated Conditions and Maintenance of Certification obligations still stand. If your EHR vendor has not yet completed their HTI-1 compliance work, that is a separate and more immediate concern than HTI-5.

Security and HIPAA: The Reality Check

Here is where we need to be direct. The removal of all privacy and security certification criteria under 170.315(d) does not change your HIPAA obligations by a single word. The HIPAA Security Rule at 45 CFR Part 164, Subpart C still applies in full.

The technical safeguards under 45 CFR 164.312 still require you to implement access controls (164.312(a)(1)), including unique user identification (Required) and automatic logoff (Addressable). Audit controls (164.312(b)) remain a Required standard - you must implement mechanisms that record and examine activity in systems containing ePHI. Encryption and decryption of ePHI (164.312(a)(2)(iv)) is an Addressable specification, meaning you must either implement it or document why an equivalent alternative is in place. Transmission security (164.312(e)(1)) and its Addressable encryption specification (164.312(e)(2)(ii)) still apply to data in transit. Person or entity authentication (164.312(d)) remains a Required standard.

On the administrative side, risk analysis under 45 CFR 164.308(a)(1)(ii)(A) is still Required. Security incident response and reporting under 164.308(a)(6)(ii) is still Required. Information system activity review under 164.308(a)(1)(ii)(D) is still Required.

A quick note on the "Addressable" designation: it does not mean optional. Under 45 CFR 164.306(d)(3), if a specification is Addressable, you must assess whether it is reasonable and appropriate in your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative measure. It is also worth noting that HHS published a separate proposed rule in January 2025 that would eliminate the Addressable/Required distinction entirely, making all implementation specifications mandatory. That proposed rule's future is uncertain under the current administration's regulatory review process, but the direction of travel is clear: expect "Addressable" to eventually mean "Required" across the board.

The bottom line is this: certification was never a substitute for your own security program. But if your organization was using certified EHR functionality as a shortcut for meeting some of these HIPAA requirements, the removal of those certification criteria means you need to verify independently that the controls are in place, configured correctly, and documented in your risk analysis.

Here is a concrete example of what this looks like in practice. Say you are a rural hospital running an EHR that was certified under 170.315(d)(1) for authentication and access control. You may have assumed that because the software was certified, your access control obligations under 164.312(a)(1) were handled. But certification only tested whether the software was capable of providing those controls. It never verified that your organization configured them correctly, applied them to all systems containing ePHI (not just the EHR), or documented them in your risk analysis. With certification no longer testing that capability, you need to confirm that the feature still exists, still works as expected, and that your policies and procedures address access control across your entire environment, including workstations, file shares, email, and any other system touching ePHI.

The same logic applies to audit logging. Certification under 170.315(d)(2) ensured your EHR could generate audit logs and tamper-resistant records. But audit controls under 164.312(b) require you to implement logging mechanisms across all information systems containing ePHI, not just your EHR. Network devices, file servers, cloud services, remote access systems - all of these need audit trail capabilities. If your audit logging strategy was anchored to your EHR's certified capabilities, this is the time to broaden the scope.

OCR's third phase of HIPAA compliance audits, which commenced in late 2024, is specifically targeting risk analysis and risk management requirements. The timing here is not coincidental. With certification removing a layer of implied assurance, organizations that cannot demonstrate independent compliance with the Security Rule's technical safeguards will be in a weaker position if OCR comes knocking.

Action Steps You Can Take Today

Even though HTI-5 is still a proposed rule, the direction is clear enough to act on. Here is what health care IT teams should be doing right now.

Contact your EHR vendor and ask for their HTI-5 response plan. You want specifics: which currently certified features will continue to be supported, what changes to expect in upcoming releases, and what their FHIR roadmap looks like. If they do not have answers, that is a data point too.

Audit your current environment against the retained certification criteria. The criteria that survive HTI-5 are the ones ASTP/ONC considers essential going forward, primarily centered on FHIR APIs under 170.315(g)(10). Understand where your EHR stands relative to those retained criteria and what upgrades might be needed.

Update your risk analysis. If your organization uses AI-enabled clinical decision support tools, the removal of model card requirements means you need your own process for evaluating those tools. Document what AI tools are in use, what they do, how they were validated, and what their known limitations are. This is now entirely your responsibility.

Review your HIPAA Security Rule compliance independently of your EHR's certification status. Walk through the technical safeguards in 45 CFR 164.312 and confirm that access controls, audit logging, encryption, integrity protections, and authentication are implemented, active, and documented. Do not assume your EHR handles it. Verify.

Prepare for CMS CEHRT adjustments. If your organization participates in Promoting Interoperability or MIPS, the CEHRT definition will change when HTI-5 is finalized. Watch for CMS guidance in upcoming rulemaking cycles and plan for any gaps between your current CEHRT status and the updated requirements.

Monitor for the final rule. The comment period is closed, and industry feedback has been extensive. A final rule is expected in the spring or summer of 2026, but specifics could change based on the comments received. Stay engaged through ASTP/ONC's updates at healthit.gov.

The Opportunity in the Reset

HTI-5 is a significant shift, but it is not just a story about what is being taken away. The compliance burden reduction is real, and if your EHR vendor reinvests that freed capacity into FHIR interoperability and better API support, your organization stands to benefit. Faster, more granular data exchange. Better patient access to their own records. Real-time public health reporting that does not require manual intervention. These are the capabilities that a FHIR-first certification program is designed to accelerate.

The risk is in the transition. If your organization treats the removal of certification criteria as a signal to relax, you will create gaps. If you treat it as a signal to own your security and compliance posture independently - which is what the HIPAA Security Rule has always required - you will be in a stronger position regardless of what the final rule looks like.

The certification program is resetting. Your HIPAA obligations are not. Use this window to close the gaps between what your vendor certifies and what your organization actually needs to have in place.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

• ASTP/ONC HTI-5 Proposed Rule page: https://healthit.gov/regulations/hti-rules/hti-5-proposed-rule/
• Federal Register, HTI-5 Proposed Rule (December 29, 2025): https://www.federalregister.gov/documents/2025/12/29/2025-23896/health-data-technology-and-interoperability-astponc-deregulatory-actions-to-unleash-prosperity
• 45 CFR Part 164 - Security and Privacy (HIPAA Security Rule): https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164
• 45 CFR Part 170 - Health Information Technology Standards: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170
• HHS HIPAA Security Rule NPRM Fact Sheet (December 27, 2024): https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html
• Healthcare IT News, "ASTP/ONC seeks relaxation of health IT certification criteria with HTI-5": https://www.healthcareitnews.com/news/astponc-seeks-relaxation-health-it-certification-criteria-hti-5