Software as a Medical Device (SaMD) is one of the fastest-growing categories in healthcare — and one of the most misunderstood from a regulatory standpoint. If your software makes a clinical claim, it may be a regulated medical device in its own right, with all the quality-system obligations that come with it. Here’s what SaMD actually means, how it’s regulated, and the quality system a SaMD company needs to build.

What is Software as a Medical Device (SaMD)?

The internationally agreed definition (from IMDRF, the global forum of medical device regulators) is precise: Software as a Medical Device is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device.

The key phrase is “without being part of.” SaMD runs on general-purpose computing platforms — a phone, a tablet, a server, the cloud — and is a medical device on its own. An app that analyzes a photo of a skin lesion to flag possible melanoma is SaMD. Software that reads MRI images to detect a stroke is SaMD. What makes it a device isn’t the platform — it’s the medical purpose: diagnosing, treating, preventing, or informing clinical decisions.

SaMD vs. software in a device vs. everything else

Not all medical software is SaMD, and the distinction decides how it’s regulated:

• SaMD — software that is the medical device (a diagnostic app, an image-analysis tool). Regulated as a device.
• SiMD (Software in a Medical Device) — software that drives or is embedded in hardware (the firmware in an infusion pump). Regulated as part of that device.
• Software that supports devices but isn’t one — tools used to design, manufacture, or maintain devices, or general wellness apps that make no medical claim. Generally not regulated as a device (though quality expectations still apply to the ones you build your product with).

The line that matters most is the intended use. Make a medical claim — diagnose, treat, or drive a clinical decision — and you are almost certainly building a regulated device.

How SaMD is regulated

Because it’s a device, SaMD sits under the same regulatory frameworks as physical devices — with software-specific layers on top:

• FDA (United States). SaMD is regulated as a medical device, typically cleared through the 510(k) or De Novo pathway. The FDA uses the IMDRF risk-categorization framework — the state of the healthcare situation (critical, serious, non-serious) combined with the significance of the information the software provides (to treat/diagnose, to drive management, to inform).
• EU MDR (Europe). Rule 11 up-classifies most medical software, so many products that were low-risk under the old directive are now Class IIa or higher.
• The QMS and software standards. Regardless of market, SaMD is built under ISO 13485, with IEC 62304 governing the software development lifecycle, ISO 14971 for risk management, and IEC 62366-1 for usability/human factors.

The quality system a SaMD company needs

This is where many software-first teams get caught off guard: shipping SaMD means running a medical device quality system, not just good engineering practice. The core obligations:

• Design controls and a Design History File (DHF) — documented design inputs, outputs, reviews, verification, and validation for your software.
• A software development lifecycle per IEC 62304 — planning, requirements, architecture, and, critically, maintenance and problem resolution, scaled to your software’s safety class.
• Risk management per ISO 14971 — a living risk file, with cybersecurity risk increasingly central for connected software.
• Controlled documentation — every procedure, specification, and record under document control with an audit trail.
• Post-market surveillance — software doesn’t stop needing oversight at launch; field data and updates feed back into risk management.

The through-line is that the whole thing has to be controlled and provable — the same governance a physical-device maker lives by, applied to code.

How TLM helps SaMD teams meet it

TLM is a quality management system built for medical device companies — including the software-first ones. It carries native DHF, DMR, and risk-file flags on controlled documents, so your design history and risk records are first-class and audit-ready rather than scattered across wikis and drives. Document control, CAPA, complaint handling, and post-market surveillance live together, so the evidence an auditor or notified body asks for is assembled as you work — and the same controlled document set feeds your 510(k) or technical file. For a SaMD company, that’s the difference between a quality system that slows the team down and one that keeps the software audit-ready without an enterprise deployment.

See a medical-device QMS built for software teams → Book a 20-minute walkthrough.

Frequently asked questions

What is Software as a Medical Device (SaMD)?
SaMD is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. It runs on general-purpose platforms (phone, tablet, cloud) and is itself a regulated medical device — for example, an app that analyzes an image to help diagnose a condition.

What’s the difference between SaMD and SiMD?
SaMD (Software as a Medical Device) is software that is the device on its own. SiMD (Software in a Medical Device) is software embedded in or driving hardware, like the firmware in an infusion pump. SaMD is regulated as a standalone device; SiMD is regulated as part of the device it runs.

Is a health or wellness app a medical device?
It depends on intended use. An app that makes a medical claim — to diagnose, treat, prevent, or drive a clinical decision — is generally a regulated device (SaMD). A general wellness app that makes no medical claim usually is not. The claim, not the platform, decides.

What standards apply to SaMD?
SaMD is built under ISO 13485 (quality management), with IEC 62304 for the software development lifecycle, ISO 14971 for risk management, and IEC 62366-1 for usability. In the US the FDA regulates it as a device (often via 510(k) or De Novo); in the EU, MDR Rule 11 sets its classification.

Does SaMD need FDA clearance?
If it meets the definition of a medical device, yes — typically through the 510(k) or De Novo pathway, with the required class and controls determined by risk. The FDA uses the IMDRF framework (the healthcare situation’s seriousness combined with the significance of the information the software provides) to gauge that risk.