Privacy and mHealth Apps: EU Draft Code of Conduct

Pearse Ryan, Colin Rooney and Hugh McCarthy take a careful look at the key features of the European Commission’s draft code of conduct on privacy for mobile health applications

The Internet of Things is fast becoming a familiar feature of everyday life.  Nowhere is this more apparent than in the health sector. The ubiquity of smart phones, tablets, sensors, wearables, personal trackers and similar wireless smart devices means that huge volumes of data concerning health, fitness, lifestyle, stress and sleep are being harvested and processed. This demand for services and products is feeding an enormous growth in mobile health apps (‘mHealth apps’).  A 2015 report commissioned by iMedicalApps[1] estimated that 165,000 mHealth apps were then available. A separate report estimates that the mHealth sector will become a $59 billion market by 2020.[2] This new marketplace is certain to offer commercial opportunities for app developers, healthcare providers and health insurers, but also presents several challenges. In particular, there are important data privacy implications where personal data relating to individual’s health and well-being is collected and processed on such a large scale. At present there is little harmonisation, whether by accident or design, across EU Member States in terms of the data protection legislation governing this sector. The European Commission has acknowledged this legal fragmentation and in July 2016 proposed a ‘Code of Conduct on privacy for mHealth apps’.[3]

Adopting the Code of Conduct

The European Commission submitted the draft Code to the Article 29 Working Party (the ‘WP29’) for approval in July 2016, which is required before the Code can have effect. The WP29 has not yet approved the Code, or given any indication of when approval might be granted. If the WP29 does approve the Code, it will then be possible for mHealth app developers to adopt the Code.  The Code is a voluntary framework and is thus not automatically binding on app developers.  Those who wish to be certified under the Code are required to: (i) conduct a Privacy Impact Assessment (PIA), together with submitting the results to the Code’s Monitoring Body: and (ii) self-certify compliance with the Code.[4]  If accepted by the Monitoring Body, the app developer and the mHealth app will be placed on a public register.  Continued adherence to the Code is necessary in order to remain on the register and the app developer can be subject to further investigations by the Monitoring Body, either by random selection by the Monitoring Body or following a complaint.

The Code has its origins in the Commission’s Green Paper on mHealth (2014)[5], which revealed that 45% of consumers were concerned with unwanted use of their data when using mobile devices for health related activities. The stated aim of the Code is therefore to foster trust among users of mobile applications which process personal data that includes data concerning health’. By certifying compliance with and following the guidance in the Code, app developers will not only go a long way towards ensuring full compliance with EU data protection legislation, but also potentially gain a competitive advantage by assuring consumer trust.  Before submitting the current draft of the Code to the WP29, the Commission had earlier requested clarification from the WP29 on the scope of the definition of health data in the context of wellbeing and lifestyle apps.   The WP29 identified three distinct situations whereby the processing of personal data by mHealth apps would be considered ‘health data’:

·                  data processed by an app that is inherently medical data;

·                  raw sensor data that can be used to draw conclusions about the status of one’s health; and

·                  data where conclusions are drawn about a person’s health status or health risk

Scope of Code

Differing slightly from the definition of ‘health data’ given by WP29, the Code defines ‘data concerning health’ as ‘any personal data related to the physical or mental health of an individual, including the provision of health care services, which reveal information about his or her health status’.  The Code makes it clear that it covers only apps dealing with data concerning health, and apps that deal only with users’ lifestyles are excluded from the Code.  For example, a lifestyle app that monitors the amount of steps someone takes in a day for the sole purpose of measuring the user's activity, but without processing that data to draw conclusions about that person’s physical condition or health status, would not be considered a lifestyle app and would fall ourtside the scope of the Code.  It would be bound by data protection law generally.  It will be necessary to assess potential application of the Code to mhealth apps on a case-by-case basis. 

The Code is currently governed by the Data Protection Directive 95/46/EC , but it provides targeted guidance on how mHealth app developers can ensure compliance with the GDPR. The Code is not intended to replace or add to existing data protection obligations (whether under the Directive or GDPR), but rather is intended to provide guidance to assist app developers in ensuring that their mHealth apps are in compliance with EU data protection law. 

The Code addresses a broad range of challenging issues and sets out a number of guidelines for app developers, the most important of which are:

·                  User Consent: mHealth app developers must obtain the user’s free, specific, informed and explicit consent for their health data to be processed for the purposes indicated by the mHealth app prior to or as soon as users install the app.

·                  Data Protection Principles: the principles outlined and defined in the Code include purpose limitation, data minimisation, transparency, privacy by design and privacy by default and data subject rights that are of the utmost relevance to mHealth apps.

·                  User Information: the user must be informed of the purpose(s) and lawful basis for which their personal data is collected and processed, the identity of the app developer, where their data will be processed and stored, including whether their data will be stored in other locations, such as back-up servers. Users must also be informed of their rights to access, correct or delete their data, as well as the right to data portability.  A layered approach is recommended, whereby users are provided with a condensed notice which contains the vital information in accessible language with the possibility of clicking through to a full privacy policy containing all other relevant information.  The information should be available before app installation and should be easily accessible again after installation should the user so wish.

·                  Data Retention: personal data may not be stored any longer than is necessary for the functionalities of the app.  Criteria must be set out and communicated to the user for either the deletion or the anonymisation of data.  As an alternative to deleting data, apps providers may also irreversibly anonymise personal data,  such that there is no risk of individuals being subsequently identified from the data.

