Before deciding what evidence is needed, it has to be acknowledged that clinical evidence planning belongs at the start of the design and development cycle, alongside the intended purpose and indications for use — not as a downstream activity once the device is built. Once intended purpose drift sets in, the evidence question becomes harder to answer and the evidence package more expensive to assemble.

Intended purpose, indication for use, target population, clinical setting, the role the device plays in clinical decision-making, and the benefit being asserted are the inputs that drive the evidence requirement. Get them wrong, leave them implicit, or let marketing pull them in a direction the technical file does not support, and the evidence question becomes unanswerable. A clinical investigation cannot be scoped if there is no settled view on what the investigation has to demonstrate.

For AI devices this is sharper still. A model that “supports clinical decision-making in the assessment of diabetic retinopathy” is doing something fundamentally different from a model that “detects referable diabetic retinopathy.” The first is a decision support tool. The second is a diagnostic claim. The evidence package for those two devices is not slightly different. It is structurally different.

The intended purpose itself rewards specificity. Position within the clinical workflow should be explicit — diagnosis, prevention, monitoring, prognosis or otherwise — going one step beyond the words used in the regulatory definition. Inputs and outputs should be defined: the SaMD takes the output of a particular previous element in the workflow as its primary input (a prior diagnosis, an x-ray image, a structured dataset), performs a defined activity, and produces a defined output. Where a device contains both medical software and non-medical software components, the non-medical components should be clearly demarcated in the technical documentation and the intended purpose, so that what is and is not under conformity assessment is unambiguous. Contraindications, warnings and side-effects belong elsewhere in the technical documentation, not buried inside the intended purpose statement.

A practical implication: the IFU and marketing copy should not be drafted before the clinical evidence work has matured. Doing it the other way around is one of the most common ways claims drift into territory the evidence cannot support. The IFU and marketing assets describe what the device does — they should reflect what has been demonstrated, not predict it.

When intended purpose, claims and evidence are aligned, what gets communicated to the world is what the device can actually do.

Clinical Evaluation under MDR Article 61 is a planned, continuous process to collect, appraise and analyse clinical data to verify safety, performance and clinical benefit. The acceptable sources are defined in Article 2(48): clinical investigations of the device, clinical investigations or studies of an equivalent device, peer-reviewed scientific literature on the device or an equivalent device, and post-market surveillance data including PMCF.

That framing is the right starting point for hardware. For SaMD and AI, regulators have converged on a sharper one. IMDRF N41 — referenced by the MHRA, FDA, Health Canada and the TGA — sets out three components that any SaMD clinical evaluation has to address, and they are the lens through which Notified Bodies and Approved Bodies actually read AI clinical files.

It is worth being precise about terminology before going further. IMDRF N41 defines clinical evidence as an important component of the technical documentation of a medical device which, alongside design verification and validation documentation, device description, labelling, risk analysis and manufacturing information, is needed to demonstrate conformity with the Essential Principles. Clinical evidence is the output. Clinical evaluation is the process that produces it. Conflating the two is one of the more common reasons technical files lose coherence, because the question “do I have enough evidence?” is not the same question as “have I done a clinical evaluation?”

The first component is valid clinical association. Is there a scientifically established link between the output the model produces and the clinical condition it is intended to address? For a model that flags suspicious lung nodules on CT, the question is whether the imaging features the model uses are accepted in the literature as associated with malignancy. N41 sets out where this evidence comes from: literature searches, original clinical research and professional society guidelines for existing evidence, and secondary data analysis or new clinical trials where new evidence has to be generated. Where the underlying clinical association is well-established, it can be referenced. Where the association is novel — a new combination of inputs, a new biomarker, a new patient population — original evidence is required.

The second is analytical validation. Does the model correctly process its inputs to produce the outputs claimed, with the accuracy, reliability and precision claimed? This is the locked test set, the held-out validation cohort, the sensitivity and specificity figures, the confidence intervals. N41 expects this evidence to be generated through verification and validation activities under the QMS, supplemented where needed by curated databases or previously collected patient data. It is verification that the software does what the specification says.

The third is clinical validation. Does using the model’s output, in the hands of the intended user, in the intended setting, on the intended population, achieve the intended clinical purpose? N41 recognises three ways to demonstrate this: referencing existing data from studies conducted for the same intended use; referencing existing data from studies conducted for a different intended use, where extrapolation can be justified; or generating new clinical data for the specific intended use. The first option is the cheapest and the rarest. The second sounds attractive but the extrapolation justification is where many manufacturers come unstuck. The third is what most novel SaMD and AI devices end up needing, in part or in full. This is the layer that cannot be answered by analytical performance alone. It is the layer that matters most, and the one most often underweighted.

Two practical consequences for SaMD and AI sit on top of that framework.

