MDS G23

MDS-G23
Guidance on Software as a Medical Device
Version Number: 1.0

Version Date: 9/4/2018
This guidance document has been published after being

distributed for public comments dated on 1/3/2018 for 30 days.
Foreword
IMDRF is a voluntary group of medical device regulators from around the world who have come
together to accelerate international medical device regulatory harmonization and convergence.
SFDA has adopted the internationally converged principles related to Software as a Medical Device
(SaMD) agreed upon by the IMDRF. The principles used in this document do not reflect SFDA
regulatory requirements and are intended only to be considerations for SFDA, manufacturers and
healthcare providers.
These principles are included in the following documents:

1. Software as a Medical Device (SaMD): Key Definitions
2. Software as a Medical Device: Possible Framework for Risk Categorization and
Corresponding Considerations
3. Software as a Medical Device (SaMD): Application of Quality Management System
4. Software as a Medical Device (SaMD): Clinical Evaluation
IMDRF/SaMD WG/N10FINAL:2013
Final Document
Title: Software as a Medical Device (SaMD): Key Definitions
Authoring Group: IMDRF SaMD Working Group
Date: 9 December 2013
Despina Spanou, IMDRF Chair
This document was produced by the International Medical Device Regulators Forum. There are
no restrictions on the reproduction or use of this document; however, incorporation of this
document, in part or in whole, into another document, or its translation into languages other than
English, does not convey or represent an endorsement of any kind by the International Medical
Device Regulators Forum.
Copyright © 2013 by the International Medical Device Regulators Forum

_______________________________________________________________________________________
Table of Contents
1.0 Introduction ......................................................................................................................4

2.0 Scope ...............................................................................................................................5
3.0 References ........................................................................................................................5
4.0 Definitions........................................................................................................................5
5.0 Key Definitions ................................................................................................................6
5.1 Software as a Medical Device .......................................................................................6
5.2 Medical purpose ............................................................................................................6
5.2.1 Medical Device ......................................................................................................6
5.2.2 In Vitro Diagnostic (IVD) medical device ..............................................................7
5.2.3 Additional considerations for SaMD ......................................................................7
5.3 SaMD Changes .............................................................................................................8
5.4 SaMD Manufacturer .....................................................................................................8
5.5 Intended use / intended purpose ....................................................................................9
5.5.1 Additional considerations for SaMD ......................................................................9
9 December 2013 Page 2 of 9

_______________________________________________________________________________________
Preface
The document herein was produced by the International Medical Device Regulators Forum
(IMDRF), a voluntary group of medical device regulators from around the world. The document
has been subject to consultation throughout its development.
There are no restrictions on the reproduction, distribution or use of this document; however,
incorporation of this document, in part or in whole, into any other document, or its translation
into languages other than English, does not convey or represent an endorsement of any kind by
the International Medical Device Regulators Forum.

_______________________________________________________________________________________
1.0 Introduction
Software is becoming increasingly important and pervasive in healthcare. Given the availability
of a multitude of technology platforms (e.g., personal computers, smart phones, network servers,
etc.), as well as increasing ease of access and distribution (e.g., internet, cloud), software created
for medical purposes (software used to make clinical decisions) and non-medical purpose (e.g.,
administrative, financial) are being used in healthcare.
In general, existing regulations address public health risks of software when embedded in a
traditional medical device. However, the current application of regulations and controls may not
always translate or address the unique public health risks posed by Software as a Medical Device
(SaMD) nor assure an appropriate balance between patient/consumer protection and promotion
of public health by facilitating innovation.
This is the first of a collection of documents that will be developed by the International Medical
Device Regulators Forum (IMDRF) to establish a common framework for regulators to
incorporate converged controls into their regulatory approaches for SaMD..
This collection of IMDRF SaMD documents will provide regulators with the fundamental
building blocks and a common understanding of the many kinds and importance of software for
medical purposes in advancing public health. Generally medical purpose software 1 consists of:
(1) software in a medical device (sometimes referred to as “embedded” or “part of”);

(2) software as a medical device (SaMD).
This document IMDRF SaMD WG N10/Software as a Medical Device 2: Key Definitions focuses
on a common definition for when software is considered to be a medical device and a reminder
of other key terms, some previously defined in Global Harmonization Task Force (GHTF)
documents, with relevance to SaMD. The key definitions and terms developed in IMDRF SaMD
WG N10 will be used to develop future documents that provide a common framework for
identifying types of SaMD and associated risks and controls to minimize these risks.
Some regulators have taken individual approaches to assure safety, effectiveness, and
performance of SaMD. Such approaches have common public health goals. The objective of this
effort is to promote consistent expectations for SaMD and to provide an optimal level of patient
safety while fostering innovation and ensuring patients and providers have continued access to
advances in healthcare technology.
1
Software used to make or maintain a device (testing, source code management, servicing, etc.) is not considered
software with a medical purpose.
2
This IMDRF document converges on the term SaMD to replace the term “standalone software” or “standalone
medical device software”. However the concepts of standalone software are included in this converged definition
of SaMD.

_______________________________________________________________________________________
2.0 Scope
This document IMDRF SaMD WG N10/Software as a Medical Device: Key Definitions focuses
on a common definition for when software is considered to be a medical device and a reminder
of other key terms, some previously defined in Global Harmonization Task Force (GHTF)
documents, with relevance to SaMD.
Software intended as an accessory to a medical device is not in the scope of this document,
unless the software meets the definition of SaMD in this document.
This document focuses on the definition of the SaMD irrespective of software technology and/or
platform (e.g., mobile app, cloud).
3.0 References
• GHTF/SG1/N55:2008 Definition of the Terms Manufacturer, Authorised Representative,
Distributor and Importer
• GHTF/SG1/N70:2011 Label and Instructions for Use for Medical Devices
• GHTF/SG1/N71:2012 Definition of Terms Medical Device and In Vitro Diagnostic
Medical Device
• ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes —
Maintenance
4.0 Definitions
This section is intentionally left blank as the definitions are contained within the body of this
document.

_______________________________________________________________________________________
5.0 Key Definitions

5.1 Software as a Medical Device
The term “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.
NOTES:
• SaMD is a medical device and includes in-vitro diagnostic (IVD) medical device.
• SaMD is capable of running on general purpose (non-medical purpose) computing platforms 3
• “without being part of” means software not necessary for a hardware medical device to
achieve its intended medical purpose;
• Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical
device.
• SaMD may be used in combination (e.g., as a module) with other products including medical
devices;
• SaMD may be interfaced with other medical devices, including hardware medical devices and
other SaMD software, as well as general purpose software
• Mobile apps that meet the definition above are considered SaMD.
5.2 Medical purpose
The following two terms as defined in GHTF/SG1/N71:2012 (italicized below) identify medical
purpose applicable to SaMD:
5.2.1 Medical Device
‘Medical device’ means any instrument, apparatus, implement, machine, appliance,

implant, reagent for in vitro use, software, material or other similar or related article, intended
by the manufacturer to be used, alone or in combination, for human beings, for one or more of
the specific medical purpose(s) of:
• diagnosis, prevention, monitoring, treatment or alleviation of disease,
• diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
• investigation, replacement, modification, or support of the anatomy or of a
physiological process,
• supporting or sustaining life,
• control of conception,
3
“Computing platforms” include hardware and software resources (e.g. operating system, processing hardware,
storage, software libraries, displays, input devices, programming languages etc.).
“Operating systems” that SaMD require may be run on a server, a workstation, a mobile platform, or other general
purpose hardware platform.

_______________________________________________________________________________________
• disinfection of medical devices,

• providing information by means of in vitro examination of specimens derived from
the human body;
and does not achieve its primary intended action by pharmacological, immunological or metabolic
means, in or on the human body, but which may be assisted in its intended function by such means.
Note: Products which may be considered to be medical devices in some jurisdictions but
not in others include:
• disinfection substances,
• aids for persons with disabilities,
• devices incorporating animal and/or human tissues,
• devices for.in-vitro fertilization or assisted reproduction technologies.
5.2.2 In Vitro Diagnostic (IVD) medical device

‘In Vitro Diagnostic (IVD) medical device’ means a medical device, whether used alone
or in combination, intended by the manufacturer for the in-vitro examination of specimens
derived from the human body solely or principally to provide information for diagnostic,
monitoring or compatibility purposes.
Note 1: IVD medical devices include reagents, calibrators, control materials, specimen
receptacles, software, and related instruments or apparatus or other articles and are used,
for example, for the following test purposes: diagnosis, aid to diagnosis, screening,
monitoring, predisposition, prognosis, prediction, determination of physiological status.
Note2: In some jurisdictions, certain IVD medical devices may be covered by other
regulations.
5.2.3 Additional considerations for SaMD
SaMD may also:

• provide means and suggestions for mitigation of a disease;
• provide information for determining compatibility, detecting, diagnosing, monitoring
or treating physiological conditions, states of health, illnesses or congenital
deformities;
• be an aid to diagnosis, screening, monitoring, determination of predisposition;
prognosis, prediction, determination of physiological status.

_______________________________________________________________________________________
5.3 SaMD Changes
SaMD Changes refer to any modifications made throughout the lifecycle of the SaMD including
the maintenance phase.
Software maintenance 4 can include adaptive (e.g. keeps pace with the changing environment),
perfective (e.g. recoding to improve software performance), corrective (e.g. corrects discovered
problems), or preventive (e.g. corrects latent faults in the software product before they become
operational faults).
Examples of SaMD changes include, but are not limited to, defect fixes; aesthetic, performance
or usability enhancements; and security patches.
5.4 SaMD Manufacturer
For SaMD manufacturer the definition in GHTF/SG1/N55:2009 applies:
“Manufacturer” means any natural or legal person 5 with responsibility for design and/or
manufacture of a medical device with the intention of making the medical device available for
use, under his name; whether or not such a medical device is designed and/or manufactured by
that person himself or on his behalf by another person(s).
NOTES:
1. This ‘natural or legal person’ has ultimate legal responsibility for ensuring
compliance with all applicable regulatory requirements for the medical device in the
countries or jurisdictions where it is intended to be made available or sold, unless
this responsibility is specifically imposed on another person by the Regulatory
Authority (RA) within that jurisdiction.
2. The manufacturer’s responsibilities are described in other GHTF guidance
documents. These responsibilities include meeting both pre-market requirements
4
ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance
• adaptive maintenance: the modification of a software product, performed after delivery, to keep a
software product usable in a changed or changing environment.
• perfective maintenance: the modification of a software product after delivery to detect and correct latent
faults in the software product before they are manifested as failures
• corrective maintenance: the reactive modification of a software product performed after delivery to
correct discovered problems
• preventive maintenance: the modification of a software product after delivery to detect and correct
latent faults in the software product before they become operational faults
5
The term “person” that appears here and in the other definitions of this document, includes legal entities such as a
corporation, a partnership or an association.

_______________________________________________________________________________________
and post-market requirements, such as adverse event reporting and notification of

corrective actions.
3. ‘Design and/or manufacture’, as referred to in the above definition, may include
specification development, production, fabrication, assembly, processing, packaging,
repackaging, labelling, relabelling, sterilization, installation, or remanufacturing of
a medical device; or putting a collection of devices, and possibly other products,
together for a medical purpose.
4. Any person who assembles or adapts a medical device that has already been
supplied by another person for an individual patient, in accordance with the
instructions for use, is not the manufacturer, provided the assembly or adaptation
does not change the intended use of the medical device.
5. Any person who changes the intended use of, or modifies, a medical device without
acting on behalf of the original manufacturer and who makes it available for use
under his own name, should be considered the manufacturer of the modified medical
device.
6. An authorised representative, distributor or importer who only adds its own address
and contact details to the medical device or the packaging, without covering or
changing the existing labelling, is not considered a manufacturer.
7. To the extent that an accessory is subject to the regulatory requirements of a medical
device 6, the person responsible for the design and/or manufacture of that accessory
is considered to be a manufacturer.
5.5 Intended use / intended purpose
For SaMD intended use, the definition in GHTF/SG1/N70:2011 “Label and Instructions for Use
for Medical Devices” applies:
The term “intended use / intended purpose” is the objective intent of the manufacturer regarding
the use of a product, process or service as reflected in the specifications, instructions and
information provided by the manufacturer.

Although not specifically included in the GHTF definition materials such as sales and
marketing materials may be considered as “information provided by the manufacturer”
and therefore reflect the objective intent of the manufacturer. Sales and marketing
materials should be comprehensive and reflect the intended use of the SaMD.
6
See GHTF/SG1/N29 Information Document Concerning the Definition of the Term “Medical Device”

International Medical
IMDRF Device Regulators Forum
Final Document
Title: "Software as a Medical Device": Possible Framework for

Risk Categorization and Corresponding Considerations
Authoring Group: IMDRF Software as a Medical Device (SaMD) Working Group
Date: 18 September 2014
YfhJ!L_
Jeffrey Shuren, IMDRF Chair
This document was produced by the International Medical Device Regulators Forum.
There are no restrictions on the reproduction or use of this document; however,
incorporation of this document, in part or in whole, into another document, or its
translation into languages other than English, does not convey or represent an
endorsement of any kind by the International Medical Device Regulators Forum.
Co yright © 2014 by the International Medical Device Re ulators Forum.

_____________________________________________________________________________________________
Table of Contents
1.0 Introduction ........................................................................................................................ 4
2.0 Scope.................................................................................................................................... 5
3.0 Definitions ........................................................................................................................... 7
3.1 SOFTWARE AS A MEDICAL DEVICE ................................................................................... 7
3.2 INTENDED USE / INTENDED PURPOSE................................................................................. 7
3.3 MEDICAL PURPOSE............................................................................................................ 7
3.4 SAMD CHANGES............................................................................................................... 9
4.0 SaMD Background and Aspects Influencing Patient Safety.......................................... 9
5.0 Factors Important for SaMD Characterization ............................................................ 10
5.1 SIGNIFICANCE OF INFORMATION PROVIDED BY SAMD TO HEALTHCARE DECISION ......... 10
5.2 HEALTHCARE SITUATION OR CONDITION ........................................................................ 11
6.0 SaMD Definition Statement ............................................................................................ 12
7.0 SaMD Categorization ...................................................................................................... 13
7.1 CATEGORIZATION PRINCIPLES ........................................................................................ 13
7.2 SAMD CATEGORIES ........................................................................................................ 14
7.3 CRITERIA FOR DETERMINING SAMD CATEGORY ............................................................ 14
7.4 EXAMPLES OF SAMD: ..................................................................................................... 15
8.0 General Considerations for SaMD ................................................................................. 20
8.1 DESIGN AND DEVELOPMENT ............................................................................................ 20
8.2 CHANGES ........................................................................................................................ 22
9.0 Specific Considerations for SaMD ................................................................................. 23
9.1 SOCIO-TECHNICAL ENVIRONMENT CONSIDERATIONS ...................................................... 23
9.2 TECHNOLOGY AND SYSTEM ENVIRONMENT CONSIDERATIONS......................................... 25
9.3 INFORMATION SECURITY WITH RESPECT TO SAFETY CONSIDERATIONS ............................ 26
10.0 Appendix ........................................................................................................................... 27
10.1 CLARIFYING SAMD DEFINITION ..................................................................................... 27
10.2 ANALYSIS OF SAMD FRAMEWORK WITH EXISTING CLASSIFICATIONS ............................. 29
11.0 References ......................................................................................................................... 30
_____________________________________________________________________________________________
18 September 2014 Page 2 of 30
_____________________________________________________________________________________________
Preface
(IMDRF), a voluntary group of global medical device regulators from around the world. The
document has been subject to consultation throughout its development.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
1.0 Introduction
Software is playing an increasingly important and critical role in healthcare with many clinical
and administrative purposes.
Software used in healthcare operates in a complex socio-technical environment—consisting of

software, hardware, networks, and people—and frequently forms part of larger systems that must
operate in a unified manner. This software frequently depends on other commercial off-the-
shelf (COTS) software and on other systems and data repositories for source data.
A subset of software used in healthcare meets the definition of a medical device; globally,
regulatory authorities regulate such software accordingly.
Existing regulations for medical device software are largely focused on medical device software
that is embedded in dedicated hardware medical devices and are focused around physical harm,
transmission of energy and/or substances to or from the body, the degree of invasiveness to the
body, closeness to sensitive organs, duration of use, diseases, processes and public health risk,
competence of user and effect on population due to communicable diseases, etc.
Today, medical device software is often able to attain its intended medical purpose independent
of hardware medical devices. It is increasingly being deployed on general-purpose hardware and
delivered, in diverse care settings, on a multitude of technology platforms (e.g., personal
computers, smart phones, and in the cloud) that are easily accessible. It is also being
increasingly interconnected to other systems and datasets (e.g., via networks and over the
Internet).
The complexity of medical device software, together with the increasing connectedness of
systems, results in emergent behaviors not usually seen in hardware medical devices.
This introduces new and unique challenges. For example:
• Medical device software might behave differently when deployed to different hardware
platforms.
• Often an update made available by the manufacturer is left to the user of the medical
device software to install.
• Due to its non-physical nature (key differentiation), medical device software may be
duplicated in numerous copies and widely spread, often outside the control of the
manufacturer.
Furthermore, there are lifecycle aspects of medical device software that pose additional
challenges. For instance, software manufacturers often:
• Have rapid development cycles,

• Introduce frequent changes to their software, and
• Deliver updates by mass and rapid distribution.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
This document is focused on a selected subset of medical device software. This software is
called Software as a Medical Device (SaMD) and is defined in IMDRF SaMD WG N10 /
Software as a Medical Device: Key Definitions.
Definition: Software as a Medical Device 1

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.
The objective of this document is to introduce a foundational approach, harmonized vocabulary

and general and specific considerations for manufacturers, regulators, and users alike to address
the unique challenges associated with the use of SaMD.
The approach developed in this document is intended only to establish a common understanding
for SaMD and can be used as reference. This document is not intended to replace or modify
existing regulatory classification schemes or requirements. Further efforts are required prior to
the use of this foundational approach for possible regulatory purposes.
2.0 Scope
Purpose of the document
The purpose of the document is to introduce a foundational approach, harmonized vocabulary

and general and specific considerations, for manufacturers, regulators, and users alike to address
the unique challenges associated with the use of SaMD by;
• Establishing common vocabulary and an approach for categorizing SaMD;
• Identifying specific information for describing SaMD in terms of the significance of the
information provided by the SaMD to the healthcare decision, healthcare situation or
condition, and core functionality;
• Providing criteria to categorize SaMD based on the combination of the significance of the
information provided by the SaMD to the healthcare decision and the healthcare situation
or condition associated with SaMD; and
1
See Section 3.0 for full definition including notes.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• Identifying appropriate considerations, during the lifecycle process (requirements, design,

development, testing, maintenance and use) of SaMD.
Field of application
• The categorization system in this document applies to SaMD defined in the related
document, IMDRF SaMD WG N10 / Software as a Medical Device: Key Definitions and
does not address other types of software.
• Software intended as an accessory to a medical device (i.e., software that does not in
itself have a medical purpose) is not in the scope of this document.
• This document focuses on the SaMD irrespective of software technology and/or the
platform (e.g., mobile app, cloud, server).
• This document does not address software that drives or controls a hardware medical
device.
Relationship to other regulatory classification and standards 2
• This document is not intended to replace or create new risk management practices rather
it uses risk management principles (e.g., principles in international standards) to identify
generic risks for SaMD.
• The categorization framework in this document is not a regulatory classification, nor

implies a convergence of classifications rules. However, it does set a path towards
common vocabulary and approach. Additional work is required to align existing
classification rules with this framework.
• The categorization framework is not meant to replace or conflict with the content and/or
development of technical or process standards related to software risk management
activities.
2
Additional details can be found in Appendix 0.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
3.0 Definitions
3.1 Software as a Medical Device
The term “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.
NOTES:
• SaMD is a medical device and includes in-vitro diagnostic (IVD) medical device.
• SaMD is capable of running on general purpose (non-medical purpose) computing
platforms. 3
• “without being part of” means software not necessary for a hardware medical device
to achieve its intended medical purpose.
• Software does not meet the definition of SaMD if its intended purpose is to drive a
hardware medical device.
• SaMD may be used in combination (e.g., as a module) with other products including
medical devices.
• SaMD may be interfaced with other medical devices, including hardware medical
devices and other SaMD software, as well as general purpose software.
• Mobile apps that meet the definition above are considered SaMD.
3.2 Intended use / Intended Purpose
For SaMD intended use, the definition in GHTF/SG1/N70:2011 “Label and Instructions for Use
for Medical Devices” applies:
The term “intended use / intended purpose” is the objective intent of the manufacturer regarding
the use of a product, process or service as reflected in the specifications, instructions and
3.3 Medical Purpose
The following two terms as defined in GHTF/SG1/N71:2012 “Definition of the Terms ‘Medical
Device’ and ‘In Vitro Diagnostic (IVD) Medical Device” (italicized below) identify medical
purpose applicable to SaMD:
3.3.1 Medical Device
‘Medical device’ means any instrument, apparatus, implement, machine, appliance, implant,
reagent for in vitro use, software, material or other similar or related article, intended by the
3
“Computing platforms” include hardware and software resources (e.g. operating system, processing hardware,
storage, software libraries, displays, input devices, programming languages etc.).
“Operating systems” that SaMD require may be run on a server, a workstation, a mobile platform, or other general
purpose hardware platform.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
manufacturer to be used, alone or in combination, for human beings, for one or more of the
specific medical purpose(s) of:
• diagnosis, prevention, monitoring, treatment or alleviation of disease,

• diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
• investigation, replacement, modification, or support of the anatomy or of a physiological
process,
• supporting or sustaining life,
• control of conception,
• disinfection of medical devices,
• providing information by means of in vitro examination of specimens derived from the
human body;
and does not achieve its primary intended action by pharmacological, immunological or
metabolic means, in or on the human body, but which may be assisted in its intended function by
such means.
Note: Products which may be considered to be medical devices in some jurisdictions but not in
others include:
• disinfection substances,
• aids for persons with disabilities,
• devices incorporating animal and/or human tissues,
• devices for in vitro fertilization or assisted reproduction technologies.
3.3.2 In Vitro Diagnostic (IVD) Medical Device

‘In Vitro Diagnostic (IVD) medical device’ means a medical device, whether used alone or in
combination, intended by the manufacturer for the in-vitro examination of specimens derived
from the human body solely or principally to provide information for diagnostic, monitoring or
compatibility purposes.
Note 1: IVD medical devices include reagents, calibrators, control materials, specimen
receptacles, software, and related instruments or apparatus or other articles and are used, for
example, for the following test purposes: diagnosis, aid to diagnosis, screening, monitoring,
predisposition, prognosis, prediction, determination of physiological status.
Note2: In some jurisdictions, certain IVD medical devices may be covered by other regulations.
SaMD may also:

• Provide means and suggestions for mitigation of a disease.
• Provide information for determining compatibility, detecting, diagnosing,
monitoring or treating physiological conditions, states of health, illnesses or
congenital deformities.
• Aid to diagnosis, screening, monitoring, determination of predisposition;
prognosis, prediction, determination of physiological status.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
3.4 SaMD Changes
SaMD changes refer to any modifications made throughout the lifecycle of the SaMD including
the maintenance phase.
Software maintenance 4 can include adaptive (e.g. keeps pace with the changing environment),
perfective (e.g. recoding to improve software performance), corrective (e.g., corrects discovered
problems), or preventive (e.g., corrects latent faults in the software product before they become
operational faults).
Examples of SaMD changes include, but are not limited to, defect fixes; aesthetic, performance
or usability enhancements; and security patches.
4.0 SaMD Background and Aspects Influencing Patient Safety
There are many aspects in an ever-increasing complex clinical use environment that can raise or
lower the potential to create hazardous situations to patients. Some examples of these aspects
include:
• The type of disease or condition

• Fragility of the patient with respect to the disease or condition
• Progression of the disease or the stage of the disease/condition
• Usability of the application
• Designed towards a specific user type
• Level of dependence or reliance by the user upon the output information
• Ability of the user to detect an erroneous output information
• Transparency of the inputs, outputs and methods to the user
• Level of clinical evidence available and the confidence on the evidence
• The type of output information and the level of influence on the clinical intervention
• Complexity of the clinical model used to derive the output information
• Known specificity of the output information
• Maturity of clinical basis of the software and confidence in the output
• Benefit of the output information vs. baseline
4
• adaptive maintenance: the modification of a software product, performed after delivery, to keep a software
product usable in a changed or changing environment
• perfective maintenance: the modification of a software product after delivery to detect and correct latent
faults in the software product before they are manifested as failures
• corrective maintenance: the reactive modification of a software product performed after delivery to correct
discovered problems
• preventive maintenance: the modification of a software product after delivery to detect and correct latent
faults in the software product before they become operational faults
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• Technological characteristics of the platform the software are intended to operate on

• Method of distribution of the software
Although many of these aspects may affect the importance of the output information from
SaMD, only some of these aspects can be identified by the intended use of SaMD. Generally
these aspects can be grouped into the following two major factors that provide adequate
description of the intended use of SaMD:
A. Significance of the information provided by the SaMD to the healthcare decision, and
B. State of the healthcare situation or condition.
When these factors are included in the manufacturer’s description of intended use, they can be
used to categorize SaMD.
Section 6.0 provides a structured approach for a SaMD definition statement to describe the
intended use. Section 7.0 provides a method for categorizing SaMD based on the major factors
identified in the definition statement.
Other aspects that are not included in the two major factors (e.g., transparency of the inputs used,
technological characteristics used by particular SaMD, etc.), although still important, do not
influence the determination of the category of SaMD. These other aspects influence the
identification of considerations that are unique to a specific approach/method used by the
manufacturer of a particular category of SaMD. For example, the type of a platform, that is
constantly changing, used in the implementation of SaMD may create considerations that are
unique to that implementation. These considerations can also vary by the capabilities of the
manufacturer or by the process rigor used to implement the SaMD. Appropriate considerations of
these aspects by the manufacturers, users and other stakeholders can significantly minimize
patient safety risks.
Section 8.0 provides general considerations and section 9.0 provides specific considerations that
when taken into account can promote safety in the creation, implementation and use of SaMD.
5.0 Factors Important for SaMD Characterization
5.1 Significance of information provided by SaMD to healthcare decision
The intended use of the information provided by SaMD in clinical management has different
significance on the action taken by the user.
5.1.1 To treat or to diagnose

Treating and diagnosing infers that the information provided by the SaMD will be used to take
an immediate or near term action:
• To treat/prevent or mitigate by connecting to other medical devices, medicinal products,

general purpose actuators or other means of providing therapy to a human body
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• To diagnose/screen/detect a disease or condition (i.e., using sensors, data, or other

information from other hardware or software devices, pertaining to a disease or
condition).
5.1.2 To drive clinical management

Driving clinical management infers that the information provided by the SaMD will be used to
aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition will
be used to guide next diagnostics or next treatment interventions:
• To aid in treatment by providing enhanced support to safe and effective use of medicinal
products or a medical device.
• To aid in diagnosis by analyzing relevant information to help predict risk of a disease or
condition or as an aid to making a definitive diagnosis.
• To triage or identify early signs of a disease or conditions.
5.1.3 To Inform clinical management

Informing clinical management infers that the information provided by the SaMD will not trigger
an immediate or near term action:
• To inform of options for treating, diagnosing, preventing, or mitigating a disease or

condition.
• To provide clinical information by aggregating relevant information (e.g., disease,
condition, drugs, medical devices, population, etc.)
5.2 Healthcare Situation or Condition
5.2.1 Critical situation or condition

Situations or conditions where accurate and/or timely diagnosis or treatment action is vital to
avoid death, long-term disability or other serious deterioration of health of an individual patient
or to mitigating impact to public health. SaMD is considered to be used in a critical situation or
condition where:
• The type of disease or condition is:
o Life-threatening state of health, including incurable states,
o Requires major therapeutic interventions,
o Sometimes time critical, depending on the progression of the disease or condition that
could affect the user’s ability to reflect on the output information.
• Intended target population is fragile with respect to the disease or condition (e.g.,
pediatrics, high risk population, etc.)
• Intended for specialized trained users.
5.2.2 Serious situation or condition

Situations or conditions where accurate diagnosis or treatment is of vital importance to avoid
unnecessary interventions (e.g., biopsy) or timely interventions are important to mitigate long
term irreversible consequences on an individual patient’s health condition or public health.
SaMD is considered to be used in a serious situation or condition when:
_____________________________________________________________________________________________
_____________________________________________________________________________________________

o Moderate in progression, often curable,
o Does not require major therapeutic interventions,
o Intervention is normally not expected to be time critical in order to avoid death, long-
term disability or other serious deterioration of health, whereby providing the user an
ability to detect erroneous recommendations.
• Intended target population is NOT fragile with respect to the disease or condition.
• Intended for either specialized trained users or lay users.
Note: SaMD intended to be used by lay users in a "serious situation or condition" as

described here, without the support from specialized professionals, should be considered
as SaMD used in a "critical situation or condition".
5.2.3 Non-Serious situation or condition

Situations or conditions where an accurate diagnosis and treatment is important but not critical
for interventions to mitigate long term irreversible consequences on an individual patient's health
condition or public health. SaMD is considered to be used in a non-serious situation or condition
when:

o Slow with predictable progression of disease state (may include minor chronic
illnesses or states),
o May not be curable; can be managed effectively,
o Requires only minor therapeutic interventions, and
o Interventions are normally noninvasive in nature, providing the user the ability to
detect erroneous recommendations.
• Intended target population is individuals who may not always be patients.
• Intended for use by either specialized trained users or lay users.
6.0 SaMD Definition Statement
The intended use of SaMD is normally reflected in various sources such as the manufacturer’s
specifications, instructions, and other information provided by the manufacturer.
The purpose of the SaMD definition statement and the components identified below are to
provide an organized factual framework. Statement “A” and “B” are to help the SaMD developer
determine the SaMD category in the categorizing framework, while statement “C” is to help the
manufacturer manage changes to SaMD that may result in change of the category and to address
considerations specific to SaMD.
The SaMD definition statement should include a clear and strong statement about intended use,
including the following:
A. The “significance of the information provided by the SaMD to the healthcare
decision” which identifies the intended medical purpose of the SaMD. The statement
_____________________________________________________________________________________________
_____________________________________________________________________________________________
should explain how the SaMD meets one or more of the purposes described in the
definition of a medical device 5, e.g. supplying information for diagnosis, prevention,
monitoring, treatment etc. This statement should be structured in the following terms
as defined in section 5.1.
o Treat or diagnose
o Drive clinical management
o Inform clinical management
B. The “state of the healthcare situation or condition” that the SaMD is intended for. This
statement should be structured in the following terms as defined in section 5.2.
o Critical situation or condition
o Serious situation or condition
o Non-serious situation or condition
C. Description of the SaMD’s core functionality6 which identifies the critical
features/functions of the SaMD that are essential to the intended significance of the
information provided by the SaMD to the healthcare decision in the intended healthcare
situation or condition. This description should include only the critical features. (See
applicability of this in section 8.0, 9.0).
7.0 SaMD Categorization
This section provides an approach to categorize SaMD based on the factors identified in the
SaMD definition statement.
7.1 Categorization Principles

The following are necessary principles important in the categorization approach of SaMD.
• The categorization relies on an accurate and complete SaMD definition statement.
• The determination of the categories is the combination of the significance of the information
provided by the SaMD to the healthcare decision and the healthcare situation or condition.
• The four categories (I, II, III, IV) are based on the levels of impact on the patient or public
health where accurate information provided by the SaMD to treat or diagnose, drive or
inform clinical management is vital to avoid death, long-term disability or other serious
deterioration of health, mitigating public health.
• The categories are in relative significance to each other. Category IV has the highest level of
impact, Category I the lowest.
5
IMDRF key definitions Final document “medical purposes” also repeated here in Section 3.3.
6
These could include specific functionality that is critical to maintain performance and safety profile, attributes
identified by risk management process undertaken by the manufacturer of SaMD.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• When a manufacturer's SaMD definition statement states that the SaMD can be used across
multiple healthcare situations or conditions it is categorized at the highest category according
to the information included in the SaMD definition statement.
• When a manufacturer makes changes to SaMD 7, during the lifecycle that results in the
change of the definition statement, the categorization of SaMD should be reevaluated
appropriately. The SaMD is categorized according to the information included in the changed
(new) SaMD definition statement.
• SaMD will have its own category according to its SaMD definition statement even when a
SaMD is interfaced with other SaMD, other hardware medical devices, or used as a module
in a larger system.
7.2 SaMD Categories
Significance of information provided by SaMD to

State of Healthcare healthcare decision
situation or condition Treat or Drive clinical Inform clinical
diagnose management management
Critical IV III II
Serious III II I
Non-serious II I I
7.3 Criteria for Determining SaMD Category
Criteria for Category IV –
i. SaMD that provides information to treat or diagnose a disease or conditions in a critical

situation or condition is a Category IV and is considered to be of very high impact.
Criteria for Category III –
i. SaMD that provides information to treat or diagnose a disease or conditions in a serious

situation or condition is a Category III and is considered to be of high impact.
ii. SaMD that provides information to drive clinical management of a disease or conditions
in a critical situation or condition is a Category III and is considered to be of high impact.
Criteria for Category II –
i. SaMD that provides information to treat or diagnose a disease or conditions in a non-

serious situation or condition is a Category II and is considered to be of medium impact.
7
“SaMD changes” are defined in section 3.4
_____________________________________________________________________________________________
_____________________________________________________________________________________________
ii. SaMD that provides information to drive clinical management of a disease or conditions
in a serious situation or condition is a Category II and is considered to be of medium
impact.
iii. SaMD that provides information to inform clinical management for a disease or
conditions in a critical situation or condition is a Category II and is considered to be of
medium impact.
Criteria for Category I –
i. SaMD that provides information to drive clinical management of a disease or conditions

in a non-serious situation or condition is a Category I and is considered to be of low
impact.
ii. SaMD that provides information to inform clinical management for a disease or
conditions in a serious situation or condition is a Category I and is considered to be of
low impact.
iii. SaMD that provides information to inform clinical management for a disease or
conditions in a non-serious situation or condition is a Category I and is considered to be
of low impact.
7.4 Examples of SaMD:
The examples below are intended to help illustrate the application of the framework and resulting
categories.
Category IV:
• SaMD that performs diagnostic image analysis for making treatment decisions in patients
with acute stroke, i.e., where fast and accurate differentiation between ischemic and
hemorrhagic stroke is crucial to choose early initialization of brain-saving intravenous
thrombolytic therapy or interventional revascularization.
This example uses criteria IV.i from Section 7.3 in that the information provided by the
above SaMD is used to treat a fragile patient in a critical condition that is life
threatening, may require major therapeutic intervention, and is time sensitive.
• SaMD that calculates the fractal dimension of a lesion and surrounding skin and builds a
structural map that reveals the different growth patterns to provide diagnosis or identify if
the lesion is malignant or benign.
above SaMD is used to diagnose a disease that may be life threatening, may require
major therapeutic intervention, and may be time sensitive.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• SaMD that performs analysis of cerebrospinal fluid spectroscopy data to diagnose

tuberculosis meningitis or viral meningitis in children.
above SaMD is used to diagnose a disease in a fragile population with possible broader
public health impact that may be life threatening, may require major therapeutic
intervention, and may be time sensitive.
• SaMD that combines data from immunoassays to screen for mutable pathogens/pandemic
outbreak that can be highly communicable through direct contact or other means.
above SaMD is used to screen for a disease or condition with public health impact that
may be life threatening, may require therapeutic intervention and may be time critical.
Category III:
• SaMD that uses the microphone of a smart device to detect interrupted breathing during
sleep and sounds a tone to rouse the sleeper.
This example uses criteria III.i from Section 7.3 in that the information provided by the
above SaMD is used to treat a condition where intervention is normally not expected to
be time critical in order to avoid death, long term disability or other serious
deterioration of health.
• SaMD that is intended to provide sound therapy to treat, mitigate or reduce effects of
tinnitus for which minor therapeutic intervention is useful.
This example uses criteria III.i from Section 7.3 in that the information provided by the
above SaMD is used to treat a condition that may be moderate in progression, may not
require therapeutic intervention and whose treatment is normally not expected to be time
critical.
• SaMD that is intended as a radiation treatment planning system as an aid in treatment by

using information from a patient and provides specific parameters that are tailored for a
particular tumor and patient for treatment using a radiation medical device.
This example uses criteria III.ii from Section 7.3 in that the information provided by the
above SaMD is used as an aid in treatment by providing enhanced support to the safe
and effective use of a medical device to a patient in a critical condition that may be life
threatening and requires major therapeutic intervention.
• SaMD that uses data from individuals for predicting risk score in high-risk population for
developing preventive intervention strategies for colorectal cancer.
above SaMD is used to detect early signs of a disease to treat a condition that may be
_____________________________________________________________________________________________
_____________________________________________________________________________________________
life-threatening disease impacting high-risk populations, may require therapeutic

intervention and may be time critical.
• SaMD that is used to provide information by taking pictures, monitoring the growth or
other data to supplement other information that a healthcare provider uses to diagnose if a
skin lesion is malignant or benign.
above SaMD is used as an aid to diagnosing a condition that may be life-threatening,
may require therapeutic intervention and may be time critical by aggregating relevant
information to detect early signs of a disease.
Category II:
• SaMD that analyzes heart rate data intended for a clinician as an aid in diagnosis of
arrhythmia.
This example uses criteria from II.ii Section 7.3 in that the information provided by the
above SaMD is used to aid in the diagnosis of a disease of a condition that may be
moderate in progression, may not require therapeutic intervention and whose treatment
is normally not expected to be time critical.
• SaMD that interpolates data to provide 3D reconstruction of a patient’s computer

tomography scan image, to aid in the placement of catheters by visualization of the
interior of the bronchial tree; in lung tissue; and placement of markers into soft lung
tissue to guide radiosurgery and thoracic surgery.
This example uses criteria II.ii from Section 7.3 in that the information provided by the
above SaMD is used to aid in the next treatment intervention of a patient where the
intervention is not normally expected to be time critical in order to avoid death, long-
term disability, or other serious deterioration of health.
• SaMD that uses data from individuals for predicting risk score for developing stroke or
heart disease for creating prevention or interventional strategies.
This example uses criteria II.iii from Section 7.3 in that the information provided by the
above SaMD is used to detect early signs of a disease to treat a condition that is not
normally expected to be time critical in order to avoid death, long-term disability, or
other serious deterioration of health.
• SaMD that integrates and analyzes multiple tests utilizing standardized rules to provide
recommendations for diagnosis in certain clinical indications, e.g., kidney function,
cardiac risk, iron and anemia assessment.
above SaMD is used to detect early signs of a disease to treat a condition that is not
_____________________________________________________________________________________________
_____________________________________________________________________________________________
normally expected to be time critical in order to avoid death, long-term disability, or

