How to compare clinical AI model card frameworks

A health system evaluating AI model cards for clinical tools now has several credible places to look, and that is both progress and a new comparison problem. CHAI, DIHI, and FDA materials all push vendors toward disclosure on intended use, target population, data provenance, demographics, validation, subgroup performance, limitations, deployment monitoring, and regulatory status. None of the three, by itself, gives a procurement team a complete way to compare two tools that arrive in different formats.

The safer move is to use a consolidated checklist: start with CHAI for a comparable, registry-oriented model card; check DIHI Model Facts v2 for HTI-1 attribute completeness; and borrow FDA’s Total Product Life Cycle questions when the tool has higher clinical or device-risk implications. That approach gives a committee something more useful than a declaration that “a model card exists.” It gives reviewers a way to ask the same second-round questions of every vendor.

A Working Comparison Checklist

This is the packet-level version of the comparison. It is not elegant, but it is reviewable. A committee can hand it to procurement, a clinical informatics lead can use it to normalize vendor responses, and a governance group can decide which missing fields are disqualifying versus which require follow-up.

How CHAI, DIHI, and FDA Differ

CHAI’s Applied Model Card is the most operational starting point because it is built as an open, web-oriented schema rather than only as a document template. Its fields cover developer identity, intended use, target population, performance and validation, data and methodology, bias and limitations, deployment and monitoring, and regulatory or compliance information. The schema is open-source through GitHub, which matters when a health system wants comparable fields across vendors instead of a pile of differently formatted PDFs.[1]

DIHI Model Facts v2 is better understood as a completeness instrument. It uses a single-page format and enumerates the 31 HTI-1 source attributes in a side column, under a Creative Commons Attribution 4.0 license. That makes it especially useful when a reviewer needs to check whether required source attributes are present, even if the vendor’s main transparency document uses another structure.[2]

FDA’s January 2025 draft guidance belongs in a different bucket. It recommends model cards for AI-enabled devices within a Total Product Life Cycle frame, with attention to model description, data, user interface, risk management, model design, performance validation, usability, and transparency design. It is draft guidance, not binding law, and it is oriented toward device submission logic more than day-to-day procurement comparison.[3]

The practical reason to start with CHAI is that it gives the review process a shared shape. The CHAI model card registry launched in February 2025 with no-cost upload and viewing, and its backers included Aidoc, Ambience, Cleveland Clinic, Kaiser Permanente, Providence, and Stanford Medicine.[4] CHAI also describes more than 1,300 member organizations in its broader coalition context.[1] Those are adoption signals, not evidence that every card will be complete or every tool will perform well. They do mean a procurement team can plausibly ask vendors to answer in a structure that other major health systems are already watching.

The Fields That Deserve Follow-Up Questions

Intended Use Cannot Stay Generic

The first weak point in many vendor disclosures is intended use. A useful model card should not merely say that a tool supports radiology, sepsis detection, documentation, readmission prediction, or prior authorization. It should name the clinical task, the intended user, the workflow step, the care setting, and the decision that follows the output.

For review purposes, “intended for clinicians” is too broad. A bedside nurse seeing an interruptive alert, a hospitalist reviewing a ranked worklist, and a coding team receiving suggested documentation all face different risks. CHAI’s intended-use and target-population fields help standardize that first pass.[1] FDA’s framing adds pressure to ask how the output is presented and what role the user is expected to play in the decision.[3]

Target Population and Data Demographics Need Separate Lines

A target population is the group the tool is meant to serve. Data demographics describe the people represented in development and validation data. They are related, but they are not interchangeable. A model can claim use in adult emergency department patients while being trained largely on data from one health system, one region, or one care pattern.

This is where DIHI’s HTI-1 mapping earns its place in the review workflow. HTI-1’s predictive decision support intervention requirements use 31 source attributes and FAVES criteria, a shorthand for fair, appropriate, valid, effective, and safe.[5] DIHI’s value is not that it solves bias review. It is that it makes it harder to overlook source attributes that should have been visible before contracting.[2]

Validation Should Say What Was Actually Tested

A model card should distinguish internal validation, external validation, silent trials, prospective evaluation, and post-deployment monitoring. These are not decorative methodological labels. They tell the committee whether performance was measured in the development environment, in a separate institution, in live workflow without action, or after the tool began affecting care.

The review packet should ask for the validation population, validation period, reference standard, performance metrics, calibration where relevant, and comparator. If thresholds drive action, the threshold should be stated. If the vendor changed thresholds between development and deployment, that should be visible too.

Subgroup Performance Is Not an Optional Appendix

Subgroup performance is where model cards move from general transparency to clinically useful transparency. In an April 2026 study of 129 physicians in Germany, 83% of surveyed physicians wanted subgroup-specific performance data in model cards, making it the most requested additional information.[6] The sample was heavily academic, with 81% of participants from academic medical centers, so the finding should not be stretched into a universal statement about all clinicians in all settings.[6]

