The use of mobile applications (“apps”) for health, lifestyle, and general well-being, has significantly increased over the last five years, and is still showing enormous potential. One might think of apps for fitness and exercise tracking, diet and nutrition monitoring, lifestyle and stress control, medication reminders and info, pregnancy tracking and info, remote patient monitoring, consultations and disease management, telemedicine, and so on.
Some of these ‘mHealth apps’ may qualify as a medical device or an in-vitro diagnostic medical device, and will therefore have to be CE marked in line with the new Medical Device Regulations (i.e. Medical Device Regulation 2017/7451 (“MDR”), fully applicable as of 26 May 2021, or In-Vitro Diagnostics Regulation 2017/7462 (“IVDR”), fully applicable as of 26 May 2022). The Regulations alter the current legislative framework for medical devices in several important ways, bringing about a number of changes for medical device software and mobile applications. But when does a health app – or software in general – qualify as a medical device? A common misconception is that the qualification as a medical device would somehow depend on the risk of harm it may pose (e.g. in case of malfunction) to patients or users. This is not the case.
The Medical Device Regulations do not provide for much detail on the qualification of apps. Luckily, a number of guidance documents do. Particular reference can be made to the MDCG guidance3 (endorsed by the Medical Device Coordination group), the MEDDEV 2.1/6 guidance4 (of the EU Commission), and the MHRA Guidance5 (of the UK Medicines & Healthcare products Regulatory Agency).
The qualification criteria are unaffected by the software’s location or the type of interconnection between the software and a device.6 They therefore apply to software and apps alike, whether used on a mobile phone, in the cloud, or on other platforms.7
The most recent MDCG guidance essentially works in two steps. First, it is determined whether the app falls within the general scope of the Medical Device Regulations, as Medical Device Software (“MDSW”), as an accessory to a medical device, or as software driving or influencing the use of a (hardware) medical device. If this is the case, it is subsequently determined whether the MDR, or the IVDR, applies. Note that the additional ‘MDR Annex XVI devices’8 are not discussed in this update.
To facilitate the qualification process, the guidance documents provide for decision trees,9 listing (amongst others) a number of key characteristics that determine whether the app remains in the running for MDSW qualification. As such, apps that do not perform an action on data, or perform an action limited to storage, archival, communication, simple search (i.e. simply matching metadata to search criteria – cf. library functions), or lossless compression, do not qualify as MDSW.10 The fact that the app alters data for embellishment purposes does not render it a medical device either, however, altering data or its representation for medical purposes, might. Also, apps that are not for the benefit of individual patients will not qualify as MDSW either. This excludes i.a. apps intended to aggregate population data, provide generic diagnostic or treatment pathways (not patient specific), serve as scientific literature, templates, models, etc.
Contrarily, apps that go beyond the actions listed above (e.g. those creating or modifying medical information), and that are for the benefit of individual patients, remain in the running for MDSW qualification.
To ultimately qualify as MDSW, the app must be intended by the developer to be used, alone or in combination, for one of the medical purposes listed in Art. 2(1) MDR. Apps for general purposes (e.g. invoicing, e-mailing, staff planning, ...), even when used in a healthcare setting, or for life-style and well-being purposes are excluded.11 The purpose is determined by what the developer (or ‘manufacturer’ in the words of the Regulations) states in the device’s labelling, instructions for use, and any promotional or sales materials.12 For apps, relevant will for instance be the app store description, the category in which it is offered for sale, the adverts, the landing page, and the developer’s social media channels.13
The medical purposes listed in Art. 2(1) MDR are:
▪ Diagnosis of disease / injury / handicap;
▪ Monitoring of disease / injury / handicap;
▪ Prevention, prediction, or prognosis of disease;
▪ Treatment or alleviation of disease / injury / handicap;
▪ Compensation for injury / handicap;
▪ 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.
If the app is intended to be used for one or more of the above listed medical purposes, alone or in combination, it qualifies as an MDSW.
However, even if the app does not qualify as an MDSW as such, it is still possible that it falls within the scope of the Regulations, in particular:
▪ when the app is an accessory to one or more medical devices14. This is the case when the app is intended to ‘specifically enable’ a device to be used in accordance with its intended purpose or to ‘specifically and directly assist’ the medical functionality of the device.15 The developer determines whether the app is intended to be used as such. Reference can be made to apps linked wirelessly to a monitoring device to record data such as temperature, heart rate, blood pressure, etc.16
▪ when the app drives or influences a (hardware) medical device, e.g. by operating, modifying or controlling the device, or by supplying output related to the (hardware) functioning of the device. In that case, it is considered as either a component of or an accessory to the medical device (depending on whether the definition of an accessory is met – see above). Whereas accessories undergo their own separate regulatory process, components are considered part of a device in its regulatory process.
Note that when the app fulfils one of the functions listed above, but also has a medical purpose (e.g. because it processes the recorded data for diagnostic purposes), it is qualified as an MDSW.
As stated above, in a second step, it is analysed whether the MDR or the IVDR is applicable to the app. In essence, the app will fall under the IVDR:
(i) if it provides information as listed in Art. 2(2) of the IVDR17;
(ii) and if the information is created based on data obtained from in vitro diagnostic medical devices only, or, in case the data is obtained from a combination of in vitro diagnostic medical devices and medical devices, the intended purpose is substantially driven by data sources coming from the former.18
Reference can for instance be made to apps giving information about a condition or disease, or about an acquired or inherited condition or disease, from results generated by an IVD, or to apps giving information about the compatibility of blood, tissues, organs or cells donated for transplant or transfusion from results generated by an IVD.19
Once it has been determined that the app qualifies as a medical device or in vitro diagnostic medical device (or as an accessory or component thereof), the classification exercise may begin. Our next update will provide some guidance on the do’s and don’ts in this respect.
1 Regulation EU 2017/745 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, OJ L 117, 5.5.2017, p. 1–175.
2 Regulation (EU) 2017/746 of 5 April 2017 on in vitro diagnostic medical devices and repealing Directive 98/79/EC and Commission Decision 2010/227/EU, OJ L 117, 5.5.2017, p. 176–332.
3 MDCG, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR (last visited 25 November 2020).
4 EU Commission, Medical Devices – Guidance document on the Qualification and Classification of stand alone software, MEDDEV 2.1/6 (last visited 25 November 2020), drafted in light of the ‘old’ regulatory framework (based on Directive 93/42/EEC and Directive 98/79/EC).
5 MHRA, Guidance: Medical device stand-alone software including apps (including IVDMDs) (last visited 25 November 2020), drafted in light of the ‘old’ regulatory framework (based on Directive 93/42/EEC and Directive 98/79/EC).
6 Preamble 19 resp. 17 of the MDR resp. IVDR.
7 MDCG Guidance, p. 3.
8 Software qualifying as a non-medical device can in a limited number of cases still fall within the scope of the MDR, notably when listed in Annex XVI. A discussion of this list falls outside the scope of this update.
9 MDCG Guidance, p. 9, 11; MEDDEV 2.1/6 Guidance, p. 9, 13; MHRA Guidance, p. 6, 10, 13. 10 MDCG Guidance, p. 8; MEDDEV 2.1/6 Guidance, p. 11.
11 Preamble 19 resp. 17 of the MDR resp. IVDR.
12 Art. 2(12) MDR and IVDR.
13 MHRA Guidance, p. 11.
14 Or in vitro diagnostic device.
15 Definition of an accessory in Art. 2(2) MDR; Art. 2(4) IVDR. 16 MHRA Guidance, p. 8.
17 I.e. information (a) concerning a physiological or pathological process or state, (b) concerning congenital physical or mental impairments, (c) concerning the predisposition to a medical condition or a disease, (d) to determine the safety and compatibility with potential recipients, (e) to predict treatment response or reactions, (f) to predict treatment response or reactions.