Note: This example includes both serious and potentially non-serious conditions but per
the categorization principle in Section 7.1 when a manufacturer’s SaMD definition
statement states that the SaMD can be used across multiple healthcare situations or
condition it will be categorized at the highest category according to the SaMD definition
statement.
• SaMD that helps diabetic patients by calculating bolus insulin dose based on
carbohydrate intake, pre-meal blood glucose, and anticipated physical activity reported to
adjust carbohydrate ratio and basal insulin.
above SaMD is used to aid in treatment of a condition not normally expected to be time
critical in order to avoid death, long-term disability, or other serious deterioration of
health.
Category I:
• SaMD that sends ECG rate, walking speed, heart rate, elapsed distance, and location for
an exercise-based cardiac rehabilitation patient to a server for monitoring by a qualified
professional.
This example uses criteria I.ii from Section 7.3 in that the information provided by the
above SaMD is an aggregation of data to provide clinical information that will not
trigger an immediate or near term action for the treatment of a patient condition that is
not normally expected to be time critical in order to avoid death, long-term disability, or
• SaMD that collects data from peak-flow meter and symptom diaries to provide
information to anticipate an occurrence of an asthma episode.
above SaMD is an aggregation of data to provide best option to mitigate a condition that
is not normally expected to be time critical in order to avoid death, long-term disability,
or other serious deterioration of health.
• SaMD that analyzes images, movement of the eye or other information to guide next
diagnostic action of astigmatism.
This example uses criteria I.i from Section 7.3 in that the information provided by the
trigger an immediate or near term action for the treatment of a patient condition that
_____________________________________________________________________________________________
_____________________________________________________________________________________________
even if not curable can be managed effectively and whose interventions are normally
noninvasive in nature.
• SaMD that uses data from individuals for predicting risk score (functionality) in healthy
populations for developing the risk (medical purpose) of migraine (non-serious condition.
This example uses criteria I.i from Section 7.3 in that the the information provided by the
trigger an immediate or near term action for the treatment of a patient condition that
even if not curable can be managed effectively and whose interventions are normally
noninvasive in nature.
• SaMD that collects output from a ventilator about a patient's carbon dioxide level and
transmits the information to a central patient data repository for further consideration.
This example uses criteria I.ii from Section 7.3 in that the the information provided by the
• SaMD that stores historical blood pressure information for a health care provider's later
review.
• SaMD intended for image analysis of body fluid preparations or digital slides to perform
cell counts and morphology reviews.
• SaMD intended for use by elderly patients with multiple chronic conditions that receives
data from wearable health sensors, transmits data to the monitoring server, and identifies
higher-level information such as tachycardia and signs of respiratory infections based on
established medical knowledge and communicates this information to caregivers.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• SaMD that uses hearing sensitivity, speech in noise, and answers to a questionnaire about
common listening situations to self-assess for hearing loss.
This example uses criteria from I.ii Section 7.3 in that the information provided by the
8.0 General Considerations for SaMD
SaMD often forms part of a clinical workflow sequence in order to improve diagnosis, treatment
and patient management. However, issues with the design and/or implementation of SaMD into a
workflow can lead to users making incorrect choices / decisions and can cause delays in
decisions being made - this may lead to adverse consequences for patients.
Developing SaMD that are safe entails identifying risks and establishing measures that give
confidence that the risks are acceptable. It is generally accepted that testing of software is not
sufficient to determine that it is safe in operation. As a consequence, it is recognized that
confidence should be built into software in order to assure its safety.
IEC 62304 is a standard for life-cycle development of medical device software. The standard
specifies a risk-based decision model, defines some testing requirements, and highlights three
major principles that promote safety relevant to SaMD:
• Risk management;
• Quality management; and
• Methodical and systematic systems engineering according to best industry practices.
The combination of these concepts allows SaMD manufacturers to follow a clearly structured
and consistently repeatable decision-making process to promote safety for SaMD.
Further information on these major principles is provided below followed by discussion on some
specific considerations in the areas of:
• Socio-technical environment
• Technology and system environments
• Information security with respect to safety
8.1 Design and development

Manufacturers should select and implement an adequate process for the planning, design,
development, deployment, and documenting of robust and dependable software commensurate
_____________________________________________________________________________________________
_____________________________________________________________________________________________
with risk—as informed by its intended purpose, reasonable foreseeable use, and the understood
and defined socio-technical environment of use.
Safety needs to be addressed early in the design and development process.
Development of software in a quality-assured manner should consider the appropriate selection

and implementation of system design and development methods that:
• Include a methodical and systematic development process using models, methods,
architecture, and design-modelling techniques appropriate for the development
language(s) and the device’s intended purpose,
• Cover the various software lifecycle stages through the application of software
development standards, e.g., IEC 62304, and use of software engineering guidebooks,
e.g., SWEBoK guide, SEBoK guide, and
• Systematically and methodically document the design and development process (using
tools as appropriate.)
8.1.1 Post Market Surveillance

Software risks can never be totally eliminated so SaMD manufacturers should continually
monitor customer issues to maintain the safety level. A monitoring process should include ways
to capture customer feedback, e.g., through inquiries, complaints, market studies, focus groups,
servicing, etc. The inherent nature of software including SaMD allows for efficient methods to
understand and capture user experiences. It is recommended that SaMD manufacturers utilize
these feedback techniques to understand failure modes and perform analysis to address safety
situations. It is also recommended that SaMD manufacturers extend their monitoring to
automatically detect errors of the software or system, i.e., discover and recover from an error
before a failure can occur.
General considerations associated with the monitoring of SaMD include:
1. Due to its non-physical nature, a SaMD may be duplicated and numerous copies and
widely spread, often outside the control of the manufacturer.
2. Often an update made available by the manufacturer is left to the user of the SaMD to
install. Manufacturers should make sure that appropriate mitigations address any risks
that arise from the existence of different versions of the SaMD on the market.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
3. Incident investigations should consider any specific case or combination of use cases that
may have contributed to the failure and as appropriate manufacturers should consider
accident reconstruction principles, e.g., data logging, black box recorder, etc. 8
8.2 Changes
Manufacturers of SaMD are expected to have an appropriate level of control to manage changes.
Due to the non-physical nature of software, a software change management process needs
specific considerations to achieve the intended result regarding traceability and documentation.
These specific considerations include:
• Socio-technical environment considerations

• Technology and system environment considerations
• Information security with respect to safety considerations
SaMD changes may have a significant unforeseeable effect on the healthcare

situation or condition and socio-technical environment of use if not managed
systematically, not only with respect to a design change in itself, but also to
the impact of the changed software after it is installed and implemented.
With any product lifecycle, change is inevitable. Failures occur and may be due to errors,
ambiguities, oversights or misinterpretation of the specification that the software is intended to
satisfy, carelessness or incompetence in writing code, inadequate testing, incorrect or unexpected
usage of the software or other unforeseen problems. An SaMD may also fail with changes to the
running environment. Changes to SaMD or its operating environment can affect its safety,
quality and performance.
SaMD changes refer to any modifications made throughout the lifecycle of the SaMD including
the maintenance phase. The nature of software maintenance changes can include adaptive (e.g.
keeps pace with the changing environment), perfective (e.g. recoding to improve software
performance), corrective (e.g. corrects discovered problems), or preventive changes (e.g. corrects
latent faults in the software product before they become operational faults). These changes
should be clearly identified and defined with a method of tracing the change to the specific
affected software.
In order to effectively manage the changes and their impact, manufacturers must perform a risk
assessment to determine if the change(s) affect the SaMD categorization and the core
functionality of the SaMD as outlined in the definition statement.
8 Leveson, N. 2012. Engineering a Safer World: Systems Thinking Applied to Safety. Cambridge, MA, USA: MIT
Press.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
Changes should undergo appropriate verification and validation before being released by the
manufacturer for use.
Examples of software changes (some may be considered significant and others not):
• Modification to an algorithm affecting the diagnosis or therapy delivered;
• A software change that affects the way data is read or interpreted by the user, such that
the treatment or diagnosis of the patient may be altered when compared to the previous
version of the software;
• Addition of a new feature to the software that may change the diagnosis or therapy
delivered to the patient;
• A software change that incorporates a change to the operating system or change to the
configuration on which the SaMD runs;
• A software change that affects clinical workflow.
9.0 Specific Considerations for SaMD
9.1 Socio-technical environment considerations
The term socio-technical environment concerns the SaMD's setting of use - often comprising
hardware, networks, software, and people. More formally, it may be characterized into spatial
(e.g., location), activity (e.g., workflow), social (e.g., responsibility), technological (e.g., devices,
systems, data sources, and connections), and physical (e.g., ambient conditions) components 9.
SaMD supplies information and/or a structure for information.
The proper and safe functioning of SaMD is highly dependent on a sufficient

and common understanding of the socio-technical environment that includes
the manufacturer and the user.
Manufacturers should be aware of the socio-technical environment where inadequate

considerations could lead to incorrect, inaccurate, and/or delayed diagnoses and treatments;
9
(Adapted from IEC 62366)
_____________________________________________________________________________________________
_____________________________________________________________________________________________
and/or additional cognitive workload (which may, over time, make clinicians more susceptible to
making mistakes) 10.
Similarly, users should also be aware of the socio-technical environment as presumed and
designed for (limitations of the SaMD’s capabilities) and by the manufacturer, as not being
aware may lead to overreliance or other inaccurate use of the SaMD.
For example:
- If the user does not have sufficient skills and expertise for correct operation of the SaMD,
possible inaccurate output data may not be questioned. The same may happen if the user
becomes habituated and over-reliant on SaMD over time.
- The introduction of SaMD sometimes changes clinical workflows in unanticipated ways;
these changes may be detrimental to patient safety.
- The user may seek alternate pathways to achieve a particular functionality, otherwise
called a workaround. When workarounds circumvent built-in safety features of a
product, patient safety may be compromised.
Considerations for the manufacturer when identifying effects/implications and appropriate
measures to safety and performance of SaMD throughout the product's design, development, and
installation:
• Transparency of information on limitations with algorithms, clinical model, quality of

data used to build the models, assumptions made, etc. can help users question the
validity of output of the SaMD and avoid making incorrect or poor decisions;
• Integrating SaMD within real-world clinical workflows (including sufficient involvement

of users from all relevant disciplines) requires attention to in situ use and tasks to ensure
appropriate use of safety features;
• SaMD (and other systems connected to the SaMD) may be configured by the user in
different ways than intended or foreseen by the manufacturer;
• Though not specific to SaMD, design of the user interface including: whether designs are
overly complex (e.g., multiple, complicated screens), the appropriateness of designs for
the target platform (e.g., smart phone screen versus desktop monitor), the dynamic nature
of data (e.g., showing information at appropriate times and for an appropriate duration);
10
Leveson, N. 2012. Engineering a Safer World: Systems Thinking Applied to Safety. Cambridge, MA, USA: MIT
Press.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• Though not specific to SaMD, identification of appropriate means to display information

such that it is understood by the intended user (e.g., usability including regionalization
parameters, language translation, and selection/display of units);
• Communicating relevant information to the user (based on the activities conducted
above) for the purpose of:
o Enabling the user to decide whether or not the user can use the device in the
organization in terms of available hardware, competence, network, required
quality for data input. And, if he/she decides to do this, information necessary to
do those measures in order to use it: inform users, establish different routines,
obtain necessary hardware.
o Enabling correct installation and configuration of SaMD for appropriate

integration with clinical workflows.
9.2 Technology and system environment considerations
Technology and system environment refers to the ecosystem where the SaMD resides, including
installed systems, interconnections, and hardware platform(s). Instructions on how to verify the
appropriateness of installation of and update to SaMD as well as any changes made to the
system environment (e.g., hardware and software) should be provided to the user. Reliance on
hardware over which the manufacturer does not have control (operating systems not designed for
a medical purpose, general-purpose hardware, networks and servers, Internet, links) should be
considered and addressed by the manufacturer during design and development of SaMD (for
instance, by designing robust and resilient SaMD designs).
SaMDs are always dependant on a hardware platform and often a connected

environment. SaMD can be affected by cross-link interconnections – both
physical connections and interoperability, i.e., the seamless communication
between devices, technology and people.
Disruption in the ecosystem (e.g., resulting from service disruptions, systems maintenance or
upgrades, platform failures) can result in loss of information, delayed, corrupted, or mixed
patient information, or inaccurate information which may lead to incorrect or inaccurate
diagnoses and/or treatments.
For example: an incorrect diagnosis is made after the connection to a clinical dataset was lost
because the patient diagnosis data is not available.
Considerations for the manufacturer when identifying effects/implications to safety and
performance of SaMD:
• Connections to other systems (e.g., reliability of the connection, resilience, quality of

service, access, security, load capacity of connections to other systems and connection
methods, system integration)
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• Presenting information to the users and system integrators about the system requirements
and resultant performance of the SaMD (e.g., the effect that changes to firewall rules
might have on the operation of the system)
• Hardware platform(s)—such as smart phones, PC, servers—(e.g., reliability,
dependencies, and interconnections with others hardware and software);
• Operating system(s) platform—such as Windows, GNU/Linux—compatibility; and
• Modifications and changes to the SaMD integration (e.g., platform updates) may have
effects on SaMD that the manufacturer did not anticipate/foresee.
9.3 Information security with respect to safety considerations
Information security may be defined as the preservation of confidentiality, integrity and

availability of information 11.
Incorrect management or transmission of information by an SaMD can lead to

incorrect or delayed diagnosis or treatment.
SaMD may be affected by particular factors relating to information security that may affect the
integrity, availability, or accessibility of information output from the SaMD needed for correct
diagnosis or treatment:
• SaMD are typically used by a variety of users with different access needs, e.g., restricted
access or varying information security requirements
• Platforms where a SaMD is installed typically runs many other software applications.
• SaMD are typically connected to the Internet, networks, databases, or servers with
varying information security requirements.
Considerations for the manufacturer when identifying implications for safety and performance of
SaMD:
• The SaMD information security and privacy control requirements may need to be
balanced with the need for timely information availability.
11
(From ISO/IEC 27000:2009 - Information technology — Security techniques — Information security
management systems — Overview and vocabulary)
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• Information security requires the identification and implementation of safe (and

formalized) ways to store, convert and/or transmit data.
• The design should use appropriate control measures to address data integrity when
common information is accessed by multiple applications and users.
• Manufacturers should make it feasible for users to safely implement information security
updates.
• The protection of sensitive information requires support for sufficient access control and
appropriate restriction to system settings and assets for important data.
• The design should address possible adverse system interactions with the inclusion of
appropriate resilience and robustness measures.
• Instructions for users related to information security should include how to safely:
o Install SaMD in appropriate operating environments (e.g., OS, integration of other
software);
o Manage authentication mechanisms; and
o Update security software/spyware, operating environments, and other systems and
applications, etc.
10.0 Appendix
10.1 Clarifying SaMD Definition
This Appendix provides a representative list of features and functionalities that either meet or
don’t meet the definition of SaMD. This list is not exhaustive; it is only intended to provide
clarity and assistance in identifying when a feature or functionality is considered to be SaMD.
Examples of software that are SaMD:
• Software with a medical purpose that operates on a general purpose computing platform,
i.e., a computing platform that does not have a medical purpose, is considered SaMD. For
example, software that is intended for diagnosis of a condition using the tri-axial
accelerometer that operates on the embedded processor on a consumer digital camera is
considered a SaMD.
• Software that is connected to a hardware medical device but is not needed by that
hardware medical device to achieve its intended medical purpose is SaMD and not an
accessory to the hardware medical device. For example, software that allows a
commercially available smartphone to view images for diagnostic purposes obtained
from a magnetic resonance imaging (MRI) medical device is SaMD and not an accessory
to MRI medical device.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
• The SaMD definition notes states that “SaMD is capable of running on general purpose (non-
medical purpose) computing platforms.” SaMD running on these general purpose computing
platform could be located in a hardware medical device, For example, software that
performs image post-processing for the purpose of aiding in the detection of breast cancer
(CAD - computer-aided detection software) running on a general purpose computing
platform located in the image-acquisition hardware medical device is SaMD.
• The SaMD definition notes states that “SaMD may be interfaced with other medical devices,
including hardware medical devices and other SaMD software, as well as general purpose
software.” Software that provides parameters that become the input for a different hardware
medical device or other SaMD is SaMD. For example, treatment planning software that
supplies information used in a linear accelerator is SaMD.
Examples of software that are not SaMD:
• The SaMD definition states “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”. Examples of software that are considered “part of” include software used to “drive
or control” the motors and the pumping of medication in an infusion pump; or software used
in closed loop control in an implantable pacemaker or other types of hardware medical
devices. These types of software, sometimes referred to as “embedded software”, “firmware”,
or “micro-code” are, not SaMD”.
• Software required by a hardware medical device to perform the hardware’s medical

device intended use is not SaMD even if/when sold separately from the hardware medical
device.
• Software that relies on data from a medical device, but does not have a medical purpose,
e.g., software that encrypts data for transmission from a medical device is not SaMD.
• Software that enables clinical communication and workflow including patient

registration, scheduling visits, voice calling, video calling is not SaMD.
• Software that monitors performance or proper functioning of a device for the purpose of
servicing the device, e.g., software that monitors X-Ray tube performance to anticipate
the need for replacement; or software that integrates and analyzes laboratory quality
control data to identify increased random errors or trends in calibration on IVDs is not
SaMD.
• Software that provides parameters that become the input for SaMD is not SaMD if it does
not have a medical purpose. For example, a database including search and query
functions by itself or when used by SaMD is not SaMD.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
10.2 Analysis of SaMD framework with existing classifications
This Annex is intended to clarify the following:
A – Categorization of SaMD relative to medical device classification

There are different classification schemes for different purposes.
Typically classification is based on a set of parameters/questions that assigns the object of
interest into groups that suit a certain purpose.
Classifications may have the purpose to determine, for example
• Appropriate levels of regulatory oversight such as requirements for

o Levels of third party intervention
o Levels of conformity controls
o Levels of quality system
• Appropriate levels of technical measures, for example
o Technical protective means, e.g., for
 Laser protection 1,2 or 3
 electrical isolation, protective earth or double insulated
 ingress of liquids, IP XX
Classification of medical devices is commonly focused on regulatory controls based on risk

classes.
Categorization for SaMD, as in the case of laser protection, is only identifying different
categories of SaMD by level of impact. Categorization in this document by itself does not imply
regulatory controls needed to manage risks. It is only intended to provide guidance for
appropriate considerations for SaMD.
B - Relationship between this document and GHTF documents.

It is important to note the following to understand the relationship between the categorization
framework in this document and the classification principles for medical devices and in vitro
diagnostic medical devices:
• GHTF classification principles, unlike this document, were intended to build classification
rules for regulatory control purposes. As explained earlier, this document identifies different
categories of SaMD by level of impact and does not address corresponding regulatory risk
classes identified in GHTF documents.
• The high-level principles used for identifying SaMD categories build substantially on the
principles (rationale) underlying the classification rules established in the GHTF
classification principles documents. Key factors like individual risks, public health risks, user
skills, and importance of the information provided are common to both frameworks.
_____________________________________________________________________________________________
_____________________________________________________________________________________________
11.0 References
IMDRF SaMD WG N10 / Software as a Medical Device: Key Definitions

GHTF/SG1/N70:2011 “Label and Instructions for Use for Medical Devices”
GHTF/SG1/N71:2012 “Definition of the Terms ‘Medical Device’ and ‘In Vitro Diagnostic
(IVD) Medical Device”
IEC 62304:2006 - Medical device software -- Software life cycle processes
Guide to the Software Engineering Body of Knowledge - SWEBOK (2004), pp. 1-202 by Alain
Abran, Pierre Bourque, Robert Dupuis, James W. Moore, Leonard L. Tripp edited by Alain
Abran, Pierre Bourque, Robert Dupuis, James W. Moore, Leonard L. Tripp
[SEBoK] Guide to the Systems Engineering Body of Knowledge (http://www.sebokwiki.org/)
ISO/IEC 27000:2009 - Information technology — Security techniques — Information security
management systems
IEC 62366:2007 Medical devices — Application of usability engineering to medical devices
Leveson, N. ‘Engineering a Safer World: Systems Thinking Applied to Safety, MIT, USA
(2011)
_____________________________________________________________________________________________
IMDRF/SaMD WG/N23 FINAL: 2015
International Medical
IMDRF Device Regulators Forum
FINAL DOCUMENT
International Medical Device Regulators Forum
Title: Software as a Medical Device (SaMD): Application of Quality

Management System
Authoring Group: IMDRF SaMD Working Group
Date: 2 October 2015
Toshiyoshi Tominaga, IMDRF Chair
This document was produced by the International Medical Device Regulators Forum.
There are no restrictions on the reproduction or use of this document; however,
incorporation of this document, in pa11 or in whole, into another document, or its
translation into languages other than English, does not convey or represent an
endorsement of any kind by the International Medical Device Regulators Forum.
Copyright© 2015 by the International Medical Device Regulators Forum.

Table of Contents
1.0 INTRODUCTION ........................................................................................................................... 4
2.0 SCOPE.......................................................................................................................................... 5
3.0 REFERENCES ................................................................................................................................ 7
4.0 DEFINITIONS ................................................................................................................................ 7
5.0 SAMD QUALITY MANAGEMENT PRINCIPLES ................................................................................ 8
6.0 SAMD LEADERSHIP AND ORGANIZATIONAL SUPPORT ............................................................... 10

LEADERSHIP AND ACCOUNTABILITY IN THE ORGANIZATION ...................................................................... 10
RESOURCE AND INFRASTRUCTURE MANAGEMENT ................................................................................. 10
6.2.1 PEOPLE .............................................................................................................................................. 11
6.2.2 INFRASTRUCTURE AND WORK ENVIRONMENT .......................................................................................... 11
7.0 SAMD LIFECYCLE SUPPORT PROCESSES ...................................................................................... 12

PRODUCT PLANNING ...................................................................................................................... 12
RISK MANAGEMENT: A PATIENT SAFETY FOCUSED PROCESS ................................................................... 13
DOCUMENT AND RECORD CONTROL .................................................................................................. 15
CONFIGURATION MANAGEMENT AND CONTROL ................................................................................... 15
MEASUREMENT, ANALYSIS, AND IMPROVEMENT OF PROCESSES AND PRODUCTS ......................................... 16
MANAGING OUTSOURCED PROCESSES, ACTIVITIES, AND PRODUCTS ......................................................... 17
8.0 SAMD REALIZATION AND USE PROCESSES ................................................................................. 19

REQUIREMENTS MANAGEMENT ........................................................................................................ 19
DESIGN........................................................................................................................................ 21
DEVELOPMENT .............................................................................................................................. 22
VERIFICATION AND VALIDATION ........................................................................................................ 23
DEPLOYMENT................................................................................................................................ 24
MAINTENANCE .............................................................................................................................. 26
DECOMMISSIONING (RETIREMENT OR END‐OF‐LIFE ACTIVITY) ................................................................. 27
APPENDIX A: MAPPING MEDICAL DEVICE REGULATIONS TO IMDRF/SAMD WG/N23 ......................... 29
2 October 2015 Page 2 of 34

Preface
There are no restrictions on the reproduction, distribution, or use of this document; however,

1.0 Introduction
The International Medical Device Regulators Forum (IMDRF) seeks to establish a common and
converged understanding for software intended for medical purposes and specifically for a subset
of such software that is intended to function as a medical device. The IMDRF Software as a
Medical Device Working Group (WG) defines this subset of software as Software as a Medical
Device (SaMD) in the IMDRF/SaMD WG/N10 document Software as a Medical Device
(SaMD): Key Definitions; this document is the foundation for developing a common vocabulary;
it defines SaMD for both manufacturers and regulators.
The SaMD WG has also provided a framework to categorize types of SaMD based on impact to
patient and public health in the IMDRF/SaMD WG/N12 document Software as A Medical
Device: Possible Framework for Risk Categorization and Corresponding Considerations.
This framework establishes a common approach for categorizing SaMD, using criteria based on
the combination of the significance of the information provided by the SaMD to the healthcare
decision and on the healthcare situation or condition where the SaMD is used.
The IMDRF/SaMD WG/N12 document also highlights the use of quality management as a
general consideration towards the safety, effectiveness, and performance of SaMD and as key to
ensuring the predictability and quality of SaMD.
Quality Management System (QMS) principles, for many industrial sectors, can be found in the
ISO 9000 family of standards. In addition, there are also a wide variety of current industry
software development lifecycle methodologies, guidance documents, and standards that address
best practices of the many aspects of software engineering quality practices. These principles are
the foundation for good practices to maintain and control the quality of products in organizations
of any size, ranging from a one-person enterprise to a multi-national corporation.
In the medical device sector it is generally accepted that following QMS requirements is one of
the controls used to minimize and manage unintentional outcomes related to patient safety. QMS
requirements for medical devices are defined by regulatory agencies in their regulations and in
the international standard ISO 13485—Medical Devices—Quality Management Systems—
Requirements for Regulatory Purposes.
In the software industry, good software quality and engineering practices are used to control the
quality of software products. These practices may readily align with the general principles of
medical device QMS requirements when the patient safety perspective is included.
This document highlights elements of good software quality and engineering practices
and reinforces medical device quality principles that should be appropriately incorporated for an
effective SaMD QMS.
This is a companion document to IMDRF/SaMD WG/N10 and N12 documents, further enabling
convergence in vocabulary, approach, and a common thinking for regulators and industry.

2.0 Scope
The objective of the document is to provide guidance on the application of existing standardized
and generally accepted QMS practices to SaMD. Furthermore, the purpose of this document is
to:
 Inform the reader of SaMD specific practices. It assumes the reader is following
generally accepted software lifecycle processes1 and may not be familiar with medical
device QMS;
 Provide guidance for the application of QMS for the governance of organizations
responsible for delivering SaMD products and managing the SaMD lifecycle support
processes (product planning; risk management; document and record control;
configuration management and control; measurement, analysis, and improvement of
processes and products; and managing outsourced processes, activities and products) and
SaMD realization and use processes (requirements management, design, development,
verification and validation, deployment, maintenance, and decommissioning);
 Highlight SaMD realization and use processes from the perspective of patient safety and
clinical environment considerations as well as technology and systems environment
considerations that should be addressed to ensure the safety, effectiveness, and
performance of SaMD;
 Help manufacturers and regulators attain a common understanding and vocabulary for the
application of medical device quality management system requirements to SaMD; and
 Complement the IMDRF SaMD framework for risk categorization and corresponding
considerations found in IMDRF/SaMD WG/N12.
This document is intended for the following audience:
 Groups and/or individuals who are or want to become developers of SaMD;
 Software development organizations (large or small) that apply good software quality and
engineering practices and that may not necessarily be familiar with medical device QMS
requirements; and
 Organizations (divisions/departments) working within established medical device quality
systems that intend to communicate the linkage between medical device quality system
practice and software development practices.
Document organization and content:
 Terminology used is intended to be familiar to the software industry and illustrates how
typical software-engineering activities (e.g., determining requirements) translate to
equivalent activities in a medical device quality management system (e.g., identifying
1
These lifecycle processes are intended to include commonly referred lifecycle processes such as software
development lifecycle processes (SDLC), software product lifecycle processes (SPLC) and Software System
lifecycle processes (SSLC).

design inputs) used in the management, design, development, implementation,

monitoring, and support of SaMD;
 Sections are organized based on processes and activities commonly found in software
engineering lifecycle approaches as well as on leadership and management processes of
the organization as a whole;
 SaMD lifecycle support processes (Section 7) and realization and use processes (Section
8) include considerations that are necessary to address patient safety and clinical
environment as well as the technology and systems environment for SaMD;
 Examples using two fictitious companies—Magna (a large organization) and Parva (a
small start-up)––are provided throughout in order to highlight some of the key points
being made; and
 References ISO13485:2003, a QMS standard currently published within the medical
device industry.
Field of application:
 The guidance for the application of QMS provided in this document applies to SaMD as
defined in IMDRF/SaMD WG/N10 and does not address other types of software; and
 This document focuses on SaMD irrespective of technology and/or platform (mobile app,
cloud, server, etc.).
This document is not intended to:
 Provide guidance on how to undertake good software quality and engineering practices or
how to implement QMSs; and
 Rewrite, repeat, or contradict QMS principles that are articulated in medical device
regulations or standards.
Relationship to regulatory requirements and to technical standards:
 The document does not replace or create new QMS standards, software quality and
engineering practices, or regulations; rather, it highlights certain common practices and
terminology used by successful software organizations;
 This document is not intended to replace or conflict with medical device legislation,
regulations, or procedures required in individual regulatory jurisdictions;
 This document is not a tutorial on risk management practices for software; rather, it
highlights risk management principles throughout the software lifecycle processes and
activities that are critical to the safety, effectiveness, and performance of SaMD; and
 The activities highlighted in this document are not meant to replace or conflict with the
content and/or development of technical or process standards related to software risk-
management activities or software-development practices but may provide input to these
processes and activities.

3.0 References
 IMDRF/SaMD WG/N10 - Software as a Medical Device (SaMD): Key Definitions.
 IMDRF/SaMD WG N12 - Software as a Medical Device: Possible Framework for Risk
Categorization and Corresponding Considerations.
 ISO 13485:2003 – Quality management system – Requirements for regulatory purposes.
4.0 Definitions
This document does not introduce any new definitions but rather relies on the following:
 Definition of SaMD as identified in IMDRF/SaMD WG/N10.
 Terms typically used in standards and regulations as they relate to QMS for medical
devices.
 Terms and vocabulary used in software quality and engineering practices.

5.0 SaMD Quality Management Principles

Medical device QMS principles allow for scaling of activities depending on the type of medical
device; risk of the product to patients; size of the organization; technology or automation used to
manufacture; and other factors that are determined by the manufacturer to control quality and
maintain the safe and effective performance of the medical device.
The manufacturing 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 (build automation, use of source code management tools, etc.). 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. However, 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 structure that provides leadership, accountability, and governance with
adequate resources to assure the safety, effectiveness, and performance of SaMD (outer
circle in Figure 1);
 A set of SaMD lifecycle support processes that are scalable for the size of the
organization and are applied consistently across all realization and use processes (middle
circle in Figure 1); and
 A set of realization and use processes that are scalable for the type of SaMD2 and the size
of the organization; and that takes into account important elements required for assuring
the safety, effectiveness, and performance of SaMD (innermost circle in Figure 1).
2
As identified by IMDRF SaMD WG N12 document

Figure 1: SaMD Quality Management Principles: Leadership and Organization Support, Processes, and Activities
The three principles outlined above should not be considered independently as a separate series
of processes in an organization. Instead, an effective QMS establishes a distinct relationship (see
Figure 2 below) between the three principles as follows:
 The governing structure of Leadership and Organization Support should provide the
foundation for SaMD lifecycle support processes; and
 The SaMD lifecycle support processes should apply across the SaMD realization and use
processes.
Figure 2: Relationship between Quality Management Principles
The concepts presented in this section relate to clauses 4 and 5 in ISO 13485:2003.

6.0 SaMD Leadership and Organizational Support

Leadership and accountability in the organization
Management of the organization provides the

SaMD Realization and Use Processes
leadership and governance of all activities related
to the lifecycle processes of SaMD including SaMD Lifecycle Support Processes
defining the strategic direction, responsibility, Leadership and Organizational Support
authority, and communication to assure the safe
and effective performance of the SaMD.
The organization’s leadership is also responsible for implementing the QMS, which can include
developing a quality policy, quality objectives, and project-specific plans that are customer
focused.
The governance structure should provide support for creating and establishing appropriate
processes that are important for maintaining the quality objectives and policies3.
In addition, the governance should include activities for systematically verifying the
effectiveness of the established quality management system, such as undertaking QMS internal
audits. Management review of the results of the QMS audits is a tool to ensure that the
established QMS is suitable, adequate, and effective and that any necessary adjustments may be
made as a result.
Example: Both Magna and Parva management have responsibilities to ensure that a QMS has
been established and that the necessary patient safety considerations have been built in to the
QMS and managed when entering the SaMD market. In the case of Magna, the company has an
organizational structure that resulted in its Chief Medical Officer being identified as being
responsible for these aspects. In the case of Parva, the company has nominated its Software
Development Manager to be responsible for including necessary patient safety aspects.
The concepts presented in this section relate to clauses 5 and 8.2.2 in ISO 13485:2003.
Resource and Infrastructure Management
The purpose of resource management is to provide the appropriate level of resources (including
people, tools, environment, etc.), as needed for ensuring the effectiveness of the SaMD lifecycle
processes and activities in meeting regulatory and customer requirements.
The concepts presented in this section relate to clause 6 in ISO 13485:2003.
3
These processes should be tailored specifically towards the needs of the organizations and the level of documented
processes, objectives, and policies should be adjusted appropriately for the type, size, and distributed nature of the
organization.

6.2.1 People
It is important to ensure that people who are assigned to SaMD projects should be competent in
performing their jobs. For SaMD, such a team should have competencies in technology and
software engineering including an understanding of the clinical aspects of the use of the software.
Example: Both companies realize the importance of ensuring that there are competent
employees to perform their assigned duties. In the case of Magna, there is a broader base of
skills amongst the staff with the SaMD skills gap being addressed through an extension of
already existing in-house training and education programs. For Parva, the skills gap was
bridged by looking to other sources such as temporary recruits and external training programs.
The concepts presented in this section relate to clauses 6.1 and 6.2 in ISO 13485:2003.
6.2.2 Infrastructure and Work Environment

Infrastructure such as equipment, information, communication networks, tools, and the physical
facility, etc., should be made available throughout SaMD lifecycle processes. Such infrastructure
is used to support the development, production, and maintenance of SaMD and consequently
needs to be provided and maintained.
For SaMD, this may entail identifying and providing the software development and test
environment that supports the SaMD realization and use processes. This may include providing a
test environment that simulates the intended environment of use and tools that support managing
various software configurations during the lifecycle processes, e.g., version management for
source code during development.
As work environments become increasingly virtual, the reliability and dependability of the
collective infrastructure environment is an important consideration (e.g., dependence on 3rd party
networks and equipment).
Example: Both companies need specific environments for ensuring code and data integrity
across these different infrastructure environments. In the case of Magna, existing computer
networks and secure building access is leveraged directly for SaMD development. In the case of
Parva, the development environment is hosted by a qualified service provider, ensuring the code
and data integrity is part of the service agreement between them and the provider.
The concepts presented in this section relate to clauses 6.3 and 6.4 in ISO 13485:2003.

7.0 SaMD Lifecycle Support Processes

An organization's QMS should be built and managed SaMD Realization and Use Processes
around processes that support the lifecycle activities of
SaMD. SaMD Lifecycle Support Processes
Leadership and Organization Support

This section addresses important processes that are
applicable across the SaMD lifecycle, regardless of the intended use of the SaMD (i.e.,
significance of the information provided by the SaMD to the healthcare decision and the state of
the healthcare situation or condition).
There are many available methods to conduct SaMD lifecycle processes. These processes are
typically scaled to address the complexity and size of the SaMD product and project (e.g., during
new product introduction or for an upgrade) that needs to be created.
The elements discussed in this section are common processes and activities that should be
considered throughout the SaMD lifecycle regardless of specific software product development
approach or method used by the organization.
Appropriate implementation of clearly structured and consistently repeatable decision-making
processes by SaMD organizations can provide confidence that efforts to minimize patient safety
risk and promote patient safety have been considered.
Product Planning
The objective of planning is to provide a roadmap to be followed during the product
development lifecycle. This comes from the quality principle that better results can be achieved
by following a methodical and rigorous plan for managing projects such as a plan-do-check-act
approach.
Product planning includes the definition of phases, activities, responsibilities, and resources
needed for developing the SaMD. It is important to understand that planning is not static—it
needs to be updated when new information is gathered or milestones are reached.
IMDRF/SaMD WG/N12 identifies that for SaMD, a thorough understanding of the socio-
technical 4 environment (clinical perspective), and the technology and system environment
(software perspective) is important in planning, as inadequate considerations could lead to
incorrect, inaccurate, and/or delayed diagnoses and treatments.5
The implementation of SaMD lifecycle processes should adequately be informed and tailored for
the type of SaMD as identified in IMDRF/SaMD WG/N12.
4
Socio-technical systems are systems that include technical systems but also operational processes and people who
use and interact with the technical system. Socio-technical systems are governed by organizational policies and rules.
5
IMDRF SaMD WG N12: Section 9.1—Socio-technical environment considerations and Section 9.2—Technology
and system environment considerations.

Example: Both companies carry out product planning to decide which operating systems best
suited their SaMD application. The larger Magna company has chosen to build its application
to work on the top five mobile phone operating systems as the company has the resources to
develop on multiple platforms. While the smaller Parva has chosen to develop for the platform
that is currently the market leader due to the company’s constraints of resources. For both
Parva and Magna, this planning phase can allow each company to take deliberate approaches to
the assignment of resources.
The concepts presented in this section relate to clauses 5.4, 7.1, and 7.3.1 in ISO 13485:2003.
Risk Management: A Patient Safety Focused Process

IMDRF/SaMD WG/N12 provides a possible framework to categorize types of SaMD based on
impact to patient and public health. Using the foundational categorization in IMDRF/SaMD
WG/N12, the safety, effectiveness, and performance of SaMD can be enhanced by appropriate
risk management. This risk management process should be integrated across the entire lifecycle
of SaMD.
Organizations that engage in general software development continuously monitor and manage
schedules and budget risks of a software project. Similarly, a SaMD organization should also
monitor and manage risks to patients and users across all lifecycle processes.
For SaMD, product risk should be informed by the intended purpose; the normal use and
reasonably foreseeable misuse; and the understood and defined socio-technical environment of
use of the SaMD. Some general considerations associated with SaMD patient safety risk include
the ease with which a SaMD may be updated, duplicated, and distributed due to its non-physical
nature, and where these updates, made available by the SaMD organization, may be installed by
others.
Risk management in the context of this document, outlines a risk-based approach to patient
safety.6 Specifically, related to QMS, some points that should be considered include:
 Identification of hazards;
 Estimation and evaluation of associated risks;
 Actions to control risks; and
 Methods to monitor effectiveness of the actions implemented to control risks.
6
ISO 14971:2007 is one commonly used standard that can be used to guide an appropriate medical device risk
management process.

For example, it is helpful to chart sources of hazards along multiple dimensions, such as:
User-Based
Is the SaMD product appropriate for all intended users? For instance, are there hazards
posed by visual acuity for an elderly user, or for patients with peripheral neuropathy? Is the
device being used in a clinical or home environment?
Application-Based
Should a SaMD application be available on any device, or should it be restricted to certain
devices in such a way that it could help to mitigate user risk?
Device-Based
Is a device with a smaller screen, such as a smartphone, adequate for the intended
application? Can a smaller screen display a large set of information without losing the
information or making it cumbersome to the users in a way that could affect patient safety?
Environment-Based
Is continuity of use (and therefore, safety) of the SaMD product compromised when there are
environmental disruptions (e.g., interruptions in use, background noise, loss of network
connectivity)?
Security-Based
Is analysis being performed that includes evaluating the security threats to SaMD product
software code during manufacturing, maintenance and in-service use? Does this analysis also
include, for example, intrusion detection, penetration testing, vulnerability scanning, and data
integrity testing to minimize system and patient risks?
Software risk management requires a balanced evaluation of both safety and security.
Security risks may affect the confidentiality, integrity, and availability of data handled by the
SaMD. When considering mitigations to protect device security, the manufacturer should ensure
that security risk controls do not take precedence over safety considerations.
Example: Both Magna and Parva know the importance of carrying out systematic risk
management activities throughout their SaMD lifecycles. Magna has a dedicated department
whose members ensure that the risk of the product is within acceptable limits, including
considerations of patient harm. Parva has chosen to train its SaMD developers in risk-
management activities and, with this knowledge, they collectively ensure that the risk of the
product is within acceptable limits, including considerations of patient harm. Both of the above
approaches ensure that the necessary risk management activities are carried out.
The concepts presented in this section relate to clause 7.1 in ISO 13485:2003.

Document and Record Control

Records are used to provide evidence of results achieved or activities performed as a part of the
QMS or SaMD lifecycle processes as well as justifications for any QMS or SaMD lifecycle
processes not performed. Records can be in paper or electronic form.
For SaMD lifecycle processes, document control and records management makes it easier for the
users of those documents and records, both within and outside (outsourced contractors,
customers, etc.) the organization, to share and collaborate in the many activities related to the
SaMD lifecycle processes. Document control and records management also serves to help
communicate and preserve the rationale for why certain decisions were made, such as those
related to patient safety or risk management.
Records generated to demonstrate QMS conformity should be appropriately identified, stored,
protected, and retained for an established period of time. The following activities are examples
of ways to manage and maintain appropriate documentation in the QMS system:
 Reviewing and approving documents before use;
 Ensuring current versions of applicable documents are available at points of use to help
prevent the use of obsolete documents;
 Retaining obsolete documentation for an established period;
 Controlling documents against unauthorized or unintended changes; and
 Maintaining and updating documents across all SaMD lifecycle processes.
Example: In the cases of Magna and Parva, it is important to manage and control
documentation throughout the SaMD lifecycle processes. Documentation does not mean
bureaucracy; rather, it is the foundation to drive traceability, repeatability, scalability, and
reliability in SaMD projects. Magna uses established documentation processes and techniques
that include the use of a commercially available requirements management tool throughout the
SaMD lifecycle processes. Parva has re-purposed its source-code control software to enable the
company to manage its documentation in a controlled way.
The concepts presented in this section relate to clause 4.2 in ISO 13485:2003.
Configuration Management and Control

Control of configurable items, including source code, releases, documents, software tools, etc., is
important in order to maintain the integrity and traceability of the configuration throughout the
SaMD lifecycle.
A systematic documentation of the SaMD and its supporting design and development, including
a robust and documented configuration and change management process, is necessary to identify
its constituent parts, to provide a history of changes made to it, and to enable recovery/recreation
of past versions of the software, i.e., traceability of the SaMD.
For SaMD, configuration is also an important consideration to enable the correct installation and
integration of the SaMD into the clinical environment. This information enables users to decide,
for example, whether or not the SaMD can be used with available hardware and networks,

whether it is necessary to establish different routines and training, or whether it is necessary to

obtain new or reconfigure existing hardware.
In the management of SaMD configuration, software tools are generally used to manage source
code, releases, documents, deployment, maintenance, etc. In SaMD, the notion of configuration
management and its complexity is amplified by the heterogeneity of the environment in which
the SaMD will operate; using the right tools and techniques is important.
Example: For Magna and Parva the importance of configuration management is well
understood. In both cases the companies’ patients can access the SaMD products through
multiple devices (e.g., smartphone, PC, and tablet) each of which require specific configurations
and optimization of user experiences. The need for multi-device access enforces the importance
of a robust and documented configuration management process to ensure the integrity and
traceability of the various configurations across product lines.
The concepts presented in this section relate to clauses 4.2.3, 4.2.4, 7.3.7, 7.5.1, and 7.5.3 in ISO
13485:2003.
Measurement, Analysis, and Improvement of Processes and Products

Measurement of quality characteristics of software products and processes is used to manage and
improve product realization and use. An effective measurement of key factors, often associated
with issues related to risk, can help identify the capabilities needed to deliver safe and effective
SaMD. Opportunities to monitor, measure, and analyze for improvement exist before, during,
and after SaMD lifecycle processes, activities and tasks, and are completed with the intent to
objectively demonstrate the quality of the SaMD. Post market surveillance including monitoring,
measurement and analysis of quality data can include logging and tracking of complaints,
clearing technical issues, determining problem causes and actions to address, identify, collect,
analyze, and report on critical quality characteristics of products developed. For SaMD,
monitoring to demonstrate through objective measurement that processes are being followed
does not itself guarantee good software, just as monitoring software quality alone does not
guarantee that the objectives for a process are being achieved. Aspects important for the
measurement, analysis, and improvement of SaMD processes and products include:
 Evaluation of the SaMD and its lifecycle processes should be based on defined
responsibilities and predetermined activities including using leading and lagging safety
indicators and collecting and analyzing appropriate quality data. The analysis of this data,
such as analysis of customer complaints, problem reports, bug reports, nonconformity to
product requirements, service reports, and trends of processes and products should be
used to evaluate the quality of the SaMD and the quality of the SaMD lifecycle processes
and where/if improvement of these processes can be made. For SaMD, customer
complaints may be the major source of the quality data that the organization should
analyze.

 Corrections and corrective actions may be required when a process is not correctly
followed or the SaMD does not meet its specified requirements (i.e., when a
nonconforming process or product exists).
 Nonconforming SaMD should be contained to prevent unintended use or delivery. The
detected nonconformity should be analyzed and actions taken to eliminate the detected
nonconformity (i.e., correction); and to identify and eliminate the cause(s) of the detected
nonconformity (i.e., corrective action) to prevent recurrence of the detected
nonconformity in the future. In some cases a potential nonconformity may be identified,
and actions such as safeguards and process changes can be taken, to prevent
nonconformities from occurring (i.e., preventive action).
 Actions taken to address the cause of SaMD nonconformities, as well as actions taken to
eliminate potential SaMD nonconformities, should be verified/validated before SaMD
release and should be evaluated for effectiveness.
 Lessons learned from the analysis of past projects, including the results from internal or
external audits of the SaMD lifecycle processes, can be used to improve the safety,
effectiveness, and performance of SaMD. The manufacturer should also have processes
in place for the collection of active and passive post market surveillance information in
order to make appropriate decisions relating to future releases.
 After the product is in the market, it is important to maintain vigilance for vulnerability to
intentional and unintentional security threats as part of post market surveillance.
Example: Customer feedback is an important part of monitoring the performance to improve the
product over time. Both Magna and Parva are in the process of developing a new and improved
version of their SaMD. Magna has a dedicated department that works independently but in
conjunction with sales, marketing, and product development to formally survey its large
customer base to gain insights into product performance. In the case of Parva, the company
invites some of its early adopters and customers into an office to conduct a round-table
discussion to get to the same kind of feedback. Both companies also use embedded analytical
tools to gain insights into customer behavior with respect to their use of their respective products.
They also routinely review and evaluate customer complaints to identify trends and potential
areas for improvement. Based on the review of various sources of data, both Magna and Parva
redesigned their SaMD to address common issues identified by customer feedback, complaints,
and any new/updated clinical evidence.
The concepts presented in this section relate to clauses 7.2.3, 7.3.7, 7.5.1.1, 8.1, 8.2, 8.3, 8.4, and
8.5 in ISO 13485:2003.
Managing Outsourced Processes, Activities, and Products

An effective QMS system takes into account and ensures quality of SaMD when processes,
activities, or products are outsourced (i.e., are not completely conducted / made in-house).
An organization may choose to outsource different parts of its SaMD process, activities, or
product based on its in-house strengths and competencies. Similarly, an organization may
procure a commercial-off-the-shelf (COTS) product or another SaMD for integration into its
SaMD. In both of these instances, understanding, maintaining control, and managing the effect

of such outsourced processes, activities, or products is important and necessary to deliver safe
and effective SaMD.
A SaMD organization may, for example, outsource customer service as a process, or outsource
the development activity for a particular module of the SaMD. As with any outsourcing strategy,
the following are considerations that are commonly achieved through the use of contractual
terms in order to provide confidence in the services and products delivered to manage or mitigate
patient safety risk of SaMD:
 Understand the capabilities and competencies of potential outsourcing suppliers;
 Clearly communicate the roles and responsibilities of the outsourcing supplier;
 Extensively define the quality requirements for the outsourced process, activity, or
product;
 Clearly establish upfront the criteria for and review of deliverables, frequency of
intermediate inspections, and relevant audits of the supplier; and
 Select and qualify the appropriate outsourcing supplier to deliver safe and effective
SaMD.
When a SaMD organization plans to procure a COTS product, such as a third-party database for
integration in its SaMD, or procure another SaMD to be integrated as a module, the following are
examples that may enhance the understanding of the effect of these decisions and help manage
the resultant effect on the SaMD:
 Understanding the capabilities and limitations of the COTS product can inform the
management of the risks, design choices, and extent of verification and validation needed
for the SaMD; and
 Understanding the processes/methods/frequency that the COTS manufacturer employs to
update, enhance, or make corrections to its products should be used to inform the
selection of the COTS product and the potential effect on the SaMD manufacturer’s QMS
processes and activities.
Example: Magna and Parva have historically used open-source code or other COTS code as
part of product development. In the development of SaMD, it is critical for both Magna and
Parva to properly verify and validate the integration of open source code or COTS code. When
appropriate, it is also critical to formally evaluate, document, and periodically audit suppliers to
ensure compliance with QMS requirements. Both companies are also responsible for monitoring
and managing the potential for defects in the COTS, as these defects can contribute to the
overall risks of the SaMD and may introduce threats to the larger system within which the SaMD
resides. Regardless of the type of code that is used and who is supplying the code, Magna and
Parva are ultimately responsible for the safety and performance of the SaMD.
The concepts presented in this section relate to clauses 7.4, 7.4.1, 7.4.2, 7.4.3, and 8.5.1 in ISO
13485:2003.

8.0 SaMD Realization and Use Processes

This section identifies key lifecycle processes 7 that SaMD Realization and Use Processes
should be identified in the methodologies used in an
organization that manufactures SaMD. SaMD Lifecycle Support Processes
Leadership and Organization Support

The following are important perspectives that should be
considered for each of the activities in this section.
 SaMD lifecycle support processes in Section 0 (product planning; risk management: a
patient safety focused approach; document and record control; configuration management
and control; measurement, analysis and improvement of processes and product;
managing outsourced processes and products) should be applied throughout the SaMD
realization and use processes.
 This section highlights those activities commonly found in software engineering lifecycle
approaches (process, activities, tasks, etc.) that are important for an effective SaMD QMS.
 The activities presented in this section should be included irrespective of methodology
used. The presentation of the material does not imply executing the activities in a serial
fashion or as discrete phases in the SaMD project; rather, these activities should be
looked upon as elements to be addressed as part of any development methodology
employed.
The concepts presented in this section relate to clause 7 in ISO 13485:2003.
Requirements Management
Developing appropriate requirements helps to ensure that SaMD will satisfy the needs across the
socio-technical environment including those of users and patients. These clinical needs should be
clearly articulated and the requirements captured in line with the intended use of SaMD as
characterized by the "state of the healthcare situation or condition" and the "significance of
information provided by SaMD to the healthcare decision" and the resulting impact to patient
and public health as identified in IMDRF SaMD WG N12.
This is a customer-driven process that requires clear, and often repeated, customer interaction to
understand the user needs. These user needs are then translated into requirements.
Well-documented requirements can then inform the testing activities later in the design cycle.
There are other sources of requirements that can include regulatory or non-customer specified
performance requirements.
7
IEC 62304:2006 is one commonly used software development lifecycle standard that can be used to develop a
medical device software lifecycle process.

Patient Safety and Clinical Environment Considerations

 SaMD is used in various clinical and home use environments and, consequently, in
addition to functional requirements, there are requirements that include considerations of
patient/user safety. Some requirements originate from the risk-management process that
evaluates risks to patients and users, and which may identify mitigations that become part
of the requirements.
 Further considerations need to be given to the integrity of data used in the SaMD which
may result in specific requirements to ensure that data is secure and to mitigate against
the loss or corruption of sensitive data.8
 Requirements for SaMD often need to include additional and specific requirements for
performing upgrades that consider potential effects on peripheral components of the
system as well as appropriate notification and coordination with customers.9
Technology and Systems Environment Considerations
 SaMD runs on an underlying platform and operating system, often from a third party, the
functionality of which should be considered as part of the requirements, as the platforms
and operating systems can be potential sources of harm.
 Requirements may also need to define non-functional aspects of a system such as service
or performance related requirements for the hardware platforms that may host the SaMD
or means of connecting/networking to the wider environment.
 Requirements should be captured in concert with stakeholders (patients, clinicians, end
users, etc.) in the process of use of the SaMD.
Note: Requirements may change as the developer better understands how the SaMD functions in
the clinical environment and how a customer uses it. Consequently, it is important to apply
usability engineering principles to the formative development and testing of the software to
ensure that the requirements were appropriately translated into design inputs.
Example: The definition and maintenance of requirements are important in ensuring that the
product meets its intended use. For Magna and Parva, requirements serve the purpose of
clearly defining what is to be developed in their respective SaMD products. In the case of Magna,
a cross-functional product team leverages existing document templates to capture requirements
and an existing document-review process to approve the requirements for use. In the case of
Parva, screen shots, sketches, and rapid prototypes are used to refine and capture the product
requirements for the SaMD features. In both cases, the requirements are captured in a way that
ensures that user, patient, and regulatory requirements are satisfied/met.
The concepts presented in this section relate to clauses 7.2.1, 7.2.2, 7.2.3, 4.2, and 7.1d in ISO
13485:2003.
8
IMDRF SaMD WG N12: Section 9.3—Information security with respect to safety considerations
9
IMDRF SaMD WG N12: Section 8.2—Changes

Design
The purpose of the design activity is to define the architecture, components, and interfaces of the
software system based on user requirements, and any other performance requirements, in line
with the intended use of the SaMD and the various clinical and home use environments it is
intended to operate in.
The requirements are analyzed in order to produce a description of the software’s internal
structure that will serve as the basis for its implementation. When complete, the SaMD design
activity should describe the software architecture, i.e., how the software is decomposed and
organized into its components, including considerations for safety critical elements, the
interfaces between those components (and any external elements), and a sufficiently detailed
description of each component.
One of the key aspects of the design process is to arrive at a clear and concise design solution
that is an effective, well described (e.g., captured in software requirements specifications) logical
architecture that best meets the user needs and that enables other lifecycle processes and
activities such as development, verification, validation, safe deployment, and maintenance of the
SaMD.
Building quality into SaMD requires that safety and security should be evaluated within each
phase of the product lifecycle and at key milestones. Security threats and their potential effect on
patient safety should be considered as possible actors on the system in all SaMD lifecycle
activities.
The goal is to engineer a system that: a) maintains patient safety and the confidentiality,
availability, and integrity of critical functions and data; b) is resilient against intentional and
unintentional threats; and c) is fault-tolerant and recoverable to a safe state in the presence of an
attack.
 Where a SaMD will be used—in the home, at the hospital bedside, in a physician's office
