https://www.quaregia.com/blog/samd-mdsw#h.

4zj7j479bqsb

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