Clinical Evaluation for SaMD: What Your CER Actually Needs

The problem most SaMD teams run into

Clinical evaluation for hardware devices has a relatively established playbook: find equivalent devices, extract clinical data, run a gap analysis, decide whether you need a clinical investigation. For software, that playbook doesn't map cleanly. There often is no direct equivalent device. There may be no clinical investigation data at all. The clinical outcomes literature may not match the exact function your software performs.

This leaves a lot of SaMD manufacturers either producing a Clinical Evaluation Report that is technically correct but substantively thin, or spending enormous effort trying to build equivalence claims that won't hold up. Neither is a good outcome. What follows is what the clinical evaluation process actually looks like for software done properly.

What Article 61 and Annex XIV require

Article 61 requires clinical evaluation for all devices, including software. The evaluation must confirm that the device achieves its intended purpose, that risks are outweighed by benefits, and that the device performs as claimed. Annex XIV lays out the methodology: an ongoing structured process, not a one-time document.

For software specifically, a few things are worth flagging. First, clinical evaluation must be appropriate to the device's risk profile and the nature of the claims made. A Class IIb AI diagnostic tool making clinical claims needs substantive clinical evidence. A Class IIa analytics tool supporting clinical workflow has a different evidence burden. What you need to gather is proportional to what you claim.

Second, Article 61(1) is clear: clinical data must be from your specific device or from equivalent devices. The concept of equivalence is harder to satisfy for software than for hardware — the equivalence criteria include "technical" equivalence, which for software means equivalent algorithmic approach, identical intended purpose, same patient population, same clinical environment. If your software uses a novel algorithm, you may not be able to find a genuine equivalent.

What clinical evidence for software looks like

Without hardware clinical investigation data, SaMD manufacturers typically build their CER from:

Performance studies — prospective or retrospective studies where the software's output is evaluated against a reference standard (gold standard clinical diagnosis, expert panel, histopathology, etc.). These are the most direct form of clinical evidence for diagnostic or detection software. A well-designed performance study can provide strong evidence of clinical validity.

Published literature — scientific publications evaluating the performance of your software or software using the same methodology on the same patient population for the same indication. Important: publications evaluating a different algorithm, a different population, or a different indication are background state of the art, not direct clinical evidence for your device.

Clinical datasets / real-world data — if your software was used during development or in a clinical setting, retrospective evaluation against known outcomes can generate clinical evidence. This requires a rigorous methodology and documentation of data provenance.

Expert opinion — useful as supporting evidence but not sufficient on its own. An opinion that a clinical function is beneficial is not the same as evidence that your specific software achieves that benefit safely and effectively.

The CER must honestly assess what evidence you have, what its limitations are, and whether it is sufficient to support your clinical claims. A thin evidence base is a problem — but a CER that acknowledges the gap and has a concrete PMCF plan to close it is better than one that papers over the gap with weak equivalence arguments.

PMCF for SaMD — how it actually works

Post-Market Clinical Follow-up is not optional decoration for software. It's a systematic plan for continuing to gather clinical evidence after launch. For software, PMCF often carries more weight than for hardware, because initial evidence may be limited and the software may continue to evolve.

What PMCF looks like in practice for SaMD:

Real-world performance monitoring — systematic collection and analysis of the software's outputs in real clinical settings versus actual clinical outcomes. This is different from general PMS complaint handling — it's structured clinical data collection.

Registry participation — contributing data to a clinical or disease registry where your software's performance can be tracked over time against outcome data.

User surveys and observational studies — structured collection of clinician feedback about whether the software performs as intended in real clinical use.

Continued literature surveillance — ongoing monitoring of the scientific literature for studies evaluating your software or methodologically equivalent tools.

The PMCF plan must be specific: what data will you collect, how, from how many sites, over what timeframe, and what conclusions will you draw from it? "Monitor performance through normal use" is not a PMCF plan.

One thing the MDCG guidance makes clear

MDCG 2020-6 on PMCF and MDCG 2020-5 on clinical evaluation both apply to software. One thing teams often miss in MDCG 2020-5: the clinical evaluation report for software should address the clinical claims made in your intended purpose statement one by one. If your IFU says the software detects condition X with sensitivity Y — your CER needs to address whether the evidence supports that claim. Vague benefit statements in the CER that don't trace back to specific claims are a common Notified Body finding.

Map your CER directly to your intended purpose statement. Every clinical claim should have evidence supporting it, or a PMCF commitment to generate that evidence.