CONSORT-AI (CONSORT Extension for Trials of AI Interventions)
The CONSORT 2010 reporting extension for randomized controlled trials evaluating interventions that include an artificial-intelligence or machine-learning component, adding 14 AI-specific reporting items to the parent checklist so that the algorithm, its inputs/outputs, its integration into the care pathway, and its failure analysis are reported transparently enough to appraise and reproduce.
What it is
CONSORT-AI is the official EQUATOR-registered extension of the CONSORT 2010 statement for reporting randomized controlled trials (RCTs) in which the intervention contains an artificial-intelligence / machine-learning component (Liu et al., Nature Medicine 2020; published in parallel in BMJ and Lancet Digital Health). It does not replace CONSORT — it layers AI-specific reporting items onto the parent checklist. The extension adds new or elaborated items covering: a clear statement that the intervention involves AI and which version of the algorithm was evaluated; the intended use, clinical pathway, and intended user (clinician vs patient vs autonomous); the input data required (handling of poor-quality, missing, or out-of-distribution inputs); the AI output and how it feeds the clinical decision; the level of human–AI interaction and required skill; the setting and on-site integration; and a pre-specified analysis of performance errors / failure modes. CONSORT-AI is the trial-report counterpart to SPIRIT-AI (Cruz Rivera et al. 2020), which governs the trial protocol; the two were developed together by the same international consensus group (SPIRIT-AI and CONSORT-AI Steering Group). It is a reporting guideline — a transparency checklist — not a critical-appraisal or risk-of-bias instrument and not a quality score.
When to use
Use CONSORT-AI when you are reporting (or peer-reviewing, or registering the report of) a randomized controlled trial whose intervention embeds an AI/ML model — for example a deep-learning triage tool, an algorithmic treatment-recommendation system, or an ML-driven monitoring/alerting intervention tested head-to-head against standard care. The decision rules that distinguish CONSORT-AI from its siblings are sharp and worth stating explicitly: (1) the design must be a randomized trial — if it is, use CONSORT-AI; the parent CONSORT still governs everything non-AI. (2) If the AI intervention is delivered in a pragmatic, routine-care RCT, combine CONSORT-AI with CONSORT-Pragmatic and characterize the explanatory–pragmatic position with PRECIS-2 — this is the principal point of contact with real-world evidence, since a pragmatic AI trial runs inside live EHR/claims workflows. (3) If you are writing the protocol, use SPIRIT-AI, not CONSORT-AI. The relevant decision contexts span regulatory submission (FDA/EMA software-as-a-medical-device and drug-device evidence), HTA/payer dossiers for AI-enabled technologies, peer-reviewed journals (most major journals require CONSORT-family adherence), and trial-report registration.
What it requires
As a reporting extension, CONSORT-AI enforces complete transparent description across the domains that determine whether an AI trial can be appraised and acted on. Framed for evidence that touches real-world data systems: design and pre-specification transparency (randomization, blinding where feasible, the specific algorithm version — frozen vs continuously-learning); data fitness-for-use of the AI inputs (input data sources, formats, acquisition, and explicit handling of poor-quality, missing, or out-of-distribution inputs — the AI analogue of data-fitness-for-use); algorithm / phenotype validation lineage (how the model was developed and validated before the trial, and the performance claim it was trial-tested against); integration and time-zero of the intervention (when and where in the care pathway the AI acts, the human–AI interaction level, and what the user does with the output); outcomes, estimands, and intercurrent events (CONSORT-AI inherits CONSORT/CONSORT-PRO outcome reporting; intercurrent events such as clinician override of the AI must be described); attrition and missing data; and a distinctive requirement for error/failure-mode analysis (how algorithm performance errors were identified, analyzed, and reported). Confounding control in the causal sense is handled by randomization itself — that is the point of using an RCT extension rather than an observational tool.
When NOT to use — limitations and common misapplications
The single most important caveat in an RWE/HEOR catalog: CONSORT-AI is an RCT reporting extension and does not apply to non-randomized, observational evaluations of AI tools. Concrete failure modes: (1) Using CONSORT-AI for an observational performance study of a deployed algorithm — wrong tool; report model development/validation with TRIPOD+AI and early live-clinical evaluation with DECIDE-AI. (2) Using it for a diagnostic-accuracy study — use STARD-AI (AI extension of STARD). (3) Treating it as a risk-of-bias or quality instrument — it is a reporting checklist; bias appraisal of AI prediction models is the job of PROBAST/PROBAST-AI, and trial risk of bias remains RoB 2. Completing the checklist does not confer internal validity, does not make a poorly-randomized trial sound, and does not make an observational AI evaluation causal. (4) Checklist-as-theater — pasting page numbers against items without the underlying reporting substance (e.g., declaring "input data handling reported" with no description of out-of-distribution behavior) defeats the purpose. (5) Wrong extension for the design — using plain CONSORT (no AI items) for an AI trial, or using CONSORT-AI to report the protocol instead of SPIRIT-AI.
How it maps to this catalog
CONSORT-AI sits at the reporting end of the AI-trial lifecycle; several catalog concepts implement the methodological substance it asks you to describe transparently. The pragmatic-trial and target-trial-emulation concepts implement the design-and-time-zero discipline the checklist reports, and target trial thinking is the bridge when an AI intervention must be evaluated where randomization is infeasible (a setting CONSORT-AI itself does not cover — that is where TTE in observational data takes over). estimands-ate-att- intercurrent-events-rwe implements the estimand/intercurrent-event reporting (clinician override of the AI is a textbook intercurrent event). predictive-and-causal-ml-models-rwe and prediction-model-validation- recalibration-rwe implement the upstream model development/validation lineage that the trial report must reference. attrition-and-loss-to-follow-up-rwe implements the attrition reporting; generalizability-transportability- external-validity-rwe implements the "intended setting / out-of-distribution input" reasoning that makes an AI result transportable. For the protocol-side counterpart, study-protocol-or-sap-elements carries the pre-specification that SPIRIT-AI governs. Applied RWE note: the genuine real-world point of contact is the pragmatic AI trial embedded in routine EHR/claims workflows — here CONSORT-AI + CONSORT-Pragmatic + PRECIS-2 are used together, and the input-data items (missing/poor-quality/out-of-distribution EHR fields) and integration items (where in the live clinical workflow the algorithm fires) become the most consequential, because they are precisely the elements that break silently when a model trained on one health system is deployed in another.