Published in Regulatory Frameworks by



The European Union has always given due consideration to the medical device market and its regulation. The reason for this attention is twofold: on the one hand, to ensure the quality of the devices on which our medical care relies, and on the other hand, to prevent excessive fragmentation of legislative approaches within the European Union from distorting the free movement of medical goods and services.

These general considerations are equally valid in the specific and innovative field of “health apps”: particular software designed to cooperate with diagnostic and therapeutic processes in the medical field. On this topic, within the framework of the H2020 PERSIST project, the CyberEthics Lab. team had the opportunity to analyse in detail the main European regulatory framework of reference, the European Medical Devices Regulation 745/2017 (or “Regulation”).

The purpose of the Regulation is to create a single European framework for obtaining the CE marking: a certification necessary for manufacturers to be able to market their medical devices in the EU/EEA area. We will not deal here with medical devices in general, but – more specifically – with the legal process necessary for medical software (Medical Device Software or MDSW) to be placed on the European market. The following paragraphs will analyse the first step of this procedure: understanding whether the Regulation is the correct legal framework and whether the software can be classified as medical.


As already mentioned, the medical device sector has been under the attention of European institutions for some time. As early as 1993, the EC Council (the European Union was not yet active as the Maastricht Treaty had yet to enter into force) had promulgated Directive 93/42/EEC (or “Directive”) “concerning medical devices.” It is noteworthy that even in this text, the possibility that software could be subject to the rules on classic medical devices was taken into consideration.

Today, the sector is instead regulated by the European Medical Devices Regulation: a law that replaces the previous Directive, going far beyond [2]. The objective of the Regulation is twofold: on the one hand, it aims to “ensure the proper functioning of the internal market for medical devices”; on the other hand, the Regulation “establishes high standards of quality and safety for medical devices.” Both aspects are closely linked, inextricably connected, and “neither is secondary to the other” [2].

The scope of the Regulation is extensive and detailed, but also has some grey areas. For example, it does not apply to all medical devices (e.g., in the case of an in vitro medical device), while some non-medical devices are subject to it (e.g., devices listed in Annex VI). Given these peculiarities, how can it be determined with certainty whether software must comply with the rules of the Regulation? Before a manufacturer can sell medical software in the EU/EEA area, this question must be answered.

Exceptions to the general regime

First of all, it should be emphasized that the Regulation includes a series of exceptions ratione materiae, contained in Art. 1(6). For example, in this section, we find listed “transplants, tissues or cells of human origin, or their derivatives” and “human blood, blood products, plasma or blood cells of human origin or devices that incorporate, at the time of placing on the market or putting into service, such blood products.” Or also, “in vitro medical devices” [3]. In all these cases, the reference legislation is not the Regulation.

The temporal regime

It should also be emphasized that the Regulation, although in force since May 26, 2017, is not yet fully operational. A particularly extensive transitional regime between the Directive and the Regulation remained active until May 26, 2021 (originally May 26, 2020, but was extended due to the Covid-19 emergency). After this date, it is no longer possible to obtain certification under the Directive, but the Regulation must necessarily be referred to. There are still two exceptions to what has been said: for certificates already issued, which remain valid until May 26, 2024, and for medical devices already legally placed on the market, which will remain so until May 26, 2025.

The discipline of the European Medical Devices Regulation

It has been said that the Regulation has a broader scope of application than the previous Directive; it also contains a broader notion of software as a medical device, reproduced verbatim below.

“medical device”: any instrument, apparatus, appliance, software, implant, reagent, material or other article, intended by the manufacturer to be used on humans, alone or in combination, for one or more of the following specific medical purposes:
·       diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
·       diagnosis, monitoring, treatment, alleviation or compensation of an injury or disability,
·       study, replacement or modification of anatomy or of a physiological or pathological process or state,
·       providing information through in vitro examination of samples derived from the human body, including blood and donated tissues […].

The novelty compared to the Directive is that software is explicitly recognized as an autonomous medical device, without the need for it to be an appendage of another device. This aspect is further elaborated in Recital 10 of the Regulation, where it is stated that “[it] is necessary to clarify that software specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device is considered a medical device.”

Furthermore, as in the Directive, according to Art. 2.2, software falls under the regime of the Regulation even when it is not a medical device, but its contribution is ancillary to the medical device itself.

The “intended purpose”

