HTI-5 Explained: What Health IT Developers Can Stop Building

Key Takeaways

• The HTI-5 final rule removes 14 certification criteria, revises seven, and leaves 39 unchanged within the ONC Health IT Certification Program.
• A removed certification criterion ends a specific federal certification obligation. It does not automatically eliminate customer needs, contractual promises, patient safety duties, HIPAA obligations, or other regulatory requirements.
• Developers can reduce work tied solely to retired certification criteria, including certain testing, documentation, maintenance, and recertification activities, after the applicable effective date.
• Healthcare organizations should not interpret HTI-5 as permission to remove useful clinical, security, patient access, or interoperability functions from deployed products without a separate risk and requirements review.
• FHIR-based APIs, electronic prior authorization, patient access, information sharing, and secure interoperability remain central to the federal direction for health technology.
• The strongest response is a controlled portfolio review that distinguishes regulatory certification work from functionality that still creates clinical, operational, commercial, or compliance value.

What the HTI 5 Final Rule Changes

The Health Data, Technology, and Interoperability final rule known as HTI-5 was published in the Federal Register on October 28, 2026. Most provisions take effect on December 28, 2026, while specified changes take effect on January 1, 2027. The rule narrows the scope of the voluntary ONC Health IT Certification Program and reduces ongoing work for developers of certified health IT.

The final rule is narrower than the proposal released in December 2025. ONC originally proposed removing 34 of the program’s 60 certification criteria and revising seven. After reviewing comments, ONC finalized 14 removals and seven revisions while retaining 39 criteria without change. Healthcare leaders should therefore base decisions on the final rule, not on early summaries of the proposal.

ONC estimates the finalized changes will produce a present value of $1.55 billion in cost savings and annualized net savings of $108.1 million in 2024 dollars, calculated at a seven percent discount rate beginning in 2027. These figures describe expected regulatory savings across affected parties. They are not a guaranteed saving for every hospital, vendor, or product.

HTI-5 also scales back portions of Real World Testing and reduces several Insights reporting measures. Conforming edits affect the Assurances, Application Programming Interfaces, and Attestations Conditions and Maintenance of Certification. The policy direction is clear: certification will focus less on mature, functionality-oriented requirements and create room for future FHIR-based API requirements.

What Developers Can Stop Building for Certification

The practical answer requires careful wording. Developers may stop building or maintaining capabilities solely to satisfy a removed ONC certification criterion, once that removal becomes effective and after confirming that no other obligation requires the capability. The rule does not order vendors to delete functioning features. It removes specified criteria from the federal certification framework.

The 14 removed criteria cover clinical decision support under section 170.315(a)(9); family health history; security tags for sending and receiving a summary of care; care plans; clinical quality measure filtering; patient health information capture; automated numerator recording; automated measure calculation; Consolidated CDA creation performance; application access for patient selection; application access for all data requests; the Direct Project; and the combined Direct Project, Edge Protocol, and XDR or XDM criterion.

Several removals become effective with the final rule on December 28, 2026. Others, including family health history, clinical quality measure filtering, patient health information capture, automated numerator recording, automated measure calculation, application access for patient selection, and application access for all data requests, take effect on January 1, 2027. Product roadmaps should reflect the correct date for each criterion.

For affected modules, developers can examine whether they still need certification-specific user interface elements, test scripts, conformance evidence, documentation, reporting logic, and regression suites created only for a retired criterion. They may also be able to avoid future recertification work linked exclusively to that criterion. The opportunity is to remove compliance overhead, not to create uncontrolled functional gaps.

Direct messaging illustrates the distinction. HTI-5 removes the Direct Project criteria from certification, so developers may no longer need to build or certify that transport method for the ONC program. However, customers may still depend on Direct for referrals, care summaries, or established exchange workflows. A vendor should review utilization, contracts, replacement options, and migration costs before retiring the capability.

The same principle applies to family history, care plans, quality calculations, and patient-submitted information. A certification requirement may disappear while the underlying capability remains useful in clinical care, quality programs, population health, payer reporting, or patient engagement. Leaders should ask whether the feature exists only because of certification or because users and workflows still depend on it.

What Developers Cannot Stop Building

