Software as a Medical Device (SaMD) is already part of many healthcare systems — from diagnostic tools to monitoring apps used in real time. It’s being adopted in more systems now, and regulatory authorities expect companies to show that this software is safe and performs as intended. However, each market handles SaMD differently.
This guide looks at how key regions regulate medical device software and what the approval process involves.
What Is Software as a Medical Device (SaMD)?
Software as a Medical Device (SaMD) refers to software that performs medical functions such as diagnosing, monitoring, or predicting diseases without being part of a physical medical device. These software applications can operate on computers, smartphones, cloud platforms, or web-based systems and are increasingly used to support clinical decision-making, patient monitoring, and disease management.
SaMD Definition vs Other Medical Device Software Categories
Medical device software can be classified into several categories, with SaMD representing software that performs a medical function independently of any hardware medical device.
IMDRF
Software as a Medical Device (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.
FDA
SaMD is defined as Software that meets the definition of a device in 181 section 201(h) of the FD&C Act and is intended to be used for one or more medical purposes without being part of a hardware device.
EU
Medical device software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the medical device regulation or in vitro diagnostic medical devices regulation.
India
SaMD may also be referred to as standalone software or not embedded/without being a part of a hardware medical device. SaMD are those software that are, either alone or in combination, intended to be used to perform one or more medical purposes without being part of a hardware medical device, wherein, “without being part of” means software does not necessarily require a hardware medical device to achieve its intended medical purpose. SaMD performs a medical purpose on its own and is intended to create new information on their own for any medical purpose.
Medical Device Software Categories Breakdown
SaMD (Software as a Medical Device)
Software applications that carry out the medical activities (diagnosis, monitoring, or treatment) independently and not embedded in hardware.
SiMD (Software in a Medical Device)
Software integrated into a physical hardware medical device. It is designed just to operate, control, or drive that particular piece of hardware and cannot function on its own. The entire physical device usually needs to be re-validated and re-approved if the software changes.
Mobile Medical Apps
A software application that meets the definition of a medical device. The mobile medical applications transform a mobile platform into a regulated medical device or is an accessory to a regulated medical device.
Digital Therapeutics (DTx) Applications
A group of SaMD focused entirely on interventions. DTx delivers evidence-based, clinically validated therapeutic solutions to prevent, manage, or treat a medical disorder or disease. DTx products are highly regulated and require authorization before it can be marketed.
When Does Software Become a Medical Device?
Whether software qualifies as a medical device depends on the manufacturer’s intended purpose, especially if it is intended for diagnosing, treating, or monitoring diseases or injuries. Software is considered a medical device when its intended use meets the definition of a medical device. After establishing that software satisfies the definition of a medical device, it should be classified according to the corresponding regulations.
Global Regulations for SaMD
Regulations of Software as a Medical Device (SaMD) on a global level evolves towards risk-based life cycle approach and varies from region to region:
IMDRF: Serves as the standard reference model and it is widely accepted conceptual framework.
USFDA: The most advanced and adaptable system is the USFDA. Which, particularly regarding AI/ML-based SaMD, blends stringent restrictions with useful, creative techniques.
EUMDR: Known for its stringent, compliance-focused rules that give clinical evidence and lifecycle governance top attention.
CDSCO: Although the operational depth and consistency of India’s (CDSCO) regulatory framework are still growing, they are usually consistent with international norms.
| Aspect | CDSCO | USFDA | EU MDR | IMDRF |
| Regulatory Nature | Emerging | Mature | Highly mature | Guiding framework |
| Legal Basis | MDR 2017 | FD&C Act | EU MDR (2017/745) | Non-binding |
| SaMD Definition | Explicit (aligned) | Explicit | Explicit | Originator |
IMDRF SaMD Risk Categorization Framework
SAMD Categorization Principles
- The classification is based on a precise and comprehensive definition statement of SaMD.
- The categorization of the SaMD is determined by the relevance of the information it provides to healthcare decisions and the specific healthcare context or condition.
- The four categories (I, II, III, IV) are established according to the degree of impact on patient or public health, where the accurate information supplied by the SaMD for treatment or diagnosis, as well as for guiding or informing clinical management, is crucial to prevent death, long-term disability, or other serious health declines, thereby protecting public health.
- The categories are ranked in relative importance. Category IV represents the highest impact level, while Category I represents the lowest.
| State of Healthcare Situation or Condition | Significance of Information Provided by SaMD to Healthcare Decision | ||
|---|---|---|---|
| Treat or Diagnose | Drive Clinical Management | Inform Clinical Management | |
| Critical | IV | III | II |
| Serious | III | II | I |
| Non-serious | II | I | I |
Global SaMD Registration and Approval Processes
Different jurisdictions have developed their own approaches to regulating software. Let’s explore how SaMD is regulated across key jurisdictions, including the United States, the European Union, India.
| Region | Legal Basis | Classification | Documentation | Approval Route | Review Authority |
|---|---|---|---|---|---|
| United States | FD&C Act | I, II, III | Basic/Enhanced Documentation | FDA Exempt, 510(k), De Novo and PMA | U.S. Food and Drug Administration |
| European Union | EU MDR (2017/745) | I, IIa, IIb, III | Annex II & III | CE Marking | Notified Bodies and Competent Authorities |
| India | MDR 2017 | A, B, C, D | Device Master File | Manufacturing/Import License | Central Drugs Standard Control Organization (CDSCO) |
Quality Management Systems for SaMD
The production of SaMD, which is a software-only product, is primarily based on the development lifecycle activities often supported by the use of automated software development tools These automated activities may in some cases replace discrete or deliberate activities (e.g., transfer of design to production) typically found in the manufacturing of hardware products. The principles in a QMS that provide structure and support to the lifecycle processes and activities are still applicable and important to control the quality of SaMD. An effective QMS for SaMD should include the following principles:
- An organizational framework that contains leadership, accountability, and governance, along with sufficient resources to guarantee the safety, effectiveness, and performance of SaMD.
- A series of realization and usage processes that are developed to the type of SaMD and the organization’s scale, while also considering essential elements necessary for ensuring the safety, effectiveness, and performance of SaMD.
Clinical Validation& Evidence Requirements
Software that meets the requirements of a medical device shall follow general Clinical Evaluation principles, such as:
- Establish and maintain a Clinical Evaluation plan and criteria applied to generate the necessary Clinical Evidence based on the characteristics of the device.
- Identification of the relevant data pertaining to performance and/or safety of the device and any remaining unaddressed issues or gaps in the data; – Appraisal of the relevant data in terms of quality.
- Analysis of the available data and its relevance about demonstrating conformity with the relevant General Safety and Performance Requirements.
- Documenting the relevant data, their assessment and the clinical Evidence derived therefrom, in the Clinical evaluation report.
- Updating the Clinical evaluation report and its documentation throughout the life cycle of the medical device software concerned with data obtained from implementation of the manufacturer’s post market clinical follow-up / post market performance follow-up (PMCF /PMPF) plan.
Cybersecurity & Data Privacy Requirements
- The EU MDR Regulation introduced new general security and performance requirements related to cybersecurity that are also applicable to medical device software, covering both pre-market and post-market aspects.
- Safety requirements must be identified and defined early in the product lifecycle.
- The solutions adopted by the manufacturer for the design and manufacture of devices must comply with the principles of information security, considering the generally recognized state of the art.
- Devices must be designed and manufactured to protect, as far as possible, from unauthorized access that could prevent the device from operating as intended.
- An appropriate security development process must be applied, and the testing process needs to include evidence of the effective implementation of this type of requirements.
- Manufacturers should evaluate assets, vulnerabilities, and security risks and record them.
- The system is likely to be adversely affected by any lack of confidentiality, integrity, or availability, and this effect needs to be evaluated.
- Documentation on the software should have cybersecurity information.
AI/ML-enabled SaMD Regulations
The U.S. FDA has published a draft guidance on framework for Artificial Intelligence-Enabled Device Software Functions Lifecycle Management and Marketing Submission. Recommendations based on SaMD that emphasizes a Total Product Lifecycle (TPLC) approach, provide recommendations for developing, validating, and submitting AI-enabled medical devices to the FDA. Based on a Total Product Lifecycle (TPLC), approach covers design, development, validation, deployment and post-market monitoring.
In the EU, AI-enabled medical devices must comply with MDR (safety, performance) and AI Act (AI-specific risks), AI Act adds extra obligations on top of MDR related to data governance, transparency, human oversight and post market AI monitoring. Inorder to secure the safety and efficacy of AI/ML-enabled SaMD throughout their lifecycle the regulatory bodies throughout the world are increasingly harmonizing around concepts like lifecycle oversight, algorithm transparency, cybersecurity, clinical validation, and continuous performance monitoring.
Post-Market Surveillance & Software Lifecycle Management
The international standard IEC 62304 defines the requirements for the life cycle of medical software or software within a medical device, from the development phase to the maintenance and process control phase, to risk management. The standard sets out the general requirements for developing software that consistently meet customer requirements and applicable regulatory requirements.
Post market surveillance including monitoring, measurement and analysis of quality data can include tracking of complaints, solving technical issues, determining problem causes and actions to address, identify, collect, analyze, and report on critical quality characteristics of products developed. Processes shall be in place for the collection of active and passive post market surveillance information to make appropriate decisions relating to future releases. After the product is in the market, it is important to maintain vigilance vulnerability to intentional and unintentional security threats as part of post-market surveillance.
Regulatory Challenges for SaMD Manufacturers
SaMD Documentation
The ongoing digital revolution has profoundly influenced the healthcare sector. An increasing number of medical devices have integrated into clinical practice, and managing the development and regulatory processes of the related documentation presents a considerable challenge for numerous medical environments.
Managing Innovation and Regulatory Compliance
Contrary to medical devices, SaMD is subject to continuous modifications. It is necessary for manufacturers to always upgrade their device and adapt it to changes in technological advancements. While doing so, they are supposed to maintain their safety and effectiveness.
Understanding of Complex SaMD Regulatory Frameworks
Businesses face the challenge of finding out how to interpret and apply current guidance and regulation to their particular SaMD. This can create a discrepancy or ambivalence in the approval process, causing difficulties to understand and follow by those who are involved.
Securing Sensitive Health Data
When personal health data is managed by a software medical device, patient confidentiality and data security need to be maintained. In addition to data protection regulations like the GDPR in the EU, there is also the challenge of ensuring data is protected appropriately, not simply that regulation is followed.
Meeting Clinical Evaluation Expectations
Since SaMD is relatively new compared to established medical devices, that have a long history and substantial clinical data. The availability of reliable clinical evidence for SaMD might not always exist. To demonstrate the safety and efficacy of such software might prove to be difficult and lengthy.
Challenges in SaMD Global Market Access
Different regions throughout the world each have unique sets of rules and regulations, making it difficult for developers of SaMD’s to be able to place them on the market worldwide. Thus, there is great potential to create a globally unified set of standards allowing these devices to reach wider markets.
Conclusion
Software as a Medical Device (SaMD), among other digital health solutions, has impacted the health care industry in several ways through improved disease diagnosis, patient monitoring, and disease management.
There have been a number of regulatory issues emerging from the increased adoption of Software as a Medical Device (SaMD). These include clinical evidence, cybersecurity, life cycle management, and post-market performance. It is very critical for regulators to strike a balance between encouraging innovations within the technology sector and making sure that safety and efficacy of medical devices are maintained. There should be no compromise in ensuring safety, efficacy, security, and reliability of SaMD products at all stages of their life cycle.
At Artixio, we specialize in assisting SaMD developers through the entire SaMD life cycle and in multiple markets worldwide. To get assistance with SaMD regulation and compliance, contact us at info@artixio.com.
