Along with the rapid development of technology in the mobile sector, has come a growing number of health apps, which can keep track of and analyse everything from the number of steps taken each day to the development of serious cancer. If an app is considered to be a diagnostic and/or therapeutic tool, the app is no longer "just an app". It is to be regarded as a "medical device", which gives rise to the imposing of certain legal obligations in respect of the app.

This creates a number of legal challenges for developers navigating the market of m-Health apps, all the more so due to the differing national implementation of the Medical Device Directive and the requirements of data protection.

The term m-health apps includes applications as lifestyle and wellbeing apps (e.g. fitness) that may be connected to medical devices or sensors (bracelets, watches) as well as personal guidance systems, health information and medication reminders. In addition, there are a number of technological solutions which measure vital signs such as heart rate, blood glucose level, blood pressure, brain activities and so on.

Technological evolution, including above all the wide spread use of smartphones, has boosted the use of mobile apps offering healthcare; the FDA counts more than 100,000 apps on the market. m-Health apps are attractive to consumers, patients and medical professionals as they offer advantages such as an increase in quality of healthcare and more accurate diagnoses and treatment. They also continue the trend of empowerment of patients, making us more independent and better informed.

Some recent examples of m-Health apps include the following:

  • NIKE +: a fitness coaching app that records your running sessions and counts your steps to allow you to monitor your running activities.
  • Pocket First Aid & CPR: an app that is intended to help you in case of an emergency, such as a heart attack, and provides first aid and rescue information.
  • ASTHMA SENSE: an app that assists you with a chronic disease, like asthma, and includes advice and recommendations. This app comprises a “user-friendly library” on the topic, does not provide personalised health advice, which would take the app into different legal territory.
  • TACTIO: a health tracking app that can record several health parameters and facilitates the communication regarding your health condition between yourself and your doctor.
  • iDialysis: an app that connects to your dialysis device and records vital parameters that you can share with your doctor.
  • Chemotherapy advisor medical apps: these are apps that are intended for healthcare professionals, rather than simply the patient, by, for example providing information that will support oncologists' decisions in terms of therapy and dosage. The app can provide dosage decision support in function of individual patient parameters, which the app can interpret and link to pre-recorded scenarios.

Legal Framework

All apps are subject to the following legislation: data protection; consumer protection; product liability; the eCommerce Directive (2000/31/EC); the Unfair Commercial Practices Directive (UCPD); and the Misleading and Comparative Advertising Directive (2006/114/EC).

If, however, the app is also a device, then the Medical Devices Directive (93/42/EC) (MDD) will apply together with, possibly, the In-Vitro Medical Devices Directive (98/79/EC) (IVMDD) and the Active Implantable Medical Devices Directive (90/385/EC) (AIMDD). Furthermore, the European Commission has issued guidelines on the qualification and classification of standalone software used in healthcare within the regulatory framework of medical devices (MEDDEV guidance 2.1/6).

However, it was suggested that the legislation is no longer fit for all purposes – the majority of respondents to a public consultation on the Green Paper on m-Health, found that the safety and performance requirements were not adequately covered by the current EU legal framework, and whilst some certification schemes (such as the one used by the NHS) were in place and certain quality standards could be made to apply to m-apps, specific legislation for lifestyle and wellbeing apps were suggested.

On 26 September 2012, the European Commission adopted a Proposal for a Regulation of the European Parliament and of the Council on i) medical devices, and ii) in vitro diagnostic (IVD) medical devices. These regulations, once adopted, will replace the existing three medical devices directives mentioned above. The European Commission has created a new m-Health data quality working group which will aim to draft guidelines on m-Health data quality, producing common quality criteria and assessment criteria for health and wellbeing apps.

The forthcoming cybersecurity Directive (Network and Information Security Directive (the NIS Directive)) may also have an impact as it:

  • applies specifically to the health sector;
  • implementation of technical and organisational measures;
  • obligation to notify security incidents;
  • national authorities may alert incidents to the public; and
  • national authorities will have audit rights.

