Last month, the International Medical Device Regulators Forum (IMDRF) reached a consensus on a potentially key aspect of the future regulation of medical software in the US, the EU, Brazil, Canada and Japan, that is, a harmonized definition of when stand-alone software will be considered to be a medical device.
This category of software, dubbed “Software as a Medical Device” (SaMD), includes PC, cloud or mobile applications (apps) that are intended to be used for a specific medical purpose, for example, to assist healthcare professionals in making a diagnosis. SaMD is distinct from embedded medical software, such as the software that runs MRI control panels, which the IMDRF refers to as “software in a medical device.”
The IMDRF is a taskforce composed of US, EU, Brazilian, Canadian and Japanese regulators. It was launched in 2013 as the successor to the Global Harmonization Task Force (GHTF). The abandonment of the GHTF was motivated in part by a desire to relegate industry participants to mere observer status; only regulators have voting rights within the IMDRF.
Following a public consultation that ended in late August 2013, the IMDRF decided that the harmonized definition of SaMD should be “software intended to be used for one or more medical purposes that perform [sic] these purposes without being part of a hardware medical device.”
The basic SaMD definition is unlikely to cause controversy; the real substance lies in the definition’s annotations. In particular, the IMDRF notes that:
- “without being part of” means software not necessary for a hardware medical device to achieve its intended medical purpose;
- Software is not 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; and
- SaMD may be interfaced with other medical devices, including hardware medical devices and other SaMD software, as well as general purpose software.
The IMDRF’s annotations arguably raise more questions than they answer; for example:
- What does “drive a hardware medical device” mean?
- Is it possible for software to be intended to “drive” hardware, but not be “necessary” for that hardware to “achieve its intended medical purpose”?
Take for example a PC-based app allowing the remote control of a medical robot, which also has manual controls. The above IMDRF’s annotations appear to cause the following paradox:
- The medical software is then not “necessary” for the achievement of the hardware’s purpose, and therefore is not “part of” that device, so is SaMD; but
- The software “drives” a hardware medical device, and is therefore not SaMD.
The IMDRF previously announced an intention to replicate the regulatory approach now being adopted for in-vitro diagnostic (IVD) devices to classify the various types of SaMD according to their risk, based on their importance in the care setting, their complexity, the severity of the disease state and their importance to the user. SaMD industry players will therefore need to pay close attention to the proposed reforms to the European IVD regulatory framework. Agreement on a final draft of the proposed new IVD Regulation could be just a few months away, but reforms relating to the proposed Medical Devices Regulation have so far grabbed the spotlight (see our previous post). A key question is whether these European reforms are premature given the progress being made within the IMDRF towards agreeing harmonized international standards for the regulation of software devices.
The publication of the key SaMD definitions brings phase I of the IMDRF’s software-related discussions to a close; it will now focus on clarifying the risk categorization of SaMD types and the level of regulatory expectations and controls to be applied. An informal public consultation closed on 30 January 2014, with a fuller public consultation beginning in March 2014, which is expected to run until the end of May 2014.