A clinician acting on an AI recommendation is entitled to know what the tool was built to do, on whose data, how well it performs, and where it fails. Two US regimes now turn that entitlement into disclosure obligations — and they run on different tracks, catch different tools, and use different words for the same idea. This page sets them side by side: what the FDA device pathway forces a maker to say, what the ONC/ASTP HTI-1 certified-EHR pathway forces it to say, where the two converge, and how little gets disclosed in practice today. Every requirement is tied to primary rule text. Because labeling and certification obligations carry legal weight and turn on how a specific product is classified, treat this as orientation and confirm any tool's obligations with your regulatory counsel or compliance function. As of July 2026.
The two regimes at a glance
The first thing to get right is that "transparency" is reached by two independent routes, and a tool's route depends on what it is and where it runs.
| FDA device track | ONC/ASTP HTI-1 track | |
|---|---|---|
| Catches | AI that meets the medical-device definition | Decision-support functions in certified health IT (EHRs) |
| Instrument | Device labeling + transparency guiding principles + draft lifecycle guidance | The Decision Support Interventions certification criterion |
| Core disclosure | Intended use, development, performance, logic, limitations | 31 source attributes for Predictive tools (13 for evidence-based) |
| Status | Principles final (2024); lifecycle guidance still draft (2025) | Final rule; maintenance duty live since Jan 2025 |
| Source | 345 | 12 |
A clinical decision support system cleared as a regulated device and embedded in a certified EHR can be caught by both. A risk calculator native to a certified EHR that never crosses the device line is caught only by HTI-1. And a device used outside certified health IT answers to the FDA track alone.
Track A — the FDA device pathway
When an AI function meets the definition of software as a medical device, its transparency obligations attach to labeling and to the FDA's guiding principles.
The anchor is a joint statement. In June 2024 the FDA, Health Canada, and the UK MHRA published Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles, which defines the concept precisely: "Transparency describes the degree to which appropriate information about a MLMD (including its intended use, development, performance, and, when available, logic) is clearly communicated to relevant audiences" 3. The principles organize disclosure around six questions — who the audience is, why the information matters, what to communicate, where to place it, when to deliver it, and how 3. This builds on the 2021 Good Machine Learning Practice principles the same three regulators issued, which already held that users should be provided "clear, essential information" about a model's intended use, data, and performance 5.
The FDA's more operational move is its January 2025 draft lifecycle guidance for AI-enabled device software functions. It sets out "FDA's current thinking on strategies to address transparency and bias throughout the TPLC of AI-enabled devices," and — tellingly — it carries an example model card and an example 510(k) summary as appendices 4. That signals the format the agency wants: structured, labeled disclosure of what a model is and how it behaves. The guidance remains a draft, so its specifics can shift before they settle; the direction is firm. Where a device also carries a predetermined change control plan, the labeling has to describe what may change and how, so a clinician reading the label knows the model can be updated within pre-authorized bounds.
Track B — the ONC/ASTP HTI-1 certified-EHR pathway
The second regime reaches AI that lives inside a certified electronic health record, whether or not it is a device. The HTI-1 Final Rule adopts the Decision Support Interventions (DSI) certification criterion and, for the first time, defines a Predictive DSI 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" 1. That definition is deliberately wide, reaching from large language models to simple risk calculators.
The substance is the disclosure list. "The HTI-1 final rule expands the number of source attributes that health IT certified to the DSI criterion must support, including 13 for evidence-based DSIs and 31 source attributes applicable to Predictive DSIs" 1. Those 31 attributes fall into nine categories:
| # | Source-attribute category (Predictive DSI) |
|---|---|
| 1 | Details and output of the intervention |
| 2 | Purpose of the intervention |
| 3 | Cautioned out-of-scope use |
| 4 | Intervention development details and input features |
| 5 | Process used to ensure fairness in development |
| 6 | External validation process |
| 7 | Quantitative measures of performance |
| 8 | Ongoing maintenance of intervention implementation and use |
| 9 | Update and continued validation or fairness assessment schedule |
The purpose is explicit: these attributes exist so that "health care organizations and clinical users [can] better determine whether their Predictive DSIs are fair, appropriate, valid, effective, and safe (FAVES)" 1. And the timing is fixed, not aspirational. Developers had to update certified health IT by 31 December 2024, and — per the rule — "starting January 1, 2025 … developers with health IT certified to the DSI criterion must comply with the associated maintenance of certification requirement" that keeps the attributes complete and up to date 2. This is a live obligation rather than a horizon.
Where the two tracks converge: the model card
Read the two regimes together and the same artifact appears in both. Category 4 and 7 of HTI-1's source attributes — development details, input features, quantitative performance — are the fields of a model card. The FDA's draft guidance ships an example model card outright 4. And the Joint Commission and CHAI, in their 2025 responsible-use guidance, recommend the format by name for post-deployment work: an AI model card, "such as CHAI's Applied Model Card, is a great way to collect this information and can be adapted to help monitor bias and risks post-deployment" 7.
The practical consequence for a health system is efficient: a single well-built model card per tool can satisfy the substance of what HTI-1 requires a certified DSI to expose, mirror what the FDA wants in labeling, and feed the intake review a governance committee runs. One artifact, three uses. Requiring a model card at procurement is among the highest-leverage transparency moves a buyer can make.
The reality gap
Requirements on paper are running well ahead of disclosure in practice, and the size of the gap is measurable. A 2025 study scored FDA-reviewed AI/ML devices on a 17-category transparency instrument and found an average score of 3.3 out of 17, with nearly half of devices not reporting a clinical study and over half reporting no performance metric at all 6. That is the backdrop against which both regimes were written, and the reason a buyer cannot assume disclosure has happened — it has to be demanded, tool by tool. The same audit noted only modest improvement after the 2021 guiding principles took hold, which is why both the HTI-1 maintenance duty and the FDA's draft labeling work exist: voluntary norms moved the average slowly. Ongoing performance transparency is also the connective tissue to monitoring: the source attributes a tool exposes at intake are the same fields an algorithmovigilance program tracks over its life.
What a buyer should demand at procurement
For a health system, these obligations collapse into a short, enforceable procurement ask. The disclosures both regimes point to can be required in writing before a tool is signed:
- A completed model card, covering intended use, training and test data, input features, and quantitative performance — the substance of HTI-1's development and performance categories and the format the FDA ships as an example 14.
- The external-validation evidence, including who conducted the testing and on what population — HTI-1 source-attribute category six 1.
- Subgroup performance figures, so the fairness process in category five can be judged rather than assumed 1.
- The maintenance and update schedule, so post-deployment behavior is known in advance — categories eight and nine, alongside the FDA's change-control expectation for any predetermined change control plan 14.
- Audience-tailored information, since the transparency principles hold that what a clinician needs differs from what a patient or caregiver needs, and the format should match the reader 3.
Naming these in a contract is what separates a vendor's marketing claim from a disclosure a governance committee can actually review at intake.
How to read this
Four cautions travel with the comparison.
First, classification decides which track applies, and classification is a legal determination. Whether a tool is a device, a certified-EHR DSI, both, or neither turns on its intended use and where it runs — a call to make with counsel, not from a datasheet.
Second, status is perishable, and one instrument here is still a draft. The FDA lifecycle guidance was issued in January 2025 and, as of July 2026, is not yet final 4; its model-card and labeling specifics can change. The HTI-1 maintenance duty, by contrast, is live 2. Read each row for its status as much as its content.
Third, disclosure is a floor, not proof of quality. A complete model card tells you what a model claims about itself; it does not certify that the model is good. Pair every disclosure with independent appraisal of the evidence behind it.
Fourth, this is US-anchored, and transparency is global. The EU AI Act imposes its own transparency duty — Article 13 requires high-risk systems to be designed so deployers can interpret output and use it appropriately, with instructions for use supplied 8 — on a separate timeline covered in our EU AI Act for healthcare timeline. The cross-jurisdiction status sits in our global AI in health regulation tracker, and the governance body that should be demanding these disclosures at procurement is the subject of our hospital AI governance committee playbook. Because these obligations carry legal weight, confirm any specific tool's requirements with your regulatory counsel before relying on this page.
Sources and method
This guide is built from primary rule text. The HTI-1 disclosures — the Predictive DSI definition, the 13-versus-31 source-attribute split, the nine categories, and the FAVES purpose — come from the ONC/ASTP DSI fact sheet 1 and the Federal Register final rule, which fixes the compliance dates 2. The FDA device-track requirements come from the 2024 FDA/Health Canada/MHRA transparency guiding principles 3, the 2025 draft lifecycle guidance with its model-card appendix 4, and the 2021 Good Machine Learning Practice principles 5. The disclosure-in-practice figure comes from a 2025 peer-reviewed transparency audit 6; the model-card convergence from the Joint Commission and CHAI's 2025 guidance 7; and the cross-jurisdiction transparency duty from Article 13 of the EU AI Act 8. Every figure and quotation is drawn from the source cited beside it. We revisit this page every ninety days and whenever a tracked instrument changes status — most urgently, if the FDA finalizes its lifecycle guidance. Statuses are current as of July 2026.