Medical devices are no longer purely mechanical instruments limited to physical functions. Today, they actively assist healthcare professionals in their work and guide medical decision-making. The integration of electronic components, touchscreens, and software, combined with connectivity and artificial intelligence, has made them more precise, reliable, and user-friendly. Behind the data they collect and process lies one or more layers of software.
Among these, Software as a Medical Device (SaMD) holds a distinctive place. Recognized as a medical device in its own right, it is governed by a strict regulatory framework established by the FDA in the United States, Health Canada, and the European Union Medical Device Regulation (EU MDR).
Its potential to enhance healthcare delivery is already well demonstrated, and SaMD is emerging as one of the most influential trends in the MedTech industry. The global SaMD market is projected to reach $93.08 billion by 2031, up from $30.17 billion in 2023.
If your goal is to develop Software as a Medical Device, this article outlines the key aspects you should understand before getting started:
- The definition of Software as a Medical Device (SaMD)
- Common use cases and examples
- Classification based on risk
- The regulatory framework that applies
- Best practices for successful development
What is Software as a Medical Device (SaMD) and What is Not?
The International Medical Device Regulators Forum (IMDRF) defines software as a medical device (SaMD) as software that operates independently and is intended to diagnose, treat, or prevent disease without relying on specific medical hardware.
A SaMD can be an application or cloud-based platform used for medical purposes on smartphones, tablets, or desktop computers.
Software is also not classified as SaMD when it does not operate independently but is integrated into a medical device. In that case, it is identified as Software in a Medical Device (SiMD), software that controls the core functions or performance of the hardware. This type of software is often referred to as embedded software, firmware, or microcode.
| SaMD | Not SaMD |
|---|---|
| A mobile app that analyzes ECG data to detect arrhythmias and recommend medical follow-up. | Software that controls the electrical signals of a pacemaker (SiMD). |
| An AI-driven platform that reviews patient health data to propose personalized treatment options. | A hospital information system that stores patient records or billing data. |
| A cloud-based tool that predicts risk of diabetic complications based on patient-entered data. | A fitness tracker app that measures steps and calories. |
| Software that calculates radiation dose for oncology treatments. | Software embedded in a radiation therapy machine to deliver the actual treatment (SiMD). |
Examples of Software as a Medical Device (SaMD)
SaMD for Diagnosis
SaMD for Treatment
SaMD for Monitoring
SaMD for Prevention
Software as a Medical Device (SaMD) Classification
Identifying the classification of software as a medical device is the first step. It helps determine the specific requirements of each regulatory body for market approval.
FDA Classification
The FDA uses a relatively simple three-tier classification system but applies additional special controls to Class II medical devices.
- Class I includes software that presents the lowest risk, such as applications supporting general wellness or assisting with basic diagnostic functions.
- Class II covers moderate-risk software, such as electrocardiogram (ECG) interpretation tools or insulin dose calculators. To ensure their reliability and effectiveness, the FDA applies additional special controls beyond the general ones.
- Class III includes high-risk software that sustains or supports life, such as applications used to configure pacemakers.
Health Canada Classification
Health Canada uses a four-class system to categorize medical devices, adding an extra level to distinguish between high-risk and very high-risk software.
- Class I includes software with the lowest risk and is generally exempt from licensing.
- Class II covers moderate-risk software, such as image viewers capable of taking measurements.
- Class III applies to high-risk software that supports critical therapeutic decision-making.
- Class IV is reserved for very high-risk software, including tools used in cancer treatment, where malfunction could have life-threatening consequences.
EU MDR Classification
The European Union Medical Device Regulation (EU MDR) applies Rule 11, which assesses risk based on their context and the severity of potential harm. The rule focuses particularly on software that supports diagnostic or therapeutic decisions.
- Class IIa includes software that provides information used for diagnostic or therapeutic purposes.
- Class IIb covers software where incorrect decisions could cause a serious deterioration in health.
- Class III applies to software that could lead to death or irreversible deterioration in health..
Software as a Medical Device (SaMD) Regulatory Framework
SaMDs are subject to standards that ensure their quality, safety, and regulatory compliance. Together, these standards provide a common framework that guarantees the reliability of software used in clinical environments.
IEC 62304
IEC 62304 is a key standard for managing the life cycle of medical device software. It defines requirements related to development, maintenance, and risk control.
The standard classifies software into three safety classes based on the potential severity of harm caused by a failure. The higher the safety class, the more extensive the activities required, including documentation, testing, and verification. This classification ensures that the level of effort invested in development aligns with the associated risk to patient safety.
| Class | Level of Risk |
|---|---|
| Class A | No possibility of injury or damage to the patient. |
| Class B | Potential for injury, but not severe. |
| Class C | Potential for severe harm or death. |
IEC 82304
The IEC 82304 standard applies to standalone health software, such as mobile health applications and cloud-based diagnostic platforms. It provides essential guidance that is highly relevant to SaMD developers.
Unlike IEC 62304, which focuses on the internal software development process, IEC 82304 addresses the software product as a whole, covering labeling, instructions for use, cybersecurity, and performance throughout its life cycle. Its goal is to ensure that health software remains safe, reliable, and user-friendly.
ISO 13485
ISO 13485 is an international standard for quality management systems (QMS) specific to medical devices. For SaMD developers, applying this standard means integrating processes into a broader organizational framework that covers document control, design reviews, and corrective actions.
A company certified to ISO 13485 (like us!) demonstrates consistent practices and earns greater confidence from regulatory authorities and customers alike.
ISO 14971
The international standard ISO 14971 is the global reference for risk management in medical devices, including SaMD. It requires identifying hazards associated with software use, such as algorithm errors, cybersecurity vulnerabilities, or data misinterpretation, and assessing their severity and likelihood of occurrence. When risks are identified, appropriate measures must be implemented to mitigate them.
| Standard | Scope | Impact on SaMD |
|---|---|---|
| IEC 62304 | Software life cycle | Defines development, testing, and maintenance requirements. |
| IEC 82304 | Standalone health software | Ensures safety, reliability, usability, and cybersecurity. |
| ISO 13485 | Quality management system | Embeds software into organizational QMS practices. |
| ISO 14971 | Risk management | Identifies, evaluates, and mitigates software-related hazards. |
5 Best Practices for SaMD Development
SaMD development follows the same principles as other types of software. However, success depends on a structured process that incorporates the standards mentioned above.
Define and Document Requirements
Integrate Risk Management from The Beginning
Follow a Structured and Compliant Life Cycle
Design for Maintainability
Build Cybersecurity into Every Layer
Our experts always got your back
With extensive cross-industry experience, we’re always ready to tackle medical device software development complexities and propel your success.
