From HTI-1 to HTI-5: how US health IT certification rules for AI are shifting, and what to build anyway

What HTI-1 did

• USCDI v3 as the baseline. HTI-1 adopted the United States Core Data for Interoperability version 3 as the baseline standard from 1 January 2026, replacing version 1¹.
• Decision support interventions. It established a decision support interventions (DSI) criterion and added a predictive DSI category covering AI and machine learning capabilities².
• Source attributes. Developers supplying predictive DSIs as part of certified health IT had to make detailed source attribute information available for review, often described as model card requirements, with an enforcement date of 1 January 2025 for the DSI provisions².

What HTI-5 proposes

In December 2025 ASTP/ONC published HTI-5, a deregulatory proposed rule. Commentary describes it as proposing to remove 34 and revise seven of the 60 certification criteria⁵⁶. ASTP/ONC's own materials describe the DSI change as reducing the criterion's scope to remove the AI model card requirements³⁴. Some changes were proposed to take effect on publication of a final rule and others later; sources differ on the details⁵.

Holland & Knight characterised the year-end actions as a strategic pivot in federal health IT policy⁶. Check whether HTI-5 has been finalised, and in what form, before changing plans.

Why I'd keep building transparency anyway

Whatever happens to the certification criterion, the underlying questions don't go away:

• Customers ask. Health systems' AI governance committees often ask vendors what data a model was trained on, how it performs in different populations, and how it is monitored. A clear model description shortens procurement.
• Other regimes apply. Products sold internationally may face the EU AI Act, and regulated device software may fall under FDA pathways such as those in FDA PCCPs.
• Safety and liability. When a model contributes to a harmful outcome, the organisation that can show what it knew about the model, and how it monitored it, is in a far stronger position. See AI incident postmortems.
• Policy swings. Requirements removed in one cycle can return in another. Building transparency as a product capability is cheaper than switching it on and off.

What I'd build regardless of the rule

1. A model description per predictive feature: intended use, training data sources, known limitations, performance overall and by relevant subgroups, update history. Keep it as structured data, not a PDF.
2. Local validation before go-live at each customer, because performance varies between sites; federation helps, as in federated health analytics.
3. Ongoing monitoring for drift and subgroup performance, with a defined path for clinicians to report problems.
4. Change control: every model update versioned, evaluated against a fixed set, and recorded.
5. Interoperable data foundations: USCDI-aligned FHIR data, which most predictive features depend on, built with the patterns in FHIR Bulk Data pipelines and TEFCA.

These map neatly to general frameworks too, such as those compared in ISO 42001 and the NIST AI RMF, so one body of evidence serves several audiences.

For health systems

If you buy rather than build, don't let a relaxed certification requirement relax your procurement. Ask vendors for the same information HTI-1 described, contractually, and require notification of model changes. Your governance committee's questions shouldn't depend on which rule is in force this year.

How I can help

I help health tech companies and health systems build clinical AI with transparency, monitoring and interoperable data foundations that hold up across changing rules. See healthcare data architecture, or analyse your challenge and bring the result to a call.