Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes — diagnosing, treating, mitigating, curing, or preventing a disease or condition — that performs those purposes without being part of a hardware medical device.
SaMD runs on general-purpose platforms such as smartphones, tablets, and computers and is regulated by the FDA, EMA, and other national regulators under standards including IEC 62304, ISO 13485, and ISO 14971. This guide covers the formal IMDRF definition, real-world examples across diabetes care and other therapeutic areas, the four SaMD risk classes, the regulatory pathway, and how SaMD development differs from hardware development.
Software as a medical device (SaMD) is considered separate from hardware medical devices by regulators. But many similar regulations (EU and US) and standards apply to both. At the same time, developing software for use in the medical industry requires a vastly different approach than hardware development.
These factors make planning, creating, and bringing SaMD to market a challenge for many medical device companies.
In this article, we’ll define what software is and isn’t a medical device, and look at some examples of this technology in the diabetes care and treatment world. We’ll also dive into the specifics of software development and how it differs from hardware development while still following similar standards and regulations. Lastly, we’ll discuss what you can do to overcome the challenges created by these conflicting characteristics to bring successful software to market.
What Is Software as a Medical Device (SaMD)?
The FDA, following the International Medical Device Regulators Forum (IMDRF), defines software as a medical device using a single sentence:
“Software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device.”
Three elements of this definition matter most:
Medical purpose
The software must be intended to diagnose, treat, cure, mitigate, or prevent a disease or condition. Software that supports patients with medical conditions but does not perform any of these clinical functions — for example, a general fitness tracker — is not SaMD.
Independent of hardware
The software must perform its medical purpose without being part of a hardware medical device. SaMD typically runs on general-purpose computing platforms — smartphones, tablets, computers — rather than on dedicated medical hardware.
Capable of running on general-purpose platforms
This is one of the IMDRF’s clarifying criteria and the most reliable practical test. If the software can only run on a specific medical device, it’s not SaMD; it’s software in a medical device (SiMD).
Most SaMD falls under the broader category of mobile medical devices (MMD) — software designed for smartphones or tablets that performs a clinical function. The boundary between what qualifies as a mobile medical device and what doesn’t is determined by intended function and associated patient risk, not by the platform itself.
How SaMD Differs from Software in a Medical Device (SiMD)
Software in a Medical Device (SiMD) is software necessary for a medical device to function — also referred to as embedded software, microcode, or firmware. The defining test is whether the device can achieve its intended medical purpose without the software. If it cannot, the software is SiMD. If it can, the software may qualify as SaMD.
SiMD examples in diabetes care
Software that powers insulin pumps, continuous glucose monitors (CGMs), smart pens, and glucose meters · Software that links a CGM and pump to allow automated dose adjustments · Mobile applications that act as remote controls or displays for a specific pump or CGM · Mobile applications that calibrate CGM sensors,
The distinguishing rule
SaMD may receive data from medical devices and interact with them, but it does not change what the devices do or how they function. The hardware operates the same with or without the SaMD connected.
How SaMD Differs from Medical Device Data Systems (MDDS)
A Medical Device Data System (MDDS) is hardware or software that transfers, stores, converts, or displays medical device data without controlling or altering the function of any medical device. The FDA classifies MDDS as a Class I device with general controls.
The boundary between MDDS and SaMD is whether the software interprets data to inform a clinical decision. An MDDS moves data; a SaMD interprets it.
For a deeper comparison and concrete examples, see our guide to the differences between MDDS and SaMD.
SaMD Examples Across Diabetes Care, Cardiology, and Beyond
SaMD examples span every major therapeutic area. The diabetes care market — where Sequenex has the deepest experience — illustrates the category clearly:”
SaMD examples in diabetes care
- Applications that provide treatment recommendations based on data from CGMs and pumps
- Software that calculates insulin doses from carbohydrate intake and blood glucose readings (without instructing the pump to deliver)
- Applications that integrate data from multiple devices and surface it to clinicians for treatment decisions
- Software that combines CGM data with biometric inputs (heart rate, activity) to predict glucose trends
- Applications that estimate carbohydrate loads and calculate dosing based on patient-specific ratios
SaMD examples in other therapeutic areas:
- Cardiology: ECG analysis software that interprets recordings from consumer wearables to flag arrhythmias
- Radiology: AI-based tools that analyze diagnostic images to assist clinical interpretation
- Mental health: cognitive behavioral therapy (CBT) applications cleared by the FDA as digital therapeutics
- Oncology: software that analyzes pathology images to support cancer detection
What’s not SaMD
Software that surfaces medical data without interpreting it for clinical decision-making is generally not SaMD. An app that displays CGM readings without offering treatment guidance is closer to MDDS. An app that estimates carbohydrate content without suggesting insulin dosing is a wellness tool, not SaMD.
SaMD Risk Classification (IMDRF Categories I–IV)
The International Medical Device Regulators Forum (IMDRF) classifies Software as a Medical Device into four risk classes — Class I, II, III, and IV — based on two axes. The first axis is the significance of the information the SaMD provides to a healthcare decision: whether it informs clinical management, drives clinical management, or treats or diagnoses a condition. The second axis is the seriousness of the patient’s healthcare situation: non-serious, serious, or critical. The combination of the two axes determines the SaMD class, with Class I representing the lowest risk and Class IV the highest.
| SaMD Class | Healthcare Situation | Information Significance | What the SaMD Does | Examples |
|---|---|---|---|---|
| Class I | Non-serious condition | Informs clinical management | Provides information that supports healthcare decisions without driving them | General wellness lifestyle dashboards; nutrition tracking apps with informational outputs only |
| Class II | Serious condition | Informs clinical management | Provides information for serious conditions that supports but does not drive clinical decisions | Continuous glucose monitor (CGM) data visualization apps; chronic disease tracking apps with informational outputs |
| Class III | Non-serious condition | Drives clinical management or diagnosis | Provides recommendations or analyses that directly inform treatment decisions for non-life-threatening conditions | Decision support apps for non-critical chronic conditions; treatment recommendation tools for stable patient populations |
| Class IV | Critical condition | Drives clinical management, treats, or diagnoses | Drives critical-care decisions, performs diagnoses, or guides treatment for life-threatening conditions | AI-based cancer diagnostic software; closed-loop insulin dosing algorithms; ICU patient deterioration prediction software |
SaMD class drives the entire regulatory and development effort. Class IV SaMD requires the most rigorous documentation, the most extensive verification and validation, and the most thorough premarket review by regulators. Class I SaMD has the lightest regulatory footprint. Most national regulators — including the FDA, EMA, Health Canada, and Japan’s PMDA — base their SaMD requirements on this IMDRF framework, which means a single classification decision typically governs market entry across multiple jurisdictions.
SaMD Regulation and the FDA Pathway
SaMD is regulated under the same general framework as hardware medical devices, with software-specific overlays. In the United States, the FDA reviews SaMD under 21 CFR Part 820 design controls and applicable premarket pathways. Internationally, regulation is increasingly harmonized around the IMDRF framework. Our SaMD regulatory pathway has more details for you.
The Standards That Govern SaMD
IEC 62304 is the international standard for the medical device software lifecycle. It defines what activities must occur during planning, requirements, architecture, detailed design, implementation, integration, system testing, and release — and prescribes documentation requirements that scale with the software’s safety classification (Class A, B, or C).
ISO 13485 is the quality management system (QMS) standard for medical device manufacturers. SaMD developed outside an ISO 13485-certified QMS faces a much steeper regulatory path; SaMD developed inside one inherits process controls that map directly to FDA design control requirements.
ISO 14971 is the risk management standard. It covers hazard identification, risk evaluation, risk control, and post-market surveillance. ISO 14971 runs in parallel with IEC 62304 across the entire SaMD lifecycle.
The FDA Premarket Pathway
Most SaMD enters the U.S. market through one of three FDA pathways:
- 510(k) clearance — for SaMD substantially equivalent to a legally marketed predicate device
- De Novo classification — for novel low-to-moderate risk SaMD with no predicate
- Premarket approval (PMA) — for high-risk SaMD where general and special controls are insufficient to assure safety and effectiveness
The FDA’s Digital Health Center of Excellence publishes guidance specific to SaMD, including the Software Precertification Program and guidance on clinical decision support software.
International Harmonization
The IMDRF framework is recognized by the FDA, Health Canada, the European Medicines Agency (EMA), Japan’s PMDA, Australia’s TGA, and other major regulators. Building SaMD to the IMDRF framework typically satisfies the foundational requirements of multiple jurisdictions, reducing duplicate regulatory effort.
SaMD Development & Regulation
SaMD development requires a fundamentally different approach than hardware development. Where hardware design typically follows a waterfall sequence — locked requirements, sequential build, then validation — software benefits from iterative cycles that surface defects early and accommodate the rapid evolution of clinical evidence, platform APIs, and regulatory expectations.
Frequently Asked Questions About SaMD
What does SaMD stand for?
SaMD stands for Software as a Medical Device. The term refers to software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device.
What is the difference between SaMD and SiMD?
SaMD (Software as a Medical Device) operates independently of any specific medical device hardware. SiMD (Software in a Medical Device) is software necessary for a hardware device to function — also called embedded software, microcode, or firmware. The test is whether the hardware can achieve its intended medical purpose without the software: if not, the software is SiMD.
What are the SaMD risk classes?
The IMDRF defines four SaMD risk classes (I, II, III, IV) based on the significance of the information the software provides to the healthcare decision and the seriousness of the patient’s condition. Class I is the lowest risk; Class IV is the highest. Higher classes require more rigorous documentation, validation, and premarket review.
Is a wellness app SaMD?
A wellness app is generally not SaMD. To qualify as SaMD, software must be intended to diagnose, treat, cure, mitigate, or prevent a disease or condition. Wellness software that supports general health without performing any of these clinical functions falls outside the regulated medical device category.
What standards govern SaMD development?
SaMD development is governed by IEC 62304 (software lifecycle processes), ISO 13485 (quality management system), and ISO 14971 (risk management). FDA-regulated SaMD also follows the design controls in 21 CFR Part 820 and applicable premarket pathways. Sequenex builds all of these as standard.
How is SaMD regulated in the United States?
In the United States, the FDA regulates SaMD under the same framework as hardware medical devices, with additional software-specific guidance. Most SaMD reaches the U.S. market through 510(k) clearance, De Novo classification, or premarket approval (PMA), depending on risk class. The FDA’s Digital Health Center of Excellence publishes guidance documents specific to SaMD.
Build SaMD With a Partner Who Already Knows the Path
SaMD development is what Sequenex does every day. Our software is engineered to IEC 62304 within an ISO 13485-certified QMS, with ISO 14971 risk management running in parallel and DHF-ready documentation produced as engineering work progresses. We have decades of experience across diabetes care, biosensors, CGM, and connected medical devices.
If you’re working out whether your product qualifies as SaMD, what risk class it falls into, or how to bring it to market on the FDA’s premarket pathway, we can help.
