Regulation & Incentives

The HTI-1 Final Rule: Decision Support Interventions and Algorithm Transparency in Your EHR

Artificial intelligence has arrived in the EHR faster than most practices expected, in the form of risk scores, sepsis alerts, no-show predictions, and drafting tools. The federal government's first substantial regulatory response for certified health IT came in the ONC Health IT Certification Program rule known as HTI-1, published in early 2024. The rule does not regulate how clinicians use these tools, and it does not certify that any algorithm works. What it does is require certified EHR developers to disclose specific information about the predictive tools they supply, so that the people relying on them can judge them. This guide explains what changed and what a practice should do with the information.

What HTI-1 is and who it applies to

HTI-1, formally the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing final rule, was issued by the Office of the National Coordinator for Health Information Technology and published in the Federal Register in January 2024. It updates the certification criteria that EHR developers must meet for their products to be listed as certified health IT, which in turn is what practices and hospitals rely on for programs such as Promoting Interoperability and MIPS.

The rule applies directly to health IT developers seeking or maintaining certification. It does not impose obligations on practices. Its effect on a practice is indirect: the certified EHR the practice uses must be updated to meet the new criteria by the rule's compliance dates, and the practice gains access to information it did not have before. The rule also carried a number of information-blocking and interoperability updates unrelated to algorithms, discussed briefly below.

From clinical decision support to decision support interventions

For years, certified EHRs met a clinical decision support criterion that focused on rule-based alerts: drug-drug interaction checks, preventive care reminders, and similar logic that a person could read and understand. HTI-1 replaced that criterion with a broader one called decision support interventions, or DSI. The new criterion recognizes two categories. Evidence-based DSIs are the traditional rule-based tools whose logic is explicit. Predictive DSIs are tools that use models, including machine learning, to produce an output such as a probability, a risk score, a classification, or a recommendation, where the relationship between inputs and outputs is learned rather than written as rules.

The DSI criterion requires certified health IT to allow users to configure, enable, and disable interventions, to provide feedback on them, and, critically, to view a defined set of information about each intervention the developer supplies. For predictive DSIs, that information is considerably more extensive than for evidence-based ones.

Scope note: the transparency requirements attach to predictive DSIs that the certified developer supplies as part of its Health IT Module. A third-party tool that the practice bolts onto the EHR itself may not be covered, and a practice should not assume the same disclosures exist for it.

Source attributes: transparency for predictive tools

The centerpiece of the algorithm transparency provisions is the requirement that developers make available a set of "source attributes" for each predictive DSI. Think of them as a nutrition label for the model. The attributes fall into several groups, and while the exact list is in the regulation, the themes are:

  • Purpose and intended use. What the intervention is for, its intended patient population, its intended users, and the clinical decisions it is meant to inform.
  • Cautions and exclusions. Known limitations, populations for which it has not been validated, and situations where it should not be used.
  • Development details. The outcome or output the model predicts, the input features it uses, a description of the training data including demographics where available, and how the developer addressed fairness and bias.
  • Validation and performance. Whether and how the model was validated externally, the performance measures used, and results across relevant subgroups.
  • Ongoing maintenance. How the developer monitors the intervention over time and how often it is updated.

Developers must also maintain and update this information as part of their intervention risk management practices, and summary information about those practices is to be made publicly available. The rule does not tell developers what the answers must be, only that they must answer. A model with weak external validation can still be shipped; the practice just gets to see that it was.

Other changes in the rule

HTI-1 was a wide-ranging rule, and the algorithm provisions were only part of it. The rule adopted a newer version of the United States Core Data for Interoperability as the baseline data set for certification, expanding the data classes certified EHRs must be able to exchange. It made revisions to the information blocking regulations, including changes to some of the exceptions. It updated certification criteria related to patient demographics, observations, and electronic case reporting, and it introduced a new "Insights Condition" under which developers report certain metrics about how their certified products are used in the field. Each of these has its own compliance timeline, and developers rolled them out through product updates over 2024 and 2025.

What it means for a practice

For most practices, the immediate effect of HTI-1 is that the EHR now has, or should have, a place where the source attributes for any predictive tool the vendor supplies can be viewed. That is an opportunity. A practice deciding whether to turn on a risk score or trust a draft generated by the EHR should read the label first: what population was it trained on, was it validated at organizations like ours, and what does the developer say about its limitations?

The rule also shifts a governance question onto the practice. Because users can enable, disable, and configure interventions, someone at the practice is making those decisions, whether deliberately or by default. Larger organizations are forming clinical informatics committees to review predictive tools before activation. A small practice can accomplish the same thing with a short checklist and a named clinician responsible for reviewing the source attributes and documenting the decision.

Finally, practices should be clear about what the rule does not do. It does not certify accuracy, it does not approve any tool for clinical use, and it does not regulate tools outside the certified module. The disclosures are a starting point for professional judgment, not a substitute for it.

Questions to ask your EHR vendor

  1. Which predictive decision support interventions are included in our certified product today, and where in the application can we view their source attributes?
  2. Which of the predictive tools you market to us are part of the certified module, and which are separate products not covered by the DSI transparency requirements?
  3. Have any of these interventions been externally validated at organizations similar to ours in size and patient population?
  4. How do we disable or reconfigure an intervention, and who at our practice has the permission to do so?
  5. How do you notify us when a model is retrained or its performance changes?
  6. Where can we find your publicly posted summary of intervention risk management practices?

A vendor that can answer these readily is one that has taken the rule seriously. A vendor that cannot is telling the practice something useful as well.

Common questions

Does HTI-1 require my practice to do anything?

Not directly. The rule sets requirements for certified health IT developers. Practices benefit from the disclosures and gain configuration controls, and they should use them, but the compliance obligation rests with the developer.

Does the rule certify that an AI tool in my EHR is accurate or safe?

No. It requires developers to disclose information about how a predictive tool was developed, validated, and maintained. Judging whether the tool is appropriate for your patients remains a clinical governance decision.

What is a predictive decision support intervention?

A tool that uses a model, often machine learning, to produce an output such as a risk score, probability, or recommendation, where the relationship between inputs and outputs is learned rather than written as explicit rules.

Are third-party AI tools connected to my EHR covered by HTI-1 transparency requirements?

Generally not, unless the certified developer supplies them as part of its certified Health IT Module. Ask the vendor which tools are in scope; do not assume the same disclosures exist for separately purchased products.