HTI-5 does not eliminate the ONC Certification Program, and it does not remove every criterion discussed in the proposed rule. Thirty-nine criteria remain unchanged. Seven criteria are revised rather than removed. These include transitions of care, clinical information reconciliation and incorporation, decision support interventions, clinical quality measure reporting, view download and transmit, antimicrobial use and resistance reporting, and safety-enhanced design.

Privacy and security provide the most important warning. The proposed rule considered removing multiple privacy and security certification criteria, but the final rule retained them. Developers should not rely on proposed-rule lists that suggested authentication, access control, audit records, encryption, integrity protections, emergency access, or multifactor authentication would disappear. Security engineering remains essential for certification, HIPAA compliance, contracts, risk management, and patient trust.

The decision support interventions criterion also remains, although its scope changes. HTI-5 removes the source attribute support and access requirements often described as model card requirements. That revision reduces a defined certification burden. It does not remove the need to manage clinical risk, validate decision support, monitor performance, document intended use, or meet other applicable obligations for predictive or AI-enabled tools.

Information blocking responsibilities also remain important. The final rule addressed a narrowed set of proposals, and ONC stated that comments on other proposed provisions remain under review. Healthcare leaders should not assume the final rule adopted every proposed information blocking change. Existing obligations concerning access, exchange, and use of electronic health information continue unless changed through a separate final action.

HTI-5 also does not reverse the broader shift toward FHIR APIs. ONC describes the rule as a reset that creates a foundation for future FHIR-based requirements. The agency intends to prioritize APIs that improve automation and performance, support interactions beyond read-only access, and expand the data available for clinical care, patient-centered services, and timely reporting.

Recent requirements from HTI-4 are among the 39 criteria retained without change. Health IT roadmaps must still account for electronic prior authorization APIs, real-time prescription benefit functionality, updated electronic prescribing, and modular API capabilities where applicable. Removing an older criterion does not cancel a newer requirement serving a related workflow.

What Healthcare Leaders Should Review Now

Healthcare leaders should begin with an inventory of certified modules, certification criteria, customer commitments, interfaces, and downstream workflows. Each affected criterion should be mapped to the product components, tests, policies, contracts, and operational processes that rely on it. This prevents a regulatory change from becoming a patient care or service disruption.

Next, classify each capability into one of four categories: certification-only work that can end; functionality customers still require; functionality required by another law, program, or contract; and functionality that should migrate to a modern standard. This classification gives finance, compliance, product, clinical, and engineering teams a common basis for decisions.

Do not measure the opportunity only by deleted code. Much of the saving may come from fewer test cases, reduced evidence preparation, simpler release gates, lower certification fees, less reporting, and fewer maintenance activities. In some products, keeping a stable capability will cost less than removing it and supporting customer migrations.

Leaders should also review vendor contracts. A hospital may have purchased functionality described as certified, standards-based, or required for a defined workflow. Even when a criterion is removed, the vendor may remain contractually responsible for availability, support, data retention, interoperability, or transition assistance. Procurement and legal teams should confirm the practical effect before accepting roadmap changes.

Finally, redirect released capacity toward measurable priorities. Strong candidates include FHIR API performance, prior authorization automation, data quality, identity and consent workflows, clinician usability, cybersecurity, observability, and patient access. HTI-5 creates flexibility, but value depends on where the organization reinvests the time and budget.

Why Certification Removal Does Not Equal Product Retirement

ONC certification establishes a federal baseline for specified health IT capabilities. Product strategy has a wider scope. Hospitals, medical groups, payers, public health agencies, laboratories, pharmacies, and patients may rely on a capability even when ONC no longer tests it as a separate criterion. Removing that capability without understanding actual use can interrupt referrals, reporting, clinical review, or access to information.

Other authorities and programs can also preserve the need. HIPAA privacy and security obligations, state laws, CMS program rules, accreditation expectations, payer agreements, business associate contracts, customer service levels, and internal risk policies operate independently from a removed certification criterion. A legal and compliance review should identify these requirements before engineering work is cancelled. Clinical leadership should separately assess whether the feature supports safety, continuity of care, or professional standards.

