In our previous post we outlined the key issues regarding mHealth devices and services from a privacy law perspective. Now, we go further into the details and discuss the scope of the personal data involved, especially relating to sensitive health data. We introduce the relevant statutory requirements in the EU and the legal opinions of the Article 29 Working Party and the European Data Protection Supervisor as well as having a look at the upcoming European General Data Protection Regulation. Against this legal background, one core question we will examine is whether information collected and processed by lifestyle apps and devices must be classified as health data and fall under the strict requirements of European data protection laws.
Personal information involved in mHealth businesses
What makes mHealth devices significant from a privacy law point of view, is that they allow the collection and processing of very large quantities of health-related information about an individual over a long period of time.
For example, popular apps can record an individual’s body weight, body mass index, calorie or medication intake as well as store information on sleep patterns, the time spent brushing teeth, the use of contraceptives, the course of a pregnancy or smoking and drinking habits. Some apps even analyze the sound of a cough.
Moreover, there is a strong demand for apps that track a user’s physical activity and training success. Such lifestyle apps are often combined with wearables like activity tracking wristbands or smart watches which usually capture the individuals’ location using GPS or other means. Successful examples on the market are digital step counters or devices monitoring heart-rate or blood pressure.
Apart from such lifestyle apps and devices, there are also a wide range of mHealth solutions used in a professional medical context between a patient and physician. Professional medical apps usually comprise information on diseases, disease risks, clinical treatment or the physiological state of the patient (e.g. electronic blood glucose meters, heart rate and blood pressure monitors; there are even fever thermometers that transfer captured data to an app).
Is the information collected “personal data”?
From a data protection law perspective, the core question is whether and to what extent the information collected and processed by such mHealth devices and apps is “personal data” under data protection laws. The applicable EU regulations (EU Data Protection Directive 95/46/EC, Directive) as well as German Data Protection provisions take a broad approach to the definition of personal data. According to Art. 2 b) of the Directive (implemented by Sec. 3 No. 1 German Federal Data Protection Act, FDPA), personal data covers any information relating to an identified or identifiable natural person. Consequently, even if an individual has not been identified by his or her name or another distinctive identifier, an accumulation of information relating to that person can become personal data if the individual is ultimately identifiable (regardless of the source of the data).
This legal approach will persist under the future European General Data Protection Regulation (GDPR) which shall apply to any information relating to a natural person who can be identified, directly or indirectly (e.g. by reference to an identifier such as a name, an identification number, location data, online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that person).
Given the broad scope of this legal term, the information collected and processed by mHealth devices like smartphones, tablets and smart watches should be considered to be “personal data”. Typically, such devices and apps require several identifiers as part of the user account registration process, such as name, address, email-address or telephone number which enables the information collected to be attributed to a specific individual.
Additionally, technical identifiers which are permanently connected to the device, like a MAC-address, IMEI, UDID or IMSI numbers are personal data (although the question of whether dynamic IP addresses are personal data is subject to proceedings pending before the European Court of Justice).
Biometric identifiers uniquely connected to an individual (e.g. fingerprint, iris images or facial geometry) will constitute personal data. Equally, address book data, calendar entries, messages (SMS, emails etc.), voice recordings and photos of the device user is personal data.
Information on a user’s location (geographical data) is personal data if it is combined with other information that makes a person identifiable (e.g. IP address) or if the person can be identified by his/her actual physical movements (e.g. by specific patterns, like travelling the same way to work each day; cf. the joint assessment of the Federal Data Protection Authorities in Germany dated 16 June 2014, p. 5).
Finally and most importantly, raw data obtained by technical sensors on mHealth devices or submitted by a user of a mobile app (e.g. concerning physical activity, vital signs, calorie intake, medication, tobacco consumption etc.) qualifies as personal data given that it is possible to link the information to a certain individual.
Pseudonymization and anonymization of personal data
One big challenge for mHealth products and services is that most legal frameworks stipulate that devices should collect as little personal information as possible (principle of data minimization). To achieve this goal, many national data protection laws encourage comprehensive pseudonymization or anonymization measures to the extent technically possible and reasonable (cf. Sec. 3a FDPA, Sec. 16 (6) German Tele Media Act).
According to Sec. 4 (3b) GDPR (draft) “pseudonymization” means the processing of personal data in such a way that the data can no longer be attributed to a specific individual (in legal terms the “data subject”) without the use of additional information, as long as such additional information is kept separately and subject to technical and organizational measures to ensure non-attribution to an identified or identifiable person. However, it is important to note that pseudonymous data is personal data if it can be re-identified by the data controller or by third parties through combining the data with external information from other sources (Opinion of the European Data Protection Supervisor of 21 May 2015, subs. 11).
Frequently, even anonymization methods are suspected of not effectively anonymizing personal data since the applied anonymization technique can be weak or the anonymized data can be so unique that it can still be linked with a specific individual. Recent published statements from European competent authorities take the view that anonymized information, in such cases, should still be considered to be personal data (cf. Opinion of the Article 29 Working Party on anonymization techniques of 10 April 2014; Opinion of the European Data Protection Supervisor of 21 May 2015, subs. 11).
Restrictions to collect and process sensitive health data
Once it is decided that the data collected and processed by mHealth products is personal data, the next important question is should this personal data be considered to be health data since, under European data protection law, health data is subject to a higher level of protection. Consequently, the opportunities to collect and process sensitive health data for different purposes other than for professional health care are limited. In most instances a data controller is required to obtain the deliberate, explicit and informed consent of the individual where the consent wording expressly refers to the use of specifically named health data. Moreover, the possibilities for relying on a statutory permission to collect or process sensitive health data are very limited. These restrictions will also apply under the future EU General Data Protection Regulation (cf. Art. 9 GDPR [draft]), whilst the European Commission noted in its Green Paper dated 10 April 2014 (Sec. 3.1) that mHealth solutions usually collect sensitive health data.
When does personal data become sensitive health data?
It goes without saying that medical information about an individual; in particular information on his or her physiological and mental health status, on diseases, disabilities, disease risks and clinical treatments, always constitute sensitive health data. Therefore, mHealth apps and devices that are used in the physician-patient relationship regularly involve sensitive health data. Apart from these specific medical mHealth devices, where other apps (not designed for physician-patient communications) are processing health data, such apps are more likely to be subject to investigations and administrative proceedings from competent data protection authorities.
But where can you draw the line between personal data and sensitive health data?
Both the European Data Protection Supervisor and Article 29 Working Party point out that the distinction should not be based on the nature of the information only. Instead, the purpose and circumstances of the data collection should be likewise considered.
In particular, the European Data Protection Supervisor takes the view that non-medical data about a person’s lifestyle and wellbeing should be considered to be health data, when processed in a medical context, monitored over a long period of time, or where information regarding an individual’s health may reasonably be inferred from the data concerned. The Article 29 Working Party shares the view that lifestyle and wellbeing information qualifies as health data if conclusions can be drawn about a person’s health, especially, where such data is collected and evaluated over time. For example, mere information about a person’s weight or blood pressure, as a rule, does not mean the data is health data. However, when being collected and evaluated over a period of time for the purpose of identifying over-/ underweight tendencies and health risks, body weight data is health data according to the Article 29 Working Party. Likewise, information on daily exercise activities, heart rate, food intake and blood pressure constitutes health data according to European data protection authorities, when it leads to conclusions on diseases and the disease risk level of the individual concerned. The same applies to information on smoking and drinking habits, as well as to daily tooth brushing routines.
Therefore, data is sensitive health data if
- inherent medical information is involved,
- non-medical data related to the physical or mental condition of a person is collected over a long period of time,
- non-medical data is processed or evaluated in a medical context or for medical purposes,
- non-medical data is combined with other data, indicating the health status of a person,
- conclusions about the health status of a person can be drawn from the collected data (regardless of whether the conclusion is true or not).
Both app developers and app providers should carefully examine and document which types of data are being collected by the specific mHealth device and for what purposes. Particular attention should be paid to the fact that many competent data protection authorities in Europe share the view that the mere possibility of identifying an individual is sufficient to trigger the application of mandatory data protection law requirements such as the requirement to obtain an explicit and fully informed consent from the device user. This is why providers of mHealth products should properly consider whether and to what extent data can be used to infer conclusions about a person’s physical and mental health, even if this opportunity is only a secondary purpose.
In the end, from a data protection compliance perspective, manufacturers and providers of mHealth devices and apps should obtain an adequate, comprehensive and explicit consent from individuals, in order to mitigate liability risks and to ensure compliance and conformity with applicable data protection laws. Our next blog post will elaborate on the indispensable elements that make up the consent that needs to be obtained from device users. We will also show the means by which and when consent can be obtained in practice.