SaMD vs SiMD: What Is the Difference?

The short answer

SaMD (software as a medical device) is software that does a medical job on its own, on a phone, a PC or a server. SiMD (software in a medical device) is the firmware and embedded software that makes a hardware medical device work. A diagnostic app that reads ECG data and flags atrial fibrillation is SaMD. The firmware that samples the electrodes inside the ECG patch is SiMD.

The difference matters because it decides how the software is classified, what goes into the regulatory file, and how freely you can update it once it ships. Many connected medical products contain both: firmware on the device, an app on the phone and a back end in the cloud. Each piece may land in a different category, and getting that split right early is one of the most useful architecture decisions a medical device team can make.

This guide is written for teams that build connected medical hardware. It covers the definitions, real examples, how classification works in general terms in the US and EU, and what changes for engineering, testing and updates in each case. It is not regulatory advice: confirm the classification of your own product with a regulatory specialist.

What is SaMD?

SaMD is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. That is the definition published by the International Medical Device Regulators Forum (IMDRF) and used by the US FDA.

The IMDRF notes add the details that matter in practice:

SaMD can run on general-purpose computing platforms: phones, tablets, PCs, servers and cloud services.
"Without being part of" means the software is not needed for a hardware medical device to achieve its intended medical purpose.
Software whose intended purpose is to drive a hardware medical device is not SaMD.
SaMD can be used in combination with other products, and can exchange data with hardware devices and other software, and still be SaMD.
Mobile apps that meet the definition are SaMD.

Typical SaMD examples:

An app or cloud service that analyses ECG recordings and flags a possible arrhythmia.
Software that analyses radiology images to help detect or triage a condition.
An insulin dose calculator that recommends a dose from glucose readings.
Software that uses a phone's own sensors, such as the accelerometer or camera, to detect or monitor a condition.

What is SiMD?

SiMD is software that is part of a hardware medical device and is needed for it to work: firmware, embedded control software and on-device algorithms. The FDA describes it as software "integral to a hardware medical device". The term SiMD is descriptive rather than a separate legal category; the software is regulated as part of the device it runs in.

Typical SiMD examples:

Firmware that controls inflation and deflation of a blood pressure cuff and calculates the reading.
Dosing and occlusion-detection software in an infusion pump or insulin pump.
Signal acquisition and filtering firmware in a pulse oximeter or ECG patch.
The control loop in a ventilator, or the sensing and pacing logic in a pacemaker.
The display and alarm software on a bedside monitor.

SaMD vs SiMD: what is the difference?

The quickest test is to ask: if the hardware were removed, would the software still do its medical job? If yes, it is likely SaMD. If the software exists to run, control or read a specific medical device, it is likely SiMD.

	SaMD	SiMD
What it is	Standalone medical software	Software that is part of a hardware medical device
Where it runs	Phone, tablet, PC, server, cloud	The device's microcontroller or processor
Typical examples	Diagnostic app, image analysis, dose calculator	Pump firmware, monitor firmware, pacemaker logic
How it is classified	On its own, by the significance of its output and the seriousness of the condition	With the device it runs in; it takes the device's class
Main risk source	Wrong or misleading information leading to a wrong decision	Hardware and software failing together: wrong dose, missed alarm, unsafe output
How it is updated	App store, web deploy or cloud release	Firmware update over USB, service tool or OTA
Testing focus	Algorithm performance, clinical evaluation, usability, data integrity	Hardware-software integration, timing, fault handling, electrical and environmental conditions
Platform control	Runs on hardware and operating systems you do not control	Runs on hardware you design and control

How do you tell whether your software is SaMD, SiMD or not a device?

Work through these questions for each software item in the product, not for the product as a whole.

Does it have a medical purpose at all?

Software that only supports administration, general wellness or fitness may not be a medical device. In the US, some software functions are excluded from the device definition by law, and FDA guidance on clinical decision support and general wellness draws further lines. In the EU, MDCG 2019-11 is the main guidance on whether software qualifies. These boundaries are detailed and change over time, so check the current guidance for your market.

Does it only move, store, convert or display device data?

In the US, software functions that are solely intended to transfer, store, convert formats or display medical device data, without modifying or analysing it and without controlling the connected device, are treated as non-device medical device data systems (MDDS) under FDA guidance. A cloud service that stores blood pressure readings for later review can fall here. Once the software analyses or interprets the data, for example by raising alarms for active patient monitoring, FDA treats that as a device function.