Still, the direction is hard to ignore. Clinicians may not want to parse every training detail, but they know that average performance can hide variation across age, sex, race, ethnicity, language, site of care, comorbidity burden, device type, insurance category, or other locally relevant groups. A model card that reports only aggregate performance leaves the governance committee to guess where risk concentrates.

The follow-up question should be specific: “Show subgroup-stratified performance for the groups available in your development and validation data, and explain which clinically important groups could not be evaluated.” That wording avoids rewarding a vendor for an attractive equity statement while penalizing neither small-sample honesty nor transparent missingness.

Limitations Should Name the Edge of Use

Known limitations are often written as soft disclaimers. In a procurement review, they need to function as boundaries. The card should say where the model was not evaluated, which patients or settings are out of scope, what inputs degrade performance, and what operational conditions could make the output unreliable.

A useful limitation is actionable. If the tool is not validated for pediatric patients, the implementation plan can exclude pediatric workflows. If the model depends on structured fields that are inconsistently captured at a site, the local team can test missingness before go-live. If the vendor cannot describe failure modes, the committee has learned something important before purchase.

Human Factors Belong in the Same Packet

The model card should not stop at the model. For clinical tools, the interface often determines whether an output becomes a helpful signal, a nuisance alert, a hidden automation bias, or an unreviewed recommendation. FDA’s draft guidance is useful here because it ties transparency to user interface, usability, and risk management across the product life cycle.[3]

A health system does not need every vendor to write a device-style submission dossier for every low-risk operational model. It does need to know what the user sees, what explanation appears with the output, whether confidence or uncertainty is shown, what action is expected, and how override or disagreement is captured.

Monitoring Is the Difference Between Review and Oversight

A pre-purchase model card is a snapshot. Clinical deployment is a moving process. The card should therefore state what will be monitored after implementation, who reviews the results, how often review occurs, what triggers escalation, and how model updates are communicated.

CHAI’s deployment and monitoring fields make this question easy to place in a standard vendor packet.[1] FDA’s TPLC framing gives the question more force for higher-risk tools because it keeps attention on change management, risk controls, and performance over time rather than only on the premarket description.[3]

Where Regulation Helps, and Where It May Not

HTI-1 gave health systems a concrete reason to care about source attributes for predictive decision support interventions in certified health IT. The Bipartisan Policy Center describes the rule’s 31-source-attribute requirement and its connection to the FAVES criteria.[5] For a governance committee, that matters because it turns transparency from a preference into a compliance-adjacent checklist for a defined slice of health IT.

The regulatory picture is not settled. A proposed HTI-5 repeal in December 2025 could remove the federal mandate for model cards in certified health IT if finalized, and its comment period ended in early 2026. FDA’s AI guidance is also still draft and non-binding.[3] The correct conclusion is not that model cards are guaranteed to remain federally required. It is that voluntary, comparable disclosure becomes more important when federal requirements are uncertain.

This is also why a single-standard approach is brittle. If a health system builds its intake process only around HTI-1, it may miss lifecycle and interface questions that matter for higher-risk clinical tools. If it builds only around FDA-style device logic, it may overburden lower-risk procurement reviews and still lack a clean cross-vendor comparison table. If it accepts any vendor-branded model card, it may mistake formatting for substance.

A Defensible Procurement Stance

For most health systems, the workable position is straightforward: ask vendors for a CHAI-style model card or a response that maps cleanly to CHAI’s comparable domains; verify completeness against DIHI’s HTI-1 source-attribute mapping when the tool falls into certified health IT or predictive DSI review; and apply FDA’s lifecycle, usability, risk management, and change-control questions to higher-risk clinical tools.

• Use CHAI to normalize the first vendor response: identity, intended use, target population, data, validation, limitations, monitoring, and compliance.
• Use DIHI to check whether HTI-1 source attributes are missing, especially where certified health IT or predictive DSI obligations are relevant.
• Use FDA’s draft guidance to deepen review of AI-enabled devices and higher-risk clinical tools, especially around usability, interface context, risk management, and lifecycle monitoring.
• Require subgroup-stratified performance or a clear explanation of why it cannot be provided.
• Treat a model card as an intake artifact, not as approval evidence.

That stance is not anti-vendor and not anti-standard. It is simply the review discipline clinical AI now requires. A polished model card can start the conversation, but the committee still needs comparable fields, missing-attribute checks, and lifecycle questions before it can decide whether the tool belongs in care.

References

1. Applied Model Card, CHAI.
2. AI Model Cards: Comparing approaches to HTI-1 transparency compliance, Pacific AI.
3. Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations, FDA, January 2025.
4. Coalition for Health AI launches model card registry, Healthcare Dive, February 2025.
5. First Into the Breach, Bipartisan Policy Center.
6. Clinician Model Card study, medRxiv, April 2026.