deliverable - starr projectdeliverable d8.3 is the last deliverable in wp8. it builds on the...

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 689947.

Deliverable D8.3.Compliance with privacy rules – data

transmission

Workpackage WP 8

Lead beneficiary

FIZ Karlsruhe

Due date 30th September 2018

Submission date

01/10/2018

Type RE; PU

Author(s) Francesca Pichierri and Diana Dimitrova (FIZ Karlsruhe) Contributors: Sabrina Panëels (CEA); Leire Ortiz Fernandez (OSA)

Abstract This deliverable presents the compliance of the data transmitted within the STARR system with the current privacy rules.

Keywords Data protection; privacy; healthcare; stroke survivors; psychological analysis

Ref. Ares(2018)5014167 - 01/10/2018

| P a g e | 1 D 8 . 3 : C o m p l i a n c e w i t h p r i v a c y r u l e s – d a t a t r a n s m i s s i o n

Decision Support and self-management system for stroke survivors

History of changes

Rev. N Description Author(s) Date

1 First draft of TOC Francesca Pichierri and Diana Dimitrova

(FIZ)

28th August

2018

2 First draft of the document Francesca Pichierri and Diana Dimitrova

(FIZ); Sabrina Panëels (CEA)

18th

September

2018

3 First review Sabrina Panëels (CEA) 26th

September

2018

4 Second review Leire Ortiz Fernandez (OSA) 27th

September

2018

5 Final version Diana Dimitrova and Francesca Pichierri

(FIZ)

28th

September

2018



Table of contents Abstract ..................................................................................................................................................................... 3

1. Introduction ................................................................................................................................................. 4

2. The STARR pilot at OSA and the evaluations of platform elements at HOP – data controllers

definition and their responsibilities ................................................................................................................... 4

3. Psychological model and emotion analysis ............................................................................................. 10

4. e-Privacy ...................................................................................................................................................... 13

5. Progress on open points from D8.2 ............................................................................................................ 14

6. Conclusion ................................................................................................................................................... 17

Bibliography ....................................................................................................................................................... 18

Annex – updated DPIA ........................................................................................................................................... 0



Abstract

Deliverable D8.3 is the last deliverable in WP8. It builds on the previous deliverables (D8.1 and D8.2) and

seeks to provide an updated analysis of the STARR developments achieved during the past 12 months. Thus,

it discusses the topic of data controllers for the STARR pilots and general compliance of the latter with the

data protection requirements and it reports on the progress on the open points which were raised in D8.2.

Furthermore, D8.3 makes an analysis of the proposed psychological models and makes recommendations

for data protection compliance for the final stages of the project.

The present deliverable is to be read together with the upcoming deliverables on Data Management, since

both deliverables complement each other.



1. Introduction

The following deliverable is a follow-up to Deliverable 8.2 where the legal requirements were applied to the

version of the technical elements discussed or developed in STARR from M10 to M20. The present deliverable

aims to continue and deepen the legal analysis, applying it to the latest developments of the STARR

technology.

In particular, D8.3 aims to:

identify the data controllers and data processors and define the data protection obligations of the

partners during the STARR trials with real patients and their data (section 2)

provide a legal analysis of the envisaged STARR psychological model and emotional analysis (section

3)

report on the progress of ePrivacy (section 4)

report on the progress on the open points raised in D8.2 (section 5)

provide an update to the Data Protection Impact Assessment (DPIA). Since D8.2, new risks have been

identified which need to be discussed (document attached)

2. The STARR pilot at OSA and the evaluations of platform elements at HOP – data controllers definition and their responsibilities

In STARR it was decided to carry out 1) a pilot of the whole STARR system at OSA and their patients’ homes

and 2) complimentary testing of certain elements of the STARR technology at HOP. To be able to give

feedback on compliance of the pilot and tests with the GDPR, it is essential to have a good overview of the

data processing activities, i.e. which personally identifiable data is going to be processed by which partners,

for which purposes, how long and via what technologies. However, here a brief description is made for the

sake of defining the data controllers and clarifying their data protection responsibilities in STARR.

Pilot at OSA

The pilot with OSA’s patients is expected to start in November 2018 (pre-pilots) and February 2019 (actual

pilots), depending on how quickly patients are recruited.1 The pilot will be an evaluation of the STARR system

including the Inithealth application, mature technologies (e.g. wearable worn on the wrist, wearable worn

on the ankle) and commercial devices (e.g. scales, blood pressure monitors, glucometer) in stroke survivors´

homes.2

The categories of data that will be processed during the pilot at OSA are listed below:

1 Email from Leire Ortiz Fernandez, “Pilot”, 29.08.2018. 2 STARR D7.1, “Research Protocol”, 06.10.2017, (hereinafter “STARR D7.1”), pp. 32.



Personal identifiable data (name, gender, age, deprivation index, hand dominance, educational level,

type of job, hobbies and socio-familiar support, the two reference numbers for the stroke survivors:

one for STARR and the other for the hospital).

Sensitive data (ethnic group, health data see below).

Health data (medical history, blood pressure, lipidic profile, glycaemia, heart rate, diet, toxic habits,

disability, weight, depression, stress, pain, motor function, physical activity, canes and wheel chair

use, gait analysis, adherence to treatment).3

No psychological analysis with the algorithms developed within the framework of STARR will be performed

in Spain; instead a questionnaire about anxiety and depression will be provided to the patients. It has been

explained by OSA that the questionnaire is used just for screening, it is not diagnostic and it does not analyse