Does it drive or control a hardware device?

If the software runs a specific medical device, sets its parameters or is needed for it to perform its intended use, it is SiMD, even if it runs on a separate computer. The EU MDR says it plainly: software that drives or influences the use of a device falls within the same class as the device.

Does it perform a medical function on its own?

If the software analyses data and produces information used to diagnose, treat, monitor or manage a condition, and does not need a particular hardware device to do so, it is likely SaMD, and it is classified in its own right.

How are SaMD and SiMD classified?

SiMD inherits the classification of the device it runs in. SaMD is classified on its own, mainly by how much its output matters and how serious the patient's condition is.

The IMDRF risk framework for SaMD combines two factors: the state of the healthcare situation (critical, serious or non-serious) and the significance of the information the software provides (treat or diagnose, drive clinical management, or inform clinical management). The result is a category from I (lowest impact) to IV (highest):

Healthcare situation	Treat or diagnose	Drive clinical management	Inform clinical management
Critical	IV	III	II
Serious	III	II	I
Non-serious	II	I	I

The IMDRF categories are a shared framework, not a legal class. Each regulator applies its own rules:

EU (MDR): Rule 11 classifies software that provides information used for diagnostic or therapeutic decisions as Class IIa, rising to IIb or III where a wrong decision could cause serious deterioration or death. Software that monitors physiological processes is IIa, or IIb for vital parameters where changes could create immediate danger. Other software is Class I. Independent software is classified in its own right; software that drives a device takes the device's class.
US (FDA): software is classified as Class I, II or III through the same device classification system as hardware, usually by matching an existing device type, and the premarket pathway follows from that.

What changes for engineering?

The category affects how you design the software, not only how you file it.

SiMD: you own the whole stack

With SiMD you control the hardware, the processor and the software. That makes some things easier (a known, fixed platform) and some harder:

Hardware and software risk are analysed together. A sensor fault, a brown-out or a stuck motor must be detected and handled in software, so fault handling, watchdogs and safe states are designed early.
Timing is a safety property. Alarm latency, control loop timing and sampling rates need to be specified, measured and tested on the real hardware, which often points to an RTOS or bare-metal design for the critical path.
Partitioning reduces risk. Keeping the safety-critical functions (dosing, alarms, control) separate from connectivity, user interface and logging, on a separate core, a separate MCU or a protected memory region, limits what a bug or an attack in the non-critical code can reach.
Every third-party component counts. RTOS, Bluetooth stack, cryptographic libraries and vendor SDKs all become part of the device and must be listed, assessed and kept patched.

SaMD: you do not own the platform

SaMD runs on phones, browsers and cloud services you do not control:

Operating system and browser updates arrive on someone else's schedule. Plan to test against new iOS and Android releases before they reach patients, and define the supported versions.
The algorithm is the product. Data quality, model or algorithm performance across patient groups, and clear presentation of results carry most of the risk.
Data integrity end to end. Readings arrive from sensors, phones and networks; the software must detect missing, duplicated or out-of-order data, and never show a stale value as current.
Cloud availability is a design input. Decide what happens when the server is unreachable, and whether any function must work offline.

Connected products: draw the boundaries on purpose

A typical connected medical product has three parts: firmware on the device, a companion app and a cloud back end. A common and sensible pattern is to keep the safety-critical medical function on the device or in one clearly bounded software item, and keep the app and cloud as thin as the product allows. If the app only relays and displays data, it may not need to be a medical device at all. If the app analyses the data, it may become SaMD with its own classification and evidence. The choice should be made by the product, clinical and regulatory team together, before the architecture is fixed, because moving a function across that boundary later is expensive.

What changes for testing?

SiMD testing proves that hardware and software work safely together; SaMD testing proves that the software's output is accurate and reliable across the conditions it will meet.

SiMD: unit tests on host and target, integration tests on real boards, hardware-in-the-loop rigs that inject sensor signals and faults, timing and alarm latency measurements, power-loss and brown-out tests, and tests across temperature and supply voltage. Electrical safety and EMC testing apply to the device as a whole.
SaMD: algorithm verification against reference data sets, performance across devices, operating system versions and network conditions, clinical evaluation of the output, usability testing of how results are presented, and security testing of the app, APIs and cloud.
Both: requirements traced to tests, regression testing on every release, and risk controls verified rather than assumed.

