Published
.tp{color:#333333 !important;line-height:1.7 !important;margin:0 0 16px 0 !important}
.th2{color:#0d2137 !important;margin:36px 0 14px 0 !important;line-height:1.3 !important}
.th3{color:#0d2137 !important;margin:24px 0 10px 0 !important;line-height:1.35 !important}
.tl{color:#003057 !important;font-weight:600;text-decoration:underline}
.tt{border-collapse:collapse;width:100%}
.tt th{background-color:#0d2137 !important;color:#ffffff !important;text-align:left;padding:10px 12px !important;font-size:.9rem;border:1px solid #0d2137 !important}
.tt td{color:#333333 !important;padding:9px 12px !important;font-size:.9rem;vertical-align:top;border:1px solid #d8dee6 !important;line-height:1.5}
.tt td.w{background-color:#ffffff !important}
.tt td.g{background-color:#f6f9fc !important}
.tt td.rg{background-color:#f1f8f3 !important}
.tt td.rp{background-color:#fff9ec !important}
.tt td.rn{background-color:#fef1f1 !important}
.tt td.rj{background-color:#f0f4fc !important}
.tt td.vg{background-color:#d9eee0 !important;color:#14532d !important;font-weight:700}
.tt td.vp{background-color:#ffecc2 !important;color:#6b4200 !important;font-weight:700}
.tt td.vn{background-color:#fbd5d5 !important;color:#7f1d1d !important;font-weight:700}
.tt td.vj{background-color:#d6e0f7 !important;color:#1e3a8a !important;font-weight:700}
The DECIDE-AI checklist is the reporting guideline for the first live, small-scale tests of an artificial intelligence decision support system on real patients. Published in May 2022 in both the BMJ and Nature Medicine by Vasey and colleagues, it lists 17 AI-specific items (28 rows once sub-items are counted) and 10 generic items, and it asks for details that trial and model guidelines never needed, such as how users were trained, which version of the software ran for which patient, and what went wrong.1,2
Most guides stop at listing the items. This one goes further. After the checklist itself, we apply it row by row to a real open-access study of a surgical AI system, published in October 2026, that states it followed DECIDE-AI, with the section of the paper beside every verdict. The DECIDE-AI checklist is the earlier-stage companion to our CONSORT-AI checklist, and we do not repeat that material here.
In Simple Words
The DECIDE-AI checklist is a list of 38 rows (28 AI rows and 10 generic rows) for papers that report an AI tool’s first use with real patients. It does not tell you how to run the study. It tells you what a reader must be able to find, including the exact software version used on each patient, every error, and how the people using the tool coped. Write the location of each row next to it before you submit, and write a short negative answer where the study did not do something.
What the DECIDE-AI Checklist Is and Where It Fits Among AI Reporting Guidelines
DECIDE-AI stands for Developmental and Exploratory Clinical Investigations of DEcision support systems driven by Artificial Intelligence. The DECIDE-AI checklist is stage specific and not design specific. The guideline targets live evaluation, meaning the decisions made with the AI system have a real effect on patient care, as opposed to offline or shadow mode testing where they do not.1 It does not prescribe a study design, so a prospective cohort, a non-randomised comparison or a case series can all use it, and it covers detection, diagnostic, prognostic and therapeutic systems.1
The guideline came from a two-round modified Delphi process followed by a virtual consensus meeting. Of the experts who joined, 123 completed the first round, 138 completed the second and 16 attended the consensus meeting, and the authors report 151 experts from 18 countries across 20 stakeholder groups in total.1 The checklist is described as a set of minimum reporting standards, and it is not a substitute for regulatory requirements.1
The table below shows where the DECIDE-AI checklist sits among the AI guidelines. It follows the structure of the stage map in the original paper, in our own words.1
Table 1. Where the DECIDE-AI checklist sits among AI reporting guidelines. Structure adapted from Vasey et al., BMJ 2022.
| Guideline | Stage of evaluation | Study design it targets |
|---|---|---|
| TRIPOD-AI (now TRIPOD+AI) | Preclinical development | Prediction model development and validation |
| STARD-AI | Preclinical development and offline validation | Diagnostic accuracy studies |
| DECIDE-AI | Early live clinical evaluation | Various designs, with extra features such as changes to the system, prespecified subgroups or learning curves |
| SPIRIT-AI | Comparative prospective evaluation | Protocols of randomised trials of AI systems |
| CONSORT-AI | Comparative prospective evaluation | Reports of randomised trials of AI systems |
Three points matter for your submission. First, the DECIDE-AI checklist sits between preclinical work and the large comparative trial, so a study that has already moved to randomisation should use the CONSORT-AI checklist and, for a protocol, the SPIRIT protocol guide. Our CONSORT 2025 guide explains why CONSORT 2025, with its 30 items, replaced CONSORT 2010. Second, the DECIDE-AI checklist is a reporting guideline and not an appraisal tool. It checks whether you described what you did, not whether what you did was sound, and for appraisal of prediction models reviewers use PROBAST. Third, if your question is purely about model accuracy, read our comparison of STARD and TRIPOD first, and use our decision tree for choosing a reporting guideline for the wider set of options.
The DECIDE-AI Checklist at a Glance, All 17 AI Items and 10 Generic Items
The table condenses the official checklist into 38 rows. Arabic numbers mark the 17 AI-specific items and Roman numerals mark the 10 generic items. We paraphrased the wording to keep it short, so use the official checklist from the BMJ or Nature Medicine paper for the exact text you submit.1,2
Table 2. The 38 rows of the DECIDE-AI checklist, condensed. Source structure from Vasey et al., BMJ 2022.
| Item | Topic | What to report (paraphrased) |
|---|---|---|
| 1 | Title | Name the study as an early clinical evaluation of an AI decision support system and say which problem it addresses. |
| I | Abstract | Give a structured summary covering intended use, algorithm type, setting, numbers of patients and users, outcomes, safety endpoints, human factors, results and conclusions. |
| 2a | Intended use, condition | Describe the condition and problem, current standard practice and the intended patient group. |
| 2b | Intended use, users | Describe the intended users, the planned place in the care pathway and the expected impact, including on patient outcomes. |
| II | Objectives | State the objectives. |
| III | Research governance | Cite any protocol, the registration number and the ethics approval. |
| 3a | Participants, patients | Describe recruitment, inclusion and exclusion at patient and data level, and how the number was decided. |
| 3b | Participants, users | Answer the same questions for the users of the AI system. |
| 3c | Participants, familiarisation | Describe the steps taken to familiarise users, including any training before the study. |
| 4a | AI system, identity | Give the version and algorithm type, the training population and preclinical performance, or a direct reference. |
| 4b | AI system, inputs | Describe the input data, how they were acquired and entered, pre-processing, and handling of missing or poor-quality data. |
| 4c | AI system, outputs | Describe the outputs and how they were shown to users, ideally with an image. |
| 5a | Implementation, setting | Describe where the AI system was evaluated. |
| 5b | Implementation, workflow | Describe the care pathway, when in it the system was used, and who made the final supported decision and how. |
| IV | Outcomes | Specify the primary and secondary outcomes. |
| 6a | Safety and errors, definition | Describe how significant errors or malfunctions were defined and identified. |
| 6b | Safety and errors, risk | Describe how risks to patient safety or harm were identified, analysed and reduced. |
| 7 | Human factors, methods | Describe the human factors tools, methods or frameworks, the use cases and the users involved. |
| V | Analysis | Describe the statistical methods, prespecified extra analyses and subgroup analyses. |
| 8 | Ethics | Describe any method used for an ethics goal, such as algorithmic fairness, and why. |
| VI | Patient involvement | State how patients shaped the question, the design or the conduct. |
| 9a | Participants, patients (results) | Report baseline patient characteristics and missingness in the input data. |
| 9b | Participants, users (results) | Report baseline user characteristics. |
| 10a | Implementation, exposure | Report user exposure, the number of uses and adherence to the intended implementation. |
| 10b | Implementation, workflow change | Report any significant change to the workflow or care pathway. |
| VII | Main results | Report the prespecified outcomes, with a comparison group if there was one. |
| VIII | Subgroups | Report differences in the main outcomes by prespecified subgroup. |
| 11 | Modifications | Report changes to the AI system or hardware, their timing and rationale, and any change in outcomes after each. |
| 12 | Human-computer agreement | Report user agreement with the AI, reasons for departing from it and any change of mind. |
| 13a | Safety and errors, events | List significant errors with rate, apparent cause, whether they could be corrected and the possible impact on care. |
| 13b | Safety and errors, harm | Report safety risks and observed harm, including indirect harm. |
| 14a | Human factors, usability | Report a usability evaluation using recognised standards or frameworks. |
| 14b | Human factors, learning curves | Report an evaluation of user learning curves. |
| 15 | Support for intended use | Discuss whether the results support the intended use in clinical settings. |
| 16 | Safety and errors, discussion | Discuss the safety profile, errors and harm, their implications and how they can be reduced. |
| IX | Strengths and limitations | Discuss strengths and limitations. |
| 17 | Data availability | Say whether and how data and code are available. |
| X | Conflicts of interest | Disclose funding, the role of funders and companies, and personal conflicts for each author. |
Notice how many rows sit under safety, errors and human factors. Rows 3c, 6a, 6b, 7, 11, 12, 13a, 13b, 14a, 14b and 16 together account for 11 of the 28 AI rows, which reflects the guideline’s focus on safety and on the human side of the system.
What Makes the DECIDE-AI Checklist Different From CONSORT-AI and TRIPOD+AI
The original paper lists methodological challenges that appear as soon as an AI system meets a clinic, and each one maps to rows you will be asked to complete.1 Four of them change how a manuscript is written.
Human factors are part of the intervention (rows 3c, 7 and 14)
The DECIDE-AI checklist treats the AI system and its users as two collaborating forms of intelligence, so how people used the tool is reported as an outcome and not left to the discussion.1 Row 7 asks which human factors methods were used, row 14a asks for a usability evaluation against recognised standards, and row 14b asks for learning curves. A study that combines questionnaires, observation and interviews is a mixed methods research design, and the same integration rules apply when you write it up. A small first-in-human series is also close in spirit to the pilot studies we describe elsewhere, with feasibility and refinement as the aim.
The system is allowed to change (rows 4a and 11)
In a drug trial the product is fixed. In early AI work the software, the hardware and the user interface are often revised between patients. Row 4a asks for the version, and row 11 asks for each change, when it happened, why, and what happened to the outcomes afterwards. Without that log, a reader cannot tell which system a given result belongs to.
Errors are data (rows 6, 13 and 16)
The guideline asks authors to define significant errors in advance, list every one that occurred with its rate and apparent cause, say whether it could be corrected, and discuss what it means for patient care.1 The framing mirrors phase 1 and 2 drug studies, where safety is the first question. It also guards against dataset shift, where small differences between training data and clinical data change performance.1
Human and AI agreement is reported (row 12)
Row 12 of the DECIDE-AI checklist asks how often users agreed with the system, why they departed from it, and whether the AI changed anyone’s mind. CONSORT-AI and TRIPOD+AI ask about user interaction and the expertise users need, but we found no row in either that asks for agreement rates and reasons for departing from the AI output. For a model-focused paper, our TRIPOD+AI checklist guide covers the reporting that comes earlier in the pathway.
Worked Example Applying the DECIDE-AI Checklist to a Real Open-Access Study
To show the checklist in use, we scored one published paper. Khan and colleagues reported a first-in-human evaluation of real-time AI anatomical segmentation during endoscopic pituitary surgery, in Pituitary in October 2026. It is published under a CC BY 4.0 licence, which is why we can quote it and reproduce two of its figures. We confirmed the licence in three places, the Crossref version-of-record licence field, the Europe PMC licence field and the JATS permissions of the full text.3
We chose it for a practical reason. It is a real paper that applies the DECIDE-AI checklist, with an IDEAL Stage 1 design, a registered study, eight patients and a surgical team of four users. It also includes its own completed DECIDE-AI checklist as Supplementary Material 2. We scored the article text first and compared with the authors’ checklist afterwards, so the verdicts below are an independent reading of the full text. The IDEAL framework, for readers who do not know it, is a staged pathway for evaluating surgical innovation.4
In the study, a computer vision model outlined the sella and the carotid arteries on a secondary monitor beside the unaltered surgical feed, and the surgical team switched the overlay on with a foot pedal. The registration is listed on ClinicalTrials.gov, and the full text is on PubMed Central.

How to read the verdicts
Reported means the row is answered in the text. Partly reported means some elements are present and others are missing. Not found means we could not locate it in the full text and the two supplements we could read. Judgement call means a reasonable reviewer could score the row either way, and the note explains why. This is an Editverse reading of the text and not an official DECIDE-AI checklist assessment.
Table 3. DECIDE-AI checklist rows scored against Khan et al., Pituitary 2026 (CC BY 4.0). Editverse reading of the full text.
| Item | Where to look in the paper | What the paper reports | Verdict |
|---|---|---|---|
| 1 | Title | The title names a first-in-human evaluation of real-time AI-assisted anatomical segmentation in neurosurgery. The words decision support do not appear. | Judgement call |
| I | Abstract | Structured with four headings. Gives the algorithm type (a DINOv3-derived vision transformer), single-centre setting, eight patients, outcomes and main findings. The number of users and any scale scores are absent. | Partly reported |
| 2a | Background, paragraphs 1 to 3 | Frames navigation error in endoscopic pituitary surgery as a patient safety risk, names existing image guidance, and defines the population in Methods as adults having elective endoscopic transsphenoidal surgery for pituitary adenoma. | Reported |
| 2b | Background, final paragraphs, and Strengths and limitations | Users are the surgical team and the interface is built around the surgeon. The Limitations paragraph then says the system was "initially deployed as a training and educational tool rather than a primary decision-support system", so the intended role is clearest only at the end. | Judgement call |
| II | Background, final paragraph, and Methods, Overview | The goal is to assess feasibility of anatomical segmentation during live endoscopic pituitary surgery while improving the system iteratively. | Reported |
| III | Methods, Overview | Gives a registry number and an ethics reference (IRAS 127474) with consent. The text says the study was "registered on a clinical trials database (NCT07568366; registered 5th May 2026)". We found no recruitment dates, so a reader cannot tell whether registration came before the first case, and no separate protocol citation. | Partly reported |
| 3a | Methods, Proof-of-concept study procedure, and Results, Overview | Six patients were planned, exclusions are listed and the sample is described as "a small, pre-specified development cohort rather than a powered sample". Results then report eight consecutive patients recruited, and the Discussion refers to "six of the eight planned cases". The change from six to eight is not explained. Data-level eligibility is not described. | Judgement call |
| 3b | Methods, Proof-of-concept study procedure, and Results, Overview | One attending surgeon and team performed every case, and Results name four users (three surgeons and one scrub nurse). How users were chosen, their eligibility and how the number was decided are not stated. | Partly reported |
| 3c | Methods, Proof-of-concept study procedure | The team was orientated on a high-fidelity simulator with a "standardised briefing on intended use, output interpretation, and the limitations of the system". | Reported |
| 4a | Methods, System overview | Names a ViT-B architecture trained on 2157 frames from 110 patients with a patient-level split (97 training, 13 test). Held-out Dice was 86.4% for the sella and 21.8% for the carotids, with carotid recall 13.6%. Model versions V1, V2, V2.1 and V2.2 are labelled in Table 1 of the paper. "No formal performance threshold was prespecified", although a Dice near 70% for the sella was treated as a reasonable minimum. | Reported |
| 4b | Methods, System overview | Video input is described in detail, 1920 by 1080 pixels at 24 frames per second from the endoscope stack through a capture card. How low-quality frames were handled during live use is not described. | Partly reported |
| 4c | Methods, System overview, and Figures 1 and 2 of the paper | Outlines instead of filled masks, overlay off by default and switched on by foot pedal, a smoothed confidence percentage beside each label, and an end-to-end latency of 50 to 100 ms in pre-operative testing. | Reported |
| 5a | Methods, System overview and Proof-of-concept procedure | A single centre, the National Hospital for Neurology and Neurosurgery, with the overlay on the existing secondary monitor of the endoscope stack. | Reported |
| 5b | Methods, Proof-of-concept study procedure | Surgery proceeded as routine on the unchanged primary display, and the overlay was used during anatomical orientation before the sellotomy and durotomy. Who made the final decision is implied (the surgeon, with the overlay off by default) and not stated as such. | Judgement call |
| IV | Methods, Data collection, analysis and system iteration | Primary outcomes cover proof of concept, feasibility (FIM questionnaire) and safety observation. Secondary outcomes cover educational yield and user feedback (AIM, SUS and STIAS). | Reported |
| 6a | Methods, Proof-of-concept study procedure | A pre-case check, "a standardised functionality check was undertaken", with root cause analysis of any failure, plus a subjective latency report. There is no formal definition of a significant error or malfunction and no severity grading. | Partly reported |
| 6b | Methods, Data collection, and the Figure 1 legend of the paper | Safety was monitored through event counts for surgeon distraction and workflow disruption on theatre video, blinded OSATS and operative time against a matched retrospective cohort, and routine clinical outcomes. The data flow was routed to avoid compromising the primary surgical feed. | Reported |
| 7 | Methods, Data collection | Uses standard instruments (FIM, AIM, SUS, STIAS, MAILS) plus structured observation notes by a research fellow. Users are the surgeons and nurses who interacted with the system, and the interface design traces to earlier simulation studies. | Reported |
| V | Methods, Data collection, and Supplementary Material 1 | Summary statistics and thematic analysis of qualitative data. Supplementary Material 1 states that no formal hypothesis testing was performed because the sample is small. | Reported |
| 8 | Whole text | No mention of algorithmic fairness or any ethics-related method in the article. The authors’ own checklist says this is not reported but covered in earlier work from the same centre. | Not found |
| VI | Whole text | No statement on patient involvement in the article. The authors’ checklist says involvement is planned for future studies. | Not found |
| 9a | Results, Overview, and Table 1 | Age, sex, diagnosis and tumour size category are given per case. No statement on missingness in the input data, apart from the two cases in which the system did not start. | Partly reported |
| 9b | Results, Overview | Four users with training level (one attending, one senior fellow, one resident, one scrub nurse), age band, sex and AI literacy (MAILS median 6.1, IQR 5 to 7.1). | Reported |
| 10a | Results, Overview | The system was used in six of the eight cases, across four of the five operating sessions. "Meaningful use of the system was limited to the sellar phase, as intended". Exposure per user and the time the overlay was switched on are not given. | Partly reported |
| 10b | Results, Safety, and Figure 3 of the paper | There were "no events of significant primary surgeon distraction or surgical team workflow disruption". Figure 3 of the paper also records that only one nurse engaged with the system and plans to move or add a screen. | Reported |
| VII | Results, Feasibility, Safety, Wider implementation feedback, and Table 1 | Most prespecified outcomes are reported with medians and IQRs (FIM 4.8, AIM 4, SUS 78, STIAS 4.3 of 7). Educational yield, measured by a Kirkpatrick-based questionnaire, appears only as a statement that all participants saw educational potential. In the version of Table 1 we read, the FIM cell is empty for cases 6 and 8. | Partly reported |
| VIII | Whole text | No prespecified subgroups are described, so the row may not apply. The authors’ checklist says it was not reported because this is a small IDEAL Stage 1 study. | Judgement call |
| 11 | Results, Device iteration, Table 1 and Figure 3 of the paper | Figure 3 of the paper lists, by operating session, the problem found and the change made for the AI model, hardware, interface and implementation, and Table 1 gives the model version per case. The change in outcome after each version is qualitative (for example, carotid "more accurate and consistent than last session"), and no Dice is reported for later versions. | Judgement call |
| 12 | Results, Table 1, and Strengths and limitations | Table 1 records surgeon-AI alignment per case in words. There are no counts of disagreement, reasons for departing from the overlay or changes of mind, and the authors acknowledge "less attention given to instances where the model potentially outperformed humans or positively changed their decision". | Partly reported |
| 13a | Results, Overview, Safety and Device iteration | Two of eight cases (cases 2 and 3) were lost to one boot failure after a reboot, fixed through manufacturer discussion, a boot-entry change and a firmware update. "This was a platform-level fault rather than a failure of the CVAI application." Other events were a false-positive sella outline over the carotid, overlay distortion by instruments, and perceived latency of about 100 ms in one case. | Reported |
| 13b | Results, Safety | No intra-operative complications, including vascular or neural injury. Two patients had hyponatraemia requiring treatment, one in a case without the system (case 2) and one with it (case 5). Mean sellar-phase OSATS in the six deployed cases was 27.2 of 30, against 28.6 in the retrospective cohort. | Reported |
| 14a | Results, Wider implementation feedback and human factors | Usability is reported with the System Usability Scale (median 78, IQR 65 to 79), alongside acceptability (AIM) and trust (STIAS). | Reported |
| 14b | Whole text | No learning curve analysis. The authors’ checklist gives the IDEAL Stage 1 design as the reason, and the Discussion lists learning curves for later studies. | Not found |
| 15 | Discussion, Principal findings, and Conclusion | States that real-time segmentation was feasible in live surgery, that most limitations were correctable, and that a larger single-centre series (IDEAL Stage 2a) is the next step. | Reported |
| 16 | Discussion, Principal findings, and the literature subsection | Names the false-positive outline over the carotid and overlay distortion by instruments as the main hazards, and Figure 3 of the paper sets out the planned mitigations, including hiding the overlay below a confidence threshold. | Reported |
| IX | Discussion, Strengths and limitations | Names the single centre, single surgical team and small series, the focus on AI errors, and the deployment as a training tool. | Reported |
| 17 | Back matter, Data availability | The statement reads "Available upon reasonable request and subject to institutional approvals". Nothing is said about code or access to the model. | Partly reported |
| X | Back matter, Funding, Competing interests and Acknowledgements | Funding sources and personal shareholdings and employment with commercial companies are declared. Medtronic, NVIDIA and Encord are thanked for collaboration, but the roles of these companies and of the funders are not described. | Partly reported |
Across the 38 rows, we scored 18 as Reported, 11 as Partly reported, 6 as Judgement call and 3 as Not found. The three Not found rows (8, VI and 14b) are the ones the authors themselves flag as not reported in their own checklist, with a reason, and row VIII is the fourth they flag. The paper is strong on the parts DECIDE-AI was written to elicit, which are errors, modifications and usability, and its gaps sit in governance detail, participant numbers, data and code, and the roles of companies.
What the Annotated Example Teaches About the DECIDE-AI Checklist
Give planned and actual numbers, and say why they differ
Row 3a asks how the number of patients was decided. The Methods plan six patients, the Results recruit eight, and the Discussion calls six of the eight deployments the planned cases. Each statement may be true, but a reader cannot reconcile them without a sentence on why the target moved. In an early-stage series, where the sample is small by design, the numbers are the first thing a reviewer checks.
Write the negative answers, as the authors did
The authors’ supplementary checklist records rows 8, VI, VIII and 14b as not reported, each with a short reason such as the IDEAL Stage 1 design. That is good practice, and it is what the guideline wants, because a stated reason is better than a blank. The reasons sit in the supplement, though, so a reader of the article alone does not see them. One sentence in the limitations paragraph would carry the same information into the paper.
Log every version, as the paper’s Figure 3 does
Row 11 asks for the timing and rationale of each change and the outcomes after it. Figure 3 of the paper is a compact model of the first two, with a column per operating session and a row each for AI model, user interface, hardware and implementation. The Methods add that the model was retrained "using data from all 110 patients and each subsequent patient included in the trial". When training data grow with every case, row 4a is best met by giving the training size for each labelled version.

Define a significant error before the first case
Row 6a asks how significant errors were defined. The example runs a pre-case functionality check and a root cause analysis for failures, which is sound, but it does not say in advance what counts as a significant error. That matters here because the first model’s sella outline spilled over the carotid (a “go zone” over a “no-go zone” in the figure above), the pattern a surgeon would consider most dangerous, and the carotid class was itself weak in preclinical testing (Dice 21.8%, recall 13.6%). A one-line definition, such as any overlay that places a safe outline over a no-go structure, would let the reader count events the same way the team did.
Count agreement, do not only describe it
Row 12 is where early-stage AI papers most often stay vague. The example records alignment per case in words, for example sella accurate and carotid only partly correct. A simple tally per structure and per case, with a reason for each departure from the overlay, turns the same observations into data. The authors name this gap themselves, noting that cases where the model helped a decision received less attention.
Name what companies and funders did
Row X asks for the role of funders and of any company. The example declares shareholdings and employment clearly, and it thanks three companies for collaboration, but it does not say what each contributed. A single sentence on who supplied the hardware, the recording platform and the annotation tools, and whether any of them saw the manuscript, completes the row. For row 17, a code and model statement belongs beside the data statement, even when the answer is that neither can be shared.
Run a consistency pass between abstract and tables
The abstract reports that the system demonstrated "acceptable real-time pixel-level sella segmentation accuracy". In the Results, accuracy in live use appears as qualitative alignment notes in Table 1, with no quantitative live accuracy. The FIM column in Table 1, as we read it, is empty for two of six deployed cases while the text gives a median. None of this changes the findings, and all of it is cheap to fix before submission.
How to Complete the DECIDE-AI Checklist Before You Submit
The routine below works for a finished manuscript and a DECIDE-AI checklist submission, and the first two steps work better if you take them while the study is still being planned.
- Download the official checklist from the BMJ or Nature Medicine paper and keep the version date in your file name.
- Plan the study around the rows so that familiarisation (3c), error definitions (6a), the change log (11) and usability instruments (14a) are in the protocol before the first patient.
- Decide what applies by marking rows that do not apply, such as subgroups or learning curves, and write the reason in the manuscript as well as in the checklist.
- Fill every row of the DECIDE-AI checklist with a location using page and line numbers from the submission file, and write a short negative answer for every row you did not do.
- Reconcile all numbers across the abstract, Methods, Results, tables and figures, starting with planned and recruited patients and users.
- Add the version log as a table or figure, with the date, the reason and the effect of each change to the model, hardware or interface.
- Count the errors by type with a rate, a cause and whether each could be corrected, and discuss what each means for patient care.
- State data, code and company roles in the back matter, including who supplied hardware, software and recording tools.
Mixed designs also need good survey practice, and our guide to questionnaire design in epidemiological studies helps with the usability and acceptability instruments. If the system is a prediction tool built on routine data, our walkthrough of AI in healthcare implementation gives the wider context, and a student mapping a thesis chapter to the right guideline can use the medical dissertation reporting guidelines guide. For the observational parts of a clinical series, the STROBE guide remains the standard companion.
The next stage after the DECIDE-AI checklist is a comparative trial. When you reach it, move to the CONSORT-AI checklist and the SPIRIT protocol guide. The guideline papers are open access, and the registry for the example study is on ClinicalTrials.gov. The IDEAL framework that DECIDE-AI aligns with is described by the IDEAL Collaboration and in a 2019 update in Annals of Surgery.4
Free Research Tools from Editverse
- GraphPro: build publication-ready charts, 25 types, with built-in t-test, ANOVA, correlation, and chi-square p-values. Free, no signup.
- StatPro: free statistical calculators and a test-selector tool covering group comparisons, categorical outcomes, time-to-event analysis, and diagnostic accuracy.
- Flowchart Pro: generate PRISMA 2020, PRISMA-ScR, CONSORT, STROBE, STARD, MOOSE, and ARRIVE flow diagrams directly in your browser.
Professional Support for DECIDE-AI Reporting
An early clinical evaluation is easier to report when the design questions are settled before the first patient and the manuscript is edited against the checklist afterwards. Two Editverse services map onto that. The first is a set of methodology consultation sessions, useful when you are deciding outcomes, sampling of users and patients, data collection and validity for a mixed-methods feasibility study. The second is substantive editing of the manuscript itself. Editverse editing and writing support aligns with COPE, ICMJE and GPP 2022, and with the ethics requirements of your institution and country.
Methodology consultation
$400
Three 45-minute sessions with PhD methodologists covering research design review, sampling, data collection and validity, with a written methodology framework. Scheduled over 4 to 6 weeks.
Advanced editing
$550
Substantive editing, scientific language polishing, APA, AMA or Vancouver style editing and reference list verification. Flat fee, 7 to 10 business days, one free revision round.
Conclusion
The DECIDE-AI checklist asks for 38 rows that together describe an AI tool’s first contact with real patients, and the rows that matter most are the ones trial guidelines never asked about, namely errors, versions, user agreement and usability. Our worked example shows the pattern. A paper can log every model change and name its failures openly, and still leave unexplained a change in the number of patients, a definition of a significant error, a code statement and the role of its commercial partners. Start from the DECIDE-AI checklist when you plan the study, write a location against every row when you draft, and run a consistency pass before you submit. A reviewer who can find every row in minutes spends the review on your science.
Frequently Asked Questions
How many items does the DECIDE-AI checklist have?
The DECIDE-AI checklist has 17 AI-specific items, which expand to 28 rows once sub-items are counted, plus 10 generic items numbered with Roman numerals. That gives 38 rows in total.
Is the DECIDE-AI checklist only for randomised trials?
No. The DECIDE-AI checklist is stage specific and does not prescribe a study design. It is meant for early, small-scale, live clinical evaluation, and a prospective cohort, a non-randomised comparison or a case series can all use it. Randomised trials of AI use CONSORT-AI.
What counts as early-stage clinical evaluation for DECIDE-AI?
The AI system is used on real patients and its output affects care, at small scale. Offline or shadow-mode testing, where the output does not affect decisions, falls outside the guideline.
How is the DECIDE-AI checklist different from TRIPOD+AI and CONSORT-AI?
TRIPOD+AI covers prediction model development and validation, and CONSORT-AI covers randomised trials. The DECIDE-AI checklist sits between them and adds human factors, user agreement, system modifications and detailed error reporting.
Does the DECIDE-AI checklist replace the other AI guidelines?
No. The guidelines cover different stages, so a project may use the DECIDE-AI checklist for its first clinical series and CONSORT-AI later for a randomised trial. Note that CONSORT 2025 replaced CONSORT 2010, and that CONSORT-AI was built as an extension of CONSORT 2010.
Should authors submit a completed DECIDE-AI checklist with the manuscript?
Many journals ask for a completed checklist with a page or line number for each row. Check the author instructions, and write a short negative answer for any row you did not address.
Where is the official DECIDE-AI checklist published?
The checklist is published in the BMJ and in Nature Medicine, both from May 2022. The BMJ version is open access.
References
- Vasey B, Nagendran M, Campbell B, Clifton DA, Collins GS, Denaxas S, et al. Reporting guideline for the early stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI. BMJ. 2022;377:e070904. doi:10.1136/bmj-2022-070904. PMID: 35584845. PMCID: PMC9116198. PubMed, PMC.
- Vasey B, Nagendran M, Campbell B, Clifton DA, Collins GS, Denaxas S, et al. Reporting guideline for the early-stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI. Nat Med. 2022;28(5):924-933. doi:10.1038/s41591-022-01772-9. PMID: 35585198. Nature Medicine.
- Khan DZ, Mao Z, Wijekoon A, Das A, Williams SC, Blandford A, et al. First-in-human evaluation of real-time pixel-level AI-assisted anatomical segmentation in neurosurgery: pituitary surgery as an exemplar. Pituitary. 2026;29(5):163. doi:10.1007/s11102-026-01762-x. PMID: 42829367. PMCID: PMC13634013. CC BY 4.0. PubMed, PMC.
- Hirst A, Philippou Y, Blazeby J, Campbell B, Campbell M, Feinberg J, et al. No surgical innovation without evaluation: evolution and further development of the IDEAL framework and recommendations. Ann Surg. 2019;269(2):211-220. doi:10.1097/SLA.0000000000002794. PMID: 29697448. PubMed.
