IMDRF Software as a Medical Device Principles and Clinical Evaluation

The IMDRF documents form one connected framework

The International Medical Device Regulators Forum developed a set of harmonised principles for software that performs a medical purpose independently of a hardware medical device. Four documents provide the main structure: N10 defines SaMD, N12 introduces risk categorisation, N23 applies quality-management principles and N41 explains clinical evaluation.

Read them as a connected system. The intended purpose establishes whether the software is SaMD and what it claims to do. The significance of its information and the healthcare situation indicate potential impact. Quality management controls the product and its lifecycle. Clinical evaluation demonstrates that its output is medically meaningful, technically trustworthy and clinically useful.

Begin with the medical purpose, not the technology

IMDRF defines SaMD as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. It may run on a general-purpose computing platform and may interface with other products, including hardware medical devices. The decisive question is what the manufacturer intends the software to do.

Software that drives or controls a hardware medical device can be software in a medical device rather than SaMD. Administrative systems, general wellness products and software that merely stores, transfers or displays information without a medical-device purpose may fall outside the SaMD definition. Boundaries must be assessed against applicable regional legislation.

Establish the product position using MTL-102 — Intended Purpose, Users and Use Environments and, for the EU, MTL-314 — MDCG 2019-11 Software Qualification and Classification.

The SaMD definition statement anchors the product

Describe the software's intended medical purpose clearly enough to support classification, risk management, requirements and evidence planning. Identify the medical condition, target population, intended users, use environment, input data, output and the role that output plays in healthcare.

A change to the population, output, clinical role or decision significance may change the evidence burden and regulatory position even if little code changes.

Risk category combines information significance and healthcare situation

IMDRF N12 uses two dimensions. First, determine whether the information treats or diagnoses, drives clinical management, or informs clinical management. Second, determine whether the healthcare situation or condition is critical, serious or non-serious. Their combination produces one of four categories, I to IV, with Category IV representing the highest impact.

The IMDRF category is a conceptual framework, not automatically the legal classification in every jurisdiction. Record the rationale and then apply the binding regional rules.

Quality management must fit a software lifecycle

IMDRF N23 explains how medical-device quality principles apply to organisations with rapid releases, distributed platforms and frequent change. Governance, scalable processes and product-realisation controls should be proportionate to the software's risk and complexity.

• Give management clear responsibility for safety, performance, quality and regulatory compliance.
• Maintain competent multidisciplinary teams and a quality culture that supports timely escalation.
• Control requirements, architecture, design, coding, review, testing, release and maintenance.
• Manage configuration, third-party software, infrastructure, data and deployment environments.
• Integrate risk management, usability, cybersecurity and clinical evaluation throughout development.
• Use post-market information and software monitoring to inform corrective action and improvement.

Build these controls with MTL-107 — Software Lifecycle, MTL-127 — Configuration and Change Management and MTL-301 — ISO 13485 and Design Controls.

Clinical evaluation asks three different questions

IMDRF N41 structures SaMD clinical evaluation around valid clinical association, analytical validation and clinical validation. Each addresses a different possible failure. All three must be considered for the exact intended purpose and released configuration.

These elements complement, rather than replace, verification, usability, risk and cybersecurity evidence. See MTL-120 — Clinical and Performance Evaluation.

Valid clinical association establishes medical meaning

Demonstrate that the relationship between input, output and targeted condition is supported by accepted clinical knowledge or credible new evidence. Sources may include peer-reviewed literature, professional guidance, consensus, clinical practice or original studies.

Assess whether evidence supports the exact population, data modality, threshold, prediction period and intended clinical role. A general association does not necessarily support a product-specific claim. Where the association is novel or weak, new clinical investigation may be required.

Analytical validation establishes technical truth

Show that the released software transforms input into output accurately, reliably and precisely. Define the reference method, test data, acceptance criteria, measurement uncertainty and operating boundaries. Challenge missing, noisy, corrupted, extreme and unexpected inputs as well as representative normal use.

Evaluate the full pipeline: acquisition, transfer, preprocessing, feature extraction, algorithm, thresholds, post-processing, presentation and interfaces. A model can perform well in isolation while the complete product fails because of mapping, units, configuration or workflow errors.

Use MTL-128 — Statistical Methods and Measurement Assurance to plan credible datasets, estimates and uncertainty.

Clinical validation demonstrates value in context

Clinical validation asks whether the accurate output achieves the claimed purpose for representative users, patients and settings. Measures may include sensitivity, specificity, predictive values, agreement, calibration, clinical decision impact or patient outcomes, depending on the claim.

Predefine clinically meaningful acceptance criteria. Address important subgroups, prevalence, user interpretation, workflow, alternative methods and consequences of false positive, false negative or delayed results. Report limitations and uncertainty instead of relying on a single aggregate score.

Plan evidence from claims and gaps

Create a claim-to-evidence map linking each intended-purpose statement and performance claim to the three evaluation components. Critically appraise existing evidence, identify gaps and choose methods proportionate to risk and novelty.

• Is the data relevant to the intended population, users and environment?
• Are reference standards and labels credible and independent?
• Are development, tuning and evaluation datasets appropriately separated?
• Are sample size, uncertainty, missing data, bias and subgroup effects addressed?
• Can every result be traced to the evaluated software, model and configuration?
• Are privacy, consent and data-governance controls defined?

Connect data governance to MTL-129 — Privacy and Data Protection by Design and US submission evidence to MTL-309 — FDA Device Software Functions — Premarket Submissions.

Real-world performance supports continuous learning

SaMD can often collect timely operational and performance information. Use this capability deliberately: monitor technical performance, user interaction, complaints, incidents, data drift, subgroup performance and changes in clinical practice. Define signals, thresholds, responsibilities and action before release.

New evidence may confirm performance, reveal deterioration or support a revised intended purpose. Any resulting change must pass through controlled impact assessment, risk management, verification, clinical evaluation and regional regulatory review. Continuous learning does not mean uncontrolled product change.

Translate IMDRF principles into regional requirements

IMDRF promotes convergence but does not grant market access. Regulators may adopt, adapt or reference its concepts differently. Determine qualification, classification, conformity assessment, submission content, clinical evidence and post-market duties under each applicable jurisdiction.

For EU software evidence, compare MTL-316 — MDCG 2020-1 Clinical and Performance Evaluation of Medical Device Software. Maintain a documented mapping between the international framework and the legal requirements applied to the product.

Common misconceptions

Practical SaMD checklist

• Is the intended medical purpose precise and jurisdictionally assessed?
• Does the SaMD definition statement cover condition, population, user, input, output and clinical role?
• Is the IMDRF risk category justified using both dimensions?
• Are software lifecycle and quality controls proportionate to risk?
• Is valid clinical association supported for the exact claim?
• Does analytical validation cover the complete released pipeline?
• Does clinical validation represent intended patients, users and workflows?
• Are datasets, statistics, bias, uncertainty and limitations documented?
• Are software and model versions traceable to every evidence result?
• Will real-world performance and change be monitored and controlled?