Imdrf
Imdrf
Imdrf
IMDRF
International Medical
Device Regulators Forum
Final Document
Title:
Authoring 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.
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
Table of Contents
1.0
Introduction ........................................................................................................................ 4
2.0
Scope.................................................................................................................................... 5
3.0
Definitions ........................................................................................................................... 7
3.1
3.2
3.3
3.4
4.0
5.0
5.1
5.2
6.0
7.0
7.1
7.2
7.3
7.4
8.0
8.1
8.2
9.0
9.1
9.2
9.3
10.0
10.1
10.2
11.0
_____________________________________________________________________________________________
18 September 2014
Page 2 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
Preface
The document herein was produced by the International Medical Device Regulators Forum
(IMDRF), a voluntary group of global 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.
_____________________________________________________________________________________________
18 September 2014
Page 3 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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 environmentconsisting of
software, hardware, networks, and peopleand frequently forms part of larger systems that must
operate in a unified manner. This software frequently depends on other commercial off-theshelf (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:
_____________________________________________________________________________________________
18 September 2014
Page 4 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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.
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
_____________________________________________________________________________________________
18 September 2014
Page 5 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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.
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 is not meant to replace or conflict with the content and/or
development of technical or process standards related to software risk management
activities.
_____________________________________________________________________________________________
18 September 2014
Page 6 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
3.0 Definitions
3.1
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:
3.2
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.
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.
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.
_____________________________________________________________________________________________
18 September 2014
Page 7 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
manufacturer to be used, alone or in combination, for human beings, for one or more of the
specific medical purpose(s) of:
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.
3.3.3
_____________________________________________________________________________________________
18 September 2014
Page 8 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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.
_____________________________________________________________________________________________
18 September 2014
Page 9 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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 manufacturers 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.
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:
_____________________________________________________________________________________________
18 September 2014
Page 10 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
To aid in treatment by providing enhanced support to safe and effective use of medicinal
products or a medical device.
5.2
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
_____________________________________________________________________________________________
18 September 2014
Page 12 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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
o
o
C.
Categorization Principles
The following are necessary principles important in the categorization approach of SaMD.
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.
IMDRF key definitions Final document medical purposes also repeated here in Section 3.3.
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.
_____________________________________________________________________________________________
18 September 2014
Page 13 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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
State of Healthcare
situation or condition
Critical
Serious
Non-serious
ii.
SaMD that provides information to treat or diagnose a disease or conditions in a nonserious situation or condition is a Category II and is considered to be of medium impact.
_____________________________________________________________________________________________
18 September 2014
Page 14 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
ii.
iii.
ii.
iii.
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.
This example uses criteria IV.i from Section 7.3 in that the information provided by the
above SaMD is used to diagnose a disease that may be life threatening, may require
major therapeutic intervention, and may be time sensitive.
_____________________________________________________________________________________________
18 September 2014
Page 15 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
SaMD that combines data from immunoassays to screen for mutable pathogens/pandemic
outbreak that can be highly communicable through direct contact or other means.
This example uses criteria IV.i from Section 7.3 in that the information provided by the
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 uses data from individuals for predicting risk score in high-risk population for
developing preventive intervention strategies for colorectal cancer.
This example uses criteria III.ii 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 may be
_____________________________________________________________________________________________
18 September 2014
Page 16 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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.
This example uses criteria III.ii from Section 7.3 in that the information provided by the
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 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.
This example uses criteria II.ii 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
_____________________________________________________________________________________________
18 September 2014
Page 17 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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.
This example uses criteria II.ii from Section 7.3 in that the information provided by the
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
other serious deterioration of health.
SaMD that collects data from peak-flow meter and symptom diaries to provide
information to anticipate an occurrence of an asthma episode.
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 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
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
_____________________________________________________________________________________________
18 September 2014
Page 18 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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
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
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
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
other serious deterioration of health.
SaMD that stores historical blood pressure information for a health care provider's later
review.
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
other serious deterioration of health.
SaMD intended for image analysis of body fluid preparations or digital slides to perform
cell counts and morphology reviews.
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
other serious deterioration of health.
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.
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
_____________________________________________________________________________________________
18 September 2014
Page 19 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
not normally expected to be time critical in order to avoid death, long-term disability, or
other serious deterioration of health.
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
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
other serious deterioration of health.
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
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
with riskas informed by its intended purpose, reasonable foreseeable use, and the understood
and defined socio-technical environment of use.
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.)
_____________________________________________________________________________________________
18 September 2014
Page 21 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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:
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.
_____________________________________________________________________________________________
18 September 2014
Page 22 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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):
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;
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.
_____________________________________________________________________________________________
18 September 2014
Page 23 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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 SaMDs 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.
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.
_____________________________________________________________________________________________
18 September 2014
Page 24 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
9.2
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:
_____________________________________________________________________________________________
18 September 2014
Page 25 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
9.3
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) platformsuch as Windows, GNU/Linuxcompatibility; and
Modifications and changes to the SaMD integration (e.g., platform updates) may have
effects on SaMD that the manufacturer did not anticipate/foresee.
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
_____________________________________________________________________________________________
18 September 2014
Page 26 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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
10.0 Appendix
10.1 Clarifying SaMD Definition
This Appendix provides a representative list of features and functionalities that either meet or
dont 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.
_____________________________________________________________________________________________
18 September 2014
Page 27 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
The SaMD definition notes states that SaMD is capable of running on general purpose (nonmedical 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.
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 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 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.
_____________________________________________________________________________________________
18 September 2014
Page 28 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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.
_____________________________________________________________________________________________
18 September 2014
Page 29 of 30
IMDRF/SaMD WG/N12FINAL:2014
_____________________________________________________________________________________________
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
ISO/IEC 14764:2006 Software Engineering Software Life Cycle Processes Maintenance
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)
_____________________________________________________________________________________________
18 September 2014
Page 30 of 30