patient`s personality traits. Data about emotions, behaviour and skeleton movement will not be processed

during the OSA pilot.4

At OSA, information is taken from the patient, from patient physical examinations and from OSA health

records (blood test and stroke information only).5However, during the meeting in Novi Sad, Serbia, on 1st

June 2018, OSA has assured the other partners that the hospital health records as such will not be technically

connected to STARR and the pilot. Still, there will be an indication in the hospital health records that a certain

patient will take part in the STARR pilot. Thus, although no automated exchange of data between the STARR

application and the hospital records is planned to take place, it should be clearly specified as a matter of

priority which data is going to be processed only on the hospital records, which data only on the STARR app

and which data might be transferred from one to the other. Furthermore, the data on the health record is to

be stored at OSA for 30 years which is a requirement under Spanish law as explained by OSA. It needs to be

checked whether all the data from the pilot fall under this requirement. For example, the fact that a patient

will take part in the pilot does not seem to be necessary to be stored for 30 years. This should be verified by

the OSA regulatory team. Thus it seems that at OSA the purposes of the processing are twofold – research in

the framework of STARR and health care assuming that the data from the pilot are stored later as part of the

health record of the patient.

Tests at HOP

The evaluations of platform elements at HOP started on the 1st of June 2018 and, at the moment, they are

expected to end in June 2019. They consist of an evaluation of 1) the usability of the wearables developed in

STARR (wearables integrating accelerometers and pressure sensors and developed by CEA for motion

analysis), 2) the data transmission to a server, 3) the integrated version of the STARR system comprising the

DSS, the applications and the software developed by INIT and MDS, the wearables from CEA and the server

from BLU and 4) the usability of the serious games and the vision-based sensing.6 It is still under discussion

3 STARR D7.1, pp. 30-31; Email from Leire Ortiz Fernandez, “Questions on pilots”, 29.08.2018. 4 Email from Leire Ortiz Fernandez, “Questions on pilots”, 29.08.2018. 5 Ibid. 6 STARR D7.1, pp. 7-13.



whether the INIT software will be available at HOP for the visualization of the information concerning the

patients to patients and therapists.7

The categories of data that will be processed during the testing of the wearables and serious games at HOP

are the following:

Personal identifiable data (e.g. name, gender, age, hand dominance, socio-familiar support, two

reference numbers for the stroke survivors: one for STARR and the other for the hospital).

Sensitive data (health data see below).

Health data (medical history, blood pressure, lipidic profile, glycaemia, heart rate, diet, toxic habits,

disability, weight, depression, stress, pain, data coming from the clinical tests made by the therapist

to evaluate motor performances of the patient when equipped with the wearable and during the

serious game, physical activity, canes and wheel chair use, gait analysis, adherence to treatment,

data coming from the evaluation of patient autonomy and self-confidence, personal opinions of the

patients regarding the serious games collected via a usability questionnaire, description of the

patient motion via the use of Kinect – e.g. time spent pedalling, time spent with arm over 90° of

flexion-, data about the performance in a particular game such as the number of objects caught, the

hand used, skeleton movements, emotions or more precisely, at the moment, the time spent with

an emotion, and possibly other information needed and obtained from the psychological analysis).8

STARR partners are contemplating to test the psychological model at HOP. This has not been decided yet.

The model in itself is still being conceptually and technically under development. When a “prototype” version

is ready, its maturity will be assessed and thus the protocol in question devised. Therefore, the psychological

model remains still to be discussed and decided upon (see section 3).9

At HOP, information is taken from the patient file during the recruitment phase, allowing the therapist to

know for example the exact pathologies and other important medical data of the patient. Once the patient

is recruited, information is taken directly from him/her and during the physical examinations.10 As in OSA,

also in HOP the hospital health records as such will not be connected to STARR and the pilot. Still, there will

be an indication in the health records that a certain patient will take part in the STARR pilot.11 A copy of the

patient´s agreement to participate in the STARR pilot goes in the patient record. Same data protection

considerations made above concerning OSA are valid here.

Data controllers

As recommended in STARR D8.2, in the months preceding the pilots and tests, the STARR partners

determined which partner(s) are to become the controllers for the STARR system/pilot. As explained in D8.1,

the controller is the party which determines the means and purposes of the processing and bears

7 Email from Stephane Bouilland, “Questions on pilots”, 06.09.2018. 8 STARR D7.1, “Research Protocol”, 06.10.2017, pp. 30-31; email from Stephane Bouilland, “Questions on pilots”, 06.09.2018. 99 Email from Sabrina Panëels, “Questions on pilots”, 05.09.2018. 10 Email from Stephane Bouilland, “Questions on pilots”, 06.09.2018. 11 Email from Stephane Bouilland, “Agenda meeting in Novi Sad”, 22.05.2018.



responsibility for compliance with the GDPR. The other partners who do not take the role of a controller but

still process personally identifiable data would most likely become processors and work under the

instructions of the controller(s).

During the meeting in Novi Sad, Serbia (May/June 2018), it was discussed that only the two hospitals, HOP

and OSA, have access to the personally identifiable information of the participants in the respective

tests/trials of STARR. The STARR partners assured that no other partner is processing personally identifiable

information about the patients. Data will be anonymized before it reaches the Middleware. The Middleware

will receive only identification numbers (e.g. Patient 1, Patient 2, Patient 3) associated with the patient from

HOP and OSA and it will share them with the other partners such as Inithealth, Bluelinea,Ulux, ULund.12 The

key for the personal identification, allowing the connection of the reference numbers to the patients, will be

only in OSA and HOP.13

In order to “create” the patients on the platform and link the devices to them, OSA (and probably also HOP)14

will provide Inithealth with a list of first names or nicknames and counters (this list will be provided by hand

or by e-mail, but always out of the platform). Personal data such as the first name (not the complete name)

or nickname of the patient is needed for the chatbot. Only the name or nickname of a person with a simple

counter like "Patient 1" very rarely provides the possibility to identify the person to which the data belongs.

Furthermore, there could be more than one patient with the same nickname (e.g. Fernando, Patient 3 -

Fernando, Patient 12). Inithealth assured FIZ and the other partners that only with the first name or nickname

they cannot identify the patient.15 This personal data (name/nickname), as well as all the anonymised data

related to the STARR project, are saved in the Inithealth cloud and Inithealth´s hosting is in France. The

company is called OVH, a large company that provides hosting service. Inithealth has assured FIZ and the

other partners that the company is very reliable in terms of security measures and data protection.16

From the meeting in Novi Sad (May/June 2018), it also emerged that it was only the hospitals, HOP and OSA,

that determined the purposes of the technologies in STARR (in view of what is needed for the therapy of the

patients) and what they are supposed to measure, how and how often. The technical partners presented the

technical options to them but did not take the decisions as to what and how the data is to be processed. On

the basis of this information, it can therefore be concluded that only the hospitals are data controllers and

this information has to be clearly mentioned in the consent forms. The other partners should, of course,

ensure the security of the system in order to avoid incidents that could lead to hackings, etc. In this sense, a

priority for the following months should be the clear identification of the role of each partner in the data

processing as well as the delineation of the responsibilities for the STARR solution as a whole between the

technical partners. If any of the partners, apart from HOP and OSA, will begin to process personally

12 Email from David Guyard, “STARR: Middleware”, 13.09.2018. 13 For example, data collected during the serious game (each game generates its own data) is sent to BLU in an xml file via mail. Patient name does not appear, only the therapist at HOP has a file with the name of the patient corresponding to the identifier HOP uses; Email from Stephane Bouilland, “Questions on pilots”, 06.09.2018. 14 It is still under discussion whether the INIT´s application will be tested also in HOP. 15 Email from Javier Escobal, ”Questions“, 30.08.2018. 16 Email from Javier Escobal, ”Data transfer between Init and MedM“, 22.05.2018; Email from Javier Escobal, “Questions”, 30.08.2018.



identifiable information in the future, they will become either controllers or processors, depending on the

purposes for which they begin to process the data. The accurate delineation of responsibilities and data

processing activities could be described in a document ad hoc that can be attached to the last version of the

Data Management deliverable in 2019.

FIZ also recommends that the two hospitals need to verify their GDPR adapting laws, especially on article 89

GDPR. This is to check whether new data protection requirements are imposed to them via these national

provisions.

The legal basis for the processing will be consent. The partners have explained that the patients will be

presented with a privacy notice, which they can sign. The privacy notice will be drafted in the respective

languages by the hospitals. It is important that the language used for information is adapted to the

foreseeable addressees of the information.17 HOP and OSA have to carefully consider the wording in consent

forms and the means by which consent is achieved.18 Furthermore, it is important that the consent form

clearly indicates that participation is voluntary and the decision not to participate will not have any negative

consequences for the patient, especially as regards to his/her treatment. They should be informed that they

may, at any time, revoke their consent, again with no negative consequences for them.19 The criteria for

consent to be legally valid are described in detail in D8.1.

Further, the hospitals, HOP and OSA, have to ensure that complete information about the data processing is

provided to the participants, including that the data will be stored as required by law in the medical records

of the patients. The requirements on the information to be provided are established in Article 13 GDPR and

Article 14 GDPR, as the data will be collected directly from the participants and indirectly. For example, when

personal data relating to a participant is obtained from the participant, HOP and OSA shall provide the latter

with information such as (a) their identity and their contact details; (b) the contact details of the data

protection officer, where applicable; (c) the purposes of the processing for which the personal data are

intended as well as the legal basis for the processing; (d) the recipients or categories of recipients of the

personal data, if any; (f) where applicable, the fact that they intend to transfer personal data to a third

country. 20 Concerning this last point, a special mention should be made of the data transfer Inithealth –

MedM The latter is a company based in Russia, outside the EU, Inithealth contracted to process anonymized

indicators from the connected objects and wearables related to the STARR patients. Inithealth has assured

the STARR partners that the data transferred to MedM is completely anonymized when sent and received by

the Russian company.21 Therefore, it can be concluded that no identifiable data will be transferred to MedM.

Further, HOP and OSA shall also provide the participant with the following further information necessary to

ensure fair and transparent processing such as (a) the storage period, or if that is not possible, the criteria

17 European Union Agency for Fundamental Rights, Handbook on European Data Protection Law, 2014, pp. 56-60. 18 Hogan Lovells, Chronicle of data protection, The Final GDPR Text and What It Will Mean for Health Data, 20.01.2016. 19 Article 7 Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), O.J. L 119, 4.5.2016 (Hereinafter “GDPR”); see also Article 29 Working Party, Opinion 15/2011 on the notion of consent, WP 187, Brussels, 13.07.2011, p. 12. 20 Article 13 (1) GDPR. 21 Email from Javier Escobal, “Data transfer between Init and MedM”, 22.05.2018.



used to determine that period, e.g. if the data is going to be stored by the hospitals after the project for legal

reasons, (b) the existence of the rights to access, rectification, erasure or restriction of processing, data

portability or right to object to the processing and if there are any restrictions thereto, (c) the existence of

the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent

before its withdrawal; (d) the right to lodge a complaint with a supervisory authority; (e) whether the

provision of the data is a statutory or contractual requirement, whether it is compulsory and what the

consequences of failure to provide the data are and (f) the existence of automated decision-making, including

profiling, and meaningful information on the logic involved for the automated decisions, as well as the

possible consequences of such processing for the data subjects.22 Concerning this last point, FIZ understands

that no automated decision-making will be performed in the framework of STARR. For example, the

psychological tests will not represent automated decision-making which cannot be reversed by a human

being.

If HOP and OSA intend to further process the personal data for a purpose other than that for which the

personal data were collected, they shall provide the participant prior to that further processing with

information on that other purpose and with any relevant further information as referred to in Article 13 (2)

GDPR.23

When personal data have not been obtained directly from the participant, Article 14 GDPR requires that the

controller shall provide in principle the same information as under Article 13 GDPR and in addition inform

the data subject of the categories of personal data to be processed and the source from which the data have

been obtained.24 The information shall be provided to the data subject at latest within one month after the

collection. If the data are used for communication with the data subject, then the controller should provide

the information at latest at the time of the first communication with the data subject. If the data are to be

disclosed to another recipient, then the controller should inform the data subject at latest when the data are

disclosed to third parties.25

Similar to Directive 95/46/EC, there are exceptions to the obligation to provide this information. The one that

could possibly apply to STARR is the exception for research purposes, whereby if the provision of information

proves to be disproportionately difficult or impossible and would seriously impair the objectives of the

research, for example. Nevertheless, the safeguards provided for in Article 89 (1) GDPR have to be respected

and the controller should take the appropriate measures to protect the data subject’s rights and legitimate

interests.26

All the obligations HOP and OSA, as controllers, have towards the participants, are described in detail in D8.1.

Therefore, we invite the partners to consult the deliverable for better guidance.

22 Article 13 (2) GDPR. 23 Article 13 (3) GDPR. 24 Article 14 (1) (d) and 14 (2) (f) GDPR. 25 Article 14 (3) GDPR. 26 Article 14 (5) (b) GDPR.



3. Psychological model and emotion analysis

The stated purpose of the psychological models in STARR, as developed by the STARR partners and which

might be tested, but then only in HOP, is to assess the state of mind of the patient for behavioural change,

e.g. to perform more physical exercise, and to test whether the system could identify the barriers to change

and automatically send the right motivational messages to the patients related to the identified issues. The

main idea is to ask the stroke survivor to fill out some questionnaires, some standard and some adapted by

CEA, and together with the monitoring of the physical activity have it analysed by an algorithm developed by

RT-RK based on the COMBI model. It is this algorithm which will assess the state of change the stroke survivor

is in, and if the survivor is not in an action stage, or fell back from an action or maintenance stage to a non-

active one (i.e. contemplation or preparation), or the activity goals are not satisfied, then it will investigate

the bottlenecks and send the feedback accordingly. This investigation takes the form of a couple questions

extracted from the questionnaires on the topics related to the bottlenecks. This investigation will occur when

there are no change in the state the survivor is in and/or if the goals aren’t achieved at all, at a frequency

that remains to be determined, possibly once a week. It is planned to perform such a psychological testing

regularly, at periods to be determined later, possibly depending on the behaviour of the individual patients.

At the time of writing the deliverable the questions and the algorithms are still under development and only

a first version has been provided so far. It can already be noted from a legal point of view that such analysis

intrudes into the private sphere of the patients as it seeks to assess psychological features about them, i.e.

the right to privacy (Art. 7 CFREU and Art 8 ECHR) are at stake. On the other hand, according to the GDPR,

data concerning health refers to “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.”27

Depending on how the psychological analysis in STARR is finally designed, it is likely that the tests fall within

this definition since the data is used in the context of healthcare. In that case such processing is forbidden

unless one of the legitimising grounds applies, e.g. explicit consent, unless Union or Member State law forbids

consent as a legal ground.28

Due to the risks for the patients of such an automated processing - assessing the motivational level of the

patient through emotional and mood analysis and formulating the right message to him – STARR has decided

to restrict testing it. Eventually, a test might be performed in a controlled environment only during the HOP

tests. This means that in the presence of a medical staff member of HOP the patient would fill out the

questionnaire prepared by CEA and HOP. If these tests indeed take place at HOP, FIZ strongly recommends

that the participating patients be informed in advance about these tests, the purposes of the latter and the

logic involved in the algorithm. The patients should be given the chance to decide not to participate in this

part of the testing or withdraw their consent for the further participation in these tests and no disadvantages

should ensue for them.

An important point is the purpose of carrying out such a profiling. Whereas in STARR the stated purpose is

to test the accuracy and feasibility of such models for examining the motivational level of the patients, this

27 Art. 4 (15) GDPR. 28 Art. 9 (1) and (2) (a) GDPR.



is different from the purposes of such psychological analytics in operational environments. In STARR the

partners have been warned about the risks related to the re-usage of the profiles for other purposes, e.g. for

advertising/insurance purposes or to manipulate the behaviour and mood of the patients in other ways. The

partners have committed to not processing the data for any other purposes. FIZ recommends that further

usage of the data is prevented by deleting the data at the end of the project. This could be further discussed

in the next iteration of the Data Management Plan.

Additional psychological insights might be gained via the questionnaires performed at OSA, which are

different from the psychological model. The purpose of the OSA questionnaires is to assess depression. It

should be borne in mind that a combination of both psychological assessments could result in quite rich

psychological profiles and safeguards should be put in place to avoid abuse of such information.

Thus, it is recommended to always perform a detailed Data Protection Impact Assessment (DPIA) pursuant

to Article 35 GDPR before launching such technologies.

General comments on psychological profiling and privacy implications

In the past months a lot of attention has been given to psychometrics – which combines psychology and

computational science.29 It became especially popular because of the Cambridge Analytica/Facebook

scandal. Numerous articles were written about the possibility to manipulate unconsciously the voting

behaviour of large numbers of the population through psychological analysis and targeting the right

messages according to the psychological traits of the individuals.

Psychological profiling and psychometrics pose many problems from a privacy and data protection

perspective. Looking especially at STARR-like scenarios, the general risks could be expressed as follows:

Such automated behaviour, emotion and psychological state assessment over time could lead to a

detailed tracking of the person and in-depth psychological assessment which is easily scalable and

easy to interpret. It is also opens the door to emotional and psychological manipulation and abuse,

especially if it is used for other purposes, e.g. to assess and influence the patient’s willingness to buy

more medical products.30

Another big problem with scalability of emotions is that they create a data double of a person which

might not accurately represent them. Thus, people are not treated any more the way they are and

their real problems are not addressed if attention is paid only to the numbers which the profiling

reveals. In such a scenario there could be a wrong belief that numbers are able to speak for

themselves and they might reinforce prejudices and beliefs about a patient instead of accurately

establishing the issues with their motivation in standard ways.31 This might have a negative effect on

the therapy of the person as a whole. There is also danger that the psychological and emotional

29 Luke Stark, “Algorithmic psychometrics and the scalable subject,” Social Studies of Science 2018, Vol 48 (2), 204-231, p. 206. 30 Ibid, pp. 205-206. 31 Ibid, pp. 207 and 212.



models may shape individuals unaware of these models and thus incorrectly interpret their

behaviour and adopt the wrong method when approaching these patients and their motivation.32

Further, there might be a belief that the volume and variety of data in itself guarantees completeness

and explains correlations. It might lead to a situation where causal questions are not asked and

subjective judgments based on the individual situation of a patient are not made.33

Sometimes the questionnaires might contain questions which are not necessary for the purposes of

motivating the patient. In this case they might pursue other purposes and thus extract much more

detailed psychological information and manipulate the behaviour of the patients unnecessarily.

Therefore, STARR-like profiling should be restricted to questions testing the motivation for

rehabilitation and other types of questions should not be “sneaked in.” A first version of the

questions was circulated at the beginning of September 2018. From the proposed list of questions it

appears that they are very broad and could allow for a quite detailed profiling. Therefore, they could

be considered to be very intrusive.

The psychological evaluation could lead to an evaluation of the motivation which could be badly used

by insurance companies, for example, refusing to pay some care because the survivor makes no

effort.

It is important to bear in mind these risks and contemplate their introduction in real-life even if the feasibility

and usability tests are successful.

Whereas for STARR many of these risks are mitigated by the fact that the tests will be performed in a

controlled environment, the purpose will be strictly defined to assessing the motivational level and the

patient will be aware of the profiling, the risks remain for real-life applications of such models. In addition,

such (partially) automated assessment is meant to be complementary to the therapist and it does not aim at

replacing face-to-face conversations among patients and therapists, but rather helping their

care/support/assessments by providing more day-to-day data. Therefore, the usage of this model should not

be lead to reduction of the face to face relationships among doctors and patients. The concerns above apply

also to the emotional analysis, which was discussed in detail in D8.2. It should not be forgotten that having

the automated psychological analysis, the depression analysis by OSA and the emotions analysis pose a

serious risk, especially if the results of these are combined which would allow rich information about the

emotional and psychological situation of the patients in extracted.

The emotional analysis by ULUX

D8.2 made a thorough and in-depth analysis of the emotional analysis technology as developed by ULUX,

more precisely on the risks in terms of privacy and data protection for the patients. These have to be taken

32 Ibid, p. 213. 33 Ibid, p. 210.



into account when such technologies are made operational and a thorough Data Protection Impact

Assessment (DPIA) pursuant to Article 35 GDPR has to always be carried out in advance to inform the decision

whether such technologies should be operated or not.

A further note related specifically to STARR is the integration of a consent option, i.e. an opt-in, for

participating in the emotional analysis into the technology. This was demonstrated by ULUX to the FIZ team

via a video conference. Thus, the patient will have the chance to opt-in for the emotion recognition and has

a real chance of expressing his willingness to participate. This is a good example of designing consent

features.

4. e-Privacy

In the previous deliverables D8.1 and D8.2, it was mentioned that the current e-Privacy Directive, which - as

argued in D8.1. - is applicable to STARR, is currently being revised. It is expected to be replaced by an e-

Privacy Regulation, the proposal for which was tabled at the beginning of 2017 and work on it is still ongoing.

At the moment of writing the present deliverabe, the European Parliament has already adopted its position.

However, the Council has not adopted its position yet and its position is not known. Thus, it will take some

time before the European Parliament and the Council start negotiating the future e-Privacy Regulation, i.e.

before the trialogues commence. In the literature, the comments made to the ongoing debates refer to the

strengthening of the data protection requirements in the proposed amendments made by the European

Parliament, which would lead also to more obligations by those offering electronic communication services.

However, the current discussions in the Council reveal the efforts of the latter to weaken the privacy

features.34

Thus, it is unlikely that the proposed e-Privacy Regulation will be adopted within the life-time of STARR.

Bearing in mind the reported divergencies between the European Parliament and the Council, it cannot be

predicted what the final text will look like. Therefore, no concrete guidance on how the STARR technology

and like technologies should be designed in order to comply with the future e-Privacy Regulation could be

made. However, the STARR partners and other technology developers developing electronic communication

technologies should take into account the requirements of the future e-Privacy Regulation as part of the legal

requirements applicable to electronic communication technologies.

A list of the possible provisions and obligations on developers and operators of electronic communication

services which might make it into the final version of the law and which could be of particular interest to the

STARR partners could be:

The privacy by design and by default features which should allow users to prevent tracking by third

parties, e.g. through add blockers;

Not putting tracking/cookie walls;

Strengthened security and confidentiality measures, e.g. end-to-end encryption;

34 IT-Pol, “EU Council considers undermining e-Privacy,” EDRi, 25.07.2018, https://edri.org/tag/eprivacy-regulation/.



Tighter requiements on consent;

Protection of metadata and content;

The usage of the traffic and location data;

Limitations on web analytics.35

The above-quoted literature refers also to the proposed higher fines than in the existing regime, i.e. up to

4% of the global turnover or 20 000 000 Euros. Thus, technology providers should make sure they fully comply

with the provisions of the future e-Privacy Regulation.

5. Progress on open points from D8.2

In the last deliverable, D8.2, several open points remained. The purpose of this section is to report on the

progress on these points:

a. Describe the technical and security measures of the whole STARR solution. STARR should define

the partners who may have access to the data on the Middleware. As explained in the Section 2 on

data controllers, only HOP and OSA will have access to personally identifiable data. The other

partners have assured FIZ that they process only anonymized data. Still, everyone should comply

with the data security requirements. To ensure the developing by the STARR partners of adequate

technical and security measures in order to protect stroke survivors´ personal data from e.g.

unjustified access by third parties, a special section in the next version of the Data Management plan

should include a description by the tech partners of their security and technical measures.

b. Determine the server location. It has been decided that the server will be on EU territory, i.e. in

France. It still needs to be clearly stated which STARR partner(s) will be responsible for it. In the case

of possible cloud computing, the further data security features should be discussed and

implemented. However, from a privacy perspective it is recommended to avoid cloud storage.

c. The third recommendation concerned defining the controller(s) for the pilots. This issue has been

taken care of as explained in Section 2 of the present deliverable.

35 Diego Naranjo, “Civil society calls for protection of communications confidentiality,” EDRi, 13.06.2018, https://edri.org/tag/eprivacy-regulation/; Dma, “ePrivacy Regulation: what will it change?”, 17.07.2018, https://dma.org.uk/article/eprivacy-regulation-what-will-it-change?; European Data Protection Supervisor 2017/6, “EDPS Opinion on the Proposal for a Regulation on Privacy and Electronic Communications (ePrivacy Regulation)”, (Opinion 6/2017), 24.04.2017; Article 29 Working Party, “Opinion 01/2017 on the Proposed Regulation for the ePrivacy Regulation (2002/58/EC)”, 04.04.2017; La Quadrature du Net, “End of the privacy debate in the European Parliament: overview”, 21.12.2017, https://www.laquadrature.net/en/eprivacy_overview_ep; Technology´s legal edge, “ePrivacy draft regulation approved by the European Parliament”, 31.10.2017, https://www.technologyslegaledge.com/2017/10/eprivacy-draft-regulation-approved-by-the-european-parliament/.



d. Determine the list of data needed for the purposes of STARR. This list has been partially provided

for in the Research Protocol, D7.1. This list needs to be better detailed and it is expected to elaborate

it upon in the next iteration of the Data Management Plan.

e. Ensure that STARR avoids the abusive usage of emotion data and the psychological model as

discussed above. This is a continuous requirement and it will always exist as long as the technology

will be used.

f. Determine the access rights to the patient data. STARR should define the data processing roles of

the different partners/entities. The crucial question is who may manually consult, enter, modify, and

erase the data. If someone else but the data subject modifies the data of the stroke survivor, would

the latter be informed of it and be able to react? A related question is who would be authorized to

access the data for consultation purposes and whether they can view only part of the data or all of

it.

g. Determine the possible interaction between the STARR application and the patient health records.

OSA and HOP has ensured the STARR partners and FIZ that no such integration will take place in

STARR.

h. Decide whether there will be location tracking of patients. It is understood that no location tracking

will be performed in STARR, meaning that the movements of the patients will not be tracked such as

the patient went to a certain shop, and then to church, and then to a certain park, etc. However, data

about the weather might be processed on the basis of the location of the device, e.g. whether it is

sunny enough to encourage the patients to go out. In this way one could derive information where

the person at present is. Whereas the processing of the location data of the device may take place

only on the basis of consent of the data subject (see Directive 2002/58), one should take into account

that information about the location should not be misused and profiles based on location should not

be created.

i. The question of the processing of STARR data after the end of the project was raised during the

review meeting on 19.09.2017 in Brussels. This concerns the potential storage of personal and/or

only anonymized statistical data of the STARR pilot participants by the STARR partners and its

possible processing for new (research) purposes within the companies of the participant

organizations (and/or by non-partner organizations which obtain the data for free or against

remuneration). This is a very important data protection topic. It has been agreed this will be discussed

in the next iteration of the Data Management plan.

j. An important issue is the processing of personal data in operational situations, more precisely the

processing of this data not only for rehabilitation purposes but also for insurance purposes. The

producers of hardware and software technologies which support STARR-like mobile health solutions

may be incentivized to forward the information collected via the STARR components to the insurance

company of the patient. Since the data collected via these technologies displays a very rich and



sensitive profile of the patient, i.e. information about their daily habits such as daily exercise,

medication intake, performance and progress, level of motivation to follow the therapy and

emotional state of mind, the insurance companies might use this data to prejudice and discriminate

against certain patients. For example, those who do not show good enough progress or are not

motivated might have to pay higher insurance fees. In such a scenario also the purposes of STARR

might shift from being a tool for recovery, support and motivation, to a tool which actually

“punishes” them for not adhering to the therapy. A related issue is the lack of transparency of such

a re-processing towards the data subject.

A careful analysis of such repurposing against the GDPR reveals also the legal problems related to

the processing of such data, e.g. for insurance purposes. Article 5 (1) (b) GDPR forbids in principle the

processing of certain data for new purposes which are incompatible with the original one (s), unless

the new purposes are historical and scientific research, archiving and statistical purposes. The

processing of data by insurance companies cannot be classified as being compatible with the original

purposes of STARR and it does not seem to fall within the definition of processing for statistical

purposes, historical and scientific research, or archiving in the public interest.

On the other hand, Article 6 (4) GDPR allows for the processing of personal data for new purposes,

but under strict conditions, i.e. (1) either based on the consent of the data subject, or (2) based on

Union or Member State law, or if (1) and (2) do not apply, then for the new processing to be legal, it

has to pass a compatibility test (3). This test takes into account:

The link between the original and new purposes. The new purpose, i.e. processing for

insurance purposes, is not close to the original purpose of tele healthcare and motivational

support. Thus, a patient cannot expect the processing for the new purpose, as explained

above.

The context of data collection, in particular the relationship between the data subject and

the controller. In principle, patients are per se in weaker positions as compared to medical

personnel, technology developers and insurance companies. This means that the nature of

the data processing might not always be voluntary and transparent. Here it would be crucial

to determine who the controller(s) of the technology would be. Especially in a scenario

where the doctors would be considered to be the controller, the processing by insurance

companies for their own purpose – e.g. profiling and/or determining the price of insurance

per patient – would entail the processing of the data by another controller. In this way the

original controller, e.g. the hospital, would be transferring data to the insurance companies,

and it is this processing which might not pass the test of Article 6 (4) GDPR. In addition, the

new controller, i.e. insurance companies would need to satisfy the requirements of the

GDPR, one of which is having a legitimate purpose for the processing. It is questionable

whether the processing for purposes of price discrimination satisfies the requirements of a

legitimate purpose.

The nature of the personal data, especially where sensitive data such as health data is being

processed. This is the case in STARR since the data which are processed are health data which

are processed for health purposes.



The possible consequences of the new processing for the data subject. As explained above,

the consequences could be significant since some patients might end up either paying more

for their insurance or having fewer procedures covered by the insurance. In both cases this

might affect their therapy and access to health services.

The existence of safeguards such as encryption or pseudonymisation. This would have to be

assessed on a case-by-case base. However, even with appropriate technical security

safeguards, the risks for the data subjects with regards to their health insurance remain.

Regarding consent, as explained in previous deliverables, it is questionable whether in STARR-like

solutions consent is a viable legal basis due to the vulnerable position of the data subject and their

possible cognitive impairments. Thus, the processing of the data for health insurance purposes might be

incompatible with the GDPR and poses significant risks for the data subject.

6. Conclusion

The present deliverable went in detail to examine the remaining data protection issues related to the

upcoming pilots in STARR. Thus, it reported on the work done in relation to defining the controllers of the

pilots at OSA and HOP. To be able to define the controllers, an analysis of the data flows between the partners

and their responsibilities in terms of data processing and data protection were discussed.

In addition, in the past year work has been done by the technical partners on the integration of psychological

models. Since such models present quite specific data protection and privacy risks, a thorough analysis of the

proposed psychological models was made. Concrete recommendations to the partners were proposed.

Last but not least, in the previous deliverable D8.2 several open points were identified. The present

deliverable reported on the progress made to solve these open points. Still, new open points were identified.

Although this is the last deliverable for WP8, FIZ will contribute to the solution of the open points and the

progress could be reported in the final iteration of the data management plan.



Bibliography

Legislation

Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection

of natural persons with regard to the processing of personal data and on the free movement of such data,

and repealing Directive 95/46/EC (General Data Protection Regulation), O.J. L 119, 4.5.2016.

Opinions, reports, handbooks, etc.

Article 29 Working Party, “Opinion 01/2017 on the Proposed Regulation for the ePrivacy Regulation

(2002/58/EC)”, 04.04.2017.

Article 29 Working Party, Opinion 15/2011 on the notion of consent, WP 187, Brussels, 13.07.2011.

Diego Naranjo, “Civil society calls for protection of communications confidentiality,” EDRi, 13.06.2018,

https://edri.org/tag/eprivacy-regulation/.

Dma, “ePrivacy Regulation: what will it change?”, 17.07.2018, https://dma.org.uk/article/eprivacy-regulation-

what-will-it-change?.

European Data Protection Supervisor 2017/6, “EDPS Opinion on the Proposal for a Regulation on Privacy and

Electronic Communications (ePrivacy Regulation)”, (Opinion 6/2017), 24.04.2017.

European Union Agency for Fundamental Rights, Handbook on European Data Protection Law, 2014.

Hogan Lovells, Chronicle of data protection, The Final GDPR Text and What It Will Mean for Health Data,

20.01.2016.

IT-Pol, “EU Council considers undermining e-Privacy,” EDRi, 25.07.2018, https://edri.org/tag/eprivacy-regulation/.

La Quadrature du Net, “End of the privacy debate in the European Parliament: overview”, 21.12.2017,

https://www.laquadrature.net/en/eprivacy_overview_ep.

Technology´s legal edge, “ePrivacy draft regulation approved by the European Parliament”, 31.10.2017,

https://www.technologyslegaledge.com/2017/10/eprivacy-draft-regulation-approved-by-the-european-

parliament/.

STARR documents

Email from Stephane Bouilland, “Agenda meeting in Novi Sad”, 22.05.2018.

Email from Leire Ortiz Fernandez, “Pilot”, 29.08.2018.

Email from Leire Ortiz Fernandez, “Questions on pilots”, 29.08.2018.



Email from Javier Escobal, ”Questions“, 30.08.2018. Email from Javier Escobal, ”Data transfer between Init and MedM“, 22.05.2018.

Email from Stephane Bouilland, “Questions on pilots”, 05.09.2018.

Email from Sabrina Panëels, “Questions on pilots”, 06.09.2018.

Email from Stephane Bouilland, “Questions on pilots”, 06.09.2018.

Email from David Guyard, “STARR: Middleware”, 13.09.2018.

STARR D7.1, “Research Protocol”, 06.10.2017, (hereinafter “STARR D7.1”).

Article

Luke Stark, “Algorithmic psychometrics and the scalable subject,” Social Studies of Science 2018, Vol 48 (2), 204-

231.


Annex – updated DPIA

Nr Risk Risk Description Probablity (Low, Medium,

High) TBD

Impact on stroke survivor Proposed mitigation measure – To be completed by technical

partners

Implemented (Y/N)

1 Data security breach

E.g. data loss, hacking, interception, etc.

Low Cannot control one’s own data, possible abuse

depending on who gains access to it

Employ security measures to protect web applications.

Encrypt all communication. Middleware provided by

Bluelinea is hosted on a secure data centre located in France.

Middleware (including DSS) software runs on machines

dedicated to the STARR project and data storage is dedicated to

the project only. Data access is regulated and

limited to only authorized personnel.

Y

2 Illegal access E.g. through cloud computing access from all over the world, cannot be controlled, e.g. by security

agencies

Low Cannot control one’s own data, possible abuse

depending on who gains access to it

E.g. local storage of data/no cloud computing, encryption,

strict authentication mechanism.

DSS does not store any patient-related data. Communication between DSS server and the

MW server is encrypted.

Y



Data access is regulated and limited to only authorized

personnel.

3 Inaccurate processing

Wrong blood pressure measurement and

communication to the doctor

Low Wrong diagnosis and treatment

Bad measurement: medical devices will be selected for the

trial. Processing error: DSS behaviour is validated against known test

sets.

Y

4 Permanent tracking in/and

or outside: Possible as concerns ULund’s

Pokemon Go-like game

Application collects someone’s location all the

time

High STARR obtains further information on someone’s lifestyle and location, can

be part of big data and conclusions can be made against this person, e.g. profiling for purposes of

direct marketing

ULund: Anonymous handling of location data, local storage

(ULUND does not make this kind of data available)

To be implement

ed when game

developed

5 Excessive data collected

e.g. data not necessary for the therapy or diagnosis

Medium Obtain more information on stroke survivor, carry

out data mining and profiling

Determine data collection and data deletion policies in STARR.

Each type of data collected should be justified against

usage made.

Ongoing

6 Re-purposing Use for marketing purposes and health

insurance determination, loss of control over use of

data

High Manipulation of the choices of stroke survivors

to their detriment. Discriminatory practices

Stick to purpose limitation principle.

Data will be separated completely isolated from that of other Bluelinea customers and

not accessible to persons outside of the project.

Measures are needed to prevent project participants

from re-purposing the usage of the data.

Ongoing



7 Illegal storage Data stored for longer than necessary, allows re-

purposing of data usage and illegal access

Medium See above Stick to STARR recommendations on data

storage. DSS does not store any patient-

related data. Data will be destroyed after the project’s end or only subset of anonymised data will be kept

along with reports/articles (TBD in data management plan).

Y (DSS)

8 Lack of legal basis

Data processed without legal basis, e.g. no consent

provided when no other legal basis exists

Low Illegal processing – this can also occur if the consent is not valid, i.e. a data subject

does not have a real and informed choice

Ask for consent which is specific, informed and explicit

Ongoing

9 Lack of transparency

Data subjects not given the necessary information

before and during the data processing or given false

information

Medium Data subjects cannot take informed decisions and exercise their rights or

exercise control over their data

Provide proper information notice

Ongoing

10 Lack of accountability

No proper data processing documentation and

documentation on DP compliance maintained

Medium Controller cannot monitor the data processing operations and their

compliance with the DP framework, no policies in place for DP subjects to

exercise their rights

Proper documentation policies to be put in place.

Ongoing

11 Breach of data subjects’ rights

No policies to allow data subjects to exercise their rights or not complying

with them

Low Data subjects cannot request information on the

data processed on them, cannot have it rectified,

erased or blocked or cannot object to the

processing

Comply with the recommendations on how to

allow data subjects to exercise their rights.

Personal data should be accessible and can be modified



either from user interface or on request.

Algorithms applied on collected data should be accessible to

user within the project.

12 Re-identification of patients in

DSS

Data is not anonymous any more, which means that

personal data is transferred to Serbia in breach of EU

data protection laws

Low Higher privacy risks when personal data is transferred

outside the EU

Data is anonymised and depersonalised. Communication between DSS server and the MW server is encrypted. All content stored in the same dedicated location and servers in France.

Y

13 Misevaluation of the

motivation for behaviour

change and current state

(psychological model)

E.g. the answers from the questionnaire and the

results from the algorithm do not reflect the real state of the stroke survivor and

consequently ill-adapted or irrelevant information

would be provided

Medium It could affect the information, care and course of treatment

provided by the STARR solution based on

erroneous or not accurate information

Several tests will be conducted before the integration into the application. Tests are done to evaluate the accuracy of the calculations in order to ensure the models implementation is robust

It will be implemented in the

next months

14 Misuse of the psychological

profile

E.g. by insurance companies or in relation to

treatment rights

High Patients lack of motivation could be used against them

to limit care/increase insurance costs

Psychological data should not be shared with third parties unless explicitly asked by users. As for therapists, only relevant data to adapt treatment and non-prejudicial data could be shared.

It will be implemented in the

next months

deliverable - starr projectdeliverable d8.3 is the last deliverable in wp8. it builds on the...

Documents