Distinguishing between Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD) is fundamental for any MedTech company developing software-driven healthcare solutions. Misclassification can derail a regulatory strategy, delay market entry, and lead to compliance risks. Regulators worldwide recognize three broad categories of software:
- Standalone software (SaMD): Software that functions as a medical device on its own.
- Embedded software (SiMD): Software that is integral to or part of a physical medical device.
- Supporting software: Software used for manufacturing, maintenance, or logistics, not considered a medical device itself.
Accurate classification determines which regulatory frameworks apply, the required conformity assessment, and the post-market obligations that follow. Understanding these distinctions early helps align design and documentation with the correct pathway.
Notably, the same algorithm can be SaMD or SiMD depending on deployment. For instance, an imaging algorithm hosted on a hospital server may be SaMD, but if embedded within the firmware of an imaging device, it becomes SiMD.
Defining SaMD vs. SiMD
The International Medical Device Regulators Forum (IMDRF) defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” This definition, adopted by both the FDA and European Commission, sets the standard for global interpretation.
In contrast, Software in a Medical Device (SiMD) refers to software that is essential to the operation of a hardware medical device. Examples include firmware in an insulin pump or the control software of an MRI scanner. It is important to note that SiMD is neither easier nor a lower burden approach. Even though SiMD is not submitted separately, IEC 62304, ISO 14971, cybersecurity, validation, and change control still fully apply within the device technical file.
Examples:
- An AI-driven diagnostic smartphone app that detects skin cancer is SaMD, since the software itself performs the medical function.
- The software controlling a smart insulin pen is SiMD, because it functions only as part of that physical device.
- A mobile app controlling or interpreting data from a device may be viewed as part of the device or a standalone medical device. This is a common grey area.
Regulatory Implications of SaMD
If your software qualifies as SaMD, it must meet full medical device regulatory requirements as a standalone product.
Under the EU MDR Rule 11, most diagnostic or therapeutic software is classified as Class IIa, IIb, or III, depending on its clinical impact. Self-certification (Class I) is now rare. SaMD manufacturers must prepare comprehensive Technical Documentation, including:
- Clinical evaluation reports
- Risk management (ISO 14971)
- Cybersecurity and usability validation
- Software lifecycle documentation (IEC 62304)
In the United States, SaMD follows the FDA’s risk-based framework. Moderate-risk products often go through the 510(k) clearance process, while novel or higher-risk products may require De Novo or PMA submissions. The FDA’s Digital Health Center of Excellence provides specific guidance, including on clinical evaluation and AI/ML-based devices.
Because SaMD stands alone, the developer bears full responsibility for quality management, validation, and post-market monitoring. Regulators also expect continuous vigilance. Frequent updates and cybersecurity patches must be managed with documented risk controls.
Regulatory Implications of SiMD
Software that functions as part of a physical medical device (SiMD) is assessed within the overall device evaluation. There is typically no separate regulatory submission for SiMD; its safety and performance are reviewed as components of the complete device system.
For example, the embedded software in a pacemaker is evaluated under the device’s Class III submission. In Europe, SiMD does not receive a separate classification under Rule 11; it inherits the classification of the parent device. However, the same software standards apply: IEC 62304, ISO 14971, and software validation are all mandatory within the device’s technical file.
Regulators also require manufacturers to manage software changes carefully. A significant firmware update may trigger a new submission (such as an FDA supplement or MDR re-certification). Additionally, software that controls or interfaces with a device, like a mobile app operating a connected insulin pump, may itself be considered part of the device system or an accessory subject to equivalent regulation.
Another important note: early regulator or Notified Body (NB) consultation is critical to avoid classification disputes. Getting aligned early can save time and help manufacturers avoid risk.
Key Criteria to Differentiate
When determining whether your software is SaMD or SiMD, consider these guiding criteria:
- Intended Use: Does the software itself diagnose, treat, or prevent disease? If so, it’s likely SaMD.
- Dependency on Hardware: If the software only operates with specific device hardware, it’s likely SiMD.
- Platform of Operation: SaMD often runs on general-purpose hardware (PCs, smartphones, cloud servers), while SiMD typically resides in dedicated medical hardware.
- Regulatory References: Review FDA guidance on digital health software and the EU’s MDCG 2019-11 guidance for software qualification and classification.
Borderline examples:
- A wearable sensor and companion app may straddle definitions. If the app interprets sensor data for diagnosis, it’s SaMD; if it merely displays readings, it may be part of the SiMD system.
Manufacturers should document the rationale for classification in their regulatory files to support interactions with the FDA or Notified Bodies.
Impact on Classification and Compliance
Accurate classification directly impacts your regulatory and commercial strategy. Misclassifying a product can have serious consequences:
- Under-classification risk: Treating a SaMD as a non-medical product or accessory can lead to noncompliance and enforcement actions.
- Over-classification burden: Treating embedded SiMD as a standalone device can waste time and resources through redundant submissions.
By classifying correctly, manufacturers can align development and evidence generation with the right regulatory expectations. SaMD developers must establish independent post-market surveillance (PMS) processes for software performance, while SiMD manufacturers integrate PMS into the broader device vigilance system.
RQM+ experts frequently advise that classification begins with a clear intended use statement. Precisely defining what the software does and for whom determines whether it meets the definition of a medical device. This clarity ensures alignment between design, regulatory documentation, and compliance obligations.
Conclusion and Best Practices
Getting the SaMD vs. SiMD distinction right is essential to regulatory success. Companies should:
- Review formal definitions from the FDA, IMDRF, and EU MDR early in the design phase.
- Use official tools such as FDA’s Q-Submission process or EU Notified Body consultations to confirm classification.
- Follow harmonized standards (ISO 13485, ISO 14971, IEC 62304) regardless of type; both SaMD and SiMD require rigorous quality and risk management.
- Maintain living documentation that clearly records classification rationale and regulatory assumptions.
As software continues to blur boundaries, especially with wearables, cloud analytics, and AI, staying informed on evolving regulatory guidance is vital. Accurate classification ensures appropriate oversight, accelerates approvals, and ultimately protects patient safety. As the FDA emphasizes, software that operates independently (SaMD) versus software integral to hardware (SiMD) differ in scope, but both demand disciplined design and evidence-based validation.
If you need expert support navigating SaMD or SiMD classification and compliance, contact us. Our team of MedTech specialists is here to help you get it right from the start.