Architecture creates another constraint. A retired criterion may share services, data models, interfaces, or audit controls with functions that remain certified. Deleting one component can create failures elsewhere or make future upgrades more expensive. Engineering teams should trace dependencies and compare three options: keep the current capability, simplify its certification-specific elements, or migrate users to a supported replacement. The lowest regulatory cost is not always the lowest total cost.

Healthcare buyers should ask vendors for a written HTI-5 impact statement. It should identify affected modules, planned changes, effective dates, customer actions, migration support, and any effect on certification status. Buyers should also request confirmation that retained security, API, patient access, and interoperability requirements remain covered. Clear documentation will help governance committees distinguish a legitimate compliance adjustment from an unsupported reduction in product capability.

For leadership teams, the decision rule is simple: remove only the work whose sole purpose was satisfying a retired certification criterion. If a capability supports care delivery, patient access, security, reporting, interoperability, or a commercial promise, evaluate it under the relevant operational standard. Record the decision, responsible owner, evidence, transition date, and customer communication so audits and product reviews can follow the reasoning.

A Practical HTI 5 Action Plan

First, establish a cross-functional owner for the HTI-5 response. The owner should coordinate product, engineering, security, compliance, clinical operations, customer success, and contracting. A narrow certification review will miss dependencies that sit outside the certification team.

Second, create a criterion-by-criterion impact register. Record whether the criterion is removed, revised, or retained; its effective date; affected products; current certification status; related contracts; user adoption; replacement options; and the proposed decision. Keep evidence for every decision, including decisions to retain a capability.

Third, separate technical retirement from regulatory retirement. A team may stop preparing certification evidence on the effective date yet continue operating the feature for customers. Technical retirement should follow its own lifecycle, including notice, data migration, security review, testing, training, rollback planning, and support.

Fourth, update the product roadmap and budget. Remove work that no longer has regulatory or customer value, preserve essential capabilities, and fund modernization that supports current interoperability needs. Avoid moving every saved hour into new feature development before security, quality, and integration risks are covered.

Fifth, communicate clearly with customers. Explain which certification obligations changed, whether product functionality will change, what dates apply, and what action customers need to take. Healthcare organizations need operational answers, not a list of regulatory citations.

What Value ChampSoft Can Add

ChampSoft can help healthcare organizations and health IT vendors translate HTI-5 into a practical product and engineering plan. The work begins with an impact assessment that maps removed, revised, and retained criteria to applications, interfaces, test assets, documentation, and customer workflows.

For capabilities that remain valuable, ChampSoft can support maintenance, modernization, and migration. This may include replacing older exchange patterns with appropriate FHIR APIs, improving integration architecture, strengthening data validation, and reducing duplicate logic across products. The objective is to lower avoidable certification effort while preserving dependable healthcare operations.

ChampSoft can also help teams redesign quality assurance after certification changes. Test suites can be separated into regulatory, contractual, clinical safety, security, and customer experience coverage. This prevents teams from deleting tests simply because a certification criterion was removed and gives leaders a clearer view of the risks each test controls.

Where organizations are investing in new APIs or AI-enabled workflows, ChampSoft can provide domain-aware engineering support across discovery, architecture, development, testing, deployment, and production support. The engagement can be structured around defined outcomes, including faster integration, lower maintenance effort, improved data exchange, or reduced manual work.

The result is a controlled transition from compliance-driven development to value-driven modernization. Decisions remain traceable, customers receive a clear migration path, and engineering capacity is directed toward the functions that healthcare users still need.

Conclusion

HTI-5 gives health IT developers meaningful regulatory relief, but it does not make established healthcare requirements disappear. The final rule removes 14 certification criteria and revises seven, creating opportunities to reduce certification-specific development, testing, documentation, and reporting work. It also retains most criteria and preserves the need for secure, reliable, interoperable health technology.

Healthcare leaders should treat the rule as a portfolio decision. Stop work that exists only for a retired certification obligation. Keep functions that protect patients, support users, satisfy contracts, or meet other legal requirements. Modernize capabilities that are better delivered through FHIR APIs and newer architecture. That approach converts regulatory relief into lower cost and better technology without creating new operational risk.

FAQs