For a manufacturer, the “intended purpose” is central to understanding whether a device has a medical nature or not. This analysis is not always simple, as not all tools intended to improve human health can be considered medical devices. For example, “software for lifestyle and well-being purposes is not a medical device.” Similarly, software intended to operate in a hospital environment does not necessarily qualify as a medical device. We find the definition of “medical purpose” in Art. 2.1.12, according to which:

“intended purpose”: the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in the promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation.

In order to bring clarity to this sensitive and complex discipline, the Medical Devices Coordination Group has issued a “Guide to the Qualification and Classification of Software.” This text contains an evaluation framework for the qualification of “medical” software, in accordance with the discipline of the Regulation. However, in many cases, this classification remains ambiguous. For this reason, an Illustrative Manual on a series of devices considered “borderline,” i.e., not easily assessable as medical devices, has also been issued [6]. Although not legally binding, these documents are the best way to avoid interpretations of the Regulation that could “put public health at risk and distort the internal market.”

Evaluation procedure

The following is a procedural presentation of the steps necessary to understand when software is subject to the Regulation.

Step 1) First, it is necessary to evaluate whether the device can be classified as software. To this end, it is useful to examine the definition provided in section 2 of the “Guide to Software Qualification and Classification.”

“Software” is defined as a set of instructions that process input data and create output data.

If the device under examination meets this definition, it could be software with a medical purpose (MDSW), or ancillary to a medical device. Therefore, proceed to Step 2.

Step 2) At this stage, the exceptions ratione materiae listed in Art. 1(6) of the MD must be reviewed. If the device is covered by one of these exceptions (for example, if it is an in vitro device), then the Regulation does not apply. Otherwise, proceed to Step 3.

Step 3) Verify if the software is included in the list contained in Annex VI of the Regulation, or if it is a “part/component” [5] or an accessory of a medical device. If the answer is positive, the software may not have a medical purpose, but is still subject to the Regulation and the evaluation process is complete. Otherwise, proceed to Step 4.

Note: It should be emphasized that software may not have a medical purpose when evaluated individually, but may still be subject to the Regulation if it is a “part/component” or accessory of a medical device. The distinction between an accessory and a “part/component” is substantial and has profound repercussions in the subsequent phases required to obtain the CE mark. For example, an accessory will be considered and evaluated independently of the reference medical device. On the other hand, a “part/component” will be evaluated together with the medical device it integrates.

Step 4) At this stage, the specific capabilities of the software under analysis begin to be evaluated. Indeed, as stated by the “Guide to Software Qualification and Classification,” if the device performs an activity beyond mere “storage, archiving, communication, simple search, compression” [5], then it could be an MDSW. If that’s the case, proceed to Step 5.

Step 5) Does the software operate for the benefit of the individual patient?

Note: Software with the sole purpose of “aggregating population data, providing generic diagnostic or therapeutic pathways (not directed at individual patients), scientific literature, medical atlases, models and models as well as software intended solely for epidemiological studies or registries” is not considered to benefit individual patients.

Step 6) Does the software meet the definition of a “medical device” under Art. 2.1? If so, the software is an MDSW and is subject to the Regulation.

In conclusion

This contribution presents the first step of the process through which medical software can obtain the CE mark and consequently be marketed in the EU/EEA area. Ultimately, it is therefore possible to summarize that software may be subject to the Regulation if it is:

  • An autonomous medical software, or MDSW;
  • An accessory to a medical device;
  • A “part/component” of a medical device.[5]





[1] European Parliament and Council, “Medical Device Directive 93/42/EEC,” 1993. [Online]. Available at:;.

[2] European Parliament and Council, “Medical Device Regulation 17/745,” 2017. [Online]. Available at:

[3] European Parliament and Council, “Regulation (EU) in vitro medical device,” 2017. [Online]. Available at:

[4] European Parliament and Council, “Amending Regulation (EU) 2017/745 on medical devices, as regards the dates of application of certain,” 2020. [Online].
Available at:

[5] M. D. C. Group, “Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR,” 2019. [Online].
Available at:

[6] M. D. C. Group, “Manual on Borderline and Classification in the Community Regulatory Framework for Medical Devices,” [Online].
Available at:


Service involved

Medical device Assessment


We provides advisory support to manufacturers on obtaining a certificate (CE mark) for medical devices. Legal consultants of our team have in-depth knowledge of MDR and experience in this kind of activity within the framework of European projects in the field of health care.
Cooperation includes a pre-assessment and based on its results, the determination of successive steps on the way to obtaining a CE mark. In addition, we can support companies in their relations with notified bodies, which are in most cases authorized to issue certificates.