--- title: SaMD vs. Software in a Medical Device (SiMD): The Critical Distinction Under MDR description: SaMD is standalone software that is itself a medical device. SiMD drives a hardware device. The distinction changes classification and lifecycle. Here is how to tell them apart. authors: Tibor Zechmeister, Felix Lenhard category: Software as a Medical Device primary_keyword: SaMD vs SiMD canonical_url: https://zechmeister-solutions.com/en/blog/samd-vs-simd-distinction source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # SaMD vs. Software in a Medical Device (SiMD): The Critical Distinction Under MDR *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Software as a Medical Device (SaMD) is software that performs one or more medical functions on its own, without being part of a physical medical device. Software in a Medical Device (SiMD) is software that is an integral part of a hardware medical device and either drives or influences its use. The MDR classifies SaMD on its own under Annex VIII Rule 11; SiMD inherits the class of its parent device. That single line determines who owns the regulatory file, how conformity assessment runs, and how the software lifecycle obligations land. Both categories must meet MDR Annex I Section 17, and both typically use EN 62304:2006+A1:2015 — but the scope of the lifecycle work differs sharply.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - SaMD runs independently of any physical device. SiMD is part of a hardware device and cannot be separated from it in the regulatory sense. - SaMD is classified on its own under Annex VIII Rule 11 of Regulation (EU) 2017/745. SiMD inherits the classification of the hardware device it drives or influences. - MDCG 2019-11 Rev.1 (June 2025) is the definitive guidance for deciding which category a given piece of software belongs to and how the classification follows. - EN 62304:2006+A1:2015 applies to both SaMD and SiMD, but the scope, the QMS boundary, and the ownership of the technical documentation differ. - The most expensive mistake in this category is treating a piece of software that is actually SaMD as if it were SiMD — or the reverse — and only discovering the error when the Notified Body reads the technical file. --- ## Why this distinction is not a vocabulary question Founders usually meet the SaMD/SiMD split as a definitional footnote in a slide deck and move on. That is a mistake. The distinction is where the MDR decides three things at once: who the manufacturer is for regulatory purposes, which classification rule applies, and how the technical documentation is structured. All three decisions cascade into months of engineering and regulatory work. Get the category wrong and the cascade runs the wrong direction. We have seen the failure mode twice in the last year. In one case, a startup building an image-processing library assumed it was SiMD because its first customer was a scanner manufacturer who would integrate it. The library was actually sold separately to several customers, carried its own intended purpose, and met Article 2(1) on its own — it was SaMD, and the startup needed its own QMS, its own technical file, and its own conformity assessment. In the other case, a ventilator manufacturer built a remote-monitoring dashboard as an "add-on" and treated it as part of the ventilator's technical file. The dashboard had its own intended purpose (alerting clinicians to physiological parameter trends), ran on separate hardware, and was placed on the market under its own SKU. It was SaMD, not SiMD, and the ventilator file did not cover it. Both errors were correctable — but only after rework that could have been avoided by answering the SaMD/SiMD question on day one, in writing, with MDCG 2019-11 Rev.1 open on the desk. ## What SaMD is under the MDR The MDR text does not use the acronym "SaMD" at all. "SaMD" is the IMDRF term. The MDR and MDCG 2019-11 Rev.1 use "Medical Device Software" (MDSW). Within MDSW, the MDCG guidance distinguishes between software that is a medical device in its own right (what IMDRF calls SaMD) and software that drives or influences the use of a hardware medical device (SiMD). SaMD, in this sense, is software whose medical function is the software itself. It runs on general-purpose computing hardware — a phone, a tablet, a cloud server, a hospital workstation — and the medical purpose is delivered by the code, not by any dedicated physical instrument it controls. A diagnostic algorithm that ingests imaging data from any DICOM-compliant source is SaMD. A clinical decision-support platform that takes EHR data and returns a risk score is SaMD. A mobile application that interprets user-uploaded ECG strips is SaMD. In each case, the software qualifies under Article 2(1) on its own terms, and the manufacturer is the entity that places the software on the market. The foundation is Article 2(1): > *"'medical device' means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes..."* — Regulation (EU) 2017/745, Article 2, point 1. Software is named explicitly. If the software alone meets the intended-purpose test, it is a medical device — and if it is not physically part of another device, it is SaMD. ## What SiMD is under the MDR Software in a Medical Device is software that is an integral part of a hardware device and cannot be separated from it without compromising the device's intended function. The firmware inside an infusion pump. The control software on a ventilator. The embedded image-processing pipeline inside a CT scanner. The motor-control firmware inside a surgical robot. In each case, the software is essential to the hardware device's medical function, but it does not have a standalone intended purpose that would make it a medical device on its own. MDCG 2019-11 Rev.1 frames this as software that "drives or influences the use" of a hardware medical device. The phrase is load-bearing. If the software's role is to make the hardware device do what it is supposed to do — run the pump at the prescribed rate, deliver the prescribed breath pattern, process the raw sensor data into the image the device is designed to produce — then the software is SiMD, and the device is the hardware plus its embedded software taken as a single regulatory object. SiMD is not separately classified under Rule 11. It inherits the classification of the parent hardware device, whichever classification rule applies to that device. The firmware of a Class IIb infusion pump is, for MDR classification purposes, Class IIb. It is not classified again under Rule 11. ## How the two categories are qualified differently The qualification question — "is this software a medical device?" — runs through the MDCG 2019-11 Rev.1 decision tree the same way for both categories at the start. The software has to meet Article 2(1), and its intended purpose has to cross the "more than storage, archival, communication, or simple search" action threshold. The fork appears at the next step. If the software has its own intended purpose that meets Article 2(1) and runs independently of any hardware medical device, it is SaMD. If the software is essential to the functioning of a hardware medical device and does not have a standalone medical intended purpose separate from that hardware device, it is SiMD — and it is regulated as part of the hardware device. Two questions decide the fork reliably in practice. First: can the software be placed on the market separately from the hardware, with its own SKU, its own labelling, and its own intended purpose? If yes, it is SaMD even if it is usually bundled. Second: does the software have a medical intended purpose that is distinct from simply making the hardware work? If yes, it is SaMD even if it is physically embedded in the hardware at the time of sale. MDCG 2019-11 Rev.1 walks through several worked examples of this fork, including cases where the same underlying code is SaMD in one deployment and SiMD in another depending on how it is placed on the market. The guidance is the reference — post 374 covers it in depth. ## How classification consequences differ This is where the distinction becomes a cost driver. SaMD is classified on its own terms under Annex VIII Rule 11. For most medical software, Rule 11 pushes the class to IIa at minimum, with IIb and III reserved for higher-stakes decision-support software. Rule 11 is covered in detail in posts 081, 085, and 086. SiMD inherits the class of the parent hardware device, and the classification rule that applies is whichever Annex VIII rule fits the hardware — typically Rules 9 through 13 for active devices, Rules 1 through 8 for non-invasive and invasive devices. The firmware of a Class I non-invasive reusable instrument is Class I. The firmware of a Class III implantable is Class III. Rule 11 does not apply. The practical consequence is that the same underlying code can sit at very different classes depending on how it is placed on the market. An algorithm that analyses physiological data could be Class IIa under Rule 11 as SaMD, or it could be part of a Class IIb parent device as SiMD, or part of a Class III parent device as SiMD — with the same algorithm. The conformity assessment route, the Notified Body involvement, and the clinical evaluation scope all follow from the class, not from the code. ## How the lifecycle implications differ — EN 62304:2006+A1:2015 applies either way, but the scope differs Both SaMD and SiMD fall under MDR Annex I Section 17, which requires that software be developed in accordance with the state of the art, taking into account the principles of development life cycle, risk management including information security, verification, and validation. EN 62304:2006+A1:2015 is the harmonised standard that provides presumption of conformity with those software-lifecycle aspects for both categories. The standard itself does not distinguish between SaMD and SiMD; it defines software lifecycle processes and software safety classes (A, B, C) that apply to any medical device software. What differs is the scope and the ownership of the lifecycle work. For SaMD, the manufacturer of the software carries the entire weight of EN 62304:2006+A1:2015 compliance on the software alone. The software is the device. The QMS, the technical documentation, the risk management file, the clinical evaluation, the post-market surveillance plan, and the vigilance obligations all attach to the software company as the manufacturer. The EN 62304:2006+A1:2015 software safety class is determined at the level of the software as a whole and drives the lifecycle activities for the entire product. For SiMD, EN 62304:2006+A1:2015 still applies — but as one component of the hardware device's technical file. The hardware manufacturer owns the overall QMS and technical documentation, and the software lifecycle is a section within that larger file. The EN 62304:2006+A1:2015 software safety class is still determined, but the determination accounts for the external risk controls that the hardware device provides. A software item that would be Class C on its own can sometimes be Class B inside a hardware device that adds a mechanical safety interlock — because the standard explicitly allows hardware risk controls to be credited. The boundary between the two cases also changes who audits what. A Notified Body auditing a SaMD manufacturer audits the software lifecycle directly against the QMS. A Notified Body auditing a hardware manufacturer audits the software lifecycle as part of the hardware device audit. For a startup that builds a component intended to be integrated into other manufacturers' hardware devices, the question of who owns the EN 62304:2006+A1:2015 file for that component is a contractual and regulatory question that has to be answered in writing before the software ships. ## Common confusions **"We run on a physical device, so we must be SiMD."** Running on dedicated hardware is not the test. The test is whether the software has its own medical intended purpose and whether it can be placed on the market separately. A diagnostic app that ships pre-installed on a bundled tablet is still SaMD if the tablet is general-purpose computing hardware and the app is licensed separately. **"Our customer is a device manufacturer, so we are SiMD."** Selling to a device manufacturer does not make your software part of their device. If your software is licensed separately, carries its own intended purpose, and could be used by other integrators, it is SaMD. The customer relationship is a commercial fact; the regulatory classification follows the placement on the market, not the customer list. **"The firmware we write is SaMD because we are a software company."** Firmware embedded in a hardware device and essential to its function is SiMD, regardless of whether the team that wrote it calls itself a software company or a firmware team. The regulatory category is determined by how the software meets the Article 2(1) definition, not by the org chart. **"Our add-on dashboard is part of the parent device, so it is SiMD."** If the dashboard is placed on the market separately, runs on separate hardware, and has its own intended purpose (alerting, monitoring, analytics), it is SaMD — even if it only works when paired with the parent device. The fact that SaMD can depend on a hardware device for its data source does not make it SiMD. **"We are SaMD and SiMD at the same time, so both rules apply."** A single piece of software is one or the other for a given placement on the market. If the same underlying code is placed on the market in two different ways — for example, embedded in a hardware device from one manufacturer and licensed separately to another — then there are two regulatory objects, and each is qualified and classified separately. ## Concrete examples - **SaMD** — A cloud-based ECG interpretation service that ingests traces from any compatible device and returns annotated results. Placed on the market by the software company under its own intended purpose. Classified under Rule 11. - **SaMD** — A mobile application that uses the phone's camera to analyse skin lesions and return a risk category. General-purpose hardware, standalone medical intended purpose. Classified under Rule 11. - **SiMD** — The closed-loop control software inside an insulin pump that reads CGM data and adjusts dosing. Essential to the pump's function, embedded in the pump, inherits the pump's class. - **SiMD** — The image-acquisition firmware inside an ultrasound scanner. Without it the scanner does not function; it is part of the scanner's regulatory object. - **SaMD, not SiMD** — A remote-monitoring dashboard for ventilators that pulls telemetry from the ventilator and alerts clinicians to parameter trends. Separate SKU, separate intended purpose, runs on hospital IT. Even though it depends on a ventilator for its data, it is SaMD on its own. - **SiMD, not SaMD** — A configuration utility that a ventilator manufacturer ships with the device and uses only to configure settings at installation. No standalone medical intended purpose. Part of the ventilator's regulatory object. ## The Subtract to Ship angle The SaMD/SiMD distinction is one of the highest-leverage decisions a medical software team makes, and it is also one of the cheapest to get right — if it is made early. The Subtract to Ship discipline here is to answer the question once, in writing, before the team commits to an architecture that forces the answer the wrong way. Three questions make the answer concrete. Will this software be placed on the market with its own SKU, label, and intended purpose? Can the software be used with hardware devices from multiple manufacturers, or is it exclusively tied to one? Does the software have a medical intended purpose that survives without the hardware — or does the hardware supply the purpose and the software just drives it? Answers to those three questions resolve the SaMD/SiMD split for most real products. What Subtract to Ship subtracts here is ambiguity. A product that is "either SaMD or SiMD depending on who you ask" is a product whose regulatory file cannot be written, because the foundation is undefined. The framework that applies is the MDR itself, via Article 2(1) and Annex VIII Rule 11, operationalised through MDCG 2019-11 Rev.1. Post 065 covers the full Subtract to Ship framework as applied to MDR; this post is a specific application of the same discipline to one of the most common category traps in medical software. ## Reality Check — Where do you stand on your SaMD/SiMD categorisation? 1. Have you written down, in one paragraph, whether your software is SaMD or SiMD under MDCG 2019-11 Rev.1? 2. If SaMD, can you state the standalone medical intended purpose that justifies that categorisation? 3. If SiMD, can you name the parent hardware device and confirm your software does not have a separate intended purpose on its own? 4. Have you confirmed how your software is placed on the market — separate SKU, bundled, or embedded — and documented the placement consistently across marketing, contracts, and labelling? 5. If your software could be used with multiple hardware devices from different manufacturers, have you treated that as a signal that it is SaMD, not SiMD? 6. Have you agreed, in writing, with any hardware partner about who owns the EN 62304:2006+A1:2015 file for the software component? 7. Is your classification argument — Rule 11 for SaMD, or inherited class for SiMD — consistent with the technical documentation you plan to build? Any question you cannot answer clearly is a category-definition gap. Close it before the Notified Body finds it. ## Frequently Asked Questions **Is SaMD always a higher class than SiMD?** No. The class depends on the applicable rule. SaMD under Rule 11 is frequently Class IIa or higher, but an SiMD component inside a Class III implantable is Class III. There is no rule that SaMD is systematically higher or lower than SiMD — the class follows the regulatory object the software belongs to. **Can the same code be both SaMD and SiMD?** Not for a single placement on the market. A single regulatory object is one or the other. But if the same underlying code is placed on the market twice — once embedded in a hardware device and once as a standalone product — then there are two regulatory objects, and each is qualified and classified separately. MDCG 2019-11 Rev.1 addresses this case. **Does EN 62304:2006+A1:2015 apply to SiMD as well as SaMD?** Yes. EN 62304:2006+A1:2015 is the harmonised standard for medical device software lifecycle processes, and it applies to any software that is part of a medical device — embedded firmware, control software, or standalone SaMD. The difference is whose QMS and technical file the lifecycle documentation lives in. **If my software runs on a phone, is it automatically SaMD?** Almost always yes, because a phone is general-purpose computing hardware, not a medical device. A mobile application with a medical intended purpose that runs on a general-purpose phone is SaMD, classified under Rule 11. **If my SiMD component is placed on the market as a standalone library for integrators, does it become SaMD?** If it is placed on the market separately, with its own intended purpose, then yes — it is SaMD, and the library's manufacturer becomes the medical device manufacturer for that placement. This is one of the most common categorisation traps for software-component businesses. **Who verifies the SaMD/SiMD categorisation — the manufacturer or the Notified Body?** The manufacturer makes the determination and documents it. The Notified Body reviews the determination as part of the conformity assessment and can challenge it. A categorisation that is not defensible under MDCG 2019-11 Rev.1 will be challenged. The safest approach is to build the argument as if a skeptical Notified Body will read it — because one will. ## Related reading - [What Is Software as a Medical Device (SaMD)?](/blog/what-is-software-as-medical-device-samd-mdr) — the pillar post for this category, which this post supports. - [When Does Software Qualify as a Medical Device?](/blog/when-does-software-qualify-medical-device) — the Article 2(1) qualification question that precedes the SaMD/SiMD split. - [MDCG 2019-11 Rev.1 — What the Software Guidance Actually Says](/blog/mdcg-2019-11-software-guidance) — the definitive guidance document that operationalises this distinction. - [MDR Classification Rule 11 for Software — The Short Version](/blog/mdr-classification-rule-11-software) — the entry-level spoke on the rule that classifies SaMD. - [MDR Classification Rule 11 for Software — The Deep Dive](/blog/mdr-classification-software-rule-11-deep-dive) — the advanced treatment of Rule 11 for SaMD. - [Rule 11 Borderline Cases](/blog/rule-11-borderline-cases) — edge cases where the SaMD/SiMD split decides the class. - [The MDR Software Lifecycle and EN 62304:2006+A1:2015](/blog/mdr-software-lifecycle-iec-62304) — the lifecycle obligations that apply to both SaMD and SiMD. - [EN 62304:2006+A1:2015 Software Safety Classification A, B, C](/blog/software-safety-classification-iec-62304) — the software safety class, distinct from the MDR device class, applied to both categories. - [Embedded Medical Device Software — The SiMD Lifecycle](/blog/embedded-medical-device-software-simd) — the SiMD-specific lifecycle deep dive. - [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology pillar that frames how to make this category decision efficiently. ## Sources 1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2, point 1; Annex VIII, Rule 11. Official Journal L 117, 5.5.2017. 2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025. 3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). --- *This post is part of the Software as a Medical Device Under MDR category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — MDCG 2019-11 Rev.1 operationalises Article 2(1) and Annex VIII Rule 11 for software, and EN 62304:2006+A1:2015 is the tool that provides presumption of conformity with the software-lifecycle requirements of MDR Annex I Section 17, not an independent authority. For startup-specific regulatory support on SaMD and SiMD categorisation, Zechmeister Strategic Solutions is where this work is done in practice.* --- *This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*