or clinic—the users (e.g., patients, clinicians, and others who may interact or use the
SaMD) should be considered in the design activities.
 Clinical hazards already identified should be an input in the design phase.
 Architectural design may be driven by the safety critical nature of SaMD and by the risk-
mitigation solutions. Risk mitigation solutions may include segregation of specific
functions into particular modules that are isolated from other areas/modules of the
software.
 SaMD design should have appropriate controls in place to ensure robustness in the event
of unanticipated upgrades of the underlying platform.
 SaMD design should include consideration and the taking of appropriate measures when
integrating or using software components or infrastructure with limited or uncontrollable
knowledge of capabilities and limitations, such as legacy software, undocumented
application programing interfaces (API), and wireless network infrastructure.

Such measures should identify the risks that could be introduced to the SaMD product
and the extent of implications to the design of the SaMD.
 External resources, sensors, and services used by high-risk aspects of the application
should be abstracted such that automated testing can be performed based on consistently
simulated values and that operational health considerations can be enforced as a separated
concern through mitigated access and mutually understood error conditions.
Example: Magna has a structure within its software department that enables it to distribute the
design of different software modules amongst different teams. These teams work in parallel to
each other with the interface considerations of the modules being discussed as a specific activity
at pre-defined points in the design phase. Parva use uses one multi-disciplined team to develop
the design. The company develops its design in an iterative way and considers the internal
interfaces as each design effort is complete. Both companies complete their design activity in a
controlled and effective manner.
The concepts presented in this section relate to clauses 7.3, 7.3.2, 7.3.3, 7.3.4, 7.3.7 and 7.3.1b in
ISO 13485:2003.
Development
The development activity transforms the requirements, architecture, design (including interface
definition), recognized coding practices (secure), and architecture patterns into software items
and the integration of those software items into a SaMD.
The result is a software item/system/product that satisfies specified requirements, architecture,
and design. Good development practice incorporates appropriate review activities, (e.g. code
review, peer review, creator self-review) and follows a defined implementation strategy (e.g.,
build new, acquire new, re-use of existing elements). Design changes resulting from the review
activity or development activity should be adequately captured and communicated to ensure that
other development and QMS activities remain current.
Use of appropriately qualified automated tools and supporting infrastructure is important for
managing configuration and having traceability to other lifecycle activities.
 The implementation of clinical algorithms adopted should be transparent to the user in
