Introduction
As digital health continues to evolve, software plays a critical role in modern medical devices. However, not all medical software is regulated the same way. Understanding the difference between Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD) is essential for defining the right regulatory strategy, documentation approach, and approval pathway.
Importantly, SaMD and SiMD are not always isolated systems. In modern medical device ecosystems, SaMD can interface directly with SiMD — creating hybrid configurations that carry their own regulatory implications. Understanding how these software types interact is just as critical as understanding their individual definitions.
What is SaMD?
Software as a Medical Device (SaMD) refers to software that performs a medical function independently, without being part of a physical medical device.
Key Characteristics:
- Operates as a standalone product
- Runs on general platforms (mobile, cloud, desktop)
- Performs functions like diagnosis, monitoring, or clinical decision support
- Can interface with hardware medical devices and other SaMD
Examples:
- AI-based diagnostic applications
- Mobile health monitoring apps
- Cloud-based imaging analysis tools
What is SiMD?
Software in a Medical Device (SiMD) refers to software that is embedded within a medical device and is necessary for its operation.
Key Characteristics:
- Dependent on hardware
- Integral to device functionality and safety
- Cannot operate independently
- May receive inputs or commands from SaMD systems
Examples:
- Infusion pump control software
- Embedded systems in MRI machines
- Firmware in wearable medical devices
SaMD Can Interface with SiMD — And It Matters Regulatory
One of the most important — and often misunderstood — aspects of the SaMD definition is that SaMD is not required to operate in isolation. According to the IMDRF SaMD framework (N10), SaMD may be:
- Used in combination (e.g., as a module) with other products including medical devices
- Interfaced with other medical devices, including hardware medical devices and other SaMD software
- Deployed as mobile apps that connect to, read from, or control a hardware device
This means a smartphone app that connects to an insulin pump to read glucose values and adjust dosing — while running on a general-purpose platform — can still qualify as SaMD, even though it interacts with SiMD embedded in the pump. The regulatory classification of each software component is assessed independently, based on its own intended purpose, not the system it connects to.
Key Principle
- When SaMD interfaces with SiMD, both components retain their own regulatory identity.
- The SaMD is regulated based on its standalone medical purpose (e.g., under FDA Digital Health framework or EU MDR Rule 11).
- The SiMD follows the classification of its parent hardware device (e.g., under 21 CFR Part 820 or EU MDR Implementing Rule 3.3).
Neither component ‘inherits’ the classification of the other — though both must address interoperability and cybersecurity.
Practical Examples: SaMD, SiMD, and Their Interfaces
The following examples illustrate how SaMD and SiMD operate — both independently and when interfaced together.
Example 1: Insulin Pump with Mobile Bolus Calculator App
An insulin pump contains embedded firmware that controls the infusion rate of insulin — this is SiMD. Its regulatory class under EU MDR is Class IIb (per Rule 12, as it delivers fluid into the body in a hazardous way). The embedded software has no independent medical purpose of its own; it simply drives the pump hardware.
Now add a mobile app that connects to the pump via Bluetooth. The app calculates the appropriate insulin bolus based on the patient’s current blood glucose reading and medical history, and sends a dosing recommendation. Because the app has its own standalone medical intended purpose (calculating and guiding insulin dosing), it qualifies as SaMD — regulated independently under Rule 11 (EU MDR) as Class IIb (Serious healthcare situation, High significance). Both components interface with each other, but each carries its own regulatory classification.
Example 2: AI Imaging Analysis Software Interfacing with an MRI Machine
An MRI machine contains complex SiMD — firmware that controls the magnetic gradients, sequences, and raw signal acquisition. This embedded software is classified as part of the hardware device (typically Class IIb or III depending on intended use).
A cloud-based AI platform that receives DICOM images from the MRI machine and performs automated analysis (e.g., detecting brain tumors or flagging anomalies for radiologist review) operates as SaMD. It runs on general infrastructure, has its own medical intended purpose (aiding diagnosis), and is assessed independently under the FDA Digital Health framework or EU MDR Rule 11. The MRI sends data to the AI platform — an SiMD-to-SaMD interface — but the regulatory pathways remain distinct.
Example 3: Remote Cardiac Monitoring App with Wearable Device
A wearable ECG patch contains embedded firmware (SiMD) that continuously captures cardiac signals and transmits data. The patch itself may be classified as a Class II or III device depending on its intended use.
A companion mobile app that receives the transmitted ECG signals, analyzes them for arrhythmias such as atrial fibrillation, and provides alerts to both the patient and their cardiologist qualifies as SaMD. The app runs on a general-purpose smartphone, performs an independent diagnostic function, and must be submitted to regulators under its own pathway (e.g., De Novo or 510(k) in the US; CE marking under Rule 11 in Europe). Cybersecurity and interoperability controls must be addressed for both the wearable firmware and the companion SaMD application.
SaMD vs SiMD: Key Differences
| Parameter | SaMD (Software as a Medical Device) | SiMD (Software in a Medical Device) |
| Definition | Standalone software performing a medical function | Software embedded within a medical device |
| Dependency | Independent of hardware | Dependent on physical device |
| Functionality | Performs medical purpose on its own | Supports or controls device operation |
| Regulatory Approach | Regulated as a separate product | Regulated as part of the device |
| Risk Classification | Based on software function and clinical impact | Based on overall device classification |
| Updates & Changes | Frequent updates requiring lifecycle management | Controlled through device change control |
| Validation Scope | Software-focused validation | System-level validation (hardware + software) |
| Examples | AI diagnostic tools, digital therapeutics | Pacemaker software, imaging device firmware |
| SaMD-SiMD Interfacing | Can interface with SiMD (e.g. app controlling a pump) | Can be controlled by SaMD via standardized protocols |
Regulatory Comparison: SaMD vs SiMD
FDA (US) Perspective
From an FDA standpoint, SaMD and SiMD follow fundamentally different regulatory approaches. SaMD is governed under the FDA’s Digital Health framework, where it is treated as a standalone medical product. Its classification is based on a risk-based model (Class I, II, or III) depending on the intended use and potential impact on patient health. In many cases, SaMD may require an independent regulatory submission, along with dedicated clinical evaluation, software validation, and cybersecurity controls. The testing scope is largely focused on the software itself, including functionality, performance, and risk mitigation.
In contrast, SiMD is not evaluated independently but as part of the overall medical device. It falls under 21 CFR Part 820 (now transitioning to QMSR) and is included within traditional regulatory pathways such as 510(k), PMA, or De Novo submissions. The classification of SiMD is determined by the device it is integrated into, not the software alone. Requirements such as clinical evaluation, validation, and cybersecurity are addressed at a system level, meaning both hardware and software must be tested together.
When SaMD interfaces with a hardware device containing SiMD, the FDA’s guidance emphasizes that each component must address interoperability risks and that cybersecurity is a shared responsibility across the interface.
EU MDR (Europe) Perspective
Under the EU MDR framework, the distinction between SaMD and SiMD is equally significant, particularly due to classification rules and compliance expectations. SaMD is typically classified under Rule 11, which has resulted in many software products being placed into higher risk classes (Class IIa, IIb, or even III). SaMD is almost always subject to Notified Body involvement, requiring clinical evaluation, post-market surveillance, and comprehensive technical documentation. SaMD must comply with standards such as IEC 62304 for software lifecycle processes and meet the General Safety and Performance Requirements (GSPR) independently.
SiMD follows the classification of its parent device under Implementing Rule 3.3, meaning its regulatory burden is directly tied to the device it supports. While standards like IEC 62304 still apply, they are implemented within the broader context of device compliance. CE marking is granted based on the complete device certification, not the software in isolation.
For interfacing configurations — where SaMD connects to a hardware device containing SiMD — both the standalone software and the device system must independently satisfy their respective compliance requirements. The app store or cloud platform distributing SaMD may also raise questions about economic operator obligations under the EU MDR.
Key Challenges in SaMD vs SiMD
- Incorrect classification leading to regulatory delays
- Complex documentation requirements for both categories
- Managing frequent updates, especially for SaMD
- Increasing focus on cybersecurity and data protection
- Managing interoperability and safety when SaMD interfaces with SiMD
- Determining regulatory responsibility when SaMD modifies the behavior of a hardware device
Strategic Importance
Correctly distinguishing between SaMD and SiMD — and understanding how they can be interfaced — helps MedTech companies:
Design interoperable systems with appropriate cybersecurity and risk management controls
Define the right regulatory pathway for each software component
Avoid costly delays or rework from misclassification
Optimize time to market
Ensure global compliance across FDA and EU MDR
Conclusion
The distinction between SaMD and SiMD is more than a technical definition — it directly influences your regulatory success and market access strategy. Critically, SaMD does not have to stand alone: it can and often does interface with hardware devices and the SiMD within them, creating powerful integrated clinical tools. MedTech companies that identify and plan for these classifications early — including how their SaMD will interact with physical devices — are better positioned to accelerate approvals and scale efficiently.