EU MDR days to go
Days
Hours
Minutes
Seconds
Software as a Medical Device (SaMD)
The term Software as a Medical DeviceExternal Link Disclaimer is defined by the International Medical Device Regulators Forum (IMDRF) as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."
Use of Software as a Medical Device is continuing to increase. It can be used across a broad range of technology platforms, including medical device platforms, commercial "off-the-shelf" platforms, and virtual networks, to name a few. Such software was previously referred to by industry, international regulators, and health care providers as "standalone software," "medical device software," and/or "health software," and can sometimes be confused with other types of software.
Use of Software as a Medical Device is continuing to increase. It can be used across a broad range of technology platforms, including medical device platforms, commercial "off-the-shelf" platforms, and virtual networks, to name a few. Such software was previously referred to by industry, international regulators, and health care providers as "standalone software," "medical device software," and/or "health software," and can sometimes be confused with other types of software.
Get Started
Drop us a line and we’ll get back to you!
SaMD quality
FDA uses a group of “Quality Management Systems” activities from a software perspective.6 First, a governance structure must provide leadership and accountability through an organization with resources to enable them to assure the safety, effectiveness and performance of an SaMD and provide a foundation for assessing SaMD lifecycle processes. Second, there must be a scalable set of quality processes that apply across lifecycle activities. Third, the organization overseeing the lifecycle activities must consider important elements required for assuring SaMD safety, effectiveness and performance.
SaMD regulations
The new European Medical Device Regulation (MDR) states when specifically intended by the manufacturer to be used for one or more medical purposes set out in the definition of a medical device, does qualify as a medical device. By contrast, software for general purposes, even when used in a healthcare setting or software intended for life-style and well-being purposes is not a medical device.
“For example, an application that allows users to take pictures of moles on the skin and store the pictures for the purposes showing them to a physician does not perform an action on data other than just storage, so that is not a medical device,”
“For example, an application that allows users to take pictures of moles on the skin and store the pictures for the purposes showing them to a physician does not perform an action on data other than just storage, so that is not a medical device,”
Classification rules
Annex VIII, Rule 11: Classification of Software as a Medical Device
The EU MDR Annex VIII discuss a number of classification rules.3 Rule 11 relates to classification of software and specifically addresses classification of software used alone or in combination with medical devices. Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause death or an irreversible deterioration of a person's state of health, in which case it is in Class III or a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as Class IIb. Software intended to monitor physiological processes is classified as Class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as Class IIb. All other software is classified as Class I. As an example, software used to monitor heart rates or any other physiological parameters during a routine checkup is classified as Class IIa. However, if the monitoring aims at vital physiological parameters, and where those parameters could result in immediate danger to the patient, the classification is elevated to Class IIb.
Annex VIII, Rule 9
According to Rule 9, all active therapeutic devices intended to administer or exchange energy are classified as Class IIa. Unless those devices have characteristics by which they may administer or exchange energy with the human body, in a potentially hazardous way (taking account of the nature, the density and site of application of the energy) they are classified as Class IIB. If active devices are intended to “control or monitor” the performance of an active therapeutic Class IIb devices or if the devices are intended to directly “influence” the performance of the devices, they are also Class IIb devices.
Active devices intended for controlling, monitoring or directly influencing the performance of active implantable devices are classified as Class III.
Annex VIII, Rule 10
Active devices intended for “diagnosis and monitoring” are classified as Class IIa devices if they are intended to supply energy that will be absorbed by the human body unless devices are intended to illuminate the patient’s body in the visible spectrum which are classified as Class I.
Active devices intended for “diagnosis and monitoring” are classified as Class IIa devices if they are intended to image in vivo distribution of radiopharmaceuticals or if they are intended to allow direct diagnosis or “monitoring of vital physiological processes.”
Active devices intended for “diagnosis and monitoring” which are specifically intended to monitor vital physiological parameters where the nature of the variation of those parameters is such that it could result in immediate danger to the patient (devices related to cardiac performance, respiration, activity in the Central Nervous System) or they are intended for diagnosis in clinical situations where the patient is in immediate danger are classified as Class IIb.
FDA’s Approach to Regulating Software Used in Medical Devices: Identifying an SaMD
According to Bakul Patel, associate director for digital health, FDA Center for Devices and Radiological Health, Software as a Medical Device (SaMD) is defined as “software intended to be used for more than one or more medical purposes that perform these purposes without being part of a hardware medical device.”
Once more, FDA defines an SaMD as a medical device that includes an in vitro medical device. Too, an SaMD is capable of running on general, no-medical purposed computing platforms. Third, software does not meet the definition an SaMD if its intended purpose is to drive a medical hardware device. An SaMD may be used in combination (such as a module) with other products, including medical devices. Lastly, an SaMD may be interfaced with other medical devices, including hardware medical devices and other SaMD software as well as general purpose software.
SaMD by Key Attributes
FDA uses “key attributes” to identify an SaMD. For example, an SaMd must meet the definition of a medical device if it achieves its intended purpose on any computing platform if it is not needed by the hardware medical device for the hardware medical device to achieve its intended purpose or if it does not drive or control the hardware medical device and it can receive data from other medical devices.
The 21st Century Cures Act signed into law on 13 December 2016 to help accelerate medical product development and bring new innovations and advances to patients who need them faster and more efficiently.5 The Act was later amended to remove software function from device definitions when meeting the following criteria:
The software does not acquire or analyze physiological signals.
The software is intended to display information about the patient.
The software allows health professionals to independently review the basis for such recommendations that such software presents so that it is not the intent that healthcare professionals rely primarily on any of such recommendations.
The EU MDR Annex VIII discuss a number of classification rules.3 Rule 11 relates to classification of software and specifically addresses classification of software used alone or in combination with medical devices. Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause death or an irreversible deterioration of a person's state of health, in which case it is in Class III or a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as Class IIb. Software intended to monitor physiological processes is classified as Class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as Class IIb. All other software is classified as Class I. As an example, software used to monitor heart rates or any other physiological parameters during a routine checkup is classified as Class IIa. However, if the monitoring aims at vital physiological parameters, and where those parameters could result in immediate danger to the patient, the classification is elevated to Class IIb.
Annex VIII, Rule 9
According to Rule 9, all active therapeutic devices intended to administer or exchange energy are classified as Class IIa. Unless those devices have characteristics by which they may administer or exchange energy with the human body, in a potentially hazardous way (taking account of the nature, the density and site of application of the energy) they are classified as Class IIB. If active devices are intended to “control or monitor” the performance of an active therapeutic Class IIb devices or if the devices are intended to directly “influence” the performance of the devices, they are also Class IIb devices.
Active devices intended for controlling, monitoring or directly influencing the performance of active implantable devices are classified as Class III.
Annex VIII, Rule 10
Active devices intended for “diagnosis and monitoring” are classified as Class IIa devices if they are intended to supply energy that will be absorbed by the human body unless devices are intended to illuminate the patient’s body in the visible spectrum which are classified as Class I.
Active devices intended for “diagnosis and monitoring” are classified as Class IIa devices if they are intended to image in vivo distribution of radiopharmaceuticals or if they are intended to allow direct diagnosis or “monitoring of vital physiological processes.”
Active devices intended for “diagnosis and monitoring” which are specifically intended to monitor vital physiological parameters where the nature of the variation of those parameters is such that it could result in immediate danger to the patient (devices related to cardiac performance, respiration, activity in the Central Nervous System) or they are intended for diagnosis in clinical situations where the patient is in immediate danger are classified as Class IIb.
FDA’s Approach to Regulating Software Used in Medical Devices: Identifying an SaMD
According to Bakul Patel, associate director for digital health, FDA Center for Devices and Radiological Health, Software as a Medical Device (SaMD) is defined as “software intended to be used for more than one or more medical purposes that perform these purposes without being part of a hardware medical device.”
Once more, FDA defines an SaMD as a medical device that includes an in vitro medical device. Too, an SaMD is capable of running on general, no-medical purposed computing platforms. Third, software does not meet the definition an SaMD if its intended purpose is to drive a medical hardware device. An SaMD may be used in combination (such as a module) with other products, including medical devices. Lastly, an SaMD may be interfaced with other medical devices, including hardware medical devices and other SaMD software as well as general purpose software.
SaMD by Key Attributes
FDA uses “key attributes” to identify an SaMD. For example, an SaMd must meet the definition of a medical device if it achieves its intended purpose on any computing platform if it is not needed by the hardware medical device for the hardware medical device to achieve its intended purpose or if it does not drive or control the hardware medical device and it can receive data from other medical devices.
The 21st Century Cures Act signed into law on 13 December 2016 to help accelerate medical product development and bring new innovations and advances to patients who need them faster and more efficiently.5 The Act was later amended to remove software function from device definitions when meeting the following criteria:
The software does not acquire or analyze physiological signals.
The software is intended to display information about the patient.
The software allows health professionals to independently review the basis for such recommendations that such software presents so that it is not the intent that healthcare professionals rely primarily on any of such recommendations.