order to avoid misuse or unintended use.
 The implementation of proper access controls and audit trail mechanisms should be
balanced with the usability of SaMD as intended.
 Development activity should leverage the inherent nature of SaMD that allows for
efficient methods to understand the user’s environment and prevent and manage failures.
 Attention to detail is critical in areas of underlying implementation of the algorithm—a
simple data overwrite can potentially lead to an adverse event. Some examples of these

critical areas include: memory usage and allocation, dependency on communication,

speed of operation, and prioritization of tasks.
 Many SaMD deal with data entry, and the methods through which data is validated and
the effect on the downstream data consumer is an important SaMD consideration.
 As SaMD runs on an underlying platform, rigorous and strict adherence to development
guidance as set forth by the platform developer should be followed to ensure backward
compatibility.
Example: For both Magna and Parva, coding is central to the delivery of the companies’ SaMD
product. Magna conducts peer code reviews for SaMD by scheduling periodic peer-review
sessions with multiple coders who are not directly involved with the code under review. In the
case of Parva, the company does not have a large coding team, and has only one developer who
is an expert in his or her chosen operating system. The company uses a technique of “design for
code readability”, thereby allowing the code review activity to be conducted with a member of
the team who is not an expert. Both achieve what is required by good software code review
guidelines including the need for independence in the review activity.
The concepts presented in this section relate to clauses 7.3, 7.3.2, 7.3.3, 7.3.4, 7.3.7 and 7.3.1b in
ISO 13485:2003.
Verification and Validation

The verification and validation (V&V) activities should be targeted towards the criticality and
impact to patient safety of the SaMD, as discussed in IMDRF/SaMD WG/N12.
Typically, verification (providing assurance that the design and development activity at each
development stage conforms to the requirements) and validation (providing reasonable
confidence that the software meets its intended use/user needs and operational requirements)
activities ensure that all elements from the SaMD design and development—including any
changes made during maintenance/upgrades—have been implemented correctly and that
objective evidence of this implementation is recorded.
A defined set of V&V activities should focus on the interface of the SaMD to the operating
system, outsourced components, and other dependencies related to the computing platform.
 These V&V activities should include scenarios that cover the clinical user/use
environment (usability, instructions for use, etc.). This can be accomplished, in part,
through structured human factors testing using a subset of patients/clinicians.
 These activities should confirm that software safety elements work properly (i.e., patient
safety / clinical use risk elements, etc.). These activities are also commonly included as
part of user acceptance testing (UAT).
 Confirmation of acceptable failure behavior in the clinical environment should be
established. This may include confirmation of the ability of the software to continue to
operate in the specified degraded modes (e.g., fail-safe, fail-secure, or fail-soft).

 Consideration of a variety of user groups to ensure software can be used by persons of

different demographics.
 The extent of test coverage should be driven by the risk profile of the device determined
by the intended use and SaMD definition statement10.
 Interoperability of components and compatibility to other platforms/devices/interfaces,
etc. with which SaMD works should be considered.
 Adequate coverage and traceability to the known hazard-related functions of SaMD
should be provided.
 The coverage of boundary conditions and exceptions (robustness, stress testing, data
security, integrity, and continuity of SaMD availability) should be included.
 Companies should employ rigorous impact analysis of changes made to SaMD (i.e.,
regression testing) to ensure updates do not compromise the safety, effectiveness, and
performance of SaMD.
Example: In both Magna and Parva, testing coverage and regression testing are important.
Magna has a number of test engineers that execute the test plans and regression testing while
monitoring coverage. Parva invested in a test automation tool that allows continuous test/build
cycle which monitors coverage and regression testing on each checked-in build. Where
automation is not possible an independent software developer runs the manual test suite prior to
each release. Both companies achieve the appropriate level of test coverage with the necessary
levels of independence.
The concepts presented in this section relate to clauses 7.3.5, 7.3.6 and 7.4.3 in ISO 13485:2003.
Deployment
Deployment activities include aspects of delivery, installation, setup, and configuration that
support a controlled and effective distribution of SaMD to the customer, including any planned
risk mitigation for hazards identified throughout the SaMD lifecycle support processes and
SaMD realization and use processes.
Some aspects of deployment activities may need to be performed every time a SaMD is
distributed to the user (e.g., distributing an upgrade or fix as a result of maintenance activity).
In some cases, especially when SaMD is a large system or is part of a large system, the
deployment activities may depend on an extensive collaborative effort with the user (which can
include training the users) for an effective use of SaMD or the system.
 Deploying SaMD into a clinical environment can require considerations of peripheral
components if it is intended to be part of a clinical IT network, such as establishing
10
IMDRF SaMD WG N12: Section 6—SaMD Definition Statement.

platform and OS requirements as well as responsibility agreements. The deployment

activity should be clearly defined for the customer as the cooperation of hospital IT,
integration engineers, clinical engineers, hospital risk managers and others who often
may not be part of a typical deployment of other products may often be required.
 Deployment needs to consider the end user and use environment(s) of SaMD.
This would be particularly true if used in the home. The deployment activity needs to be
tailored to the user’s abilities and background. Appropriate human factors engineering
practices can aid in understanding this aspect and would affect the user requirements
capture activity.
 Where possible, user documentation and user training materials should identify any
limitations with SaMD. These may include limitations of the algorithm, provenance of
data used, assumptions made, etc., that should be considered during deployment.
 There should be communication of relevant information to enable correct installation and
configuration of the SaMD for appropriate integration with clinical workflows. This can
include instructions on how to verify the appropriateness of the installation and update to
SaMD as well as any changes made to the system environment.
 Deployment should also include the collection of the settings and the environment of
each installation for configuration management. This information should be maintained
throughout the life of SaMD at each installation.
 Deployment of SaMD when installed on specific platforms should be according to the
intended use that was verified and validated.
 Processes should be in place to ensure the appropriate and correct version is delivered to
the user.
 The choice of deployment method should consider the integrity of the SaMD to ensure
that the software can be delivered in a secure and reliable manner.
 Deployment methods and procedures should ensure repeatability of SaMD delivery,
installation, setup, configuration, intended operation, and maintenance.
 Methods that confirm that the software is delivered consistently and comprehensively and
that it is used in a defined environment are also important. Non-technical measures may
have to be implemented as part of the software product package for deployment.
 When deploying an update to SaMD, updating user manual(s), anomaly lists, or
providing training may be necessary.
Note: Non-technical measures can include warning/confirmation dialogs, warning displays,
usage notes, and user training requirements.
Example: For Both Magna and Parva, when a SaMD is deployed on ‘the cloud’ or a mobile
platform, it is critical to ensure integrity of the deployment activity with an extended network of
stakeholders. For instance, a SaMD application that is designed for use on a smart phone should
be supported with proper processes and documentation that include parties such as app stores

