Monitor showing an ECG heartbeat line, a x-ray image of a hand and a graph, symbolizing medical stand alone software or Software as Medical Device (SaMD).

Stand-Alone Software as Medical Device

2019/01/10 - Medical Software - Thorsten Prinz and Isabel Jakobs

When you develop software that has something to do with health applications, it usually becomes complicated. If you want to market such software in Europe, you have to answer a crucial question: Is it medical software or not? The Medical Device Regulation (EU MDR) provides the regulatory framework to answer this question. In particular, it distinguishes between software as part of a medical device and stand-alone software. In this article we will show you how to classify software according to the EU MDR.

Check if the Software Is Part of a Medical Device

Interestingly, the EU-MDR does not define the term “software”. However, you can follow the definition in the EU Commission’s MEDDEV 2.1/6 guide of July 2016. You should note that the MEDDEV guidelines generally refer to the former EU directives (MDD) and not to the EU MDR. From a regulatory point of view, you can distinguish the following types of software:
Type of Software Brief Description
Embedded Software The software is part of a medical device, e.g. a patient monitor.
Software as Accessory The software supports the use or medical function of the medical device, e. g. as service software.
Stand-alone Software The software is a medical device on its own, e.g. a medical app or decision support software.
Accordingly, embedded software is an integral part of a medical device. Art. 2 (2) of the EU MDR regulates the handling of accessories which, like the medical device itself, must meet the basic safety and performance requirements in accordance with Annex I. The MEDDEV 2.1/6 guideline uses the term “stand-alone software”. Furthermore, the guidelines of the International Medical Device Regulators Forum (IMDRF) refer to this type of software as “Software as a Medical Device” (SaMD). Unfortunately, the EU MDR has not adopted either of the two terms. Instead, recital 19 of the EU MDR includes the term “software as such”.

Specify the Intended Purpose of The Stand-Alone Software

In the next step, you must define a purpose for the software that describes its later use in detail. The exact description of the intended purpose is important and strongly influences whether the software is to be regarded as a medical device or not. The description of the intended purpose must comply with the details
  • supplied by the manufacturer on the label,
  • given in the instructions for use,
  • given in promotional or sales materials or statements, and
  • as specified by the manufacturer in the clinical evaluation (Art. 2 (12) EU MDR).
Describe the following aspects in the intended purpose of the software:
  • the intended medical benefit (diagnosis, therapy or monitoring of disease or injury),
  • the functional principle (for example, in the case of software usually the underlying algorithm),
  • the intended use context (e.g. ambient brightness), and
  • the intended user (e.g. medical professionals versus patients).
Note, however, that the intended purpose must not arbitrarily exclude medical use to circumvent the regulatory requirements for medical devices. This has been stated by the Court of Justice of the European Union (CJEU) or the German Federal Supreme Court (BGH) in the past.

Check Whether the Stand-Alone Software Meets the Definition of a Medical Device

Software is a medical device if it meets the definition in Art. 2 (1) EU MDR. The definition is based on the areas of application. These are:
  • diagnosis, prevention, monitoring, prediction, prognosis, 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, and
  • providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations.
In addition, devices for the control or support of conception and products for cleaning, disinfection or sterilization are medical devices according to the EU regulation. The EU MDR also defines that a medical device acts in or on the human body. However, this restriction does not apply to software. The location of the software or the nature of the connection between the software and a product does not determine whether the software is a medical device or an accessory (recital 19 EU MDR). The following questions help to decide whether stand-alone software is a medical device or not:
  • Is the software output data used for a medical purpose as described in the medical device definition?
  • Does the intended purpose include terms such as “alert, analyze, calculate, detect, diagnose, interpret, convert, measure, control, monitor, or amplify”?
  • Does the software change or interpret its input data?
  • Is the software intended to be used for or on humans?
If you answer “yes” to these questions, the software is likely to be a medical device.

Examples for Stand-Alone Software as Medical Device

Let’s look at an example from the EU Commission’s “Manual on Borderline and Classification” of April 2018. The manual describes a medical app, which:
  • compares photos of patient’s moles with a database of diagnosed melanomas using an algorithm, and
  • based on this comparison, evaluates the photographed moles in detail and displays the probability for the moles to be a melanoma.
The data of this app play a role in the diagnosis of melanoma in humans. Presumably, the description of the intended purpose includes the terms “detect” or “diagnose”. The algorithm interprets the data and may even change it, for example if the contrast is increased for better analysis. Another example for a medical stand-alone software is a decision support system. It provides healthcare professionals with recommendations for diagnosing, predicting, monitoring and treating individual patients. This includes for example:
  • radiotherapy planning systems for the dosage calculation of ionizing radiation in cancer therapy,
  • drug planning systems to prevent resistance during chemotherapy or antibiotic treatment, and
  • computer-assisted detection systems for imaging of cancer or coronary heart disease.

Definitely not a Medical Device

Not all software used in health care facilities is a medical device (recital 19 EU MDR). This includes the so-called “software for general purposes”, which can be, for example, an office package or the operating system. Software intended for “lifestyle and well-being purposes” is also not a medical device. An example of this is a fitness app that records the user’s physical activities.
Note, however, that the transition from this so-called “health software” to a medical device can be smooth. This also applies to lifestyle hardware products such as the Apple Watch Series 4, which has been approved by the FDA as a medical device for its electrocardiogram (ECG) function.

It Depends on the Function

According to MEDDEV 2.1/6 consider the following functions as indicators for software not being a medical device:
  • storage,
  • archiving,
  • lossless compression, or
  • simply search of data.
Imagine, for instance, that the above-mentioned moles app would only save the photos of the moles in order to manage them, make them accessible to doctors and document them. In this case, the data would only be stored and no diagnostic support would be provided. Patient data management systems (PDMS) or hospital information systems (HIS) are further examples of software with the sole function of storing or providing data.

Modules of Stand-Alone Software

Note that in the case of software consisting of several modules, the CJEU has ruled that only parts of the modules can be qualified as medical device (CJEU Case C-329/16). If a PDMS is only used for storing and transferring patient information, it is not a medical device. However, if this stand-alone software contains a module which provides additional information, for example in the form of an alarm for diagnosis, therapy and follow-up, then this module should be treated as a medical device. In view of new software developments in the healthcare sector, it is sometimes difficult for manufacturers to decide whether a medical device is involved or not. However, this has a crucial influence on the cost of product marketing. Therefore, it is very important to clarify this question early and conclusively.

Our Recommendations