Software as a Medical Device: Regulatory Basics for Buyers

Software has moved from a supporting feature inside hardware devices to a product in its own right, running on a hospital server, a clinician's laptop or a mobile phone with no physical device attached at all. Software as a Medical Device (SaMD), the international term for software that performs a medical function independently of any hardware it may happen to run on, now covers diagnostic image analysis, clinical decision support, dose calculators and a growing range of monitoring and triage tools. For buyers and distributors used to evaluating a physical product's labeling and sterility, SaMD raises a different set of questions.

What Makes Software "SaMD" Rather Than Just Software

The defining test, set out by the International Medical Device Regulators Forum (IMDRF) and adopted in substance by both the EU and the FDA, is intended medical purpose, not the presence of hardware. A standalone application that analyzes radiology images to flag a possible abnormality, calculates a treatment parameter, or monitors a physiological signal to inform a clinical decision is generally SaMD. General wellness apps, scheduling tools and software that simply displays or stores data without interpreting it for a medical purpose typically fall outside the definition, though the line is assessed case by case against the manufacturer's stated intended use, not the software's technical sophistication.

Risk Classification Is Driven by Clinical Context, Not Code Complexity

The IMDRF framework classifies SaMD along two axes: the seriousness of the condition or situation the software addresses (critical, serious or non-serious) and the significance of the information the software provides to a healthcare decision (treat/diagnose, drive clinical management, or inform clinical management). A tool that drives treatment decisions in a critical condition sits in a higher risk category than one that merely informs management of a non-serious condition, regardless of how technically advanced the underlying algorithm is. Under EU MDR, most SaMD intended to provide diagnostic or therapeutic information is captured by Rule 11, which routes a meaningful share of these products into Class IIa or higher, often requiring Notified Body involvement where a hardware-only product of similar apparent simplicity might not.

Clinical Evidence and Quality System Expectations

Because SaMD has no physical form to inspect on receipt, its conformity rests almost entirely on documented evidence: verification and validation records, clinical evaluation of the software's actual performance in its intended use setting, and a quality management system covering the software development lifecycle itself (commonly referenced against IEC 62304). Buyers evaluating a SaMD product should expect to see evidence that the software was tested against its stated intended use population and clinical workflow, not only that it functions correctly as code. Cybersecurity documentation, covering how the manufacturer identifies and manages vulnerabilities over the product's life, is now a standard part of that technical file rather than an optional add-on.

Why Version Updates Change the Compliance Picture

A hardware device's certification generally covers a fixed, static product. Software is routinely updated, and not every update is regulatory-neutral. A change that alters the software's clinical function, its intended use, or its risk classification typically requires a new or updated conformity assessment, while a bug fix or performance patch with no functional change to the medical claim may not. Manufacturers are expected to maintain a documented change-control process that makes this distinction explicit for every release, and distributors sourcing SaMD should ask how a given manufacturer tracks and documents that boundary rather than assuming every update is automatically covered by the original certificate.

Due Diligence Questions Before Sourcing SaMD

A short set of questions tends to surface whether a SaMD manufacturer's documentation is mature:

• What is the stated intended use, and does the marketed use case match it exactly?
• What risk class and regulatory pathway applies in each target market, and is the current certificate still in scope for the version being sold?
• Is there a documented software lifecycle quality system and a change-control process for updates?
• What cybersecurity and data-handling documentation exists, and how are post-market issues reported?
• Does the clinical evaluation reflect the actual deployment environment, or only a controlled test setting?

The Takeaway

SaMD is regulated the same way any other medical device is: by intended use and risk, not by whether it ships on a shelf or downloads to a server. For distributors and institutional buyers, that means the due diligence shifts from physical inspection toward documentation review, with particular attention to how a manufacturer manages software updates and clinical evidence over time rather than at a single point of certification.

This is general educational information, not legal or regulatory advice; consult the current official texts and your competent authority.