and private app clouds, as well as third-party hosting service providers, etc. Unlike the
deployment of general consumer software, for example, these extended deployment stakeholders
should be qualified and integrated per the QMS requirements for outsourcing and third-party
supplier management.
The concepts presented in this section relate to clauses 7.2.3, 7.5, 7.5.1.2.1, 7.5.1.2.2, 7.5.1.2.311
and 7.5.5 in ISO 13485:2003.
Maintenance
Maintenance includes activities and tasks to modify a previously deployed SaMD. Maintenance
activities can be adaptive, perfective, preventive, and corrective activities originating from
software lifecycle processes and activities including in-service monitoring, customer feedback,
in-house testing or other information, or changes to user requirements or changes in the socio-
technical environment.
When a previously deployed SaMD requires maintenance, all appropriate SaMD lifecycle
support processes, and SaMD realization and use processes should be considered. Maintenance
activities should preserve the integrity of the SaMD without introducing new safety,
effectiveness, performance, and security hazards.
To effectively manage the maintenance activities and any resulting changes and their effect on
SaMD, a risk assessment should be performed to determine if the change(s) affect SaMD
categorization and the core functionality of SaMD as outlined in the SaMD definition
statement.12
 Within the context of SaMD it is important to understand how systems, software, context
of use, usability, data, and documentation might be affected by changes, particularly with
regards to safety, effectiveness, and performance.
 The SaMD manufacturer should take into account implications and introduction of
patient safety risk as a result of changes to architecture and code.
 As highlighted in other SaMD lifecycle processes and SaMD lifecycle activities, people,
technology, infrastructure, and new hazards resulting from implementation and use
activities should be considered.
 It is important to understand the effect of the change on patient safety and the need for
addressing the change in a timely manner when appropriate.
11
For software products, capabilities like performance, security and safety heavily depend on the computing
environment and platforms put in place. The use context and the processes used with the software product will
generally influence the above capabilities. Though at the time of deployment or runtime the SaMD organization may
have little or no technical control over such factors, the SaMD organization's hazards or mitigations analysis should
consider the socio-technical aspects of the intended use and the intended/foreseeable use context of the SaMD
12
IMDRF SaMD WG N12 - Section 8.2 Changes


 There should be processes that manage risk arising from changes to system, environment,
and data.
 SaMD manufacturers should make it feasible for users to safely implement information
security updates.
 Instructions for users related to information security should include how to safely update
security software/spyware, operating environment, and other systems and applications,
etc.
Example: Magna has a process that controls change of its SaMD through a change-control
board. This is a multi-disciplined team that meets at regular intervals to review the change
requests and recommend (or reject) them for incorporation in the next version of software.
Parva has assigned its project manager to act as a customer representative; as part of this role,
she reviews the feedback items received and adds any relevant issue to the backlog of the next
release. Both companies prioritize the change requests to ensure that any significant issues are
dealt with in a timely manner.
The concepts presented in this section relate to clauses 7.2.3, 7.5, 7.5.1.2.3, 7.5.4, 7.6 and 8.2.1
in ISO 13485:2003.
Decommissioning (Retirement or End-of-Life Activity)

The purpose of decommissioning activities is to terminate maintenance, support, and distribution
of SaMD in a controlled and a managed fashion. Although not specifically mentioned in ISO
13485 as a clause, the standard does require planning of product realization in the design which
would include decommissioning.
Decommissioning activities are important to minimize the impact to patient and public health
safety as a result of retiring the SaMD. These activities may include aspects of configuration
management that apply to the document; source code or the delivered SaMD; and
communicating a plan to the user for gracefully terminating maintenance and support of SaMD.
This process indicates an end to active support, and may entail deactivation and/or removal of
SaMD and its supporting data. The decommissioning of SaMD data is of special importance.
While the product and/or access may be terminated, there may be country specific requirements
for managing the data.
 Provide clarity to users which services (e.g., bug fixes, updates, patches, technical
support, etc.) will be available once end-of-life (EOL) is signed-off.
 Appropriately safeguard patient data and any other confidential data. This may include
removal, migrating patients to a new SaMD or another product, safe archival of user
information, etc.


 Inform customers of important EOL milestones, with sufficient lead-time for users to find,
evaluate, and qualify possible alternatives.
 Archive a user's environment in an agreed-upon state, which may include steps to protect
the security and integrity of information and/or systems.
Example: For both Magna and Parva, it is necessary to have procedures that ensure effective
decommissioning, documentation, and data archival for SaMD products. Both have a process
that asks for a decommissioning plan to be created. This plan takes consideration of the
following points to arrive at an effective solution for decommissioning a SaMD:
 What minimum retention time periods are defined by each territory in which the devices
are marketed;
 Will any data be migrated onto new/replacement devices/software systems and, if so, will
any data conversion be needed and how will this be validated;
 Will the SaMD be withdrawn or will it be only a withdrawal of support for the device;
 How sensitive legacy data (patient information, etc.) will be securely stored; and
 How the users of the device that is to be decommissioned will be informed and supported.
In this way both companies can make the appropriate decisions to effectively and gracefully plan
the decommissioning of their devices.
The concepts presented in this section relate to clauses 4.2, 7, and 7.5.1.1 in ISO 13485:2003.

Appendix A: Mapping Medical Device Regulations to IMDRF/SaMD WG/N23

The following table provides a mapping of applicable clauses, articles, and subsections of the
regulations for a QMS for SaMD for the jurisdictions represented in the current IMDRF SaMD
WG members. It is important to note that not all jurisdictions may require demonstration of
compliance to a QMS for all types of medical devices. Regulatory requirements may also permit
exclusions or provide alternative arrangements to be addressed in a QMS. It is the responsibility
of the organization to ensure conformity with appropriate jurisdictional regulatory requirements.
The objective of this table is to share how QMS requirements map to the elements presented in
the IMDRF/SaMD WG/N23 when compliance to a QMS is required in the specified jurisdictions.
Applicability to Health Canada regulations:
 The Medical Devices Regulations require class II, III and IV medical devices to be
manufactured (class II) or designed and manufactured (class III & IV) under CAN/CSA ISO
13485:2003.
Applicability to Europe Union regulations:
 EU legislation foresees the QMS to be assessed by third parties only for certain classes of
products.
 EN ISO 13485:2012 Annexes ZA, ZB, ZC specify in detail which parts of the relevant
