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, the part of the Department of Health and Human Services that sets standards for health software, released the Health Data, Technology, and Interoperability final rule, known as HTI-1. Much of it dealt with ONC’s certification program, the federal stamp of approval for electronic health record (EHR) systems that hospitals rely on to qualify for federal programs, and with information blocking, the rules against unreasonably withholding patient data.

The rule’s most discussed provision addressed a familiar moment. A nurse on a busy medical floor sees a small banner in a patient’s electronic chart: this patient is at elevated risk of sepsis, a life-threatening reaction to infection. The nurse has seconds to decide how much weight to give it. Until December 2023 there was no standard place to find out who built that warning, what patients it was trained on, or whether anyone had checked that it worked as well for this hospital’s patients as for the ones it learned from.

HTI-1 replaced the old clinical decision support certification criterion with a new one for decision support interventions: the alerts, scores and recommendations software puts in front of clinicians. Developers of certified health IT that supply predictive decision support interventions, meaning tools that use patterns in past data to estimate what is likely to happen to a patient, would have to make available a defined set of “source attributes” describing them, a nutrition label for an algorithm. The attributes cover the tool’s intended use, the data it was developed on, how it was validated, how fairness was assessed and how it is maintained. Developers also had to apply risk management practices to these tools.

The rule went a step further. Certified systems also had to let users, meaning hospitals and clinics, record and view source attributes for interventions the users developed themselves or obtained from someone else, and to support user feedback on those tools. The EHR had to provide a place for the label even when the EHR vendor had not written it.

The rule was published in the Federal Register on January 9, 2024. From January 1, 2025, only the new criterion counted toward the Base EHR definition, the core set of capabilities a certified system must have. The practical question for each hospital was which of its algorithms the rule actually covered, and the answer was less obvious than it looked.

HTI-1 was among the first federal rules to require transparency about AI used in clinical care. One narrow feature of its design 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 together 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. The rule treated those three groups very differently, and a board or executive team that understands the split can see quickly where its exposure sits.

What a predictive model is, and why a label matters

A predictive model is a piece of software that has studied a large amount of past data and learned to estimate the likelihood of something in the future. Feed it a patient’s vital signs, lab results, age and diagnoses, and it returns a number: perhaps a 20 percent chance of being readmitted within thirty days, or a high risk of deteriorating overnight. The model does not understand medicine. It has noticed statistical patterns across millions of records, and it never gets tired.

That strength is also the weakness. A model only knows the patients it learned from. If it was trained mostly on adults at large urban teaching hospitals, it may be less accurate for a rural community hospital’s older population, or for groups that were underrepresented in the data. If the way a hospital records lab results changes, the model may get worse without anyone noticing. And because the reasoning is buried in statistics, a clinician cannot simply look at the alert and judge whether it is sound.

This is where “source attributes,” often called a model card, come in. A model card is a structured fact sheet about an algorithm. Under HTI-1, the attributes for developer-supplied predictive tools cover 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. The card does not guarantee that a model suits a given hospital, but it tells a qualified person what they need to judge that.

The EHR itself is the hub of all this. An electronic health record system is the hospital’s central clinical software, where orders are placed, notes are written and results arrive. Predictive tools increasingly live inside it or plug into it, which is why a rule about EHR certification became, in effect, a rule about clinical algorithms.

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, the clinician or analyst who bridges medicine and technology, 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. Local validation simply means testing the model on the hospital’s own historical patients to see whether it performs as advertised there.

Suppose a 250-bed community hospital is about to switch on a deterioration score that came with its EHR. The informatics lead reads the model card and notices that the development data came from a handful of large academic centers and that results are not broken out by age group. The hospital’s patients skew older. That is not a reason to refuse the tool, but it is a reason to run it silently for a period, compare its predictions with what actually happened, and only then let it interrupt nurses. Without the card, nobody would have known to ask.

The rule does not require developers to share anything beyond the attributes, so contract terms matter. Useful terms include 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. A threshold is the cut-off score at which an alert fires; moving it even slightly can double or halve the number of alerts nurses see, which changes workload and the risk of alert fatigue overnight. 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. A model register is simply an inventory listing every model, who owns it and when it was last checked.

Internal teams often skip fairness and subgroup analysis because nobody outside asks for it. The template makes the omission visible. A blank field marked “fairness assessment” is hard to ignore in a review meeting in a way that an unwritten assumption is not.

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. Say a health system’s analytics team builds a model to forecast how many beds will be needed next week. It is low risk and gets a short record. A year later, a care management team starts using the same scores to decide which individual patients get a follow-up phone call after discharge. The model has not changed, but its consequences have: it now affects who receives care. If the tier was written down, someone reviewing the new use will see the mismatch. If it was not, the model will carry on with a short record and no fairness check.

Why this group carries reputational risk

When a vendor’s model misfires, a hospital can at least point to the vendor. When a home-grown model treats some patients worse than others, the hospital owns the whole story, including the question of why it never checked. For general counsel and boards, internal models are the group where documentation is most clearly a matter of the organization’s own diligence.

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. An integration framework is the set of standard connection points that lets outside software read data from the EHR and display results inside it. 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 start-up that cannot say what data its model was trained on is telling you something about its maturity, and possibly about the model.

