Period trackers have been in the news recently after Privacy International revealed its concerns about the amount of personal data collected by them.
The privacy campaign group had made subject access requests to five apps in an attempt to discover what personal data was held by them and to whom it was disclosed. The exercise raised a number of concerns including around transparency (especially in relation to disclosure to third and fourth parties), the amount of data collected and the fact that it was largely stored on servers rather than on user devices.
These issues are typical privacy issues around mHealth apps which range from fitness trackers, to menstruation trackers, disease and illness diagnosis, treatment and management, as well as mindfulness and wellbeing aids. The majority will process personal data which, in the EU and UK, will make the processing subject to the GDPR and UKGDPR respectively (referred to here as the GDPR for ease). Much of the data processed will be special data which is subject to more stringent protections (read more here).
Meeting GDPR compliance requirements can be complex but getting it wrong can be fatal in terms of reputation management as well as financial penalties. Paying particular attention to the following areas can help mHealth apps build user trust and achieve regulatory compliance.
Data protection has to be considered at the earliest stages of app development and built in from the start. Privacy settings should be set to their highest levels by default.
DPIAs will be required for many mHealth apps but even where they aren't mandatory, they are a useful exercise to help focus on potential risks to data subjects of planned processing, and ways to reduce that risk. They are also vital to help meet the accountability requirement which requires you to be able to demonstrate GDPR compliance.
Each processing operation must be carried out under one of the lawful bases for processing personal data. In addition, where special data (which includes health data) is being processed, an Article 9(2) condition must be met. This can be a tricky process, particularly because valid GDPR consent can be difficult to obtain in a health context so it needs to be carefully thought through. The personal data cannot then be processed for a purpose which is incompatible with the original purpose for which it was collected.
How much of the data you process really needs to link to an identifiable individual? This will depend on the nature of your app. If it is used to help deliver tailored medical treatment, then the data is more likely to need to be personal. If your data relates to more generalised issues, for example, tracking menstrual cycles and symptoms, does it really need to be personal? Consider whether it can be anonymised or, at least pseudonymised. And do you really need the individual to register?
Many of the COVID contact tracing apps have taken a decentralised approach which means that personal data they collect stays on the user's device. While we can debate the overall usefulness of contact tracing apps, a decentralised approach has helped build public confidence that personal data won't be misused. If you need to store data on a server rather than on a user device, can you anonymise or pseudonymise it?
The more sensitive the nature of the data being processed, the tighter the security should be. Any data breach can attract regulator scrutiny and cause reputational damage, but failure to protect health data is particularly likely to set off alarms.
Transparency is essential to avoid 'data shock'. Beyond this being a central GDPR requirement, it is common sense. If it is clear to the user what is happening to their data, they are less likely to have a problem with it or to discover at a later stage that their data is being used in unexpected ways. For mHealth apps, the challenge can be conveying this information in a digestible form so be creative – ICO guidance may help.
Users should have control over their data. They should, for the most part, be able to access it, correct it and delete it. You need to have the processes in place to enable them to do that.
It is not enough to comply with the GDPR, you have to be able to demonstrate compliance which requires clear policies, procedures and an audit trail.
This isn't just an issue where the data is leaving the EU or UK (as the case may be) although that certainly brings in a range of additional considerations. It's also important to consider which third parties are getting access to the data and why, as well as who they might pass data on to. Again, anonymisation can help leverage the data without creating additional risks to the rights and freedoms of data subjects.
Personal data should not be held for longer than necessary for the purpose for which it was originally collected. If you anonymise it, the restriction no longer applies.
It's tempting, given the value of data (financial or otherwise), to collect as much of it as possible for as wide a range of purposes as you can. While the GDPR aims to prevent this, one of the interesting points highlighted by Privacy International's investigation into period tracker apps was that some of them were doing everything in accordance with their privacy policies; users had agreed to all of it. Yet Privacy International still felt that users would be shocked if they really understood how much intimate personal data was being processed and transferred to third parties.
Did the apps really need all the data they collected in order to fulfil their purpose and if not, why were they processing it? While the apps said they needed the data to provide a more tailored experience, Privacy International questioned the benefits to the user and stressed that the apps needed, above all, to comply with the principles of data minimisation and purpose limitation.
That's not all there is to GDPR compliance but it's a good place to start.
If you would like to discuss any of the issues raised in this article in more detail, please contact a member of our Life Sciences & Healthcare or Data Protection & Cyber teams.