Is an App a Medical Device?

In order to determine which of the above regimes governs the regulation and sale of an m-app, it is important to establish whether it falls within the definition of a medical device (as set out identically in both Article 2a of Directives 90/385 and 93/42):

“any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, together with any accessories, including the software intended by its manufacturer to be used specifically for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of:

  • diagnosis, prevention, monitoring, treatment or alleviation of disease,
  • diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,
  • investigation, replacement or modification of the anatomy or of a physiological process,
  • control of conception,
  • and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means”.

As by definition an app is a piece of software, the following diagram below maybe helpful as it sets out the elements that determine whether a piece of software is a medical device.

[see pdf for flow chart]

We set out below how to use the flow chart:

a. Is the software a computer program?

“Computer Program” means syntactic unit conforming to programming, language and composed of declarations or statements needed to solve certain functions, tasks or problems.

b. Is the software incorporated in a medical device or is it stand-alone?

If the software is incorporated into a medical device then it is automatically covered by the MDD.

Stand-alone software, however, is only covered by the MDD if its intended purpose falls into the scope of the definition of medical device (art 2(a) as set out above). This was established in Brain Products GmbH (Case C‑219/11), the facts of which are set out below.

Biosemi and Others (Biosemi) market electro technical systems and equipment, in particular, a system called ‘ActiveTwo’ which enables human brain activity to be recorded. According to German company Brain Products, since ActiveTwo is a medical device and Biosemi do not have CE certification for such devices, the marketing of that product should be prohibited.

Biosemi responded by asserting that since ActiveTwo is not intended for medical use it cannot be classified as a ‘medical device’ within the meaning of Directive 93/42. Moreover, the mere fact that that system can be transformed into a diagnostic device does not itself lead to the device being classified as a medical device. Furthermore, they assert that a restriction on the marketing of ActiveTwo would be contrary to the principle of the free movement of goods since the competent Netherlands health authority takes the view that there is no need to certify that system

The German lower courts held that ActiveTwo could not be classified as a ‘medical device’ within the meaning of Directive 93/42. According to the court of appeal, that system satisfies the criteria in the third indent of Article 1(2)(a) of Directive 93/42, but not the additional implied condition that its intended purpose must be for medical use, so that Biosemi are not required to submit ActiveTwo to clinical examination.

Brain Products appealed to the Bundesgerichtshof, which determined that the purpose of the device is necessarily medical only in the cases referred to in the first and second indents of Article 1(2)(a) of Directive 93/42. The devices referred to in its third and fourth indents have, however, to be designed to be used for medical purposes in order to fall within the scope of Directive 93/42. There was, therefore, confusion as to whether the design for intended use as a medical device is an implied condition for satisfaction of the definition of the ‘medical device’ within the meaning of the Directive.

The Bundesgerichtshof stayed the proceedings and referred the following question to the Court for a preliminary ruling:

"Does a product which is intended by the manufacturer to be applied for human beings for the purpose of investigation of a physiological process constitute a medical device, within the terms of the third indent of Article 1(2)(a) of Directive 93/42/EEC, only in the case where it is intended for a medical purpose?"

The court decided that the concept of a ‘medical device’ covers an object conceived by its manufacturer to be used for human beings for the purpose of the investigation of a physiological process only if it is intended for a medical purpose.

c. Is it performing an action on data different to storage/archival, compression, communication or simple search?

Decision support system

The product does not necessarily need to generate the diagnosis (which lies with the HP) in order to qualify as a medical device. In practice, there are a wide range of "decision support systems" (from simple to more elaborate). The same applies to patient monitoring; the app needs to perform active monitoring to qualify as a medical device.

Decision support software is usually considered a medical device when it applies automated reasoning such as a simple calculation, an algorithm or a more complex series of calculations. For example, dose calculations, symptom tracking, and acts as a clinician's guide to help when making decisions in healthcare.

