Written and maintained by CASRAI Editorial Board
Last updated
Last verified: September 25, 2026. The only rule currently in force in the United States that compels a structured, itemised disclosure about a specific deployed predictive model is not an AI law. It is a health-IT certification criterion. Under 45 CFR 170.315(b)(11), a Health IT Module cannot be certified unless it surfaces thirty-one named source attributes, across nine categories, for every Predictive Decision Support Intervention its developer supplies. That is a far more granular disclosure obligation than any frontier-AI statute imposes on any frontier lab. It is also, in the places that matter most, optional in substance: for external validation, external-data performance, local monitoring and the update schedule, the module need only indicate that the information is not available. In NIKOLAI terms this is the same shape CASRAI has documented across frontier-lab safety frameworks, and it maps onto the N8 transparency-and-review track: the rule mandates a disclosure field, not a disclosed fact.
This guide walks the codified text: what HTI-1 is, how a Predictive DSI differs from an evidence-based one, what the thirty-one attributes actually are, exactly which of them may be left blank, what paragraph (vi) adds through intervention risk management, and the four structural limits that make this rule much narrower than its headline suggests.
What HTI-1 is, and why it is not an AI law
HTI-1 is the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing final rule, published in the Federal Register on 9 January 2024 by the Office of the National Coordinator for Health Information Technology, now the Assistant Secretary for Technology Policy (ASTP/ONC). Its authority is not an AI statute. It runs through section 4002(a) of the 21st Century Cures Act (Public Law 114-255), which gave the agency authority to set conditions and maintenance-of-certification requirements for the voluntary ONC Health IT Certification Program.
That legal hook determines everything about the rule’s reach. Certification is voluntary in form, but effectively compulsory in practice, because participation in Medicare and Medicaid promoting-interoperability programmes requires certified health IT. The obligation therefore attaches to the health IT developer, the company that sells the EHR, not to the hospital that runs it and not to the clinician who reads the model’s output.
The criterion replaced the older clinical decision support criterion at 170.315(a)(9). Developers had to have modules certified to the new (b)(11) criterion by 1 January 2025, the date on which (a)(9) was removed from the Program. So this is not a forthcoming obligation. It has been a condition of certification for more than a year and a half.
Evidence-based DSI versus Predictive DSI
The criterion splits decision support interventions into two classes and gives each its own source-attribute list.
An evidence-based DSI is the familiar kind: a rule, alert or order set grounded in a citation, a guideline or a published study. Its source attributes, at (b)(11)(iv)(A), are essentially bibliographic and provenance facts, including the bibliographic citation, the developer, funding source, release and revision dates.
A Predictive DSI is defined by the rule as 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 definition is deliberately model-agnostic. A logistic-regression sepsis score and a large language model summarising a chart can both land inside it, and neither is named. What triggers the obligation is the relationship between training data and output, not the architecture or the size of the model.
The thirty-one source attributes, category by category
Paragraph (b)(11)(iv)(B) enumerates nine categories. The table below gives the categories in the order the regulation sets them out, the attributes inside each one, and whether the module is permitted to answer “not available” rather than answer at all.
| Paragraph | Category | Attributes required | May be marked “not available”? |
|---|---|---|---|
| (iv)(B)(1) | Details and output of the intervention | Name and contact information for the intervention developer; funding source of the technical implementation for the intervention’s development; description of the value the intervention produces as output; whether that output is a prediction, classification, recommendation, evaluation, analysis or other type | No |
| (iv)(B)(2) | Purpose of the intervention | Intended use; intended patient population(s); intended user(s); intended decision-making role for which the intervention was designed, for example whether it informs, augments or replaces clinical management | No |
| (iv)(B)(3) | Cautioned out-of-scope use | Tasks, situations or populations where a user is cautioned against applying the intervention; known risks, inappropriate settings, inappropriate uses or known limitations | No |
| (iv)(B)(4) | Intervention development details and input features | Exclusion and inclusion criteria that influenced the training data set; use of variables as input features; description of demographic representativeness; description of the relevance of the training data to the intended deployed setting | No |
| (iv)(B)(5) | Process used to ensure fairness in development | Description of the approach the developer has taken to ensure the output is fair, including how bias was managed | No |
| (iv)(B)(6) | External validation process | Description of the data source used for external validation; the party that conducted the external testing; demographic representativeness of that external data; description of the external validation process | Yes |
| (iv)(B)(7) | Quantitative measures of performance | Validity in test data; fairness in test data; validity in external data; fairness in external data; references to evaluation of the intervention’s outcomes | Partly — the external-data and outcome items |
| (iv)(B)(8) | Ongoing maintenance of the intervention’s implementation and use | Process and frequency for monitoring validity over time; the same for validity using local data; process and frequency for monitoring fairness over time; the same for fairness using local data | Partly — the two local-data items |
| (iv)(B)(9) | Update and continued validation or fairness assessment schedule | Process and frequency of updates; the frequency with which performance is corrected when risks are identified | Yes |
Read as a disclosure schema rather than as a rule, this is unusually good. Category (2) forces the developer to state the intervention’s intended decision-making role in language a clinician can act on, and the regulation’s own worked example is the informs / augments / replaces triad. Category (3) forces an affirmative statement of out-of-scope use, which is a question most published model documentation avoids. Category (4) asks, in plain terms, who was excluded from the training set and whether that training set resembles the hospital the model now runs in. Nothing in any frontier-AI framework asks that question in a form that produces a comparable, checkable answer.
The escape hatch at (v)(A)(2)
Paragraph (b)(11)(v) governs how the attributes reach a human. Under (v)(A)(1), the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain-language descriptions of the applicable source attributes. Plain language is a real constraint, and it is stated in the regulation rather than left to guidance.
Then (v)(A)(2) says that for a Predictive DSI the module must indicate when information is not available for review, and it names the paragraphs this applies to: (iv)(B)(6), (iv)(B)(7)(iii) through (v), (iv)(B)(8)(ii) and (iv), and the whole of (iv)(B)(9).
Line those up against the table and the pattern is exact. Every attribute that can be left unanswered is an attribute about evidence generated outside the developer’s own shop or after the model was shipped:
- whether anyone independent ever validated the model, and who;
- how it performs on data that is not the developer’s own test split;
- whether validity and fairness are monitored against the deploying hospital’s own patients;
- when, and how often, the model is updated or corrected.
Everything the developer necessarily already knows, because it built the thing, is mandatory. Everything that would require the developer to have commissioned outside scrutiny, or to keep watching the model after the sale, may be answered with a blank. The certification criterion is satisfied either way. A Health IT Module that displays “not available” against all four of those categories is as certified as one that fills them in.
This is the same failure mode this cluster has documented repeatedly on the frontier-AI side, where a framework commits a lab to publish a category of information without committing it to have the information. The difference is that here the blank is not an omission a reader has to notice. It is a rendered, standardised field, which is a meaningfully better design: an unanswered question that announces itself is easier to act on than one that is silently absent. It is still, however, a disclosure field rather than a disclosed fact. For the frontier-lab version of the same problem, and for what a principled non-disclosure vocabulary would look like, see our guide to the redaction reasons AI labs will and will not admit to.
Paragraph (vi): intervention risk management
The criterion does not stop at disclosure. Paragraph (b)(11)(vi) requires the developer to apply intervention risk management practices to each Predictive DSI it supplies as part of its Health IT Module, in three parts:
- (vi)(A) Risk analysis. An analysis of potential risks and adverse impacts associated with the intervention across eight named dimensions: validity, reliability, robustness, fairness, intelligibility, safety, security and privacy.
- (vi)(B) Risk mitigation. Practices to mitigate the risks identified in that analysis.
- (vi)(C) Governance. Policies and controls governing how the data used by the intervention are acquired, managed and used.
The eight-dimension list is worth sitting with, because it is a codified risk taxonomy for deployed clinical models and it is broader than most voluntary frameworks. Intelligibility, in particular, is rare as a named risk dimension in binding text.
The limit is what happens to the output. Summary information about these practices is provided for review as part of the certification process, through the ONC-Authorized Certification Body. The criterion does not require the risk analysis itself to be handed to the hospital, and it does not require it to be surfaced next to the source attributes the clinician reads. The analysis is an artefact of certification, not of deployment.
Four structural limits worth naming
1. It binds the EHR developer, not the hospital. The source-attribute obligation applies to Predictive DSIs supplied by the health IT developer as part of its Health IT Module. A model the health system builds itself, or buys from a third party and bolts on, is outside that obligation. Paragraph (v)(B) requires the module to let authorised users record and change source attributes, including for interventions the customer supplies, so the schema is available for self-developed models. Using it is a local choice.
2. Nothing requires anyone to act on what they read. The criterion is satisfied when the information is displayable to a limited set of identified users in plain language. There is no obligation on the hospital to review the attributes before go-live, no threshold that blocks deployment, and no consequence for deploying a model whose external-validation field reads “not available”. Whether that review happens is a governance question for the health system, which is why the committee structure matters as much as the rule; see our comparison of a hospital AI governance committee against a corporate AI governance board.
3. It reaches clinical AI the FDA does not. Section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act, added by the 21st Century Cures Act, excludes certain clinical decision support software from the device definition where, among other conditions, the clinician can independently review the basis for the recommendation. A great deal of predictive software running inside an EHR sits in that non-device space and is never reviewed by the FDA at all. The certification criterion catches much of it, by a completely different mechanism: transparency-by-certification rather than premarket review. For how the premarket route works and where foundation models strain it, see our comparison of foundation models against the FDA’s SaMD framework.
4. Certification is a point-in-time test. The attributes must be complete and up-to-date, but the mechanism that checks them is a certification test performed against the module, not a continuous audit of every model running in every hospital that licenses it.
Why this matters to research administration
Academic medical centres sit on both sides of this rule at once, and that is an uncomfortable place to be.
As customers, university health systems run certified EHRs and therefore receive the thirty-one attributes for every vendor-supplied Predictive DSI. That is a ready-made, standardised intake form for a clinical AI review committee, and it is already in the building. Categories (4) and (5), on training-set inclusion and exclusion criteria, demographic representativeness and the fairness process, ask close to the questions an IRB would ask about generalisability if it had a framework for doing so. It generally does not: as we document in OHRP’s unactioned AI recommendations, the federal body that would normally tell IRBs how to weigh AI-specific risk has not issued that guidance. The DSI attribute list is not a substitute for it, but it is a concrete, already-populated set of facts an IRB or a research-computing group can start from.
As builders, the same institutions are outside the obligation entirely. A research-computing team that trains a readmission model on its own health-system data and deploys it through the EHR is not a health IT developer for the purposes of (b)(11), so none of the thirty-one attributes are required of it. Paragraph (v)(B) means the module must let that team record them anyway. Adopting the nine categories as the internal documentation standard for locally developed models is the cheapest available way to make institution-built and vendor-supplied models comparable in the same governance review, and it costs nothing but discipline.
The third angle is sponsored research. When a locally developed predictive model is the subject of a grant-funded study rather than routine care, the attribute list gives sponsored-programs and compliance staff a vocabulary that already exists in regulation, which is easier to defend in a progress report than a bespoke internal template.
Where NIKOLAI fits
NIKOLAI is CASRAI’s own independent frontier-AI-safety dictionary. It is not endorsed by ASTP/ONC or by any other body, and no organisation has filed a Mapping Declaration asserting that its terminology corresponds to these elements. Every correspondence below is therefore a shadow mapping: CASRAI’s own reading, published so it can be checked and disputed, not a claim about how the agency uses its terms.
Two N8 elements are directly in play. Redaction reason exists because a published artefact that omits something should say, in a controlled vocabulary, why it omits it, and should distinguish permitted reasons from prohibited ones. Paragraph (v)(A)(2) is an unusually literal instance of the first half and a complete absence of the second: the rule requires the module to declare that an attribute is unavailable, but attaches no reason code, so “we never commissioned an external validation” and “the external validation exists but we will not share it” render identically to the clinician reading the screen. A redaction-reason vocabulary is precisely the missing field.
External review is the second. Category (6) asks who conducted the external testing, which is the same question NIKOLAI’s external-review element captures through the reviewing party’s identity, the review’s type and its scope. HTI-1 asks the question and then, at (v)(A)(2), permits a blank answer. NIKOLAI’s contribution here is not to require a better answer than the regulator does. It is to give the blank and the answer the same field name, so that a hospital comparing four vendors’ modules can line up four “not available” declarations and see them as a pattern rather than as four unrelated gaps.
Frequently asked questions
Is HTI-1 an AI regulation?
Not in form. It is a certification rule for health information technology, issued under the 21st Century Cures Act, and its subject is what a certified Health IT Module must be able to do. It happens to contain the most itemised model-disclosure requirement currently binding in US federal regulation, which is why it belongs in any serious map of American AI governance.
What counts as a Predictive Decision Support Intervention?
Technology supporting decision-making based on algorithms or models that derive relationships from training data and produce an output resulting in prediction, classification, recommendation, evaluation or analysis. The definition turns on the training-data-to-output relationship, not on the model’s architecture or scale, so simple statistical risk scores and modern generative systems can both fall inside it.
How many source attributes are there, and are they all mandatory?
Thirty-one, grouped into nine categories at 45 CFR 170.315(b)(11)(iv)(B). They are all required to be supported, but (b)(11)(v)(A)(2) permits the module to indicate that the information is not available for the external-validation category, three of the quantitative-performance items, the two local-data monitoring items, and the whole update-schedule category.
Does the rule apply to a model my hospital built itself?
The source-attribute obligation applies to Predictive DSIs supplied by the health IT developer as part of the certified module, so a self-developed or separately procured model is outside it. The module must nonetheless allow authorised users to record and change source attributes, which means the same nine-category schema can be used voluntarily for locally built models.
Does a certified EHR have to stop a clinician from using a model whose fields are blank?
No. The criterion is about making the attributes accessible in plain language to a limited set of identified users. It creates no gate, no threshold and no obligation to review before deployment or use.
When did compliance start?
Health IT developers had to have modules certified to 170.315(b)(11) by 1 January 2025, the date the predecessor clinical decision support criterion at 170.315(a)(9) was removed from the Certification Program.
Sources
- Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing, final rule, Federal Register, 9 January 2024 (document 2023-28857) — codified regulatory text at 45 CFR 170.315(b)(11)(iv) through (vi).
- ASTP/ONC, Health Data, Technology, and Interoperability Certification Program page, and the Decision Support Interventions certification companion guide and test method.
- 21st Century Cures Act, Public Law 114-255, section 4002(a); Federal Food, Drug, and Cosmetic Act section 520(o)(1)(E).
