Regulation and policy

Clinical Evaluation Versus Clinical Investigation, and Why Medical Software Needs Both

A clinical evaluation gathers all the evidence that bears on a device and judges whether it adds up to the claim. A clinical investigation runs a study to produce new evidence when what exists falls short. One appraises, the other generates.

A clinical evaluation gathers all the evidence that bears on a device and judges whether it adds up to the claim. A clinical investigation runs a study to produce new evidence when what exists falls short. One appraises, the other generates. People confuse them because both carry the word clinical and both end in a written report, yet they answer different questions, and a serious medical product usually needs both. This article explains the distinction in plain terms, drawing on the medical device regulation training I completed at KTH Royal Institute of Technology and on FDA Clinical Investigator coursework. It is general education, not medical or regulatory advice for your specific product.

What a clinical evaluation actually is

A clinical evaluation is a structured argument. You state what the device is for, then you assemble every relevant source of evidence and weigh whether it supports that purpose. Those sources include published studies on the device, studies on equivalent devices, data from earlier versions, and findings collected once the product reaches the market.

The verb that matters is appraise. You are not running an experiment. You are reading what already exists, deciding how much each piece is worth, and writing down where the evidence holds and where it stays thin. A good evaluation is honest about its own gaps.

Under EU MDR, this work is neither optional nor one and done. The evaluation is a living file that gets updated as new data arrives, because a device that looked well supported at launch can drift out of alignment with reality as it meets new populations and new uses.

What a clinical investigation actually is

A clinical investigation is a study you design and run because the evidence you need does not yet exist. It is the medical device counterpart of a clinical trial. You write a protocol, define who is studied and what is measured, obtain ethics approval, enroll participants, and collect data under rules set in advance.

The point of an investigation is to create a fresh and trustworthy piece of evidence. When a clinical evaluation hits a question the literature cannot answer, an investigation is how you go and answer it.

This is the part that carries the heaviest obligations, because you are now studying real people. Protocol design, informed consent, participant safety, and pre-specified outcomes all become formal duties. The FDA Clinical Investigator training I completed is built around getting these duties right, since the credibility of any result depends on the discipline of the method.

How the two fit together

Picture the evaluation as the question and the investigation as one possible answer. The evaluation asks whether the current evidence supports the claim. If the answer is yes, you may need no new study at all. If the answer is no, the evaluation tells you which gap a new study has to close.

This ordering protects people and resources. A study on human participants is a serious undertaking, so you should run one only when reading the existing evidence shows you genuinely need to. The evaluation justifies the investigation, and the investigation feeds its result back into the evaluation.

The loop does not stop at launch. Once a device is in use, real-world data flows back into the evaluation, and sometimes that data raises a new question that prompts another investigation. A mature product treats this as a cycle, not a hurdle cleared once.

Why software makes this harder, not easier

Medical software tempts teams to skip the hard part. Code feels fast and revisable, so it is easy to assume evidence can be revisable too. The regulation does not see it that way. If software is intended to inform a diagnosis or a treatment decision, it is a medical device, and the same evidence logic applies.

A machine learning model sharpens the problem. Its performance is a claim about a number, and a number has to be measured rather than asserted. A model can perform beautifully on the data it was built from and quietly stumble on a population it never saw. A clinical evaluation of such a system has to ask which populations the evidence actually covers, not which populations the marketing implies.

Software also changes between versions, sometimes without anyone announcing it. That movement is exactly why post-market data matters so much for digital products. The evaluation has to keep asking whether yesterday's evidence still describes today's behavior, and an investigation may be the only honest way to confirm that it does.

What this looked like in my own work

When I co-developed EASY Diabetes, a decision-support system for type 2 diabetes, the clever part was never the bottleneck. The bottleneck was evidence. A tool that suggests how to manage a chronic condition is making a clinical claim, and a claim like that has to be tested rather than demonstrated in a slide deck.

So the work included a registered randomized controlled trial (NCT03258268), designed to test the tool against ordinary care rather than a friendly internal benchmark. That is a clinical investigation in the formal sense: a protocol, pre-specified outcomes, and an independent record. The system later received Sweden's Medtech4Health Innovation Award.

I want to be careful about where authority sits here. The durable backbone of my own credibility is peer-reviewed science, including work published in Science and a meta-analysis in Diabetes Care, rather than any single product. A trial is one well-run study; the evaluation is the wider habit of asking what all the evidence, taken together, is allowed to claim. The course that taught me to hold both at once was the KTH Medical Device Regulations training, which covers EU MDR, IVDR, FDA pathways, and Software as a Medical Device.

The question worth carrying

If you are building a medical product, the most useful early question is not how to avoid being regulated. It is what you are claiming, and what evidence would honestly support it. That single question splits cleanly into the two processes in this article.

Ask first what the existing evidence already shows. That is your clinical evaluation, and it may reveal that you are claiming more than you can support. Then ask what new evidence you would need to close the gap. That is your clinical investigation, and it is how a claim earns the right to be believed. For anything touching your own health, take the specifics to a qualified clinician who knows your situation.

References and sources

  1. MDCG 2020-1 Clinical Evaluation of Medical Device Software
  2. EU MDR 2017/745 Article 61 Clinical Evaluation
  3. EASY Type 2 Diabetes Decision Support Trial NCT03258268

How this was researched. This explainer is built from the primary sources listed above and reflects Dr. Tojjar's own critical appraisal of that evidence. It explains and evaluates research and does not provide medical care.

This article is for general education and is not medical or professional advice. For guidance about your own health, talk with a qualified clinician.

Cite this article

Tojjar, D. (2026). Clinical Evaluation Versus Clinical Investigation, and Why Medical Software Needs Both. Dr. Damon Tojjar. https://readingtheevidence.org/articles/clinical-evaluation-vs-clinical-investigation/

Back to all insights