Some decision support software may not be considered to be a medical device if it exists only to provide information to enable healthcare professionals to make a clinical decision, as they ultimately rely on their own knowledge. However, if the software/app performs a calculation or interprets or interpolates data and the healthcare professional does not review the raw data, then this software may be considered a medical device. Apps are increasingly being used by clinicians who will rely on the outputs from this software and may not review the source/raw data.


Telehealth is the delivery of health services or information using telecommunication technologies. It uses devices to monitor people's health in their own home including monitoring vital signs (blood pressure, blood oxygen levels or weight). The data can then be transmitted to a healthcare professional who can observe health statuses without the patient leaving home. This function is increasingly being placed on a server and then software is used to interpret the patient data, which could be considered a medical device.

However, consideration should be given to the difference between social care, well-being and health, which can become blurred. For example, an app that uses an accelerometer or gyroscope as a falls detector in epileptic patients is likely to be regulated as a medical device but the same app or device could alert someone if an elderly person has got up from a chair or bed in a social care context. As a detector of falls as part of a medical condition the app will qualify under the MDD and be regulated as a medical device but in the second case it will not meet the definition of a medical device and the medical device regulation would not apply.

Home telehealth systems with connected monitoring devices

Such systems may be composed of a number of elements, for example in the above example of an app which detects falls using a motion sensor. Items such as a hub and possibly a motion detector (depending on the claims of the manufacturer) are not likely to be medical devices as they do not have a medical purpose. However, the software that runs on the server and interprets or manipulates patient data, is likely to be a medical device and would be regulated under the MDD.

Some stand-alone software may break down into a significant number of applications for the user where each of these applications is correlated with a module. Some of these modules have a medical purpose, some not.

a.Is the action performed for the benefit of individual patients?

It can be inferred from this requirement that the benefit of individual patient is more important than either the collation of data for a patient cohort or, of course collection of data for commercial or marketing purposes.

b. Does the defined purpose fall under article 2a of the Medical Device Directive?

In other words, is it designed to provide any of the following:

  • diagnosis, prevention, monitoring, treatment or alleviation of disease;
  • diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap;
  • investigation, replacement or modification of the anatomy or of a physiological process; and
  • control of conception.

c. Is it an accessory to a medical device?

An accessory is an "article which, whilst not being a device, is intended specially by its manufacturer to be used together with a device to enable it to be used in accordance with the use of the device intended by the manufacturer of the device" (Art 2(b) MDD). Accessories, are treated as medical devices by the MDD (art 1) and also need a CE mark.

If the answer to all of these questions, except the last, is yes then, the software will be subject to the MDD.

Other Categories of Software

Active medical devices

An active medical device means any medical device relying for its functioning on a source of electrical energy or any source of power other than that directly generated by the human body or gravity and which acts by converting this energy. Standalone software that falls under the MDD is always an active medical device according to art 2(b) of Directive 90/385 (and Annex IX, section 1.4 of Directive 93/42/EC) because it requires power.

The EN 60601 family of standards is of major importance for all electrical active devices for demonstrating compliance with the Essential requirements of the MDD.

In vitro medical device (IVD)

It is possible that software falling under the MDD is also subject to the IVMDD if it is used in conjunction with an IVD. An IVD is defined as a device which, whether used alone or in combination, is intended by the manufacturer for the in vitro collection, preparation and examination of specimens taken from the human body, solely or principally to provide information for diagnostic, monitoring or compatibility purposes. If the software is part of an expert system incorporating the IVD which provides information within the scope of the IVD definition (differential diagnosis prediction of risks, prediction of failure of treatment, identifying species of bacteria etc.) and the data use is obtained by both the IVD and software element, then it is an IVD.

Active implantable medical device

Active medical devices can also be caught by the AIMDD, if the device is intended to be totally or partially introduced, surgically or medically, into the human body or by medical intervention into a natural orifice, and which is intended to remain after the procedure (art 2(c)).

Who is Responsible for Ensuring Compliance?

