Software as a Medical Device (SaMD)

What is software as a medical device?

The Medical Device Regulation (MDR) is fully in force from May 2021. Alongside extensive provisions relating to physical medical devices, the MDR also applies to any software that meets the definition of a medical device. In this free guide, we outline how to apply the Medical Device Regulation (EU) 2017/745 to the unique case of software as a medical device.

While it may be a surprise to some people that software may be classed as a medical device, this has been the case since the introduction of the Medical Device Directive in 1993.

Medical device software is any software product that meets the following criteria:

1. it is intended by the manufacturer to be used for a medical purpose
2. it meets the MDR Article 2 definition of “medical device”.

The increasing availability of medical software means that this aspect of medical device regulation is becoming increasingly important. The ever-expanding selection of medical apps, AI diagnosis and diagnostic-assist technology, medical imaging analysis software, decision support tools and other medical software solutions required that the new MDR accounted for the full scope of software with a medical purpose.

How to understand whether a software product will be a medical device

When seeking to determine whether a software product will be a medical device, a key consideration is the intended purpose of the product as stated by the manufacturer. This would extend to any claims made about the product on promotional material and developer-associated websites. Manufacturers must take great care when writing the public description of their product since the MDR will require them to provide evidence that these claims can be met.

Beyond the stated intended purpose, Article 2 of the MDR contains a wide definition of “medical device” which extends to software. According to Article 2, any software that is intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, and/or diagnosis or monitoring of an injury or disability, would likely be classed as a medical device.

The nature of software, however, is that even with such a broad definition it can still be unclear whether the EU MDR will apply. Some software products, for example, have a functionality that enables healthcare activity but does not have a stated medical intended purpose (for example, software that co-ordinates shift patterns of healthcare workers, or inventory-management software). Other software may make healthcare-related information more accessible while claiming not to alter the information in any way (such as an app that shows a trend of blood sugar readings over time).

The following additional considerations may be useful in further understanding whether a software product will fall under the MDR.

1. The software must have a medical purpose on its own

This applies whether the software is a stand-alone product, or whether it is integrated into a hardware device. For example, the software that drives decisions on automated defibrillators is embedded in a hardware device; however, it would itself be a medical device if it was extracted from the defibrillator

2. The software must add medical value

Simple “archive and retrieval” software that, in effect, replicates the action of a paper recording of healthcare data is not likely to be classed as software as a medical device. However, if the software highlights data in any way (especially if it applies an analysis to trends or draws attention to potentially significant findings) then this would be classed as “adding medical value”, making it likely that the MDR would apply.

3. Software incorporating a “call to action”

Any “call to action” initiated by the software and related to any of the aspects covered by MDR Article 2 will likely cause the product to be software as a medical device. For example, an app that advises the patient to visit their doctor based on a reading or data entry is likely to be classed as software as a medical device.

4. Do virtually-identical systems operate outside the medical device sector?

An increasingly-relevant example are systems that enable remote medical consultation. If the system is simply a communication aid (such as video-conferencing software that could equally be used, unaltered, for non-medical purposes) then it is unlikely to be software as a medical device. Systems that enable remote consultation but also assist the provision of care in any way (for example, by highlighting important information) are likely to fall under the MDR.

What regulatory systems need to be in place for software as a medical device under the MDR?

Software as a medical device must meet the same range of regulatory requirements as required for physical medical devices. Medical device software must be CE-marked, indicating that all regulatory obligations have been met, with requirements for obtaining permission to apply a CE-mark differing depending on the classification of the product.

Medical devices of all types fall into one of four risk classes: Class I, IIa, IIb or III. Class I devices are the lowest risk category (with correspondingly lighter regulatory requirements) while Class III devices are the highest risk with, accordingly, the highest regulatory burden. The key to understanding risk classification of software as a medical device is MDR Annex VIII Rule 11, which sets out a classification system that can be applied to any medical software product. While there is scope for software being in any of the four risk classes, by virtue of Rule 11 most software as a medical device will fall into Class IIa.

Manufacturers of all devices (including software) apart from Class I devices must gain approval from a Notified Body before applying a CE-mark.

Specific regulatory processes that must be in place for software as a medical device include:

• Risk Management system
• Quality Management System (QMS)
• Post-Market Surveillance (PMS) system, including PMCF and Vigilance components
• the performance of a Clinical Evaluation and compilation of a Clinical Evaluation Report (CER)
• the production of a full dossier of Technical Documents according to MDR Annex II and III.