HTI-1: Algorithm Transparency Requirements for Certified Health IT

HTI-1 rewrote the decision support portion of the ONC Health IT Certification Program for the first time since 2012. The old clinical decision support criterion at 45 CFR 170.315(a)(9) was retired and replaced by a decision support interventions criterion at 170.315(b)(11), which does three things.

1. It defines a predictive DSI. ONC's definition is technology that supports decision making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. That language is broad on purpose and it captures far more than machine learning branded products.
2. It requires structured disclosure. A certified module must let a limited set of identified users see complete and current descriptions of 13 source attributes for each evidence-based DSI and 31 source attributes for each predictive DSI that the developer supplies. Those same users must be able to record and change source attributes for interventions the organisation supplies itself.
3. It requires risk management. For each predictive DSI the developer supplies, the developer must apply intervention risk management practices covering risk analysis, risk mitigation and governance, and must make a summary of those practices publicly available.

Note what is absent. There is no accuracy threshold, no fairness threshold, no approval step and no prohibition on deploying a model that performs badly. HTI-1 is a disclosure and process rule. Whether a model is fit for your population is still your judgement, which is why this page ends with a checklist rather than a compliance certificate.

The test is not whether a vendor calls something AI. It is whether the technology supports decision making using a model derived from data, and whether the developer of the certified health IT supplies it as part of the module.

Things that typically fall inside: sepsis and deterioration scores shipped with the EHR, no show and readmission risk models, length of stay predictions, coding or documentation suggestions that use a trained model, and patient risk stratification used in care coordination workflows. Things that typically fall outside: a rule based alert built from an if-then statement, a third party model your organisation licences separately and pipes in through an API, and anything you build yourselves in an analytics environment.

That last category is where the disclosure gap opens up. HTI-1 was written around the assumption that predictive models arrive bundled with the EHR. In practice a growing share of clinical prediction reaches the bedside through separate contracts with vendors who have no certification obligation at all. Those tools are not lawless, they are simply governed elsewhere: by HIPAA where they touch patient data, by FDA where they cross the device line, and otherwise by whatever you wrote into the contract. The practical implication is that your model inventory has to be wider than the list of predictive DSIs your EHR vendor discloses.

ONC groups the 31 predictive DSI source attributes into nine categories. They are the closest thing US health care has to a standard model card, and reading them properly is the single highest value thing a clinical informatics team can do with this rule.

Categories 7 and 8 are where most conversations get interesting. A developer can satisfy the criterion by describing its process honestly, including describing that local validity is not monitored. The rule requires the disclosure, not the good answer. Read for the gaps.

Confusion about HTI-1 nearly always comes from collapsing three different roles into one. They carry very different obligations.

The asymmetry is the point worth taking away. The category of tool that is most heavily disclosed under federal rules is the one bundled with your EHR. The category expanding fastest, standalone AI agents bought on their own contract, is disclosed only if you insist. That is a procurement problem, and it is solvable at procurement.

Generally no, and it is worth being precise about why. An ambient documentation tool sold by a separate vendor and integrated through an API is not a decision support intervention supplied as part of a certified Health IT Module, so the criterion does not attach to it. The same holds for an AI phone agent, a patient intake agent or a prior authorisation workflow.

Two caveats change the answer. First, if your EHR developer ships its own ambient documentation or inbox drafting capability inside the certified module, and that capability uses a trained model to produce a recommendation, evaluation or classification, it can fall within the predictive DSI definition. Ask, do not assume. Second, a tool that starts as documentation and grows into suggestion can drift across the line. A scribe that drafts a note is one thing. A scribe that proposes a diagnosis code or flags a suspected condition is doing something closer to decision support, and it raises the FDA device question as well as this one.

FDA has addressed the overlap directly. In its clinical decision support FAQs, FDA notes that some predictive DSIs meet the definition of a device under section 201(h) of the Federal Food, Drug, and Cosmetic Act and others do not, and points developers to the Clinical Decision Support Software guidance to work out which. Being disclosed under HTI-1 says nothing about whether a tool is a regulated device, and being outside HTI-1 says nothing about whether it is safe.

Most organisations that request source attributes read them once, file them, and never return. That wastes the rule. Three uses justify the effort.

Deciding whether local validation is required. Category 4 tells you the training population and category 6 tells you whether the model was ever tested outside its home institution. A model trained on an academic centre's population and never externally validated, deployed in a community health centre with a different case mix, is a candidate for local validation before it influences care, not after. Category 7 gives you the performance baseline to validate against.

Setting the human oversight level. Category 2 states the intended decision making role: informs, augments, or replaces clinical management. If the developer says a model was designed to inform and your workflow lets it drive an action without review, you have a governance gap that is visible in a document the developer wrote. That is an easier conversation than one based on intuition.

Building the monitoring plan. Categories 8 and 9 tell you what the developer monitors and how often it updates. Whatever the developer does not monitor is what you monitor, and whatever the developer updates on a schedule is what you re-baseline on that schedule. This is the part of a model inventory that most organisations skip, and it is the part that catches silent degradation.

None of this requires a data science team. It requires someone senior enough to read nine categories, ask three questions, and write the answers down where an auditor can find them.

Yes, with a visible question mark over its future. The transparency requirements at 45 CFR 170.315(b)(11) and the maintenance obligations at 170.402(b)(4) remain in the Code of Federal Regulations and were still being enforced in 2026, including through the January 1, 2026 update deadline that ONC softened to February 28, 2026 after the appropriations lapse.

The HTI-5 proposed rule, published December 29, 2025 at 90 FR 60970 under the title Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions To Unleash Prosperity, proposes to reset the certification program's scope substantially and, per ASTP/ONC's own fact sheet, to reduce the scope of the DSI criterion so as to remove the AI model card requirements. The comment period closed February 27, 2026 at 5:00 pm ET. No final rule had been published as of early August 2026.

The operator's reading is straightforward. Do not build your AI governance on the assumption that a federal disclosure requirement will keep supplying you with model documentation. Build it on contract terms and an internal model inventory that survive whatever happens to the criterion, and treat any federal disclosure you get as a bonus rather than the foundation. Organisations that did this in 2024 have not had to change anything. Organisations that outsourced their model transparency to the certification program are now watching a comment docket.

The certification program regulates your vendor. This checklist is about what you do with that.

1. Inventory every model in clinical or operational use. Split it into two columns: supplied by the certified EHR, and everything else. Most organisations discover the second column is longer than expected.
2. For column one, request the source attributes in writing. Name the intervention, cite 45 CFR 170.315(b)(11), and ask for all nine categories. Also ask for the hyperlink to the developer's public summary of its intervention risk management practices, which it is required to maintain and submit to its certification body.
3. For column two, ask for the same nine categories as a contractual deliverable. There is no legal obligation, which is exactly why the answer is informative. Do this during vendor selection, not after signature.
4. Triage on categories 4, 6 and 7. Anything with no external validation, a training population unlike yours, or no reported performance numbers goes on a local validation list before it influences care.
5. Set an oversight level per model from category 2 and check that the live workflow matches it.
6. Write the monitoring plan from categories 8 and 9, with a named owner and a review interval, and put it in the same risk register as the rest of your estate rather than in a project spreadsheet.
7. Re-check ONC's rulemaking status each quarter. HTI-5 is pending, and the answer may change.

Steps one, four and six are the ones that take real time, and they are the ones that hold up under scrutiny from a board, a payer or a regulator. If you want that inventory and monitoring plan built once, properly, our AI governance and compliance engagement does exactly this work, and the readiness audit is the shorter way to find out how big your second column really is.