The manufacturer is responsible for compliance, including "materiovigilance" (market surveillance). The manufacturer is defined as the natural or legal person with responsibility for the design, manufacture, packaging and labelling of a device before it is placed on the market under his own name, regardless of whether these operations are carried out by that person himself or on his behalf by a third party (Article 1(2),f), Directive 93/42).

In terms of materiovigilance, the manufacturer must report incidents occurring following placing of device on the market to the national authorities competent for "materiovigilance". This would be any dysfunction or any deterioration of the characteristics and/or the performances of a device; any inadequacy of the labelling or the instructions for use likely to result in or to have resulted in death or a degradation of the health condition of a patient, a user or a third person; and any technical or medical reason related to the characteristics or performances of a device for the reasons listed in the preceding paragraph that has required the systematic recall of the devices belonging to the same type by the manufacturer.

General Requirements of the MDD

The MDD classifies medical devices under its remit into four categories (I, IIa, IIb and III) with increasing levels of risk (Annex IX, rules 2-9). The requirements of the Directive, which are set out in Annex I, vary depending on the class of the device. For example CE marking is mandatory for all devices before placing on the market, except devices intended for clinical investigations and Class I ("custom-made") devices.

The CE marking of conformity, as shown in Annex XII, must appear in a visible, legible and indelible form on the device or its sterile pack, where practicable and appropriate, and on the instructions for use. Where applicable, the CE marking must also appear on the sales packaging (Article 17 of the MD Directive and Article 16 of the IVD Directive). When applied to software, this might be on a start-up screen, at the point of download (on the download platform) and in the instructions for use.

MHRA requires individual devices to be CE marked as medical devices but does not require a "system" to be CE marked (see below) as a medical device unless it is placed on the market as a single product. Going back to the example of a telehealth monitor of motion, a hub and possibly a motion detector (depending on the claims of the manufacturer) are not likely to be CE marked medical devices as they do not have a medical purpose. However, the software that runs on the server and interprets or manipulates patient data is likely to be a medical device and would be regulated under the MDD.

Where devices incorporate software, or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification (Annex I to MDD).

The assessment required to determine whether the manufacturers have conformed with the requirements of the MDD vary depending on the class to which the device belongs. For example, for Class I devices, self-certification is permitted whereas the other classes require a third party notified body to certify them (Annex VII to MDD).

IT and Commercial issues

The players involved in the context of an m-Health app are the end-user, the app store, the app providers and the app developers.

App stores provide "information society services" and are arguably providing "hosting"services. The e-Commerce Regulations provide a safe harbour from liability for hosting service providers if (a) the provider has no actual knowledge of wrongdoing or if the services of "a mere technical, automatic and passive nature” and (b) it quickly removes the offending data upon gaining knowledge of it.

However, whether the safe harbour applies is uncertain and requires case-by-case analysis. An open, untended app store such as Google’s “Google Play” may be acceptable, but a store that screens all apps, such as Apple’s App store, is likely to be on shakier ground. The UCPD may also apply to the supply of an app. Schedule 1 of the UK Regulations (Consumer Protection from Unfair Trading Regulations 2008) lists some examples of unfair practices:

  • Displaying a trust mark or quality mark without authorisation.
  • Falsely claiming endorsement from a public body.
  • Falsely claiming that a product is able to cure illness.
  • Therefore the sale or marketing of a medical device displaying a CE mark, which mark has not been granted, would fall foul of these Regulations, resulting in potential civil or criminal sanctions.

Data Protection

Personal data protection is a fundamental right in Europe, enshrined in Article 8 of the Charter of functioning of the EU and Article 16(1) of the TFEU.

According to the Data Protection Directive (95/46/EC and enacted in the UK as the Data Protection Act 1998) personal data is any information relating to a living individual, who can be identified, directly or indirectly.

Personal data can be the name of the user, mobile phone number, e-mail, location, contacts, credit card and payment data, health data, browsing history, pictures and videos.

In the context of an app, the International Mobile Equipment Identity (IMEI) and International Mobile Subscriber Identity (IMSI) have been held to e-personal data as, combined with other pieces of information that may come into the hand of the data controller, could be used to identify the relevant individual.

