On January 1, 2025, a new federal certification criterion became the successor to the older clinical decision support criterion for electronic health records. HTI-1 required capabilities for accessing information about predictive tools and required developers to manage risks associated with tools they supplied through certified health IT.
A hospital could now ask for structured information about a prediction’s intended population, validation, and limitations. But a certification designation did not answer the hospital’s next question: does the evidence support using this prediction with our patients, our data, and our clinical workflow?
HTI-1 makes that question easier to investigate. It does not decide the answer for the hospital.
The Category Concerns Predictive Tools Supplied Through Certified Health IT
The HTI-1 final rule defines predictive decision support interventions, or predictive DSIs, by how they work. They use algorithms or models that learn relationships from training data and produce predictions, classifications, recommendations, evaluations, or analyses to support decisions.
For the developer disclosure and risk-management obligations discussed here, a second condition matters: the certified health IT developer supplies the intervention as part of its module certified to the DSI criterion, section 170.315(b)(11). A trained model estimating a patient’s likelihood of deterioration is an illustrative candidate. A fixed clinical rule is not automatically a predictive DSI merely because software delivers it.
This is not a general licensing regime for automated systems. An unrelated employment-screening model does not become subject to these requirements simply because it uses machine learning. The relevant connection is to the certified health IT and the intervention supplied through it.
Nor is predictive DSI another name for a medical device. FDA expressly explains that some predictive DSIs may meet the statutory device definition and others may not. Device status requires a separate analysis of the software function and applicable law. A tool can fall within both frameworks. ONC certification does not replace an applicable FDA authorization, and exclusion from device regulation does not establish exemption from ONC’s requirements.
The Developer Must Explain What the Evidence Concerns
The ONC fact sheet identifies 31 predictive source attributes. These are categories of information about the intervention, rather than 31 tests that every model must pass.
They address intended use, patient populations, users, decision-making role, and cautioned uses. Development information includes training-data inclusion and exclusion criteria, demographic representativeness, relevance to the intended setting, and use of specified demographic, social-determinant, and health-status inputs.
Validation information addresses external testing, the testing party, population, and process. Performance categories distinguish results from data related to the training source, results from external data, and local performance. They also address evaluations of clinical outcomes and arrangements for monitoring, updating, and correcting performance.
These disclosures help a purchaser identify what the evidence actually covers. A favorable result from adult inpatients does not establish performance in children. A prediction of deterioration within 24 hours does not establish that the same score identifies who needs intervention within an hour.
The source-attribute provisions do not require delivery of the underlying training dataset. They also should not be mistaken for a complete operational specification describing every input, transformation, and missing-data rule. The hospital needs enough additional technical information to understand what will actually enter the model.
Risk Management Requires Work Beyond Disclosure
The regulatory text requires analysis of potential risks and adverse impacts concerning validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy. Developers must apply mitigation practices and governance policies and controls, including controls over data acquisition, management, and use.
Fairness is therefore expressly part of the framework. The rule also calls for descriptions of fairness approaches and efforts to manage bias, alongside quantitative fairness information. It would be inaccurate to describe HTI-1 as silent on discriminatory performance.
But required analysis is different from a government-established passing score. ONC’s developer guidance says the Certification Program has not established requirements for specific measures of validity or fairness. The companion guide requires a Health IT Module to indicate when source attribute information is not available for review. ONC expects developers to exercise due diligence before determining that a source attribute’s information is unknown, and to update source information when appropriate.
Certification therefore does not establish that every supplied model has undergone independent external validation, achieved a particular accuracy threshold, or demonstrated adequate performance in every customer’s setting. The requirement to manage risks is substantive; its existence is not proof that every proposed deployment is supported.
The Hospital Must Connect the Evidence to the Installation
Consider a hypothetical hospital purchasing a deterioration score evaluated at another institution. The original evaluation used frequent observations and promptly available laboratory results. At the purchasing hospital, observations arrive less often, laboratory feeds have delays, and overnight response staffing differs.
There are several questions to resolve before treating the published results as evidence for this installation.
First, are the inputs equivalent? A correctly transferred value can still be unsuitable if its units, timing, clinical meaning, or treatment of missing observations differ from what the model expects. Interface testing alone does not settle that question.
Second, does the evidence support performance in this population? The hospital needs to examine relevant differences and determine what additional local evaluation is necessary. That does not automatically require retraining the model or repeating its entire development program.
Third, what happens at the selected alert threshold? The hospital needs to understand missed cases, false alerts, and the workload created. An overall performance statistic does not choose the acceptable tradeoff for a particular clinical service.
Finally, can staff act on the result? An accurate warning delivered after the opportunity to intervene has passed does not produce the intended benefit. The clinical workflow is part of the proposed use.
These are practical deployment judgments. Section 170.315(b)(11) does not independently impose a universal hospital testing protocol or require each hospital to conduct every form of validation itself. The hospital can evaluate vendor evidence, obtain assistance, and negotiate testing and monitoring responsibilities. It still needs an adequate basis for its decision.
