In our recent article, Privacy in Mobile mHealth Apps (Part I), we discussed the core aim of the 'Code of Conduct on privacy for mHealth apps' (Code): to regulate and secure the personal data gathered by mHealth apps. However, compliance with the Code doesn't necessarily equate to compliance with data protection law. Any code for mHealth will need to be consistent with the meaning and spirit of the GDPR, which comes into effect in 2018. Now, we assess the interplay between the proposed Code and the GDPR.

The Code and GDPR

The Article 29 Working Party (WP29) – the collective group of EU data protection authorities – provided recommendations to amend the text of the Code in April 2017. In a letter issued to the project editor of the draft Code, WP29 underlined that the Code should not only be compliant with current law, the Data Protection Directive (Directive), but also with GDPR. WP29 also highlighted that consent to personal data processing for data controllers must comply with all requirements of the GDPR, the Directive, and with guidance in relation to obtaining consent to the processing of children's data.

"Data concerning health" is treated as a special category of data under the Directive but is not defined further. The GDPR has improved upon this and introduces a definition of health data encompassing mHealth data. Like the Directive, health data is categorised as 'sensitive personal data'. In practice, this means that processing this data is prohibited unless based on one or more additional conditions:

  • the individual's explicit consent;
  • necessity for archiving purposes in the public interest;
  • scientific, historical research or statistical purposes; and/or
  • where Member States have introduced further conditions or limitations, known as "further conditions".

Health data under GDPR

Under GDPR, the purpose limitation principle is linked to the processing purposes which have been disclosed to the individual at the time of data collection. This means that the data can only be processed in the manner described to the individual or within their reasonable expectation. Without appropriate disclosures, and potentially obtaining additional consents, using big data and analytics techniques for further different purposes (e.g. profiling or marketing activities) would not be permitted. Also, the processing of health data and manipulation of large amounts of data runs the risk of creating inaccurate conclusions relating to health or misusing individuals' data. Providers of mHealth services must ensure that they define clear, compatible and legitimate purposes to guard against misuse of the individual's data.

On the issue of security, WP29 stated that the Code should include more details and relevant examples on how app developers can integrate 'privacy by design' and 'privacy by default' into their development processes, as well as being attentive to legal restrictions relating to retention periods. Until now, the adoption of data protection by design was voluntary but considered best practice. The GDPR now makes it essential for a data controller "having regard to the state of the art and the cost of implementation...[to] implement appropriate technical and organisational measures". These measures include robust internal policy and practices, such as pseudonymising and encrypting personal data, improved security features, and increased transparency.

Organisations that collect or process EU citizens' health data, whether or not these organisations are established in the EU, will need to be GDPR compliant. It is hoped that the publication of the Code will provide clear guidance for mHealth developers on achieving such compliance. Importantly, failure to comply could result in fines up to €20m or 4% of the businessannual turnover, whichever is greater.

What is next?

The number and variety of mHealth apps has multiplied in recent years. A harmonised EU code aims to provide guidance to mHealth app developers on the level of data protection and security that mHealth app users should expect.

As previously mentioned, Member States will be able to adopt "further conditions" for processing health data. This means that differences may arise between EU Member States. Organisations processing health data and mHealth developers should consider whether they are subject to further conditions set out by separate Member States and, if they are operating in several EU jurisdictions, whether they understand the differences of each Member State.

Organisations now face extra costs associated with GDPR compliance, such as accountability and notification obligations, and, in some cases, the appointment of a Data Protection Officer. The GDPR will also place increased legal obligations on data processors meaning that data processors failing to comply with their obligations will also be exposed to the high sanctions provided for under the GDPR.

WP29 has called for careful consideration on what "added value" the Code will provide and, in particular, what specific examples, practical solutions or recommendations can be drawn from discussions with stakeholders. In the meantime, given the shortage of guidance in this area, mHealth developers and organisations processing health data should consider following the Code and the recommendations from WP29 in order to conform to best practice.

It's not yet known when the Code will be approved by WP29. Once approved, app developers can sign up to the Code on a voluntary basis, thereby committing to following its rules. While it is not fully clear what extra advantages or benefits can be enjoyed by those who voluntarily sign up to the Code, the Code should make strides to provide direction to mHealth app developers and those dealing with health data to be legally compliant.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.