If the electronic health record your practice already pays for is certified by the federal government, does that mean someone in Washington has checked the AI tools built into it? Until recently, the honest answer was "partly." After the HTI-5 final rule, the answer for AI transparency is closer to "no," and that changes how every healthcare organization should approach AI vendor vetting.
On October 26, 2026, the Office of the National Coordinator for Health IT released the HTI-5 final rule, which HHS describes as a deregulatory action projected to save more than $1.5 billion in compliance costs for health IT developers. Buried in that rule is a change that matters to every clinic, specialty group, and health system using AI: the federal "model card" requirements for decision support tools are being removed.
HTI-5 removes the requirement that certified health IT give users access to standardized information about how AI and other decision support tools were built, trained, and validated. According to the American Hospital Association's summary of the final rule, ONC removed 14 certification criteria rather than the 34 it originally proposed, revised seven others, and narrowed the decision support interventions criterion specifically to drop the AI model card requirements.
Those requirements came from HTI-1, finalized in December 2023. Since January 1, 2025, certified health IT has had to support access to 31 source attributes for predictive tools and 13 for evidence-based ones, covering intended use, training data, validation, and performance, as Health System CIO's analysis of the rule lays out. Most HTI-5 changes take effect 60 days after the rule's scheduled October 28, 2026 Federal Register publication, which puts the model card removal in late December 2026. ONC has said it may consider restoring some source-attribute requirements in future rulemaking, but no one should plan around a maybe.
Here is the direct answer for a practice leader: HTI-5 does not ban AI transparency. It removes the federal requirement that your EHR vendor hand it to you. If you want to know how a predictive tool was trained, validated, and monitored, you now have to ask for that information yourself, in writing, and make delivery of it a condition of the contract.
The common reaction to HTI-5 is that a safety net just disappeared. I would push back on that, because it gives the old rules more credit than they earned. HTI-1's source attributes were disclosure requirements. They made information available. They never evaluated whether a sepsis alert or a readmission risk score performed well on your patient population, and they never told your clinicians whether to trust it.
In other words, the vetting was always yours. HTI-1 just made the first step easier by guaranteeing that the documentation existed and sat in a predictable format. HTI-5 removes that guarantee. The organizations that will feel this most are not the ones that were reading model cards closely. They are the ones that assumed the word "certified" meant someone had already done the review.
That assumption shows up in the commentary on the rule as well. Hooper Lundy & Bookman's review of the final rule notes that ONC removed the model card and risk-management mandates despite opposition from a large majority of commenters, who warned the change would shift evaluation, governance, and liability burdens onto providers and health systems. That is the practical effect. The burden did not vanish. It moved down the supply chain to the buyer.
It fits a clear direction. In January 2026, the FDA updated its clinical decision support and general wellness guidance in ways that, according to McDermott Will & Schaumburg's review of the FDA updates, allow more digital health technologies to reach the market without premarket review. We covered the FDA side of this in our look at how the FDA is building its AI medical device rulebook; the common thread is that fewer AI tools in your clinical workflow will arrive with a federal reviewer's fingerprints on them.
This is the part most practices miss, and it is where the compliance exposure actually sits. HTI-5 reduces what EHR developers must provide. It does nothing to the duties that fall on the provider using the tool.
The clearest example is Section 1557 of the Affordable Care Act. Under 45 CFR 92.210, a covered entity must not discriminate through its use of patient care decision support tools, has an ongoing duty to make reasonable efforts to identify tools that use inputs measuring race, color, national origin, sex, age, or disability, and must make reasonable efforts to mitigate the risk of discrimination from each such tool. Those identification and mitigation duties have applied since May 2025, and they are still in the current federal regulations.
Think about what that means in practice. Your organization is still responsible for knowing which inputs a predictive tool relies on. The federal mechanism that made the developer put that information in front of you is going away. If your team cannot get it voluntarily from the vendor, you have an obligation you cannot document meeting. HIPAA works the same way: the Security Rule's risk analysis duty covers every system that touches ePHI, including AI features, regardless of what the certification program requires of the developer. Our breakdown of the HIPAA Security Rule changes healthcare organizations need to know covers that side in more detail.
Ask for the same information HTI-1 required, and make it contractual. The source-attribute categories are a ready-made checklist: they were developed through public rulemaking, vendors already built them, and many will keep producing them for customers who ask. The difference is that delivery is now a negotiation, not an entitlement.
| What certified health IT had to make available under HTI-1 | What you should require in writing after HTI-5 |
|---|---|
| Intended use and cautioned out-of-scope uses | A written statement of intended use, and a commitment to notify you before the vendor changes it |
| Training data description, including demographic composition | Training data provenance, with enough detail to complete your Section 1557 input-variable review |
| External validation and performance measures | Validation results on a population comparable to yours, plus your right to run local validation |
| Ongoing maintenance and update schedule | Advance notice of model updates or retraining, and drift monitoring responsibilities named in the contract |
| Intervention risk management practices | Incident reporting obligations when the tool produces harmful or materially incorrect output |
The contract piece matters more than the questionnaire. A sales team will answer almost anything during evaluation. What protects you is a clause that obligates the vendor to keep that documentation current and gives you the right to verify it. We went deeper on that in our piece on the AI vendor contract clause that decides whether you can prove compliance.
Fold it into third-party risk management you already run rather than inventing a parallel process. Most healthcare organizations already send security questionnaires and sign business associate agreements before onboarding a vendor. AI review belongs in that same gate, triggered whenever a tool produces clinical, financial, or eligibility recommendations. If your vendor program is thin to begin with, start with our guide to protecting your business from vendor vulnerabilities.
From what we see in regulated client environments, a workable minimum looks like this:
The record of what a vendor would not provide is easy to overlook and valuable. If a regulator, plaintiff, or payer later asks how you evaluated a tool, "we asked, they declined, and here is how we compensated" is a defensible answer. Silence is not.
HTI-5 is a healthcare rule, but the lesson applies to any regulated business buying AI. Federal policy in 2026 has generally moved toward lighter requirements on AI developers, while the obligations on the businesses that deploy AI, from anti-discrimination law to privacy and sector regulators, have stayed in place. We tracked that divergence in our analysis of how sector regulators kept moving while state AI laws stalled. The organizations that treat vendor documentation as something they must obtain, rather than something they will be handed, are the ones that will hold up under scrutiny.
This is also why AI adoption is, at its core, a governance decision rather than a technology one, a point we make in why AI adoption for SMBs is a governance problem. The tool is rarely the hard part. Knowing who approved it, on what evidence, and who is watching it is.
For healthcare and other regulated clients, Securafy builds AI review into the vendor risk process they already have. We inventory the AI features running across their platforms, including the ones vendors switched on quietly, then map each tool to the obligations it triggers under HIPAA, Section 1557, and any state rules that apply. From there we draft the AI documentation request and contract language, track what each vendor actually delivers, and keep the evidence file current at renewal.
The goal is not to slow procurement. It is to make sure that when someone asks how a tool was vetted, the answer is already written down, with the vendor's documentation, your review, and any gaps you chose to accept on the record.
HTI-5 removes the federal requirement that puts AI model information in front of you, but it leaves your duty to evaluate those tools fully intact. The fastest next step is an inventory of the AI already running in your clinical and business systems, followed by a documentation request to each vendor before the model card requirements lapse in late December.
If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. AI University gives your people role-based AI training with security built into the material, not bolted on afterward.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.