For hospitals, HTI-1’s model cards covered only the EHR vendor’s own algorithms

The week

On December 13, 2023, the Office of the National Coordinator for Health Information Technology released the Health Data, Technology, and Interoperability final rule, known as HTI-1. Among other changes to the certification program and information blocking rules, it replaced the clinical decision support certification criterion with a new decision support interventions criterion. Developers of certified health IT that supply predictive decision support interventions would have to make available a defined set of source attributes describing them. The attributes cover intended use, development data, validation, fairness and maintenance, and developers also had to apply risk management practices. Certified systems also had to let users record and view source attributes for interventions the users developed or obtained elsewhere, and to support user feedback. The rule was published in the Federal Register in January 2024, with the new criterion required by the end of 2024.

HTI-1 was widely described as the first federal transparency rule for AI in clinical care. Earlier articles in this series have covered the governance committees and post-deployment monitoring such tools need, and those apply here. This article looks at a narrower feature of the rule’s design that decided how much transparency a given hospital would actually get. The duty to disclose fell on developers of certified health IT, and only for the predictive interventions they supply. A hospital’s portfolio of predictive models is broader than that, and for the rest the certified EHR had only to provide a place to record the information. The portfolio divides into three groups by who built the model, and they cover every predictive tool a hospital runs through its EHR: models the EHR developer supplies, models the hospital builds itself, and models obtained from other vendors and run inside or alongside the EHR.

Models the EHR developer supplies

For sepsis alerts, deterioration scores, no-show predictions and similar tools shipped with the EHR, the developer had to make available the full set of source attributes: what the model is for and for whom, what data it was trained on, how it was validated and on which populations, what performance and fairness measures were assessed, and how it is maintained. That gave hospitals, for the first time, a standard place to look.

The hospital’s job here is to read the attributes and act on the gaps. An informatics lead can compare each model’s development population with the hospital’s own, flag missing subgroup results, and ask the developer for local validation support before activation. The rule does not require developers to share anything beyond the attributes, so contract terms matter: notice before a model is retrained or its threshold changes, access to performance data from the hospital’s own deployment, and a commitment to update the attributes when the model changes. Those terms are cheapest to obtain at renewal, and they protect the hospital if the regulatory requirement ever narrows.

Models the hospital builds

Academic medical centers and large systems with data science teams build their own models, for readmission risk, bed demand, imaging triage or outreach prioritization, and run them through the EHR. HTI-1 required the certified system to let the hospital record source attributes for these, but nothing in the rule required the hospital to fill the fields in. The hospital is the developer, and the documentation burden is its own.

In practice that means a documentation standard for internal models, applied before deployment and kept current. The attribute list in HTI-1 is a sensible template, because clinicians will see vendor and internal models side by side and should find the same information for both. The data science team owns the content; the clinical owner of the use signs off on intended use and limitations; and a model register tracks version, retraining dates and who reviewed the latest attributes. Internal teams often skip fairness and subgroup analysis because nobody outside asks for it. The template makes the omission visible.

There is a cost. Documenting a model properly takes data scientists away from building the next one, and some internal models are small enough that the effort feels out of proportion. A tiered approach helps. A model that changes a clinician’s workflow or a patient’s access to care gets the full attribute set and a fairness analysis. A model used only for internal capacity planning, with no effect on individual patients, gets a shorter record. The tiering decision itself should be recorded, so that a model’s use cannot drift into a higher-risk category unnoticed.

Models obtained from other vendors

The third group is the fastest-growing: models from specialty vendors, start-ups and research collaborations, delivered through EHR integration frameworks or separate applications. Many of these vendors are not certified health IT developers, so HTI-1’s disclosure duty does not reach them at all. The certified EHR may hold their attributes, but only if someone enters them.

Here the transparency HTI-1 offered depends entirely on procurement. Requests for proposals and contracts can require the vendor to supply the same source attributes the rule requires of certified developers, in the same structure, and to update them with each model version. They can also require evidence of the vendor’s own risk management, rights to local validation, and notice of performance problems found at other customers. Where a vendor refuses, the refusal is itself information for the committee deciding whether to deploy. A hospital that writes these terms into one template contract, used by every department buying an algorithm, closes the largest gap in the rule.

A short portfolio report brings the three groups together. For each predictive model in use, it records the group, whether complete attributes are on file, the date of the last review and the accountable clinical owner. The share of models with complete, current attributes, broken down by group, is a useful measure for a clinical AI committee. It shows where the documentation gap sits and which owner has to close it.

With hindsight

The decision support criterion took effect as scheduled, and certified developers published source attributes for their predictive interventions, with detail that varied from vendor to vendor. Hospital AI governance expanded through 2024 and 2025. HTI-1 pushed it, as did HHS’s 2024 nondiscrimination rule under Section 1557, which addressed patient care decision support tools. The largest push came from the spread of generative AI for documentation and messaging, which the predictive criteria were not designed for. Federal direction then reversed. In late 2025 ASTP/ONC proposed the HTI-5 rule, which would remove the source attribute and predictive risk management requirements from the certification criterion, and its comment period closed in February 2026. As we write the rule has not been finalized. Whatever its outcome, the transparency a hospital can rely on increasingly comes from its own contracts and records, which is where two of the three groups always sat.