HTI-5 removes the EHR model card, so send one anyway

ONC's HTI-5 final rule removes the source attribute requirements in 45 CFR 170.315(b)(11)(iv) and (v) and the intervention risk management requirements in (b)(11)(vi) from the decision support interventions criterion. The rule was published in the Federal Register on Oct. 28 and takes effect Dec. 28, 2026, except for a few amendatory instructions that take effect Jan. 1, 2027. The (b)(11) changes are in the Dec. 28 group.

ONC's own description of what it removed is blunt. The rule says the source attribute requirements "support 'model cards' for PDSIs, which essentially function as nutrition labels," covering things like how a predictive algorithm was trained, its intended use and limitations, and how it performs across patient groups. Those were adopted in the 2024 HTI-1 rule, as Akin's summary notes. After Dec. 28, certified EHR developers no longer have to provide that label as a condition of certification.

The information does not stop mattering. ONC says so itself, and that is where vendors come in.

What the rule actually says

The Federal Register text is worth reading directly, because the summary headlines lose some of it. Here is what I took from the decision support section.

ONC finalized removal of paragraphs (b)(11)(iv) through (vi). It also removed the maintenance requirement in 170.402(b)(4) that had required developers to review and update source attribute information and risk management practices. It kept the electronic feedback requirement for evidence-based interventions, now redesignated as (b)(11)(ii)(B), and narrowed the predictive data requirement in (b)(11)(iii)(B) to the evidence-based data list plus Clinical Notes and Assessment and Plan of Treatment.

ONC reported that "a large majority of commenters were not supportive" of the proposal. Its response was that it found no evidence that users relied on the transparency requirements or that they improved patient care. Then comes the sentence I would underline: ONC encourages users of certified health IT "to ask their developers for such information," and reminds them of their obligation to identify potential bias in predictive tools and avoid discrimination under 45 CFR 92.210.

One commenter argument in the rule stuck with me. Some commenters rejected the idea that low use at the point of care means the information has no value, arguing that the real users are governance, procurement, implementation, compliance, and safety teams. ONC did not adopt that view. I think the commenters described the buyer correctly.

A small note for anyone searching the text: in line with an executive order, the rule uses "super intelligence (SI)" where earlier rules said "artificial intelligence". Search for "SI" as well as "AI."

Why this lands on vendors

The removed requirements applied to decision support supplied by certified health IT developers as part of a certified module. If you build a predictive tool that a health system runs alongside or inside its EHR, the question ONC just told health systems to ask is going to arrive in your inbox, in your security questionnaire, or in contract language.

Health systems that already run AI governance will keep asking for this information because their review process needs it. The federal requirement gave everyone a shared list of what to ask. Without it, each health system writes its own. That is more variation for vendors, not less.

The practical response is to stop waiting for each request and publish a standard document. ONC removed the requirement. It did not remove the reasons anyone wanted the answers.

The one-page model card, mapped to the old list

The removed list is still a good template, and it is public. The predictive source attributes in 170.315(b)(11)(iv)(B), as the text reads until Dec. 28, fall into nine groups. I would build a vendor model card with one short block for each:

1. Details and output. Your name and a contact, funding source for the technical implementation, what value the model produces, and whether that output is a prediction, classification, recommendation, evaluation, analysis, or something else.
2. Purpose. Intended use, intended patient population, intended users, and the decision-making role: does the output inform, augment, or replace clinical judgment?
3. Cautioned out-of-scope use. Tasks, situations, or populations where users should not apply it, plus known risks, inappropriate settings, and known limitations.
4. Development details and input features. Inclusion and exclusion criteria for training data, which demographic and social variables are input features, how representative the training data is, and how relevant it is to the setting where it will be deployed.
5. Fairness process. How you approached fair output and how you manage or reduce bias.
6. External validation. Where validity and fairness were tested outside the training source, who did the testing, and how representative that data was.
7. Quantitative performance. Validity and fairness on internal test data and on external data, and references to any evaluation of outcomes.
8. Ongoing maintenance. How and how often you monitor validity and fairness over time, and what you know about performance in local data.
9. Update schedule. How often the model is updated, and how quickly performance is corrected when validity or fairness problems are found.

Add a short tenth block from the removed (b)(11)(vi): how you analyze risks, how you mitigate them, and what governance covers how data is acquired, managed, and used.

Keep it to one page by linking out to longer evidence rather than pasting it in. Put a version number and a date on it.

Where vendors get this wrong

The common failure is filling every block with confident text. The old rule handled gaps honestly. Section (b)(11)(v)(A)(2) required certified modules to indicate when information was not available for certain attributes, including external validation and local performance. Do the same. "Not yet externally validated" is a useful answer. A vague paragraph that implies validation happened is a liability, and a careful reviewer will find it.

The second failure is letting the card go stale. The removed 170.402(b)(4) required developers to keep source attribute information current. Hold yourself to that anyway. Update the card when the model, the training data, or the intended use changes, and keep the old versions.

The third is treating this as a sales document. Reviewers can tell. Write it for the governance and safety teams the commenters described, in plain language they can quote in their own intake records.

Where it fits

If you are already preparing for structured intake, this page overlaps heavily with what CHAI's draft intake playbook asks vendors to evidence. Write it once and map it to both.

The open question is what ONC does next. The rule says it will consider in future rulemaking whether some source attribute transparency elements for evidence-based interventions should be restored. Until then, the list in your own documentation is the one health systems will see. Do you have a version you could send this week?