Defining the Regulatory Pathway for SaMD and MDSW

In the evolving landscape of healthcare technology, software plays a vital role in enabling innovative solutions for patient care and diagnostics. Software as a Medical Device (SaMD) and Medical Device Software (MDSW) are subsets of medical devices that are entirely based on software or have software components. As these technologies continue to advance, it is essential to understand the regulatory pathway that governs their development, approval, and marketing. In this article, we will explore the regulatory framework for SaMD and MDSW, highlighting the key considerations involved when establishing a regulatory strategy.

1. When does software qualify as medical device/ in vitro diagnostic medical device (IVD)?

Determining when a software qualifies as a medical device requires careful consideration of its intended purpose, impact on clinical action, and benefit for the patients. In general, if the software has its own medical purpose and is intended to be used for the benefit of patients it qualifies as a medical device.

MDSW is thus software of which the output has direct implications for medical (e.g. diagnosis, treatment, prevention, monitoring and alleviation of disease) and clinical action (e.g. surgical procedure guidance), medical decision-making (e.g. treatment planning), and patient management.

Additionally, MDSW shall perform actions on data beyond storage, archiving, communication of information, simple searches or lossless compression and be used for the benefit of patients.

The software's intended purpose should be clearly defined and aligned with the recognized medical purposes.

2. Which regulations apply to SaMD and MDSW?

In Europe, software that qualifies as MDSW falls under the MDR (Regulation (EU) 2017/745) or IVDR (Regulation (EU) 2017/746). The difference lies in the type of data being processed.

MDSW is governed by the IVDR if it provides information based on data obtained only from IVDs (in vitro diagnostic devices) or if its intended purpose is based primarily on IVD data sources. Under the IVDR, MDSW is considered an in vitro diagnostic medical device (IVD) when it is intended to provide information about a physiological or pathological process, concerning the predisposition to a medical condition, to determine the safety and compatibility with potential recipients, or to monitor therapeutic measures. 

MDSW falls under the scope of the MDR if it is intended by the manufacturer to be used, alone or in combination, for human beings for specific medical purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease; investigation, replacement or modification of the anatomy or of a physiological or pathological process or state; providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations (definition as per MDR (Regulation (EU) 2017/745)).

In the USA, the same approval pathways used for traditional medical devices are available to SaMD. For pre-market review, the 510(k) pathway can be used if a SaMD is substantially equivalent to a device already on the market. SaMD that is considered a higher risk (see classification below) is subject to the more stringent Pre-Market Authorization (PMA) process. SaMD for which there is no substantial equivalent can be evaluated either through the PMA pathway or, if they have a lower risk profile, through the De Novo pathway.

3. What is the difference between SaMD and MDSW?

SaMD is an international term coined by the International Medical Device Regulators Forum (IMDRF), while MDSW is exclusively an EU term. MDSW is defined as 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 MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.

MDSW is thus used to refer to both stand-alone software that is independent from and embedded software that is part of a hardware medical device, if it has its own medical device purpose in addition to that of driving/influencing the hardware medical device. On the other hand, SaMD only refers to software that is independent and completely excludes embedded software.

4. How is SaMD and MDSW classified?

4.1 SaMD and MDSW - device classifications under the applicable regulations (EU)

The level of risk associated with the intended use of the MDSW and its potential impact on patient and user safety are crucial factors in determining its classification.

In general, MDSW follows the classification rules of medical devices under the applicable regulations.

Under the MDR, software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:

-        death or an irreversible deterioration of a person's state of health, in which case it is in class III; or

-        a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb.

Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. For a comprehensive understanding of classification rules please refer to Annex VIII of the MDR Regulation. Additionally, the document MDCG 2019-11 is a very useful reference as it provides specific examples and interpretation of the classification rules outlined in the MDR and IVDR.

The IVDR regulation classifies MDSW into four risk classes (A to D), with the highest risk class (D) subject to the most rigorous conformity assessment. There are no software-specific classification rules in the IVDR, meaning that the general classification rules must be followed.  

For both MDR and IVDR, the classification determines the conformity assessment route and the involvement of notified bodies for conformity assessment purposes. MDCG guidance documents are available to support with the classification of medical devices (MDCG 2021-24) and of IVDs (MDCG 2020-16).

4.2 SaMD and MDSW - device classifications under the applicable regulations (USA)

The FDA's regulatory approach focuses on risk-based categorizing of devices into three regulatory classes: I, II, and III. The classification is related to the level of risk to patient safety and determines the level of control necessary to ensure the safety and effectiveness of the device,  with Class III being the highest class and requiring a Pre-Market Authorization (PMA) submission.

According to the newest guidance document published in June 2023, depending on the risk of the MDSW,  software submissions are categorized into two “Documentation Classes”. These classes are “Basic Documentation” and “Enhanced Documentation” and they serve as a framework to control the amount of documentation to be submitted for the MDSW.

Software falls under the category of Enhanced Documentation if it meets specific conditions such as being a combination product, used in transfusion medicine or organ donation, classified as class III, or having the potential to cause death or serious injury in case of a fault. The risk assessment that determines the Documentation Class should take place in the context of the device’s intended use and be performed prior to the implementation of risk control measures.  

5. SaMD and MDSW classification under IEC 62304

Independent of the device classifications according to the applicable regulations as described above (see section 4), software can also be classified based on their safety according to IEC 62304, the internationally harmonized standard for medical device software lifecycle processes. The aim of this classification is to assist manufacturers in determining the procedures necessary during the entire lifecycle of the MDSW, including requirements related to development, coding, release, and maintenance. The IEC 62304 thus identifies 3 safety classes for software: class A (no injury or damage to health is possible), class B (Non-serious injury is possible), and class C (death or serious injury is possible).

6. Regulatory Pathways for SaMD and MDSW – how we can support you

We have 50+ years of experience with regulatory and compliance considerations for medical device software, including documentation and submission for your SaMD/ MDSW, taking into account key aspects such as quality management systems, software lifecycle processes, risk classification, clinical/ performance evaluation, and post-market surveillance. For a comprehensive overview of our services, please visit our MDSW presentation page.

Particularly, as changes and the addition of modules/functionalities to a software may lead it to be newly qualified as MDSW or to a revision of its classification, we can support you with processes meant to ensure continuous conformity, safety, and performance throughout the lifecycle of the software.

Contact us at info@quaregia.com for an appointment!

Last updated 2023-06-13