A sub-set of personal data, which deserves an additional level of protection, is 'sensitive data'. This includes information about any physical or mental health or condition, and so would capture much of the data which is collected by an m-Health app.

Most data protection obligations apply to controllers but some obligations will extend to processors under the General Data Protection Regulation.

There are eight enforceable principles of good information handling practice (s4(4) and schedule 1 of DPA 1998). They are that the data must be:

  1. Fairly and lawfully processed.
  2. Processed for limited purposes.
  3. Adequate, relevant and not excessive.
  4. Accurate and up-to-date.
  5. Not kept longer than necessary.
  6. Processed in accordance with the individual’s rights.
  7. Secure.
  8. Not transferred to countries outside the EEA unless the country has adequate protection for the individual.

In the context of m-Health apps, when sensitive data is involved, in order to comply with the requirement for fair data processing, is to obtain the explicit consent of the individual. The rules are a little more flexible for personal data, but consent is still the best way to ensure.

Apps have the following inherent problems:

  • Lack of user control.
  • Inferences: data quality challenges; risks from profiling; and re-purposing.
  • Data tsunami threat to anonymity.
  • Low quality consent (but requirement for consent).
  • Security weaknesses.
  • Inferences lead to sensitive data.
  • Application of cookie rules.

The new general Data Protection Regulation (GDPR) will enter into force on 24 May 2016 and shall apply from 25 May 2018. It will replace the current Data Protection Directive (95/46) and will be directly applicable in all Member States. The aim of the GDPR is to provide further harmonisation of data protection rules in the EU, ensuring legal certainty for businesses and creating trust on health services with a consistent and high level of protection of individuals. It also introduces "data minimisation""data protection by design"and "data protection by default".

There are existing rights of access to personal data and to object to direct marketing, certain types of processing and to profiling. New rights will be added such that individuals will have the right to be forgotten and the right to “data portability”. The latter refers to electronic data, provided by the individual, a right for data to be provided in electronic form and a right to 'port' it to a new provider.

The new Regulations will require more paperwork (contracts, documentation, privacy policies) and will require explicit consent for secondary use, except for broad statistical and scientific exemptions.


There are different rules regarding advertising standards, which vary according to where in the food chain the advertisement was aimed. The general rule prohibits advertising for a product whose marketing authorisation (or in the case of an app, its CE marking) has not been granted.

If the end-user is patients (general public) then NO product-related content can be shared with the general public. This means that there can be no promotion of an m-Health app. 

If the end-users are healthcare professions only, product-related content can be shared as long as there is an access control (i.e. activation) available to protect end-users.

Also to be borne in mind when advertising and promoting the sales of m-Health apps, are e-privacy requirements, including the consent to access stored data, security and confidentiality and communication services.

Practical considerations

The first step when putting a product on the market is to decide on qualification and classification of the app (or parts of the app/modules thereof. If it is decided not to qualify or promote the product as a medical device, consistency is required in communication so as to avoid requalification

When advertising and marketing the product, it is essential to keep control on dissemination of information. Awareness is required as to differences in implementation of legislation in the Member States. The manufacturer will need to have a strategy for any necessary updates or changes to the app and how these will be communicated to the users/purchaser.

Advertising is forbidden for medical devices that do not bear the CE marking exception at fairs and exhibitions (but with clear indications regarding the non-conformity of the device).

When marketing the app to healthcare professionals, no "advantages" or gifts can be offered (Article 10 of the Act on Medicines).

CE-marking can be used as a "proof of quality" – bearing in mind it is a requirement, so marketing should not be elaborated in a non-ambiguous or misleading way.

The offering of an app may have an impact on professional insurance so check whether the scope of your policy is broad enough.

Contracts with users should address liabilities with respect to medical devices legislation and materiovigilance procedures.

*Article first published in International Comparative Legal Guide to Pharmaceutical Advertising 2016 (Global Legal Group Ltd.), view the article here.