Source: https://www.chino.io/blog/9-key-things-about-gdpr-that-health-app-developers-need-to-know/
Timestamp: 2018-05-23 22:26:29
Document Index: 646596647

Matched Legal Cases: ['art. 83', 'art. 37', 'art. 9', 'Art. 29', 'art. 49', 'art. 4', 'art. 4']

9 key things about GDPR that Health App Developers need to know
By Giulio Messori — a year ago in
The EU General Data Protection Regulation (GDPR), is a new legal instrument that harmonizes privacy rules for all European Union Member States. Approved in 2016 and immediately applicable,1 the Regulation aims at making it simpler for businesses to deliver services in EU, but it brings also new rules and increases fines for rules violations.
This article will narrow its focus on businesses collecting or processing health data (or "data concerning health")2 such as startups and companies developing mHealth, eHealth or Digital Health services or apps. Before proceeding, remember that:
If you are collecting or processing EU citizens Health Data in your business (either you are established in EU or not), it is pivotal to ensure GDPR compliance. This is especially important because the new fines in case of data breaches or data misuse can reach up to € 20 Mln, or up to 4% of your annual worldwide turnover (see art. 83, par. 5 & 6 GDPR).
If you don't know what type of data you are collecting or processing (which in most of the cases need to be GDPR compliant as well), you can easily find it out in our Self-Assessment Compliance test.
Privacy and security requirements for digital health businesses
Let's examine some of the requirements that you need to comply with if you are running a digital health business and you are processing health data. In each of the following bullet points, you will find a brief explanation and practical suggestions.
1) CONSENT: consent is a freely given, specific, informed and unambiguous indication of an individual’s wishes regarding his/her data collecting and processing. The aim of asking consent is to maintain an interactive relationship with any subject while handling its privacy.
Suggestion: Implement an “explicit and affirmative consent” through check boxes and clear privacy policies. You must work with lawyers to craft policies and terms based on your needs and data processing. In addition, you must track all the actions that users do from the signup to account deletion.
2) RESPONSIBILITIES OF DATA CONTROLLERS AND PROCESSORS: typically the entity that offers a service to citizens is called data controller. It has a criminal law liability regarding sensitive data processing and must ensure compliance. With GDPR controllers must implement data protection by design and by default.
In addition, with GDPR controllers must ensure that their data processors with whom they collaborate are liable for the data processing that they are in charge of, and the data they manage on behalf of the controllers.
Suggestion: If you are offering a Digital Health service to end users you will be considered as a data controller. You must implement privacy and security by design, i.e. consider privacy requirements from early stage design phases. Furthermore, you must choose very well your Cloud providers (data processors) in order to ensure that they do comply with GDPR. This is challenging nowadays, with EU-US Privacy Shield evolutions and data transfers. In addition, check processors contracts and Terms and Conditions carefully. Few of them take liability about the data you give them. Check our eBook at the end of this article for more info about this aspect.
3) DATA PROTECTION OFFICER (DPO): the GDPR introduced a specific obligation for data controllers and processors to appoint a Data Protection Officer (DPO) where the processing of data: a) is carried out by a public authority or body; b) require regular and systematic monitoring of data subjects on a large scale; c) consist of processing on a large scale of special categories of data (see art. 37 GDPR). The DPO is a figure that can facilitate compliance and become a competitive advantage for businesses.
Suggestion: It is still difficult to understand if your health business falls into one of the just mentioned condition and you need to appoint a DPO. The GDPR defines what a 'special category of data' is (namely those defined in art. 9 GDPR), but it does not define what constitutes a ‘public authority or body’, what is a 'regular and systematic monitoring' and what processing on a 'large scale' means. In order to better understand these expressions, regard should be put on Art. 29 Working Party guidelines on Data Protection Officers. The Working Party is an European Body who owns advisory role to all the other EU institutions. More detailed information will be provided in the period to come.
4) DATA BREACH NOTIFICATION: GDPR defines a 'personal data breach' as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.3
Suggestion: data breach cases come from a lack of appropriate security infrastructure standards. Usually app developers program their own full stack (apps and server side) and they don't have much experience with cyber security. So first of all, consider a secure way to store your data! In case of breach, as a data controller of your business (see point 2), you must notify any breach to the supervisory authority (most likely the authority appointed by your Member State) within 72 hours. The notification has to be detailed and it must contain the mention of the DPO (if appointed).
On the other hand, if you have appointed a data processors (see point 2) he/she has the only obligation to notify the data controller (you) about the data breach.
5) CROSS BORDER DATA TRANSFERS: GDPR authorises transfers of data to third countries if they are all awarded by the Commission’s adequacy designation, binding all EU. The designation is given if such countries provide “essential equivalence” of protection. However, there are mechanisms disciplined by art. 49 GDPR that allow cross-border data transfer in absence of "adequacy", such as approved certification mechanisms together with binding enforceable commitments of the data controller or processor.
Suggestion: If you are transferring data in other countries you must consider a secure and 'adequate' method in order to avoid data breaches and leaks. Check your processor's terms and conditions, and ensure that they comply with EU laws.
6) PROFILING: profiling data under GDPR means an activity of automated processing of personal data and the consequent use of the personal data so collected to evaluate certain personal aspects related with a natural person (e.g. economic situation, performances at work, location, etc.). Profiling activity involves the prediction of subjects behavior, preferences and the undertaking of decisions based on them.
Suggestion: If you are developing an mHealth App and you are profiling your users, you must inform the data subject that his or her data are being collected. You also need to inform about the “logic” behind data profiling, the purposes, the consequences of profiling decisions and the right for the subject to inquire any data controller of such activities.
7) RIGHT TO BE FORGOTTEN AND DATA PORTABILITY: the Right To Be Forgotten (RTBF), is a new fundamental individual right created in 2014 by the CJEU. It allows natural subjects to require the deletion of personal data ("without undue delay"), and to require all other controllers, in case the data was rendered public, to do so.
The Right To Data Portability (RTDP) implies the obligation to provide all data to the related subject in a commonly used format and to comply with the transfer of that data to another controller at any data subject request.
Suggestion: GDPR explicitly codifies these rights. As a data controller of an mHealth App, you must grant RTBF and RTDP by communicating these rights to your users, using a transparent form always accessible on your platform and using a plain language.
8) PSEUDONYMIZATION: pseudonymization is "the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information".
Suggestion: If you are processing health data you may consider this technique to better protect them. GDPR encourages pseudonymization, although it does not deem it preclusive of other forms of protection (even more protective). In fact, pseudonymization still allows attribution of data to a natural person with additional information. Pseudonymisation does not mean anonymity: a data breach could still allow obtaining the key, or the identification of subjects by combining indirect identifiers. We at Chino.io can help you with pseudonymization! Check our eBook at the end of this article for more info.
9) CODES OF CONDUCT AND CERTIFICATIONS: first clarification: no codes or certification schemas have been declared as mandatory so far. However, codes of conduct are used to demonstrate that data controllers and processors are analyzing risks in an efficient way while providing a protocol to reduce them, complying with GDPR. Codes of conduct facilitate cross border data transfers, but they are also useful as a criterion for Controllers to select processors without reviewing them, by simply checking the degree of satisfaction of the code requirements.
Certifications are useful to show compliance with requirements of data protection by design and by default (see point 2), they also help in all the circumstances related to codes of conduct.
Suggestion: as an mHealth App Developer you might consider implementing Codes of Conduct and Certifications and you should make them always visible to your users.
How Chino.io can help you comply with these requirements
As you had the chance to read, complying with GDPR requirements is hard and it requires not only legal and compliance consciousness, but IT programming and technical know-how as well.
The truth is that fulfilling these requirements takes time, resources and a great deal of study. With our experience, we at Chino.io can help you with that.
Chino.io gives Digital Health, eHealth, mHealth developers the possibility to store (partially or totally) sensitive data that they collect into a secure data storage through an API integration. We act as data processors, and in this way, you can delegate us your data management responsibilities and increase data security without worrying about time.
If you want to know more about health data security don't hesitate to contact us at info@chino.io or download our FREE eBook on health app compliance:
Do you want to learn more about GDPR and Health App Compliance?
European Commission considers 24 months as a period for all data controllers and data processors to make modification to their systems to comply with the regulation. However, not all the states expressed the will to wait for such a long time. France clearly indicated the desire to shorten the “grace period” up to 12 months. ↩
According to art. 4, par. 15 GDPR, "data concerning health" are defined as "personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status". ↩
[^3] See art. 4, par. 12 GDPR.