A hospital that writes these terms into one template contract, used by every department buying an algorithm, closes the largest gap in the rule. That matters because algorithm purchases are often decentralized. Radiology may buy an imaging triage tool, the revenue cycle team a denial predictor, population health an outreach model, each through its own budget and each with its own paperwork. A single template turns a patchwork of good intentions into a consistent standard, and it gives the procurement office a simple instruction: no signed attributes, no contract.

What the three-way split means for the business

For the two groups of models that HTI-1’s disclosure rules did not cover, a hospital that never asked how a tool was tested will have nothing to show a regulator or a plaintiff.

• Patient safety and quality. A model that performs poorly for some patients can delay care or send attention to the wrong place. The attributes are the first line of defense, because they tell clinicians and committees what to test.
• Legal and regulatory exposure. Regulators and plaintiffs alike will ask what the hospital knew about a tool and what it did to check it. A complete, current record is evidence of diligence. A blank one is evidence of the opposite.
• Cost. Poorly tuned alerts waste clinicians’ time and erode trust, so that useful warnings get ignored along with noisy ones. Asking the right questions before activation is far cheaper than retuning or withdrawing a tool after staff have learned to dismiss it.
• Negotiating position. Contract terms on retraining notice and performance data cost little at renewal and a great deal later. A hospital that knows what to ask for gets more from the same vendor relationship.
• Trust. Patients and staff increasingly ask whether AI is involved in their care. Being able to explain simply what each tool does and how it was checked is part of the hospital’s reputation.

The regulation gave hospitals a strong lever for one group of models and only a filing cabinet for the other two. Everything beyond the EHR vendor’s own tools depended on the hospital’s own discipline.

A coverage report for the AI committee

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.

In a well-run hospital, that report might show nearly complete coverage for EHR-supplied models, because the developer was required to provide the attributes; partial coverage for internal models, improving quarter by quarter as the data science team works through its backlog; and the weakest coverage for third-party tools, with a named procurement action against each gap. That pattern is normal. What matters is that the committee can see it and that each gap has an owner.

The failures are just as recognizable:

• Assuming the rule covers everything. Leaders hear that federal rules now require model transparency and conclude the problem is solved. It is solved, at most, for one of three groups.
• Treating the attributes as paperwork. A model card that is filed but never compared with the hospital’s own population has done nothing.
• No inventory. Many organizations cannot list every predictive model they run. Without that list, no percentage of coverage means anything.
• Letting use drift. A low-risk model reused for a higher-risk purpose without a fresh review is one of the most common ways problems arise.
• Department-by-department buying. Without a template contract, each purchase sets its own standard, and the weakest one becomes the hospital’s real policy.

Where the gaps in the portfolio hide

1. How many predictive models are running through our EHR today, and which group is each in: supplied by the EHR developer, built by us, or bought from someone else?
2. Do our contracts require notice before a model is retrained or its alert threshold changes?
3. Which of our internal models affect individual patients, and have they had a fairness and subgroup analysis?
4. Does every department buying an algorithm use the same contract template, and does it require the vendor to supply and update source attributes?
5. If a regulator, a journalist or a patient asked how a particular alert was checked, could we show them the record that same week?

Behind those sit the follow-up checks: whether anyone has read the EHR developer’s attributes against the hospital’s own patient population, who signs off on intended use and limitations for models built in-house, and what share of models carry complete, current attributes, with a named owner for each gap. Asking takes no technical expertise, only an expectation that the answers exist and that someone is accountable for them. That expectation, set from the top, is what turns a federal rule with a narrow reach into a hospital-wide habit.

With hindsight

The decision support criterion took effect as scheduled, and certified developers had to make source attributes available for the predictive interventions they supplied. For the first group of models, the one the rule reached directly, hospitals got the standard place to look that HTI-1 promised.

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. Section 1557 is the anti-discrimination provision of the Affordable Care Act, so its reach into algorithms gave compliance and legal teams a second reason, beyond certification, to know what their tools did and for whom. The largest push came from the spread of generative AI for documentation and messaging, which the predictive criteria were not designed for. Generative AI writes text, such as a draft clinical note or a reply to a patient message, rather than producing a risk score, and so it fell largely outside the model-card framework HTI-1 had built.

Federal direction then reversed. In December 2025 ASTP/ONC proposed the HTI-5 rule, which would narrow the decision support criterion to remove its AI “model card” (source attribute) requirements, and its comment period closed on February 27, 2026. As we write the rule has not been finalized.

The one group that the regulation did reach could lose its federal backstop. Hospitals that wrote retraining notice, performance data and attribute updates into their contracts with EHR developers will keep those protections whatever happens to the rule. Hospitals that relied on the regulation alone may find the label disappears at the next product update.

The work on the other two groups was never the regulation’s to do. 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. An inventory, a documentation standard for internal models, a template contract for outside vendors and a simple coverage report for the AI committee remain sensible no matter which way federal policy moves. Boards are better served treating algorithm transparency as part of the hospital’s own quality and risk management than as a compliance box someone else is responsible for ticking.