mHealth apps: The Code of Conduct on privacy, explained

"mHealth" or "mobile healthcare" refers to the use of apps to allow users to monitor, evaluate and improve their health using data recorded by their smartphones and other mobile devices. While apps of this type clearly provide a vastly useful service to their users, the data that the apps record – heartrate, blood-sugar levels, general fitness, etc. – is highly sensitive.

The 'Code of Conduct on privacy for mHealth apps' was originally proposed by the European Commission in June 2016. The Commission highlighted the benefits that mHealth apps bring to society, but was also aware of their particularities, the type of data being processed and, accordingly, the type of protection they require. The Code aims to be a tool that promotes the development of applications, with the intention of ensuring that highly sensitive data of this kind is adequately protected according to the principles set out in the European data protection laws. At the same time, it aims to bridge gaps not currently covered by data protection legislation.

The Code is a voluntary framework for app developers and is therefore not binding. At the moment, it is a draft for consideration by the Article 29 Working Party ("WP29", an independent advisory body comprised of representatives of EU data protection authorities, which has since been replaced by the European Data Protection Board).

What does the Code consist of?

The core of the draft Code consists of a number of guidelines which are a reflection of some of the principles included in the EU’s General Data Protection Regulation (GDPR). The Code focuses on a large number of issues related with mHealth app developments, the most important of which are the following:

• User’s consent: mHealth app developers need to obtain free, specific, informed and explicit consent from the data subject in order to process their data. This must take place prior to the installation of the app or as soon as this takes place.
• Purpose limitation, data minimisation and secondary purposes: data may be processed only for specific and legitimate purposes and in a manner compatible with the original purpose. Processing for scientific or historical research may be considered as compatible with original purposes, provided all relevant national and EU level restrictions are observed. Only data that is strictly necessary for the functionality of the app may be processed and this should not be processed for longer than required.
• Privacy by design and by default: privacy implications of the app have to be considered at each step of development and wherever the user is given a choice. The app developer has to pre-select the least privacy-invasive choice by default.
• User information: users should be informed in plain language of the purpose(s) and lawful basis for which their personal data is collected and processed, the identity and contact details of the app developer, the categories of personal data processed, the transfer of the personal data from users' device and the categories of recipients. Users should also be informed how they can exercise their data protection rights. In providing the information to users, the Code also opts for a layered approach, by first providing the user with the most significant information regarding the processing of their personal data and once the app is installed, providing a second set and more detailed information.
• Data retention: personal data may not be stored longer than necessary, unless otherwise regulated. In this regard, the Code recommends that app developers define the criteria to delete the personal data and communicate such criteria to app users.
• Security measures: app developers should ensure that apps are designed following guidance on secure smartphone app development and secure software development. In order to determine the specific technical and organisational measures that need to be implemented, the app developer needs to carry out a risk assessment based on the personal data processed. In addition, app developers shall carry out a privacy impact assessment.
• Advertising: use of advertising must be authorised by the user before the app is installed, but there is a difference in approach depending on whether advertising involves the processing of personal data or not. If the advertisements are shown without processing of users’ personal data, or these do not imply sharing personal data with any third party, the app developer only needs to allow the user to opt-out of the contextual advertising. Otherwise, showing advertisements to a user will require their prior opt-in consent, which must be obtained specifically and separately.
• Data transfers to third parties: app users need to be informed prior to disclosure of their personal data to a third party. Data transfers to locations outside the EU/EEA must be protected by appropriate safeguards (such as EC model clauses or Binding Corporate Rules, among others).
• Personal data breach: when it comes to data breaches, the developer's place of establishment and local law will determine the need to notify data breaches as well as the specific timeline to make such notification, the information to be provided and whether there is an obligation to notify affected individuals.
• Data relating to children: the Code includes a specific guideline to address mHealth apps that are aimed at children. Depending on the age limit defined in national legislation, the most restrictive data processing approach needs to be taken and a process to obtain parental consent needs to be put in place.

WP29 recommendations

The European Commission submitted the draft of the Code to WP29 for its approval in June 2016 and WP29 provided its recommendations in April 2017.

WP29 determined that the provisions in the Code did not bring sufficient added value to the Directive and/or national law and that the Code did not elaborate sufficiently on the relationship between EU legislation and implementing national legislation in individual EU Member States.

Moreover, according to WP29, the Code did not take into consideration other legislation that could have a major impact on apps (legislation around cookies, for instance). WP29 also considered that the Code should clarify the roles of the parties involved in the processing of personal data (making a reference to the notions of data controller and data processor) and that, as per the notions of health data and lifestyle data of the Code, these should be aligned with the definitions given in the GDPR and the Directive.

Besides these general comments, WP29 considered (amongst other things) that:

• First, insufficient detail had been provided for it to determine whether the governance model detailed in the Code, involving a General Assembly, could be compliant with some GDPR provisions (for example, the Code fails to provide information on sanctions or monitoring activities, no clear information is provided on the independence, impartiality and transparency of the different governing bodies, no specific information is provided on the composition of the General Assembly and on the membership management).
• Second, the Code did not acknowledge that there are other conditions which may render data processing fair and lawful, besides consent. This is relevant considering that consent might not always be freely given by individuals, particularly if the use of the app has been recommended to them. When it comes to obtaining the consent of guardian's to process children's data, the WP29 recommended that more details should be included on the consent verification given the vulnerability of these users.
• Third, the Code did not cover all the relevant data protection principles (such as the accuracy and quality of data, its accessibility and security issues linked with data storage), or did not give enough practical explanation regarding some other principles.
• Fourth, the Code did not provide sufficient information or practical examples on how users can exercise their rights and on how controllers and processors should meet their obligations related to data subject rights, particularly in relation to data portability
• Finally, the Code did not provide enough information or examples on how mHealth app developers can integrate "privacy by design" and "privacy by default" in their development process; WP29 indicated that app developers should be attentive to legal restrictions relating to retention periods.

What next for the Code?

It is clear that compliance with a voluntary code designed to protect users’ data could give mHealth app developers an advantage in the highly competitive world of mHealth apps, particularly with the current levels of public awareness of the importance of data protection following the implementation of the GDPR. Compliance will also be a useful tool for app developers to ensure that they avoid any fines (and associated negative publicity) under the GDPR.

The WP29 made clear that the current information provided by the Code does meet either with the GDPR requirements nor with the level of security that is needed to process health data. The draft will now need to be reconsidered by the drafting group, and we will have to see which inclusions are made by the drafting group in order to cover the issues pointed out by WP29. Thereafter, the Code will need to be (re)submitted to what is now the European Data Protection Board.

Developers of mHealth apps should look out for a revised version of the Code, when it is published. In the meantime, they should ensure that they are compliant with the GDPR and other relevant legislation.