Where the two terms actually come from
Software as a Medical Device is an IMDRF term. The IMDRF formed its SaMD working group in 2013, chaired by the FDA, and defined SaMD as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. The important half of that definition is the last clause. Software does not meet the SaMD definition if its intended purpose is to drive a hardware device.
Software in a Medical Device is the informal counterpart, used by the FDA and widely across industry to describe software that is embedded in, or drives, a piece of hardware. It is useful shorthand. It is not a defined term in the MDR.
What the MDR and its guidance actually use is MDSW, medical device software. And the MDR deliberately dropped the old directive-era term standalone software, on the rationale that software should be qualified and classified on its intended purpose alone, regardless of where it happens to run. That is a deliberate design choice, and it is why arguing about SaMD versus SiMD does not, by itself, get you to a regulatory answer.
The question the MDR actually asks
MDCG 2019-11 is explicit that the plumbing is irrelevant to qualification. The type of interconnection between the software and the device, whether that is an embedded system, a wire, Wi-Fi or Bluetooth, does not affect whether the software qualifies as a device, and nor does whether the software is incorporated in the device or sits somewhere else entirely.
What does matter is how the software is placed on the market. The guidance sets out two routes: software placed on the market as a medical device in its own right, or software placed on the market as an integral component or part of a hardware device. That single distinction, not the SaMD or SiMD label, is what drives the regulatory consequences.
One nuance worth holding onto, because it trips people up: the guidance notes that software can be technically independent under both routes, despite the form in which it reaches the market. Independence of the code is not the test. The test is what you place on the market, and what you claim it is for.
Route one: placed on the market in its own right
Here the software is the product. It has its own intended purpose, it is classified on that purpose under Rule 11, it goes through its own conformity assessment, and it carries its own CE marking. The guidance is direct about the obligation: software placed on the market or put into service in its own right must undergo an appropriate regulatory process that takes account of its qualification, its classification and its intended purpose.
The guidance's own examples of this route are instructive because they are not all phone apps. They include an app that calculates anticoagulant dosage from INR results, an app that produces a ten year cardiovascular risk score from user-entered data, and software installed on a fully automated analyser to determine a concentration in serum from that analyser's results. That last one matters: software can run on someone else's instrument and still be placed on the market in its own right.
Route two: placed on the market as an integral part of a device
Here the software reaches the market inside the product, as a component of it. The consequence is significant, and the guidance states it plainly: software placed on the market or put into service solely as an integral component or part of a hardware device may not have to undergo its own regulatory process. Instead it is assessed through the regulatory process applied to the device as a whole, as that device is placed on the market.
Again the guidance's examples are concrete: software contained within a blood gas analyser that lets a user run tests on the instrument, software forming part of a handheld point of care device for determining blood glucose, and software inside a pulse oximeter that filters noise from low perfusion and motion artefacts and converts a light ratio into a blood oxygen saturation value.
The word doing the work in that sentence is solely. If the same software is also made available separately, or is marketed as achieving its own medical purpose, you are no longer cleanly on this route.
| In its own right | As an integral component or part | |
|---|---|---|
| Industry shorthand | SaMD | SiMD |
| What the MDR calls it | MDSW placed on the market in its own right | MDSW placed on the market as part of a device |
| Conformity assessment | Its own, based on its own intended purpose | Assessed through the process applied to the whole device |
| CE marking | Carries its own | Covered by the device's marking |
| Classification | Rule 11, on the software's own intended purpose | The class of the combination, and never below the hardware's class where the software drives it |
| Guidance example | An app calculating anticoagulant dosage from INR results | Software inside a pulse oximeter converting a light ratio into SpO2 |
Embedding is not a shortcut
The most common commercial hope is that shipping an algorithm inside a partner's hardware makes the regulatory problem someone else's, and lands the whole thing in a lower class. Three provisions make that hope unreliable.
First, implementing rule 3.3. Software that both achieves its own intended purpose and drives or influences the use of a hardware device is classified on its own, based on the purpose it achieves, and its class may not be lower than the class of that hardware device. Embedding sets a floor, not a ceiling. Implementing rule 3.5 then means that where several rules or sub-rules apply, the strictest wins.
Second, the classification of the combination is not automatic. The guidance warns that applying the classification rules to what is, in effect, a combination of hardware and software requires careful consideration of the intended purpose of the software, and that this has to be analysed again whenever the software later changes.
Third, Article 23(2) of the MDR. An item intended specifically to replace a part or component of a device, where it significantly changes the performance or safety characteristics or the intended purpose of that device, is itself considered a device and has to meet the requirements of the regulation in its own right. Replacing a hardware component with a smarter algorithm is exactly the fact pattern that provision describes.
Modules: when your product is only partly a device
Most real products are not uniformly medical. A platform might combine scheduling, billing, records and one clinical decision function. The guidance handles this through modules: the modules that fall under the medical device regulations must comply and must carry the CE marking, and the modules that do not are not subject to those requirements.
The obligation that follows is easy to underestimate. It is the manufacturer's job to identify the boundaries and the interfaces between those modules, and to do so on the basis of intended use. If the regulated modules are intended to be used in combination with the unregulated ones, or with other devices or equipment, the whole combination including the connection system must be safe and must not impair the performance of the regulated modules.
In practice this is an architecture question as much as a regulatory one. Teams that draw those boundaries deliberately, early, keep the regulated surface small. Teams that do not usually discover that the regulated surface is the entire product.
Your answer is not frozen
Both qualification and classification can move. The guidance requires manufacturers to evaluate the potential impact of any change to the function, the intended use, the essential design or the manufacturing characteristics on whether the software still qualifies as MDSW and on how it is classified, including how the combination of the software with another device is classified.
Two specific traps are called out. Adding functionality can cause software that was previously outside the regulations to qualify as MDSW, or move it up a class. And a module added to an existing product might qualify as MDSW in its own right, even though the product around it did not change.
That is why the classification rationale is a living document rather than a one-off memo. Feature work changes regulatory status more often than most teams expect.
What this means commercially
If you are building an algorithm to sit inside an OEM's device, the questions to settle before signing are not really technical. Whose CE certificate covers the software, who owns the intended purpose statement, what happens to that certificate when you ship a model update, and who carries the cost and the delay if a change forces a reassessment of the combination.
One thing does not change between the two routes. IEC 62304 governs the software lifecycle either way, and your quality system obligations under ISO 13485 do not disappear because your code ships inside someone else's box. What changes is who holds the certificate, whose process you sit inside, and how much control you retain over your own release cadence.
- Decide the route to market first, because it drives everything downstream
- Do not assume embedding lowers the class; implementing rule 3.3 sets a floor
- Check Article 23(2) if your software replaces a hardware part or component
- Draw module boundaries deliberately, and document the interfaces
- Re-run qualification and classification on every material change, including model updates
- In OEM deals, settle certificate ownership and change control in the contract