What changes for software updates?

SaMD can usually be released through app stores or cloud deployments; SiMD needs a firmware update path designed into the device, with secure boot, signed images and rollback. In both cases, a change to medical device software has to be assessed before release.

Assess every change. The FDA has published guidance on deciding when a software change, explicitly including firmware, needs a new 510(k). The IMDRF notes that SaMD changes include defect fixes, performance and usability improvements and security patches. Plan time for change assessment in every release, not only for major versions.
SiMD updates are harder to roll out. Devices may be in hospitals, homes or patients' bodies, with limited connectivity and no tolerance for a failed update mid-therapy. A safe OTA design checks battery and device state, never interrupts therapy, verifies the image signature before installing and can fall back to the previous version. See our guide to OTA and FOTA updates for the mechanics.
SaMD updates are easier to ship, and easier to ship by mistake. Cloud releases reach every user at once, so use staged rollouts, version pinning for API clients (including device firmware) and a fast rollback.
Keep versions compatible. In a connected product, firmware, app and cloud are released on different schedules. Define which combinations are supported, and make each side reject or safely handle versions it does not support.

What about cybersecurity?

In the US, a "cyber device" (a device that includes software, can connect to the internet directly or indirectly, and could be vulnerable to cyber threats) must come with a plan to monitor and address post-market vulnerabilities, a process for timely updates and patches, and a software bill of materials (SBOM). This is section 524B of the Federal Food, Drug, and Cosmetic Act. It applies to SiMD and SaMD alike, so a connected device with Bluetooth firmware and a companion app needs both parts covered.

For the engineering side of this, including secure boot, device identity and remote lock, see our post on device anti-theft: remote lock, wipe and kill switch. Medical device cybersecurity rules are being updated in several markets, so check the current FDA and EU expectations when you plan a submission.

Common SaMD and SiMD mistakes

Classifying the product instead of each software item. Firmware, app and cloud can fall into different categories.
Letting the app grow a medical function by accident. A "simple" trend chart that starts flagging abnormal readings can change the app's status.
Designing firmware without an update path. Devices without secure, recoverable OTA are hard to patch when a vulnerability or defect is found.
Treating cloud and app updates as routine web releases. If the software is a medical device, each release needs change assessment and regression testing.
Ignoring third-party components. Open-source libraries and vendor SDKs must be tracked in the SBOM and patched for the life of the device.
Leaving the regulatory conversation until the end. Category, classification and evidence needs shape the architecture, so settle them early.

SaMD and SiMD: frequently asked questions

What is the difference between SaMD and SiMD? SaMD is software that performs a medical purpose on its own, on general-purpose computers, phones or the cloud. SiMD is software that is part of a hardware medical device and is needed for it to work, such as the firmware in an infusion pump or a patient monitor.

What does SaMD stand for? SaMD stands for software as a medical device. The term was defined by the International Medical Device Regulators Forum and is used by the FDA and other regulators. (SAMD is also the name of a family of microcontrollers; that is unrelated.)

What is an example of software in a medical device? Firmware that controls a blood pressure cuff and calculates the reading, dosing software in an insulin pump, the sensing and pacing logic in a pacemaker, and the alarm software on a bedside monitor are all examples of SiMD.

Can a mobile app be a medical device? Yes. A mobile app that meets the SaMD definition, for example one that analyses data to detect or monitor a condition, is SaMD. An app that only transfers, stores or displays device data without analysing it may not be a device in the US. An app that controls a medical device is regulated as part of that device.

Can one product contain both SaMD and SiMD? Yes. A wearable cardiac monitor may run firmware on the patch (SiMD) and send data to an app that analyses it and flags arrhythmias (SaMD). Each software item is assessed separately, even though they work together.

Is SiMD classified separately from the device? Generally no. Software that drives or influences a hardware device is regulated as part of that device and takes its classification. SaMD, by contrast, is classified in its own right.

Building connected medical device software?

akranIQ engineers the firmware, embedded software, companion apps, cloud back ends and secure OTA paths for connected medical products, and works alongside your regulatory and quality team so the architecture supports the classification you need. To discuss a device or a software split, talk to our engineering team or see our medical device software services.

SaMD vs SiMD: Software as a Medical Device vs Software in a Medical Device