An AI model card in healthcare is a short, standardized document describing what a model does, the data it was trained and tested on, how well it performs and for whom, and its known limits. Model cards help buyers and governance committees judge a tool. They only improve care if the key facts reach clinicians at the moment they use it.
In December 2025, the US federal health IT office made an unusual admission. In a proposed rule, ASTP/ONC wrote that despite health IT products offering detailed information about predictive algorithms since early 2025, it had no publicly available evidence that “a single doctor, nurse, or administrator” had accessed, recorded or modified any of it.
That information was the result of a rule the same office finalized in January 2024. Known as HTI-1, it required certified EHR software to let users see 31 “source attributes” about predictive decision support tools: who developed them, what data they used, how they were validated, how they performed across groups and more. It was, in effect, a mandatory model card built into the EHR. Two years later, the office proposed scrapping it, arguing that the expected benefits had not appeared.
That episode is the most useful thing to happen to the model card debate in years. It shows that transparency documents are easy to mandate and hard to make matter. My argument is that model cards are valuable, but only when they are designed for a specific reader making a specific decision. A label written for everyone is read by no one.
This article reflects US and EU rules and proposals as of late May 2026. It is general information, not legal or regulatory advice.
What is a model card for health AI?
The idea comes from machine learning research. In 2019, Margaret Mitchell and colleagues at Google proposed “model cards for model reporting”: short documents that accompany a trained model and describe its intended use, the factors that affect its performance, its metrics, the data it was evaluated on, ethical considerations and caveats. The goal was to make it harder to use a model outside the conditions it was built for.
Healthcare quickly adapted the idea. In 2020, Mark Sendak and colleagues at Duke published a “model facts” label in npj Digital Medicine, modeled on a drug label or nutrition panel, for a sepsis prediction model used at their hospital. It fit on one page and was written for clinicians. It included the model’s purpose, its outcome definition, its performance, and specific warnings about when not to use it.
Since then, model cards have moved from research proposal to regulatory expectation:
- The FDA, with Health Canada and the UK’s MHRA, published guiding principles on transparency for machine learning-enabled medical devices in June 2024. The FDA’s January 2025 draft guidance on AI-enabled device software functions includes an example model card as a suggested way to present information to users.
- The EU AI Act requires providers of high-risk AI systems to supply instructions for use that let deployers interpret outputs and understand accuracy, known limits and risks.
- The Coalition for Health AI has published an open model card template for health AI developers.
- The FDA’s revised clinical decision support guidance, issued in January 2026, puts weight on letting clinicians independently review the basis for software recommendations.
The concept is now mainstream. The question is whether it works.
What should a healthcare AI model card include?
Good model cards share a core. For a clinical model, that means:
- Intended use: the clinical question, the setting and the intended user.
- Out-of-scope uses: populations and settings where the model has not been validated or should not be used.
- Training and test data: where it came from, when, and who was included, with key demographics.
- Outcome definition: exactly what the model predicts. “Sepsis” can mean several different things.
- Performance: sensitivity, specificity, positive predictive value at the recommended threshold, and calibration, overall and by subgroup.
- Known failure modes: situations where the model is known to perform poorly.
- Update history: version, date and what changed.
A card missing the outcome definition or subgroup performance is marketing, not transparency. As we argued in bias in clinical algorithms, the fix that matters most is often the one nobody checks: whether the model works for the people it will actually be used on.
Why don’t clinicians read AI model cards?
The ONC’s admission points to the answer, and it is not that clinicians do not care.
Wrong moment. A clinician deciding whether to act on a sepsis alert has seconds. A model card lives somewhere else, often several clicks away. Nobody reads a drug’s full prescribing information while giving it, either.
Wrong reader. Many fields in a full model card, such as training data provenance or fairness metrics, are most useful to someone deciding whether to buy or deploy a tool. That is a governance committee or informatics team, not the bedside nurse.
Wrong format. Dense technical documents do not translate into action. A clinician needs to know, in one line, when to distrust the output.
No consequence. If reading the card changes nothing about what the clinician can do, rational people stop reading it.
The HTI-1 approach assumed that making information available would lead people to use it. That is the same assumption behind privacy policies and terms of service. It rarely holds.
A worked example: one model, two labels
Here is a hypothetical hospital deploying an AI model that predicts 30-day readmission to prioritize follow-up calls.
The full model card, for the governance committee, runs to four pages. It explains that the model was trained on data from 2019 to 2023 at three urban hospitals, defines readmission as any unplanned inpatient stay within 30 days at the same health system, and shows performance by age, sex, race and ethnicity, payer and discharge disposition. It notes that performance is weaker for patients discharged to skilled nursing facilities and that readmissions to other hospitals are not counted. The committee uses it to decide whether the model fits their population, what threshold to use and what to monitor.
The bedside label, for the care managers who make the calls, is three lines shown next to each score:
- Predicts: unplanned readmission to this health system within 30 days.
- Less reliable for: patients discharged to skilled nursing facilities.
- Does not see: readmissions to other hospitals.
The second label is not a summary of the first. It is a different document for a different decision. The care manager does not need calibration curves. She needs to know that a low score for a patient who lives near a competitor’s hospital might be misleading.
That split, one detailed card for the people who decide whether to deploy, one short in-context warning for the people who act, is where model cards start to earn their keep.
Is the case for model cards overstated?
The strongest argument against mandatory model cards is ONC’s own. If nobody reads them, they are a cost with no benefit. Developers spend time documenting 31 attributes. The information is outdated as soon as the model is retrained. And by giving an appearance of transparency, cards may reassure buyers without informing them, which is worse than nothing. Developers of certified EHRs also complained, according to ONC, that the rule imposed duties on them that did not apply to other companies building similar AI.
There is a real point here. A regulatory checklist, filled in to comply, is not the same as understanding. And model cards cannot fix a bad model. They can only describe it.
But the conclusion does not follow. That clinicians did not click through to a separate screen shows the design was wrong, not that transparency is useless. The users who most need a full model card, governance committees and procurement teams, are exactly the users who should be asking for one before signing a contract. The absence of evidence that bedside staff accessed source attributes says little about whether informatics teams used them in evaluation. And removing the requirement means buyers lose a standard way to demand the same information from every vendor. The better response would be to keep the disclosure for buyers and redesign the bedside version, not to remove both.
As of this writing, ONC’s proposal to remove the source attribute requirements remains a proposal. Comments closed in February 2026.
What this means for hospitals, developers and regulators
For hospitals, make a complete model card a condition of purchase and put it in the contract, whatever federal rules end up requiring. Have your governance committee actually read it, and use it to set local validation and monitoring. Then write your own short bedside label for each deployed tool, in plain language, focused on when not to trust the output. Our checklist on buying digital health is a good place to add it.
For developers, stop treating model cards as compliance paperwork. Two audiences need two documents. The detailed card should be honest about failure modes and subgroup gaps, because hospitals will find them anyway. The in-context warning should be short enough to sit inside the alert.
For clinicians, ask your informatics team the three questions any bedside label should answer: what exactly does this predict, where is it weak, and what can it not see. If nobody can answer, that is information too. We made a related point about training in teach residents to work without the AI first.
For regulators, measure transparency by use, not availability. Requirements should specify where information appears and for whom, and should be tested with real users before being mandated.
Frequently asked questions
What is the difference between a model card and a model facts label?
A model card, proposed by Mitchell and colleagues in 2019, is a general format for documenting a machine learning model’s intended use, performance, data and limits. A model facts label, published by Sendak and colleagues in 2020, is a healthcare adaptation modeled on drug labels, designed to fit on one page for clinicians. Both aim to prevent models being used outside the conditions they were built for.
Are AI model cards required by law in healthcare?
Not as such in most places. In the US, the ONC’s HTI-1 rule required certified EHR software to provide 31 source attributes for predictive decision support, which functions like a model card, but a December 2025 proposal would remove that. In the EU, the AI Act requires instructions for use for high-risk AI. The FDA recommends, but does not require, model card-style information.
What are ONC’s HTI-1 source attributes?
They are 31 pieces of information that certified health IT had to make available about predictive decision support interventions supplied by the developer. They cover details such as intended use, development data, validation processes, performance measures including fairness, and ongoing maintenance. In December 2025, ASTP/ONC proposed removing these requirements, citing burden and a lack of evidence that users accessed them.
Who should read a healthcare AI model card?
Primarily the people deciding whether and how to deploy the model: governance committees, informatics and data science teams, procurement and clinical leaders. They need the full detail to judge fit, set thresholds and plan monitoring. Bedside clinicians need a much shorter summary, shown where they use the tool, focused on what it predicts and when not to trust it.
The takeaway
Model cards were meant to make AI legible. Their first large-scale test in US hospitals suggests that making information available is not the same as making it used. The fix is not to abandon transparency but to aim it: a full card for the people who decide whether a model enters the building, and a three-line warning for the people who act on it every day.
Has anyone at your organization ever read an AI model’s documentation before using it? What would make a bedside label worth reading?
