Is your software a medical device?
Feature Articles | 08 March 2019 | Citation
Computer software used in healthcare device applications developed for demographic data gathering, physical examinations or therapies are increasingly part of the regulatory landscape. This article, based on presentations from RAPS Regulatory Convergence, October 2018, explores whether and when computer software, used in a variety of ways in healthcare is a medical device.1 The author reports on recent software and application regulations in both the European Union where medical device regulations were recently revised and the US, where the US Food and Drug Administration (FDA) is responsible for determining how and when software may or may not be considered a “medical device.”
Introduction
Because many medical devices depend on computer software to carry out their tasks, the question of whether the software itself can be considered a “medical device” is important. A variety of questions have been raised about whether and when software can be considered a medical device and “what ifs” linked to this question are many and, accordingly, a number of regulatory experts offered their expertise and opinions in Vancouver.
For example, Melissa Walker, president and CTO of Graematter, Inc., posed many questions related to the central question of whether the computer software used in a medical device is, in itself, a medical device. She asked, “Can the software be used by itself, or only together with another medical device?” Is the software intended for users with specific medical conditions? What type of information is provided in the output of the device? How is the output information used, and by whom?
Walker also posed several “what if” questions to explore if software is in itself a medical device. In cardiac care, what if the data captured is used to assess the performance of the clinical team? What if the physician relies on the data to determine the next actions for a patient’s care? What if the “app” using the software collects data from a variety of digital devices or the output offers suggestions to the user for lifestyle changes or treatments?
The EU Perspective
In an effort to answer the questions, Sara Jafari, project manager for GMED North America looked at software as a medical device from the EU MDR perspective. According to Jafari, the new EU MDR regulations provide definitions, classifications, rules and procedural requirements for medical device software. This will have an impact on software currently regulated as Class I medical devices.2 MDR Article 2 says a “medical device” means any instrument, apparatus or appliance or software intended by the manufacturer to be used alone or in combination for humans for medical purposes, including diagnosis, prevention, monitoring, prediction, prognosis or treatment or alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability; investigation, replacement or modification of the anatomy or of a physiological or pathological process or state; providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations, and which does not achieve its principal intended action by pharmacological, immunological or metabolic means, in or on the human body, but which may be assisted in its function by such means.” MDR Article 2 further designates that software is considered as an “active device” by defining “active device” as any device the operation of which depends on a source of energy other than that generated by the human body or by gravity and which acts by changing the density of or concerting that energy.
“Whether software qualifies as a medical device depends on its intended purpose,” said Jafari. “Even if your software has a medical purpose, if software is, for example, intended to communicate, store information or perform a simple search, it does not qualify as a medical device.”
She also noted that by EU MDR definition software in its own right, 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,” explained Jafari.
Figure 1. Annex VIII: 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.”4
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:
Figure 2. Clearly Defining Intended use of an SaMD
SaMD Quality Management Principles
Regarding quality management of SaMDs, 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.
Figure 3. Clinical Evaluation SaMD Spectrum
Summary and Conclusion
With the broadly raised question of whether software, in and of itself, can be considered a medical device, the answers to that question depend on the specific definitions for a medical device as developed by regulating bodies. In the EU, under the recently revised regulations pertaining to medical devices, software can be considered a medical device if it is “active.” That is, if the device depends on a source of energy other than that generated by the human body or by gravity and which acts by changing the density of or concerting that energy. Additionally, a classification system has been developed and depending on a variety of parameters, software can be categorized by rules into several Classes (I, Im, IIa, IIb and III. Im is a sub class for Class I devices for which the involvement of the notified body shall be limited to the aspects relating to the conformity of the devices with the metrological requirements.)
In the US, FDA’s perspective on 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.” Too, software does not meet the definition an SaMD if its intended purpose is to drive a medical hardware device. Expect the definitions and classifications that do or do not consider software a medical device to change as new medical devices requiring software are developed. As noted by Walker, issues of whether software can be used by itself or with other medical devices, who are the end users, what type of information is provided as output and how is the information used will continue to be variables needing review.
References
About the Author
Randolph Fillmore is a technical writer for Florida Science Communications Inc.
Cite as: Fillmore R. “Is your software a medical device?” Regulatory Focus. March 2019. Regulatory Affairs Professionals Society.
Introduction
Because many medical devices depend on computer software to carry out their tasks, the question of whether the software itself can be considered a “medical device” is important. A variety of questions have been raised about whether and when software can be considered a medical device and “what ifs” linked to this question are many and, accordingly, a number of regulatory experts offered their expertise and opinions in Vancouver.
For example, Melissa Walker, president and CTO of Graematter, Inc., posed many questions related to the central question of whether the computer software used in a medical device is, in itself, a medical device. She asked, “Can the software be used by itself, or only together with another medical device?” Is the software intended for users with specific medical conditions? What type of information is provided in the output of the device? How is the output information used, and by whom?
Walker also posed several “what if” questions to explore if software is in itself a medical device. In cardiac care, what if the data captured is used to assess the performance of the clinical team? What if the physician relies on the data to determine the next actions for a patient’s care? What if the “app” using the software collects data from a variety of digital devices or the output offers suggestions to the user for lifestyle changes or treatments?
The EU Perspective
In an effort to answer the questions, Sara Jafari, project manager for GMED North America looked at software as a medical device from the EU MDR perspective. According to Jafari, the new EU MDR regulations provide definitions, classifications, rules and procedural requirements for medical device software. This will have an impact on software currently regulated as Class I medical devices.2 MDR Article 2 says a “medical device” means any instrument, apparatus or appliance or software intended by the manufacturer to be used alone or in combination for humans for medical purposes, including diagnosis, prevention, monitoring, prediction, prognosis or treatment or alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability; investigation, replacement or modification of the anatomy or of a physiological or pathological process or state; providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations, and which does not achieve its principal intended action by pharmacological, immunological or metabolic means, in or on the human body, but which may be assisted in its function by such means.” MDR Article 2 further designates that software is considered as an “active device” by defining “active device” as any device the operation of which depends on a source of energy other than that generated by the human body or by gravity and which acts by changing the density of or concerting that energy.
“Whether software qualifies as a medical device depends on its intended purpose,” said Jafari. “Even if your software has a medical purpose, if software is, for example, intended to communicate, store information or perform a simple search, it does not qualify as a medical device.”
She also noted that by EU MDR definition software in its own right, 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,” explained Jafari.
Figure 1. Annex VIII: 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.”4
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.
Figure 2. Clearly Defining Intended use of an SaMD
SaMD Quality Management Principles
Regarding quality management of SaMDs, 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.
Figure 3. Clinical Evaluation SaMD Spectrum
Summary and Conclusion
With the broadly raised question of whether software, in and of itself, can be considered a medical device, the answers to that question depend on the specific definitions for a medical device as developed by regulating bodies. In the EU, under the recently revised regulations pertaining to medical devices, software can be considered a medical device if it is “active.” That is, if the device depends on a source of energy other than that generated by the human body or by gravity and which acts by changing the density of or concerting that energy. Additionally, a classification system has been developed and depending on a variety of parameters, software can be categorized by rules into several Classes (I, Im, IIa, IIb and III. Im is a sub class for Class I devices for which the involvement of the notified body shall be limited to the aspects relating to the conformity of the devices with the metrological requirements.)
In the US, FDA’s perspective on 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.” Too, software does not meet the definition an SaMD if its intended purpose is to drive a medical hardware device. Expect the definitions and classifications that do or do not consider software a medical device to change as new medical devices requiring software are developed. As noted by Walker, issues of whether software can be used by itself or with other medical devices, who are the end users, what type of information is provided as output and how is the information used will continue to be variables needing review.
References
- RAPS Regulatory Convergence, Vancouver, Canada, October 2018. “Is my software a medical device?” Presented by Sara Jafari, Bakul Patel and Melissa Walker.
- Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on Medical Devices, Amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and Repealing Council Directives 90/385/EEC and 93/42/EEC. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32017R0745. Accessed 11 February 2019.
- Ibid.
- Software used as a Medical Device (SaMD). FDA website. https://www.fda.gov/medicaldevices/digitalhealth/softwareasamedicaldevice/default.htm. Accessed 11 February 2019.
- 21st Century Cures Act. FDA website. https://www.fda.gov/regulatoryinformation/lawsenforcedbyfda/significantamendmentstothefdcact/21stcenturycuresact/default.htm. Accessed 11 February 2019.
- Op cit 4.
About the Author
Randolph Fillmore is a technical writer for Florida Science Communications Inc.
Cite as: Fillmore R. “Is your software a medical device?” Regulatory Focus. March 2019. Regulatory Affairs Professionals Society.
© 2025 Regulatory Affairs Professionals Society.