Annexes to Directive 90/385 (Active Implantable Medical Devices (AIMD) Directives
93/42 (Medical Device Directive (MDD) and 98/79 (In Vitro Diagnostic Directive (IVDD)
align to clauses of ISO 13485:2012.
 Note: MEDDEV Guidance 2.1/6 Guidelines On The Qualification And Classification Of
Stand Alone Software Used In Healthcare Within The Regulatory Framework Of Medical
Devices", while not binding, constitutes a significant additional reference.
Applicability to Australian regulations:
 The Therapeutic Goods (Medical Devices) Regulations 2002 require manufacturers to
demonstrate compliance with appropriate conformity assessment procedures as specified in
Division 3.2, three of which require implementation of a QMS.
 The Conformity assessment standards order (standard for quality management systems and
quality assurance techniques) 2008 enables the use of ISO13485 to demonstrate compliance
with applicable clauses of those procedures. Mapping is as per the following table key:
[Code]—Procedure name (legislative reference):
o [P5]—Product Quality Assurance procedures (Schedule 3, Part 5, Clause 5.4)
o [P4]—Production Quality Assurance procedures (Schedule 3, Part 4, Clause 4.4)
o [P1]—Full Quality Assurance procedures (Schedule 3, Clause Part 1, 1.4)
o [All]—required for all (Product, Production, and Full Quality Assurance) conformity
assessment procedures
 The # symbol is used to indicate clauses of ISO 13485 considered to additionally be
applicable to software medical devices under Australian legislation.

Japan
Brazil China
ISO MHLW US 21
N23 Topic Australia RDC MD GMP
13485:2003 QMS CFR
16/2013 ([2014]64)
Ordinance
5.0--SAMD QUALITY Quality management strategy 4 2.1 3,24 5 820.5
MANAGEMENT All
Management responsibility 5 5-7,78
PRINCIPLES
6.0--SAMD LEADERSHIP AND ORGANIZATIONAL SUPPORT
Management responsibility 5
2.2.5,
Management commitment 5.1 6 10 820.20b
2.2.6
Customer focus 5.2 11
6.1--LEADERSHIP AND Quality policy 5.3 2.2.1 6 12 820.20a
ACCOUNTABILITY IN Quality planning 5.4 All 6 13, 14 820.20d
THE ORGANIZATION Responsibility and authority 5.5 2.2.3 5 15 820.20b1
Management representative 5.5.2 2.2.5 7 16 820.20b3
Internal communication 5.5.3 2.2.1 17
Management review 5.6 2.2.6 78 18, 19, 20 820.20c
Internal audit 8.2.2
6.2--RESOURCE AND
INFRASTRUCTURE Resource Management 6 All
MANAGEMENT
Provision of resources 6.1 2.3 6 21 820.20b2
6.2.1--PEOPLE All
Skill management 6.2 2.3 8-10 22, 23 820.25
6.2.2-- Infrastructure 6.3 5.1 12-23 24 820.70f,g
INFRASTRUCTURE
All
AND WORK Work environment 6.4 5.1 11 25 820.70c
ENVIRONMENT
7.0--MANAGING SaMD LIFECYCLE SUPPORT PROCESSES
Quality planning 5.4 All 6 13 820.20d
7.1--PRODUCT 820.30a,
Planning of product realization 7.1 All 4.1 28,29 26
PLANNING 70a
Design planning 7.3.1 P1 4.1 28,29 30 820.30a,b

Japan
Brazil China
ISO MHLW US 21
13485:2003 QMS CFR
16/2013 ([2014]64)
Ordinance
7.2--RISK
MANAGEMENT: A
Planning of product realization 7.1 All 2.4 4,38 26-5, 26-6 820.30g
PATIENT SAFETY
FOCUSED PROCESS
Quality system record 3.1.6 24 820.186
Documentation requirements - General 4.2.1 24 6 820.20e
7.3--DOCUMENT
Quality manual 4.2.2 2.2.1 24 7 820.20e
CONTROL AND All
Document control 4.2.3 3.1 25,26 8 820.4
RECORDS
Control of records 4.2.4 3.1.6.2 27 9 820.18
Device master record 4.2 50 6-2 820.181
Document control 4.2.3 All 3.1 25,26 8 820.4
Control of records 4.2.4 All 3.1.6.2 27 9 820.18
Control of design and development
7.3.7 P1 4.1.10 37 36 820.30i
7.4--CONFIGURATION changes
MANAGEMENT AND Production and service provision - 820.70a,g,
7.5.1.1 All 5.1 45,46 40
CONTROL General requirements I,h
Identification 7.5.3.1 All 6.4 51 47 820.6
Traceability 7.5.3.2 All 6.4 53 48 820.65
Status identification 7.5.3.3 All 52 50 820.86
Measurement, analysis, and improvement 8
2.2.5.1,
Conformity assurance 8.1 78 54 820.8
2.2.6
66
7.5--MEASUREMENT, 7.2 71 820.198
Feedback 8.2.1 55
ANALYSIS AND 7.2.1.4,
75,76 822
IMPROVEMENT OF 7.2.1.5
All
PROCESSES, Internal audits 8.2.2 7.3 77 56 820.22
ACTIVITIES AND Process monitoring 8.2.3 7.3, 2.2.6 57 820.70a
PRODUCT Product monitoring 8.2.4 7.3, 2.2.6 59,60 58 820.8
Nonconforming product 8.3 6.5 67-70 60 820.9
Data analysis 8.4 2.2.6, 9 73 61 820.25
Improvement 8.5
Improvement - General 8.5.1 2.2.1 71,76 62

Japan
Brazil China
ISO MHLW US 21
13485:2003 QMS CFR
16/2013 ([2014]64)
Ordinance
Improvement - General 8.5.1 7.2 72,75 62 803
Corrective action 8.5.2 7.1 74 63 820.1
Preventive action 8.5.3 7.1 74 64 820.1
Customer communication 7.2.3 7.2 66,71 29
7.3.7 P1 4.1.10 820.70b
changes
Production and service provision -
7.5.1.1 All 4.1.11 62 820.184
General requirements
Purchasing process 7.4 2.5 39,40 37 820.5
7.6--MANAGING
Vendor evaluation 7.4.1 2.5.2 41,42 37 820.50a
OUTSOURCED
Purchasing information 7.4.2 2.5.1 43 38 820.50b
PROCESSES, All
Verification of purchased product 7.4.3 2.5.4 44 820.8
ACTIVITIES AND
PRODUCTS Improvement - General 8.5.1 2.2.1 71,76 62
Improvement - General 8.5.1 7.2 72 ,75 62 803
8.0--SAMD REALIZATION AND USE PROCESSES
Customer requirements capture 7.2.1 4.1.3 27
Contract review 7.2.2 4.1.6 28
Quality system record 3.1.6 24 820.186
8.1--REQUIREMENTS Documentation requirements - General 4.2.1 24 6 820.20e
All
MANAGEMENT Quality manual 4.2.2 2.2.1 24 7 820.20e
Document control 4.2.3 3.1 25,26 8 820.4
Control of records 4.2.4 3.1.6.2 27 9 820.18
Documentation requirements - General 4.2.1 4.2 50 6-2 820.181
Requirements records 7.1d 24
Design and development 7.3
Design inputs 7.3.2 4.1.3 30 31 820.30c
Design and development outputs 7.3.3 4.1.5 31 32 820.30d
8.2--DESIGN + 8.3-- Design and development outputs 7.3.3 4.1.11 820.30j
P1
DEVELOPMENT Design review 7.3.4 4.1.6 33 33 820.30e
Design transfer 7.3.1b 4.1.7 32 30-3-2 820.30h
7.3.7 37 36
changes

Japan
Brazil China
ISO MHLW US 21
13485:2003 QMS CFR
16/2013 ([2014]64)
Ordinance
Design verification 7.3.5 P1 4.1.4 34 34 820.30f
8.4--VERIFICATION
Design validation 7.3.6 P1 4.1.8 35,36 35 820.30g
AND VALIDATION
Verification of purchased product 7.4.3 All 2.5.6 44 39 820.80b
Production and service provision
Contamination control 7.5.1.2.1 6.2.1 48 41 820.70e
All
8.5—DEPLOYMENT Installation 7.5.1.2.2 8.1 65 42 820.17
Distribution 7.5.5 6.3 62 820.16
Servicing 7.5.1.2.3 8.2 64 43 820.2
Production and service provision
Servicing 7.5.1.2.3 8.2 64 43 820.2
8.6--MAINTENANCE Customer property (confidential health All
7.5.4 51
information)
Monitoring & measuring devices 7.6 5.4 56-58 53 820.72
Feedback 8.2.1 66 55
Control of records 4.2.4 3.1.6 24 820.186
Documentation requirements - General 4.2.1 24 6 820.20e
Quality manual 4.2.2 2.2.1 24 7 820.20e
8.7-- Document control 4.2.3 3.1 25,26 8 820.4
All
DECOMMISSIONING Control of records 4.2.4 3.1.6.2 27 9 820.18
7.5.1.1 4.2 50 6-2 820.181
Product realization 7

The following clauses are not specifically addressed in this document:
Japan
ISO Brazil China
Australia MHLW US 21
N23 Topic 13485:2003 15 RDC MD GMP
13, 14 QMS CFR
16/2013 ([2014]64)
Ordinance
Control of production and service
7.5.1.2 All# 47 41
provisions
Process validation 7.5.2 P1#, P4# 49 45 820.75
Traceability documentation 7.5.3.2.1 All# 48
Requirements for active implantable 7.5.3.2.2 49

#
Status identification 7.5.3.3 All 50
Device packaging 7.5.5 All# 55 820.13
Handling 7.5.5 All# 55 52 820.14
Storage 7.5.5 All# 55 820.15
These clauses are not Monitoring and measurement 8.2.4.1 All# 58
specifically addressed by
N23 Monitoring and measurement of active
8.2.4.2 59
implantable
Sterilization records 7.5.1.3 44 820.184
Production personnel 820.70d
7.5.1.1 P1#, P4# 820.12
Issue and implementation of advisory
All# 806
notices
Medical device tracking 821
Device classification 860
Label design 801

Final Document
Title: Software as a Medical Device (SaMD): Clinical Evaluation

Authoring Group: Software as a Medical Device Working Group
Date: 21 September 2017
J. Patrick Stewart, IMDRF Chair
This document was produced by the International Medical Device Regulators Forum. There are
no restrictions on the reproduction or use of this document; however, incorporation of this
document, in part or in whole, into another document, or its translation into languages other than
English, does not convey or represent an endorsement of any kind by the International Medical
Device Regulators Forum.
Copyright © 2017 by the International Medical Device Regulators Forum.

_____________________________________________________________________________________________
Table of Contents
1.0 Executive Summary .......................................................................................................4
2.0 Background ....................................................................................................................6
3.0 Introduction ....................................................................................................................7
4.0 Scope ...............................................................................................................................8
5.0 Definitions .......................................................................................................................9
5.1 Clinical Evaluation of a SaMD .........................................................................................9
5.2 Valid Clinical Association of a SaMD ..............................................................................9
5.3 Analytical / Technical Validation of a SaMD ...................................................................9
5.4 Clinical Validation of a SaMD ....................................................................................... 10
6.0 General Principles and Context of SaMD Clinical Evaluation Process ..................... 11
6.1 SaMD Definition Statement and SaMD Category ........................................................... 11
6.2 Clinical Evaluation Processes ......................................................................................... 12
7.0 SaMD Clinical Evaluation Process Flow Chart .......................................................... 13
7.1 Considerations for Generating and Assessing Evidence .................................................. 15
8.0 Importance of Independent Review of a SaMD’s Clinical Evaluation ....................... 16
9.0 Pathway for Continuous Learning Leveraging Real World Performance Data ....... 18
9.1 Considerations for Continuous Learning Leveraging Real World Performance Data ...... 19
Appendix – Comparison of SaMD Clinical Evaluation Process to Process for Generating
Clinical Evidence for IVD Medical Devices in GHTF/SG5/N7:2012 [13] ................................ 21
References................................................................................................................................ 22
Glossary ................................................................................................................................... 24

_____________________________________________________________________________________________
Preface

_____________________________________________________________________________________________
1.0 Executive Summary

This document is the fourth issued by the International Medical Device Regulatory Forum
(IMDRF) that provides a path for global regulators to converge on terminology, a risk-based
framework, an understanding of quality management system principles, and in this document, an
approach to making Software as a Medical Device (SaMD) clinically meaningful to users1. This
document focuses on the activities needed to clinically evaluate SaMD -- and relies on the reader
to gain knowledge from the previous documents as a pre-requisite to this document.
This document, and previous documents, provides harmonized principles for individual
jurisdictions to adopt based on their own regulatory framework. They are not regulations.
This document describes a converged approach for planning the process for clinical evaluation of
a SaMD (software with a medical purpose as defined in SaMD N10[1]2), as illustrated in Figure 1,
to establish that:
 There is a valid clinical association between the output of a SaMD and the targeted
clinical condition (to include pathological process or state); and
 That the SaMD provides the expected technical and clinical data.
Clinical Evaluation
Valid Clinical Association Analytical Validation Clinical Validation

Does use of your SaMD’s
Is there a valid clinical Does your SaMD correctly accurate, reliable, and precise
association between your process input data to generate output data achieve your intended
SaMD output and your accurate, reliable, and precise purpose in your target population
SaMD’s targeted clinical output data? in the context of clinical care?
condition?
Figure 1 - Clinical Evaluation Process
The knowledge gained from previous documents is critical to the understanding of information
in this document. This document builds on previously introduced vocabulary, risk-based
considerations, and SaMD lifecycle processes and activities to help emphasize the clinical
considerations essential to the success and adoption of SaMD as illustrated in Figure 2.
1
Users include patients, healthcare providers, specialized professionals, lay users, consumers.
2
Internet addresses (URLs) can be found in the References section.

_____________________________________________________________________________________________
Figure 2- SaMD Landscape

_____________________________________________________________________________________________
2.0 Background
The IMDRF has acknowledged that software is an increasingly critical area of healthcare product
development and has developed a series of documents concerning the definition, the
categorization, and the application of quality systems principles of SaMD.
In 2013, IMDRF’s SaMD Working Group released SaMD N10[1] Software as a Medical Device
(SaMD): Key Definitions to create a standard terminology for SaMD. The following year,
IMDRF adopted SaMD N12[2] Software as a Medical Device: Possible Framework for Risk
Categorization and Corresponding Considerations which proposes a method for categorizing
SaMD based on the seriousness of the condition the SaMD is intended to address. In 2015, the
SaMD Working Group published SaMD N23[3] Software as a Medical Device (SaMD):
Application of Quality Management System, outlining how manufacturers should follow Quality
Management System (QMS) Principles for medical devices as well as good software engineering
practices.
Knowledge of the previous three IMDRF SaMD documents is a prerequisite for readers of this
document.
This document, and previous documents, provides harmonized principles for individual
jurisdictions to adopt based on their own regulatory framework. They are not regulations.
The goal, strategy, principles and concepts, and implementation pathway for a harmonized
SaMD framework are illustrated below in Figure 3.
Figure 3 - SaMD Regulatory Pathway

_____________________________________________________________________________________________
3.0 Introduction
The International Medical Device Regulators Forum (IMDRF) seeks to establish a common and
converged understanding of clinical evaluation and principles for demonstrating the safety,
effectiveness and performance of SaMD.
As illustrated in Figure 4, this document represents a global harmonization effort to articulate

this process.
Clinical Evaluation
Valid Clinical Association Analytical Validation Clinical Validation

condition?
Figure 4- Clinical Evaluation Process
The document further explains that:

 Clinical evaluation should be an iterative and continuous process as part of the quality
management system for medical devices (See SaMD N23[3] for more information);
 Certain SaMD may require independent review of the results of the clinical evaluation,
akin to peer review or design review, to ensure that the SaMD is clinically meaningful to
users. The level of evaluation and independent review should be commensurate with the
risk posed by the specific SaMD (See SaMD N12[2] for more information); and
 Software is unique in its level of connectivity, which may allow the continuous
monitoring of the safety, effectiveness, and performance of SaMD. This document
encourages manufacturers to use this feature to understand and modify software based
on real-world performance. (See 9.0 Pathway for Continuous Learning Leveraging Real
World Performance Data for more information).
Healthcare decisions increasingly rely on information provided by the output of SaMD where
these decisions can impact clinical outcomes and patient care. As such, global regulators expect
that performance metrics for a SaMD have a scientific level of rigor that is commensurate with
the risk and impact of the SaMD to demonstrate assurance of safety, effectiveness, and
performance.

_____________________________________________________________________________________________
4.0 Scope
This document focuses on the activities needed to clinically evaluate SaMD -- and relies on the
reader to gain knowledge from the previous documents as a pre-requisite to this document.
Specifically, this document:
 Expects readers to have knowledge of the vocabulary, approach, and common thinking
of previous IMDRF SaMD documents;
 Expects readers to understand that the concepts are limited to SaMD, as defined in
SaMD N10[1], which focuses on software with a medical purpose; and
 Refers to – and paraphrases as needed -- previous Global Harmonization Task Force
(GHTF3) and IMDRF documents that provide a common understanding and application
of terminology, concepts and principles for a clinical evaluation that demonstrates the
performance metrics of a SaMD.
This document does NOT exhaustively address all regulatory requirements relevant to SaMD,
which may vary by jurisdiction (e.g., informed consent, pre-market regulatory review). In
addition, this document does not repeat the following concepts from previous SaMD documents:
 The definition of a SaMD (SaMD N10[1]);

 Examples of SaMD (SaMD N12[2]);
 Where a SaMD fits in the risk categorization and the descriptions of the risk categories
(SaMD N12[2]); and
 Which Quality Management principles are appropriate for SaMD (SaMD N23[3]).
3
GHTF was a voluntary group of representatives from national medical device regulatory authorities and industry
representatives. GHTF was disbanded in 2012 and its mission has been taken over by the IMDRF.

_____________________________________________________________________________________________
5.0 Definitions
5.1 Clinical Evaluation of a SaMD
For purposes of this document “Clinical evaluation of a

Clinical Evaluation
SaMD” is defined as a set of ongoing activities
conducted in the assessment and analysis of a SaMD’s The assessment and analysis of clinical
clinical safety, effectiveness and performance as intended data pertaining to a medical device to
by the manufacturer in the SaMD’s definition statement. verify the clinical safety, performance
and effectiveness of the device when
This definition is consistent with prior SaMD documents used as intended by the manufacturer.
and is adapted from GHTF SG5 N2R8:2007[8]. Figure 5- Clinical Evaluation
Clinical Evaluation see GHTF SG5 N2R8:2007[8]
5.2 Valid Clinical Association of a SaMD
For purposes of this document, valid clinical association, Valid Clinical Association
also known as scientific validity, is used to refer to the Is there a valid clinical association
extent to which the SaMD’s output (concept, conclusion, between your SaMD output and your
measurements) is clinically accepted or well-founded SaMD’s targeted clinical condition?
(based on an established scientific framework or body of
evidence4), and corresponds accurately in the real world Figure 6- Valid Clinical Association
to the healthcare situation and condition identified in the
SaMD definition statement.
A valid clinical association is an indicator of the level of clinical acceptance and how much
meaning and confidence can be assigned to the clinical significance of the SaMD’s output in the
intended healthcare situation and the clinical condition/physiological state. 5
SaMD Definition Statement see Section 6.0 in SaMD N12[2]

SaMD Clinical Considerations see Section 9.1 in SaMD N12[2]
5.3 Analytical / Technical Validation of a SaMD
Analytical validation measures the ability of a SaMD to

Analytical Validation
accurately, reliably and precisely generate the intended
technical output from the input data. Said differently, Does your SaMD correctly process
analytical validation: input data to generate accurate, reliable,
and precise output data?
 Confirms and provides objective evidence that
Figure 7-Analytical Validation
4
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3261486/
5
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2993536/

_____________________________________________________________________________________________
the software was correctly constructed – namely, correctly and reliably processes input
data and generates output data with the appropriate level of accuracy, and repeatability
and reproducibility (i.e., precision); and
 Demonstrates that (a) the software meets its specifications and (b) the software
specifications conform to user needs and intended uses.
The analytical validation is generally evaluated and determined by the manufacturer during the
verification and validation phase of the software development lifecycle using a QMS.
Analytical validation is necessary for any SaMD.
SaMD Verification and Validation see Section 8.4 in SaMD N23[3]
5.4 Clinical Validation of a SaMD

Clinical Validation
Clinical validation measures the ability of a SaMD to yield
a clinically meaningful output associated to the target use Does use of your SaMD’s accurate,
reliable, and precise output data
of SaMD output in the target health care situation or achieve your intended purpose in
condition identified in the SaMD definition statement. your target population in the
Clinically meaningful means the positive impact of a context of clinical care?
SaMD on the health of an individual or population, to be Figure 8-Clinical Validation
specified as meaningful, measurable, patient-relevant
clinical outcome(s), including outcome(s) related to the function of the SaMD (e.g., diagnosis,
treatment, prediction of risk, prediction of treatment response), or a positive impact on individual
or public health.
Clinical validity is evaluated and determined by the manufacturer during the development of a
SaMD before it is distributed for use (pre-market) and after distribution while the SaMD is in use
(post-market).
Clinical validation of a SaMD can also be viewed as the relationship between the verification
and validation results of the SaMD algorithm and the clinical conditions of interest. Clinical
validation is a necessary component of clinical evaluation for all SaMD and can be demonstrated
by either:
 Referencing existing data from studies conducted for the same intended use;
 Referencing existing data from studies conducted for a different intended use, where
extrapolation of such data can be justified; or
 Generating new clinical data for a specific intended use.
Clinical validation is necessary for any SaMD.
SaMD Verification and Validation see Section 8.4 in SaMD N23[3]

_____________________________________________________________________________________________
6.0 General Principles and Context of SaMD Clinical Evaluation Process

A SaMD can best be described as software that utilizes an algorithm (logic, set of rules, or
model) that operates on data input (digitized content) to produce an output that is intended for
medical purposes as defined by the SaMD manufacturer (Figure 9). The risks and benefits posed
by SaMD outputs are largely related to the risk of inaccurate or incorrect output of the SaMD,
which may impact the clinical management of a patient.
SaMD Algorithm
SaMD inputs Algorithm, Inference SaMD outputs

engine,
Patient data Equations, SaMD defined
(Lab results, Image Analysis engine outputs
medical device data, Model based logic, etc. (Inform, Drive,
Physiological status, Diagnose, Treat)
Symptoms, etc.)
Reference data,
Knowledge base,
Rules,
Criteria, etc.
Figure 9 - SaMD Basic Programming Model
6.1 SaMD Definition Statement and SaMD Category
The SaMD definition statement, as defined in SaMD N12[2], is used by the SaMD manufacturer
to identify the intended medical purpose of the SaMD (treat, diagnose, drive clinical
management, inform clinical management), to state the healthcare situation or condition that the
SaMD is intended for (critical, serious, non-serious), and to describe the core functionality of the
SaMD.
The SaMD manufacturer will use the factors identified in the SaMD definition statement to
determine the category of a SaMD in the SaMD categorization framework as illustrated in Figure
10.
Significance of information provided by SaMD to the healthcare decision
State of Healthcare
Drive Clinical Inform Clinical
Situation or Condition Treat or Diagnose
Management Management
Critical IV III II
Serious III II I
Non-Serious II I I
Figure 10 - SaMD N12[2] Framework
SaMD Definition Statement see Section 6.0 in SaMD N12[2]

SaMD Risk Categorization Framework see Section 7.0 in SaMD N12[2]

_____________________________________________________________________________________________
6.2 Clinical Evaluation Processes
A SaMD manufacturer is expected to implement on-going lifecycle processes to thoroughly

evaluate the product’s performance in its intended market. As part of normal new product
introduction processes, prior to product launch (pre-market) the manufacturer generates evidence
of the product’s accuracy, specificity, sensitivity, reliability, limitations, and scope of use in the
intended use environment with the intended user, and generates a SaMD definition statement.
Once the product is on the market (post-market), as part of normal lifecycle management
processes, the manufacturer continues to collect real world performance data (e.g., complaints,
safety data), to further understand the customer’s needs to ensure the product is meeting those
needs, and to monitor the product’s continued safety, effectiveness and performance in real-
world use. This real world performance data allows the manufacturer to identify and correct any
problems, support future expansions in functionality, meet anticipated user demands, or improve
the effectiveness of the device.
Product lifecycle activities, which include clinical evaluation activities as illustrated in Figure 11,
should follow
appropriate
planning processes
as part of an
organization’s
lifecycle activities
and processes, as
described in SaMD
N23[3].
Risk assessment
done as part of the
SaMD’s lifecycle
activities and
processes should
also be considered
when conducting
clinical evaluation.
Figure 11 - SaMD Clinical Evaluation Landscape
Pre-market see GHTF Study Group 1 documents[4]

Post-market see GHTF Study Group 2 documents[5]
SaMD Considerations for Risk Management see Section 7.2 in SaMD N23[3]
SaMD User Needs Intended Use see Section 8.3 of SaMD N23[3]
SaMD Clinical Evidence see Section 8.4 in SaMD N23[3]

_____________________________________________________________________________________________
7.0 SaMD Clinical Evaluation Process Flow Chart

Clinical evaluation is a systematic and planned process to continuously generate, collect,
analyze, and assess the clinical data6 pertaining to a SaMD in order to generate clinical evidence
verifying the clinical association and the performance metrics of a SaMD when used as intended
by the manufacturer. The quality and breadth of the clinical evaluation is determined by the role
of the SaMD for the target clinical condition, and assures that the output of the SaMD is
clinically valid and can be used reliably and predictably.
This section uses simple steps to help SaMD manufacturers through the approach to generating
evidence for the clinical evaluation of a SaMD and provides links to techniques, definitions and
sources that are available to help a SaMD manufacturer generate appropriate evidence.
Note: The examples used are not intended to be comprehensive. All data sources and statistical
methods should be tailored to the specific SaMD and its intended use.
Clinical Evaluation
① Valid Clinical Association ② Analytical Validation ③ Clinical Validation

condition?
Figure 12 - Clinical Evaluation
① Valid Clinical Association:

Examples of existing evidence
Is there a valid clinical association between
your SaMD output, based on the inputs and  Literature searches
algorithms selected, and your SaMD’s  Original clinical research
targeted clinical condition?  Professional society guidelines
Examples of generating new evidence
Step 1: Verify that the association between
the SaMD output and the targeted clinical  Secondary data analysis
condition is supported by evidence.  Perform clinical trials
Note: All SaMD should demonstrate a valid clinical association.

Question: How do I “generate evidence”?
You can verify by using existing evidence or you can verify by generating new evidence.
6
Clinical data is defined as safety and/or performance information that are generated from the clinical use of a
medical device. Source: GHTF SG5 N1R8:2007[7]

_____________________________________________________________________________________________
② Analytical Validation:
Does your SaMD meet technical
requirements? Verification – confirmation through
provision of objective evidence that
Step 1: Generate evidence that shows that
specified requirements have been fulfilled.
the output of your SaMD is technically
Source: GHTF SG3 N18:2010[6] Section 2.7
what you expected.
Note: All SaMD should demonstrate Validation – confirmation through
analytical validation. provision of objective evidence that the
requirements for a specific intended use or
Question: How do I “generate
application have been fulfilled. Source:
evidence”?
GHTF SG3 N18:2010[6] Section 2.8
You can generate evidence during
verification and validation activities as part of your quality management system or as part of
your good software engineering practices, or by generating new evidence through use of curated
databases or use of previously collected patient data.
③ Clinical Validation:
Does your SaMD generate clinically Examples of measures of clinical validation
relevant outputs?
 Sensitivity
Step 1: Generate evidence that shows  Specificity
your:
 Positive predictive value (PPV)
 SaMD has been tested in your  Negative predictive value (NPV)
target population and for your  Number needed to treat (NNT)
intended use; and that
 Number needed to harm (NNH)
 Users can achieve clinically
meaningful outcomes through  Likelihood ratio negative (LR-)
predictable and reliable use.  Likelihood ratio positive (LR+)
 Odds ratio (OR)
Note: All SaMD should demonstrate
clinical validation.  Clinical usability / User Interface
 Confidence interval
Question: How do I “generate evidence”?

You can generate evidence to validate clinical significance during verification and validation
activities as part of your quality management system or as part of your good software
engineering practices, referencing existing data sources from studies conducted for the same
intended use. Where available data references studies conducted for a different intended use,
extrapolation or generation of new clinical data may be required.

_____________________________________________________________________________________________
7.1 Considerations for Generating and Assessing Evidence
Being able to generate evidence to demonstrate the valid clinical association, analytical
validation and clinical validation of a SaMD is essential to establishing the SaMD’s value for
users. The degree of evidence generation needed for a given SaMD will depend on parameters
including but not necessarily limited to the:
 Maturity of evidence underlying the clinical association; and
 Confidence in the evidence, as applied to a specific SaMD.
The purpose of the assessment of the evidence is to select information based on its merits and
limitations to demonstrate that the clinical evaluation evidence is high-quality, relevant, and
supportive of the SaMD intended use.
For example, an assessment of clinical association would classify a SaMD as having either a:
a) Well-established clinical association: These SaMD have outputs with well-documented
association as identified in sources such as clinical guidelines, clinical studies in peer
reviewed journals, consensus for the use of the SaMD, international reference materials
or other similar well-established comparators in terms of previously marketed devices /
SaMD; or a
b) Novel clinical association: These SaMD may involve new inputs, algorithms or outputs,
new intended target population, or new intended use. An example may include the
combination of non-standard inputs such as mood or pollen count, with standard inputs
such as gait, blood pressure or other physiological and environmental signals using novel
algorithms to detect early onset of a deterioration of health or diagnosis of a disease.
What if I can’t generate evidence to demonstrate ①, ②, or ③?
 Perform ongoing data analysis
 Modify your intended use to one that can be supported by available evidence
 Modify the target clinical association
 Make changes to the software

_____________________________________________________________________________________________
8.0 Importance of Independent Review of a SaMD’s Clinical Evaluation

SaMD categories are based on the levels of impact on the patient or public health where accurate
information provided by the SaMD is important to treat or diagnose, drive clinical management
or inform clinical management. For additional information on SaMD categorization, please see
Section 7.0 in SaMD N12[2]. As part of the risk-based approach, and subject to individual
jurisdiction’s laws, independent review of clinical evidence of certain low-risk SaMD may be
less important and the manufacturer may ‘self-declare’ the appropriateness of the evidence.
Again, subject to individual jurisdiction’s laws, independent review of clinical evidence of more
high-risk SaMD is more important in providing users the confidence in the SaMD’s performance
metrics, including but not limited to, identification of design errors or limitation, broadening
technical competence, testing the appropriateness of assumptions, and management of bias.
The recommendation for independent review highlights where the evidence generated from the
clinical evaluation of the SaMD should be reviewed by someone who has not been significantly
involved in the development of the SaMD, and who does not have anything to gain from the
SaMD, and who can objectively assess the SaMD’s intended purpose and the conformity with
the overall clinical evaluation evidence. The level of clinical evaluation and importance of
independent review should be commensurate with the risk posed by the SaMD. This document
recommends where independent review is more or less important.
Figure 13 - Risk Based Approach to Importance of Independent Review
Figure 13 illustrates where independent review is more or less important. In the figure, the red,
vertical dividing line differentiates where independent review is less important and where
independent review is more important for different SaMD categories. Independent review is
more important for SaMD that ‘Treats/Diagnoses Serious and Critical’ health care situations and

_____________________________________________________________________________________________
conditions and SaMD that ‘Drives Critical’ health care situations and conditions. Independent
review in this document does not necessarily imply regulatory review but instead demonstrates
the concept where independence in review of the results is important.
For purposes of this document ‘less important’ independent review is analogous to the concept of
design review performed in the QMS system. Less important independent reviews can be
conducted by individuals within the company or by utilizing outside experts.
For purposes of this document ‘more important’ independent review may be conducted by
outside experts such as formal consultation with regulators, third parties on behalf of regulators,
or the editorial board of a peer-reviewed journal, but may also be conducted by “non-conflicted”
internal expert reviewers without significant involvement in the development of the SaMD.

_____________________________________________________________________________________________
9.0 Pathway for Continuous Learning Leveraging Real World Performance

Data
SaMD may leverage connectivity between devices, and people to continuously monitor the
safety, effectiveness and performance of the SaMD.
A SaMD manufacturer may have a hypothesis about future functionality and intended use of a
SaMD that may be informed by continuously collecting and analyzing data on use of the SaMD
in a post-market setting. Monitoring real world performance data can help the SaMD
functionality and intended use evolve after initial introduction into the market. Such data may
include post-market information such as safety data, results from performance studies, on-going
clinical evidence generation for medical devices, new research publications / results that support
or strengthen the clinical association of the SaMD output to a clinical condition, or direct end-
user feedback, that can help the SaMD manufacturer understand the real world performance of
the SaMD. This may lead to a change to the SaMD definition statement if supported by the
clinical evidence generated through clinical evaluation leveraging real world performance data
from the continuous monitoring as illustrated in Figure 14.
Figure 14 - Pathway for Continuous Learning - Use of Real World SaMD Performance Data in Ongoing SaMD Clinical
Evaluation
Learning may impact the original category of a SaMD in the following ways:
 Real world performance data may provide evidence that the analytical or clinical validity
of a SaMD is superior to the performance measures initially evaluated by the SaMD
manufacturer, or

_____________________________________________________________________________________________
 Real world performance data may provide evidence that analytical or clinical validity of a
SaMD is inferior to the performance measures initially evaluated by the SaMD
manufacturer.
As additional clinical evidence is gathered to confirm the hypothesis and create and support new
intended use, the SaMD manufacturer will update the clinical evaluation and generate a new
definition statement. Then the cycle repeats.
This document encourages SaMD manufacturers to leverage SaMD’s capability to capture real-
world performance data to understand user interactions with the SaMD, and conduct ongoing
monitoring of analytical and technical performance to support future intended uses.
9.1 Considerations for Continuous Learning Leveraging Real World Performance Data
 SaMD should facilitate post-market information gathering to allow for disablement of

existing or enablement of new functionality within the SaMD.
 It is not necessary for the collection of real world performance data by the SaMD
manufacturer to rely on the active involvement of the end user. The SaMD manufacturer
should aim to impose the least burdensome approach possible in its data collection and
leverage the capability of SaMD to collect clinical evidence.
 With ongoing clinical evaluation the risk categorisation may potentially change,
necessitating a change in the SaMD definition statement.
Figure 15 - Change to SaMD category from continuous learning
 Real world performance data including post-market information may not be sufficient to
generate complete clinical evidence necessary for a change to the SaMD definition
statement; as such the SaMD manufacturer should appropriately take into account other
clinical evaluation steps required to support the change in SaMD definition statement.
_____________________________________________________________________________________________
 During the continuous learning across the life cycle, SaMD manufacturers should
consider the recommendations in the previous section on independent review when new
information changes the category of the SaMD as illustrated in Figure 15.
 The “continuous learning” referred to here is not “machine learning software” (i.e., where
software device keeps learning automatically after it has been released into the market);
rather it refers to collecting post-market information.
 Manufacturers should appropriately review the post-market information collected to
determine if there are any changes to the safety, effectiveness or performance, or possible
impact on benefits and risks of the SaMD that would indicate a need for a design change
or a labeling change regarding contraindications, warnings, precautions or instructions for
use. The labeling should identify limitations of the SaMD relevant to its clinical
performance and interpretation of its output in a way that is understood by end users. The
assessment of post-market information may also lead to a change of intended use (e.g.,
expansion, modification, or restriction).
NOTE: A change to the SaMD definition statement may be subject to regulatory requirements in
the individual jurisdiction and a SaMD manufacturer should consult with the regulatory
authorities in their jurisdiction.
SaMD Software Changes see Section 7.5 in SaMD N23[3]

SaMD Continuous Improvement see Section 7.5 in SaMD N23[3]
Medical Devices Post Market see GHTF SG3 N79R11:2009[15]
Medical Devices Observation Studies see Section 6.1 in GHTF SG5 N8:2012[16]

_____________________________________________________________________________________________
Appendix – Comparison of SaMD Clinical Evaluation Process to Process for

Generating Clinical Evidence for IVD Medical Devices in GHTF/SG5/N7:2012[13]
Analogous to
SaMD Valid
Clinical
Association
Analogous to
SaMD Analytical
Validation
Analogous to
SaMD Clinical
Validation

_____________________________________________________________________________________________
References
IMDRF Documents:
1. SaMD N10: Software as a Medical Device (SaMD): Key Definitions --
http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-samd-key-definitions-
140901.pdf
2. SaMD N12: Software as a Medical Device (SaMD): Possible Framework for Risk
Categorization and Corresponding Considerations --
http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-
categorization-141013.pdf
3. SaMD N23: Software as a Medical Device (SaMD): Application of Quality Management
System -- http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-151002-samd-qms.pdf
GHTF Documents:
4. GHTF Pre-market: GHTF Study Group 1 documents -- http://www.imdrf.org/documents/doc-
ghtf-sg1.asp
5. GHTF Post-market: GHTF Study Group 2 documents--http://www.imdrf.org/documents/doc-
ghtf-sg2.asp
6. GHTF SG3 N18:2010: Quality management system –Medical Devices – Guidance on
corrective action and preventive action and related QMS processes --
http://www.imdrf.org/docs/ghtf/final/sg3/technical-docs/ghtf-sg3-n18-2010-qms-guidance-
on-corrective-preventative-action-101104.pdf
7. GHTF SG5 N1R8:2007: Clinical Evidence – Key Definitions and Concepts--
http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n1r8-clinical-evaluation-
key-definitions-070501.pdf
8. GHTF SG5 N2R8:2007: Clinical Evaluation --
http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n2r8-2007-clinical-
evaluation-070501.pdf
9. GHTF SG5 N3:2010: Clinical Investigations --
http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n3-clinical-investigations-
100212.pdf
10. GHTF SG5 N4: Post-Market Clinical Follow-up Studies --
http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n4-post-market-clinical-
studies-100218.pdf
11. GHTF SG5 N6:2012: Clinical Evidence for IVD medical devices – Key Definitions and
Concepts -- http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n6-2012-
clinical-evidence-ivd-medical-devices-121102.pdf

_____________________________________________________________________________________________
12. GHTF SG1 N68:2012: Essential Principles of Safety and Performance of Medical Devices --
http://www.imdrf.org/docs/ghtf/final/sg1/technical-docs/ghtf-sg1-n68-2012-safety-
performance-medical-devices-121102.pdf
13. GHTF SG5 N7:2012: Clinical Evidence for IVD medical devices - Scientific Validity
Determination and Performance Evaluation--
http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n7-2012-scientific-validity-
determination-evaluation-121102.pdf
14. GHTF SG1 N70:2011: Label and Instructions for Use for Medical Devices--
http://www.imdrf.org/docs/ghtf/final/sg1/technical-docs/ghtf-sg1-n70-2011-label-instruction-
use-medical-devices-110916.pdf
15. GHTF SG2 N79R11:2009: Medical Devices: Post Market Surveillance: National Competent
Authority Report Exchange Criteria and Report Form --
http://www.imdrf.org/docs/ghtf/final/sg2/technical-docs/ghtf-sg2-n79r11-medical-devices-
post-market-surveillance-090217.pdf
16. GHTF SG5 N8:2012: Clinical Evidence for IVD Medical Devices - Clinical Performance
Studies for In Vitro Diagnostic Medical Devices --
http://www.imdrf.org/docs/ghtf/final/sg5/technical-docs/ghtf-sg5-n8-2012-clinical-
performance-studies-ivd-medical-devices-121102.pdf
International Standards:
17. ISO 14155:2011: Clinical investigation of medical devices for human subjects -- Good
clinical practice --
http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=45557
18. ISO 14971:2007: Application of risk management to medical devices --
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=31550&ICS
1=11&ICS2=40&ICS3=1
19. ISO 62304/A1: 2015: Medical device software – Software life-cycle processes --
https://www.iso.org/standard/64686.html
20. IEC 62366-1:2015: Medical Devices – Part 1: Application of usability engineering to
medical devices -- https://www.iso.org/standard/63179.html
21. IEC 80002-1:2009: Medical device software -- Part 1: Guidance on the application of ISO
14971 to medical device software --
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=54146
22. ISO 82304-1:2016: Health software – Part 1: General requirements for product safety --
https://www.iso.org/standard/59543.html

_____________________________________________________________________________________________
Glossary
Algorithm -- a finite set of instructions (or rules) that defines a sequence of operations for
solving a particular computational problem for all problem instances for a problem set.
Analytical Validation -- measures the ability of a SaMD to accurately and reliably generate the
intended technical output, from the input data.
Basic Programming -- problem-solving process used to create a computer program.
Claim -- the objective intent of the manufacturer regarding the use of a product, process or
service as reflected in the specifications, instructions and information provided by the
manufacturer.
(Also see Intended Use / Purpose)
Additional resources: see Section 4.0 in GHTF SG1 N68:2012[12]
Clinical Association -- refers to the extent to which the SaMD’s output (concept, conclusion,
measurements) is clinically accepted or well founded (existence of an established
scientific framework or body of evidence) that corresponds accurately in the real world to
the healthcare situation and condition identified in the SaMD definition statement.
(Also see Scientific Validity)
Clinical Considerations -- aspects that can raise or lower the potential to create hazardous
situations to patients.
Additional resources: see Sections 4.0 and 9.1 in SaMD N12[2]
Clinical Data -- defined as safety and/or performance information that is generated from the
clinical use of a medical device.
Additional resources: see GHTF SG5 N1R8:2007[7]
Clinical Evaluation -- the assessment and analysis of clinical data pertaining to a medical device
to verify the clinical safety, performance and effectiveness of the device when used as
intended by the manufacturer.
Additional resources: see GHTF N2R8:2007[8]
Clinical Evidence -- an important component of the technical documentation of a medical
device, which along with other design verification and validation documentation, device
description, labelling, risk analysis and manufacturing information, is needed to allow a
manufacturer to demonstrate conformity with the Essential Principles.
Additional resources: see Section 7.5 in SaMD N23[3] , and GHTF SG5 N8:2012[16],
GHTF SG5 N6:2012[11], GHTF SG5 N1R8:2007[7]
Clinical Performance -- the ability of a device to yield results that are correlated with a
particular clinical condition/physiological state in accordance with target population and
intended user.
(Also see Clinical Validation)
Clinical Research -- use of clinical data generated through clinical use.
_____________________________________________________________________________________________
Additional resources: see Section 6.2 in GHTF G5 N2R8:2007[8]
Clinical Trials -- A properly conducted clinical investigation, including compliance to the
clinical investigation plan and local laws and regulations, ensures the protection of
human subjects, the integrity of the data and that the data obtained is acceptable for the
purpose of demonstrating conformity to the Essential Principles.
Additional resources: see Section 6 in GHTF SG5 N3:2010[9]
Clinical Usability -- the means by which the user and a computer system interact, in particular
the use of input devices and software and the evaluation of safety considerations for
device users, use environments and user interfaces.
Additional resources see ISO/IEC 62366-1:2015[20], SaMD N12[2]Section 4.0, SaMD
N23[3] Section 7.2 and 8.4
(Also see Usability, User Interface)
Clinical Validation -- measures the ability of a SaMD to yield a clinically meaningful output
associated to the target use of SaMD output in with the target health care situation or
condition identified in the SaMD definition statement.
(Also see Clinical Performance)
Continuous Monitoring -- collecting post-market information.
Additional resources: see Section 7.5 in SaMD N23[3]
Confidence Interval -- An interval about a point estimate that quantifies the statistical
uncertainty in the true value being estimated (e.g. an accuracy metric) due to variability
in the subject/sample selection process. A 1 – α level confidence interval contains the true
value in 100(1 – α) % of applications, but in any given application either contains it or
does not.
Critical (situation or condition) -- situations or conditions where accurate and/or timely
diagnosis or treatment action is vital to avoid death, long-term disability or other serious
deterioration of health of an individual patient or to mitigating impact to public health.
Additional resources: see Section 5.2.1 in in SaMD N12[2]
Definition Statement -- clear and strong statement about intended use that explains how the
SaMD meets one or more of the purposes described in the definition of a medical device
and describes the SaMD's core functionality.
Additional resources: see Section 6.0 in in SaMD N12[2]
Diagnose (SaMD output to) -- information provided by the SaMD will be used to take an
immediate or near term action.
(Also see Treat (SaMD output to))
Drive Clinical Management (SaMD output to) -- the information provided by the SaMD will be
used to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or
condition will be used to guide next diagnostics or next treatment interventions.
Additional resources: see Section 5.1.2 in SaMD N12[2]
_____________________________________________________________________________________________
Effectiveness -- when it can be determined that a device, based upon valid scientific evidence,
that in a significant portion of the target population, the use of the device for its intended
uses and conditions of use, when accompanied by adequate directions for use and
warnings against unsafe use, will provide clinically significant results.
(Also see Safety, Performance)
Functionality -- identifies the critical features/functions of the SaMD that are essential to the
intended significance of the information provided by the SaMD to the healthcare decision
in the intended healthcare situation or condition.
Additional resources: see Sections 6.0, 7.3, 8.2, 9.1, and 10.1 in SaMD N12[2]
Global Harmonization Task Force -- was a voluntary group of representatives from national
medical device regulatory authorities and industry representatives. GHTF was disbanded
in 2012 and its mission has been taken over by the IMDRF.
Hypothesis -- a supposition or proposed explanation made as a starting point for further
investigation. Evidence is not necessary to form a hypothesis.
Independent Review -- the process of subjecting a work, research, or ideas to the scrutiny of
others who are experts in the same field.
Inform Clinical Management (SaMD output to) -- Informing clinical management infers that
the information provided by the SaMD will not trigger an immediate or near term action.
Input (SaMD) -- one or several defined numeric tables or models accepted by an algorithm.
(Also see Basic Programming Model, Outputs)
Intended (Medical, Purpose, Use) -- the objective intent of the manufacturer regarding the use
of a product, process or service as reflected in the specifications, instructions and
(Also see Claim)
International Medical Device Regulatory Forum -- a voluntary group of medical device

regulators from around the world who have come together to build on the strong
foundational work of the Global Harmonization Task Force on Medical Devices (GHTF),
and to accelerate international medical device regulatory harmonization and convergence.
Labeling -- the label, instructions for use, and any other information that is related to
identification, technical description, intended purpose and proper use of the medical
device, but excluding shipping documents.
Least Burdensome -- addressing a premarket issue that involves the most appropriate investment
of time, effort, and resources.
Likelihood Ratio Negative (LR-) -- (1 – sensitivity) / specificity = ratio of the probabilities of
testing negative in patients with and without disease or clinical condition. It can be

_____________________________________________________________________________________________
interpreted as the increase in the odds of disease given a test negative result relative to the
pretest odds.
Likelihood Ratio Positive (LR+) -- sensitivity / (1 – specificity) = ratio of the probabilities of
testing positive in patients with and without disease or clinical condition. It can be
interpreted as the increase in the odds of disease given a test positive result relative to the
pretest odds.
Literature Search -- use of published clinical data that establishes a valid clinical association.
Additional resources: see Section 6.1 in GHTF SG5 N2R8:2007[8]
Machine Learning Software (Incremental) -- software device for which input data is
continuously used to automatically extend the existing device's knowledge i.e. to further
train the device after it has been released into the market.
Negative Predictive Value (NPV) -- proportion of test negative patients who do not have the
disease or clinical condition.
Non-Serious (situation or condition) -- situations or conditions where an accurate diagnosis and
treatment is important but not critical for interventions to mitigate long term irreversible
consequences on an individual patient's health condition or public health.
Number Needed To Harm (NNH) -- number of patients that need to be treated in order have an
adverse effect on one patient.
Number Needed To Treat (NNT) -- average number of patients that need to be treated in order
to have an impact on one person.
Odds Ratio (OR) -- ratio of the odds of disease or clinical condition given the SaMD test result is
S to the odds of disease given the SaMD test result is not S. OR is equivalent to ratio of
likelihood ratio positive to likelihood ratio negative.
Output -- results obtained from an algorithm.
Performance (Essential Principles) -- a product’s behavior must not cause harm to a person,
place or thing if something goes wrong
(Also see Effectiveness, Safety)
Performance (Metrics) -- measures behaviors, activities and performance.

Performance (Real World) -- information on real-world device use and performance from a
wider patient population than a more controlled study or pertinent literature, and thus
provide information that cannot be obtained through such studies.
(Also see Real World Performance)

_____________________________________________________________________________________________
Performance (Studies) -- establish or confirm aspects of device performance which cannot be
determined by analytical validation, literature and/or previous experience gained by
routine testing.
Positive Predictive Value (PPV) -- proportion of test positive patients who have the disease or
clinical condition.
Post-market Surveillance -- the practice of monitoring the safety of a medical device after it has
been released on the market.
Additional resources: see GHTF Study Group 2[5] documents; GHTF SG2
N79R11:2009[15]
Pre-market -- the period prior to a product being available for purchase.
Additional resources: see GHTF Study Group 1[4] documents
Professional Society Guidelines -- practices and documents recommended by leading
authorities; use of existing, well-established standards and/or clinical data.
Additional resources: see Section 9 in GHTF SG5 N2R8:2007[8]
Real World (SaMD) Evidence -- evidence derived from aggregation and analysis of real world
data elements.
Real World Data -- product information generated after a product has been released to the
market that can provide insight into the performance of the product used in actual clinical
settings, in routine medical practice, and by regular use by consumers.
Real World Performance -- information on real-world device use and performance from a wider
patient population than a more controlled study or pertinent literature, and thus provide
information that cannot be obtained through such studies.
(Also see Performance (Real World))
Risk Categorization Framework (SaMD) -- a framework to determine the category of a SaMD

based on the significance of the information provided to the healthcare decision and on
the state of the healthcare situation or condition that the SaMD is intended for.
Additional resources: see Section 7.0 in in SaMD N12[2]
Safety -- a product should be designed and manufactured in such a way that, when used under
the conditions and for the purposes intended and, where applicable, by virtue of the
technical knowledge, experience, education or training, and the medical and physical
conditions of intended users, they will perform as intended.
(Also see Effectiveness, Performance)
Safety Data -- adverse events and other problems with medical devices that impact the health
and safety of patients; safety data may be collected in the same activity as performance
data; absence of safety issues during clinical performance testing is an indicator of safety.

_____________________________________________________________________________________________
Scientific Validity -- refers to the extent to which the SaMD’s output (concept, conclusion,
measurements) is clinically accepted or well founded (existence of an established
scientific framework or body of evidence) that corresponds accurately in the real world to
the healthcare situation and condition identified in the SaMD definition statement.
(Also see Clinical Association)
Secondary Data Analysis -- use of analyzed data collected for another purpose.
Sensitivity -- effectiveness of a SaMD to correctly identifies patients with the intended clinical
disease or condition.
Serious (situation or condition) -- situations or conditions where accurate diagnosis or treatment
is of vital importance to avoid unnecessary interventions (e.g., biopsy) or timely
interventions are important to mitigate long term irreversible consequences on an
individual patient’s health condition or public health.
Specificity -- correctly identifies across a range of available measurements patients that do not
have the intended disease or condition.
Treat (SaMD output to) -- information provided by the SaMD will be used to take an immediate
or near term action.
Usability -- the means by which the user and a computer system interact, in particular the use of
input devices and software and the evaluation of safety considerations for device users,
use environments and user interfaces.
Additional resources see ISO/IEC 62366-1:2015 [20], SaMD N12[2] Section 4.0, SaMD
(Also see Clinical Usability, User Interface)
User Interface -- the means by which the user and a computer system interact, in particular the
use of input devices and software and the evaluation of safety considerations for device
users, use environments and user interfaces.
Additional resources see ISO/IEC 62366-1:2015[20], SaMD N12[2] Section 4.0, SaMD
(Also see Clinical Usability, Usability)
User(s) - includes patients, healthcare providers, specialized professionals, lay users, consumers.
Validation -- confirmation through provision of objective evidence that the requirements for a
specific intended use or application have been fulfilled.
Verification -- confirmation through provision of objective evidence that specified requirements
have been fulfilled.

_____________________________________________________________________________________________

MDS G23

Uploaded by

Copyright:

Available Formats

MDS G23

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MDS G23

Uploaded by

Copyright:

Available Formats

MDS-G23

Guidance on Software as a Medical Device

Version Number: 1.0

This guidance document has been published after being

These principles are included in the following documents:

Title: Software as a Medical Device (SaMD): Key Definitions

Authoring Group: IMDRF SaMD Working Group

Date: 9 December 2013

Despina Spanou, IMDRF Chair

Copyright © 2013 by the International Medical Device Regulators Forum

1.0 Introduction ......................................................................................................................4

9 December 2013 Page 2 of 9

9 December 2013 Page 3 of 9

(1) software in a medical device (sometimes referred to as “embedded” or “part of”);

9 December 2013 Page 4 of 9

9 December 2013 Page 5 of 9

5.0 Key Definitions

5.2 Medical purpose

5.2.1 Medical Device

‘Medical device’ means any instrument, apparatus, implement, machine, appliance,

9 December 2013 Page 6 of 9

• disinfection of medical devices,

5.2.2 In Vitro Diagnostic (IVD) medical device

5.2.3 Additional considerations for SaMD

SaMD may also:

9 December 2013 Page 7 of 9

5.3 SaMD Changes

5.4 SaMD Manufacturer

For SaMD manufacturer the definition in GHTF/SG1/N55:2009 applies:

9 December 2013 Page 8 of 9

and post-market requirements, such as adverse event reporting and notification of

5.5 Intended use / intended purpose

5.5.1 Additional considerations for SaMD

9 December 2013 Page 9 of 9

Title: "Software as a Medical Device": Possible Framework for

Authoring Group: IMDRF Software as a Medical Device (SaMD) Working Group

Date: 18 September 2014

Co yright © 2014 by the International Medical Device Re ulators Forum.

Software used in healthcare operates in a complex socio-technical environment—consisting of

• Have rapid development cycles,

Definition: Software as a Medical Device 1

The objective of this document is to introduce a foundational approach, harmonized vocabulary

Purpose of the document

The purpose of the document is to introduce a foundational approach, harmonized vocabulary

• Establishing common vocabulary and an approach for categorizing SaMD;

• Identifying appropriate considerations, during the lifecycle process (requirements, design,

Relationship to other regulatory classification and standards 2

• The categorization framework in this document is not a regulatory classification, nor

3.1 Software as a Medical Device

3.2 Intended use / Intended Purpose

3.3 Medical Purpose

• diagnosis, prevention, monitoring, treatment or alleviation of disease,

3.3.2 In Vitro Diagnostic (IVD) Medical Device

SaMD may also:

3.4 SaMD Changes

4.0 SaMD Background and Aspects Influencing Patient Safety

• The type of disease or condition

• Technological characteristics of the platform the software are intended to operate on

5.0 Factors Important for SaMD Characterization