·                  Security: the Code requires the carrying out of a Data Privacy Impact Assessment and adoption of security measures which have been recommended by ENISA.  Provisions in both areas are outlined in annexes to the Code.  It might be noted that mHealth app developers, as well as being within the scope of data protection legislation, including the Code (which is a voluntary arrangement), may also be within the scope of the Directive on Network and Information Security (the ‘NIS Directive’), whether as an ‘Operator of Essential Services’ or ‘Digital Service Provider’.  Further discussion of the NIS Directive is outside the scope of this article.

·                  Advertising: any advertising within the mHealth app must have been given prior authorisation by the content user, but this requirement differs depending on whether the advertising involves the processing of personal data.  For contextual advertising, which is a form of targeted advertising based on the identity of the user and the content displayed, an opt-out option must be given to the user before any processing of personal data can occur.

·                  Use of Data for Secondary Purposes: Any further data processing must be compatible with the purposes for which it was originally collected, as communicated to the content users.  Processing for scientific or historical research may be considered as compatible with original purposes, provided all relevant national and EU-level restrictions are observed. Data anonymisation or pseudynomisation may facilitate secondary processing for the purpose of big data analytics.

  • Disclosing Data to Third Parties: Data may be made available to a third party for processing only after the user has been appropriately informed.  A legally binding agreement must be entered into with the third party, which restricts the third party from processing the data for any purpose other than that which the user has been informed of and must contain specific security obligations on the third party.

·                  Data Transfers: The Code provides that data can be transferred and stored on the app developer’s servers only if proper consent has been obtained from the user.  Transferring data to third parties must satisfy the conditions mentioned above, and, in the case of data transfers to locations outside the EU/EEA, legal guarantees are required to ensure that the transfer is permitted under EU data protection law (ie must ensure that the country to which the data is being transferred has an adequate level of data protection).  The European Commission has published a list of countries that it deems to have an adequate standard of data protection.  Subject to several exceptions,[6] the Directive states that transfers of personal data should not be made to countries that do not appear on this list.

·                  Data Breaches: The Code sets out practical steps to follow in the event of a data breach. These steps could be pro-actively implemented by app developers to compile a data breach ‘play-book’ before a data breach occurs. The Code outlines the notification process that accompanies breaches of personal data.  Note that, where applicable to a developer, the NIS Directive contains a (separate) notification and post-notification investigation, including potential sanction, process.

·                  Children’s Data: The Code places specific conditions on mHealth apps that are deliberately aimed at children.  It is recommended that app developers pay attention to the age limit defining minors (which may vary from one EU Member State to another under the GDPR), and apply the most restrictive data processing approach to children’s data.  Moreover, it is noted that parental involvement is critical for such apps and therefore ‘reasonable efforts’ must be taken by app developers to verify consent.  The approach adopted in the Code largely mirrors that of the GDPR, particularly as regards the processing of children’s data.

Code Oversight

A three-tiered governance system has been proposed under the Code to ensure compliance with the Code and that the views of relevant stakeholders are taken into account.  The governance of the Code will be financed and supervised by a General Assembly, comprised of representatives of all stakeholders, namely app developers, the ‘data protection community’ (which appears to be the collective term for the relevant regulatory bodies), industry associations, and end-users.  A Governance Board consisting of 6-10 members selected from the General Assembly has been proposed to manage the everyday interpretation and maintenance of the Code, as well as any potential code amendments.  Furthermore, a Monitoring Body comprised of members chosen by the Governance Board after consultation with the General Assembly will deal with complaints and ensure the adherence to and effective enforcement of the Code by keeping a public registry of all app developers complying with the requirements of the Code and by engaging in reviews of app developers’ applications.

Is the Code Likely to be Attractive to App Developers?

While the purpose of the Code is to assist app developers in ‘making responsible and informed choices that comply with European data protection law’, it remains to be seen whether the Code will prove attractive to app developers in large numbers.  There is no guarantee that stating adherence to the Code will lend a competitive advantage to app developers. Further, if this were to be the case, it is unclear whether any commercial advantages accrued would outweigh the administrative and regulatory burden of continued compliance with the Code (such as the necessary completion of a PIA and ongoing checks by the Monitoring Body). For example, in certain circumstances, app developers who conduct a PIA may be subject to an obligation to ‘consult’ with the relevant data protection authority on the findings of the PIA.


The huge increase in the number and type of mHealth apps available over a short timeframe, largely driven by the consumer willingness to utilise IOT devices, has alerted the Commission to the need to intervene based on its consumer protection and personal data protection mandates. 

The Code has been some time in gestation and has been with WP29 since July 2016 awaiting approval.  The time taken is likely due to overlap with the general overhaul of data protection legislation, seen in the GDPR and the January 2017 Commission proposed Regulation on Privacy and Electronic Communications, together with new information security initiatives, seen in the Directive on Security of Network and Information Systems (with the two Regulations and one Directive taking effect in May 2018).

The Code provides a harmonised EU data privacy framework, intended to protect users’ privacy and ensure adequate data security in a burgeoning area which shows no signs of slowing down.  While the Code benefits mHealth solution users it remains to be seen whether mHealth app developers will find the Code as beneficial, given its high administrative and regulatory burdens, which will quite likely impact on the volume of developer take-up.

We will follow the legislative progress of the Code, as well as its subsequent roll-out, with interest. 

Pearse Ryan and Colin Rooney are both partners and Hugh McCarthy is an associate in Arthur Cox’s Technology and Innovation Group.


[4] The PIA under the Code is separate to the obligation contained in Article 35 of the GDPR to conduct a data protection impact assessment in instances of high-risk data processing. This is beyond the scope of this article.


      This site uses cookies. By using the site you agree to our use of cookies as set out in our Privacy Policy.