IMDRF/SaMD WG/N10FINAL:2013
_______________________________________________________________________________________
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.
9 December 2013 Page 4 of 9