Equivalence is difficult in this industry generally, and harder still for AI. Two infusion pumps with comparable specifications can plausibly be equivalent. Two image classification models trained on different datasets, validated on different populations, with different decision thresholds and different deployment workflows almost certainly are not — even if their stated intended purposes look similar on paper. The MDR’s technical, biological and clinical equivalence criteria were not written with AI in mind, and they do not flex to accommodate it. Treat equivalence claims for AI devices as a high bar that will probably not be cleared, not as a shortcut to default to. Even outside AI, access to a comparator’s technical file is rare, and equivalence claims fail at conformity assessment for that reason alone with regularity.

Literature behaves very differently depending on whether the device is well-established or genuinely novel. For a well-established device category, literature can carry significant weight: the underlying clinical association is typically settled, comparator data exists, and the SOTA is documented across multiple sources. For a novel device, literature is much harder to lean on. Published studies of AI devices are growing fast but the field has well-documented problems: small datasets, single-site validation, retrospective designs, lack of prospective deployment data, and selective reporting. A systematic literature review for a novel AI device has to grapple with all of that honestly. Citing twelve favourable retrospective studies does not establish state of the art if the state of the art is now prospective, multi-site, and reporting algorithmic bias metrics.

A literature review for a serious clinical evaluation rarely consists of a single search. Three or four targeted searches, each with a defined scope, will usually do more useful work than one broad sweep — one search for clinical SOTA, another for similar or alternative devices, another for evidence specific to the device under evaluation. Recognised scientific databases, more than one per search, paired with a documented appraisal methodology, are the baseline.

A clinical investigation is required when existing data is not adequate to demonstrate conformity for the specific device, the specific intended purpose and the specific claims. Looked at through the IMDRF N41 lens, the threshold is usually reached because of one specific gap: analytical validation alone does not establish clinical validation, and for SaMD that gap is rarely closed by literature or equivalence.

A locked-dataset performance study tells you how a model performs against a fixed reference standard in a controlled environment. It tells you nothing about how the model performs when a junior clinician uses it under time pressure, on a population whose distribution has drifted from the training data, in a workflow where the model output competes with five other information sources. For higher-risk decisions and higher-risk patient interactions, the regulator is increasingly going to want prospective deployment evidence — clinical validation, in N41 terms — and that usually means a clinical investigation, a real-world performance study, or a structured deployment evaluation.

Two further factors push the bar higher. Novelty is one: new mechanisms, new populations, new workflows and new AI/ML decision support paradigms all reduce the amount of existing evidence that can be relied on, by definition. Claims drift is the other: if the claims sit in diagnostic territory, the evidence has to sit there too, regardless of what the model can technically do.

Clinical performance is also rarely uniform across a SaMD. Many devices are modular: only some features make a clinical claim. Where modules operate independently, clinical performance has to be validated at the module level rather than at the device level. A performance matrix is a useful way to demonstrate this — features mapped against the metrics used to validate them (sensitivity, specificity, positive and negative predictive values, likelihood ratios, odds ratios, confidence intervals, usability outcomes), tied back to clinical SOTA and to similar or comparator devices where data exists. MDCG 2020-1 frames this around intended use, indications, desired clinical outputs expressed as claims, and the clinical benefits expected to follow.

When a clinical investigation is run, ISO 14155:2020 is the framework. It governs ethics, scientific validity, monitoring, data management, statistical analysis and reporting. Notified Bodies, Approved Bodies and the MHRA all expect compliance with it for investigational studies.

A clinical investigation is not required when sufficient clinical data already exists, when the device is well-established technology, when meaningful clinical endpoints don’t exist (a sterilisation-cycle logger, for example), or when safety and performance can be fully justified by non-clinical evidence and the claims are genuinely technical rather than clinical.

Article 61(10) of the EU MDR sometimes gets reached for here, on the assumption that it lets a manufacturer demonstrate conformity without clinical data. It can — but only in narrow circumstances, and SaMD and AI devices very rarely qualify. The route is intended for Class IIa or non-implantable Class IIb devices where clinical data is genuinely not appropriate, the clinical benefit is indirect, and there are no meaningful clinical endpoints to measure. A data-logger with no clinical claims might qualify. Image management software with purely functional claims might qualify. Almost any AI device making a clinical decision, triage, diagnostic or prognostic claim will not and is likely to struggle (think back to our IMDRF N41 documentation).

Pre-market evidence rarely settles every clinical question for a SaMD, and it almost never does for an AI device. Post-market surveillance and post-market clinical follow-up are where residual risks get confirmed or downgraded, where performance drift gets detected, and where the assumptions in the original clinical evaluation get tested against actual use or any gaps are verified or removed.

PMCF should not be a placeholder, it should be designed to address the specific residual risks identified in the risk file, and to confirm or revise the clinical performance assumptions that underpinned market entry. Where AI is involved, real-world performance data is also the mechanism by which model drift gets identified before it affects patient outcomes.

State of the art (SOTA) also has a habit of moving faster than clinical evaluation reports. SOTA defined three years ago, never revisited, is a recurring finding in conformity assessment reviews. For AI specifically, what counted as SOTA for a 2022 retinal imaging model is not what counts in 2026; the methods, the reporting standards and the expectations around bias and equity have all shifted. SOTA needs to be reviewed deliberately, on a defined cadence, and the CER updated accordingly.