Internet Explorer 11 (IE11) is not supported. For the best experience please open using Chrome, Firefox, Safari or MS Edge

It’s never too early to consider GDPR and its future implications when designing your digital health products and services. Baking in GDPR principles from the outset of your design process is important. Having a clear plan for what data you will need, how you’ll collect it, what you want to do with the data and when, and what you need to tell those affected, can help you achieve compliance and avoid delays and issues in the future.

What is required

The GDPR principle of “data protection by design and default” obliges controllers to:

  1. Implement appropriate measures to adhere to data protection principles both at the time you are deciding how you are going to process data and the first time you start processing, and
  2. Ensure that, by default, only necessary personal data is being processed.

This means GDPR compliance cannot be an afterthought - you must be able to show it’s been baked into the design process and the functionality of the product from the outset.

Increasingly, regulators are asking providers of products and services, especially those handling sensitive data like health data, to demonstrate compliance with these principles. Regulators will look beyond external facing documents like terms of service and privacy policies. They will also expect to see evidence of data protection consideration throughout the life cycle of the product and reflected in documentation, such as data protection impact assessments.

Practical issues to consider

From the outset, issues to consider are:

Transparency: you must be clear with individuals about how their data will be collected, used and shared. This means ensuring your privacy notice is written in clear, precise and understandable language and avoids overly-technical jargon. It also means ensuring this information is presented in an effective manner that is appropriate to the product or service. For example, providing in-product notifications for key messages to individuals and providing individuals with summaries and layered privacy notices.

Fairness: you must not use data in a way that is unjustifiably detrimental or discriminatory or in a way that is misleading or unexpected. This means ensuring any algorithms relied on are reviewed regularly for any bias against certain categories of individuals and mitigation measures are put in place, such as human oversight and intervention. It also means ensuring that options are presented in a fair and neutral manner and individuals are not “nudged” into providing unnecessary data or unnecessarily accepting more permissive privacy settings, such as sharing data with third parties.

Purpose limitation: you must collect data for a specific purpose and not use it for any other incompatible purposes an individual wouldn’t expect. For example, the dataset collected and used for purpose A cannot be merged with data collected and used for purpose B unless individuals have been made aware of this. This underlines the importance of ensuring when you collect data you explain in your privacy notice how you’re going to use data and keep users informed. It also means that before you start processing for a “new” purpose, you need to carefully consider whether an individual would expect it and whether further steps need to be taken, such as obtaining a further consent.

Data minimisation: you should only process data that is necessary for the purposes for which you intend to use it. Data that might be valuable or useful in the future should not be collected. This means that product features and settings should be reviewed carefully to ensure they are only collecting what you need and not enabling passive and inadvertent collection of data. It also means that, once the raw data collected is no longer necessary, such as where data will only be used for statistical purposes, you should consider de-identification measures or aggregation.

Accuracy: you should ensure data you process is accurate and steps are taken to ensure accuracy over time. This means making certain that measures are in place to review / verify the accuracy of any data sources you intend to rely on, such as to train algorithms, at the time of collection and throughout the life cycle of the product. This can also mean ensuring individuals have the ability to edit and update their information.

Storage limitation: you should only keep data as long as you need it. Keeping data “just in case” is not permitted. This means ensuring there are clear internal rules on how long data is needed. This should reflect the reality that data will be needed for different periods such as to provide your service, for operational and technical purposes and legal reasons. Once the relevant period has passed, the data should be deleted or anonymised.

Security: you must have appropriate measures in place to protect the data from risks. The measures required will depend on the nature of the data and the possible harm that could arise. For example, more robust measures will be required if you are processing health or other sensitive data than if you are handling less sensitive data such as contact details. Measures also need to be in place to prevent and mitigate risks arising from security breaches, such as measures to detect unauthorised access and a robust incident response policy. You should also conduct regular security assessments to ensure your measures remain appropriate.

Next steps

Early consideration of GDPR principles should be seen as an essential part of any product and service development and a necessary step to achieve compliance with GDPR. Integration of these principles into your processes and systems as soon as possible, will put you in the strongest position to achieve compliance and avoid future issues, such as needing to redesign your product at a later date or risks of user complaints or enforcement.

For more information, please contact a member of our Privacy & Data Security team.

The content of this article is provided for information purposes only and does not constitute legal or other advice.

Share this: