REBECCA – D1.3: Legal, ethical and operational framework
Abstract
The aim of this deliverable D1.3 (“Legal, ethical and operational framework” report) is to provide an overview of the European and national frameworks for handling legal and ethical issues in Horizon 2020 research and innovation projects, and in REBECCA in particular. It describes the legal and ethical restraints as well as operational and patient requirements, that should be addressed by the partners when designing REBECCA, so as to ensure the project’s compliance with the applicable laws and regulations.
Full text
This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 965231. Horizon 2020 EUROPEAN COMMISSION Directorate-General for Research and Innovation People, Combating Diseases D1.3 – Legal, ethical and operational framework Project Acronym: REBECCA Grant Agreement No: 965231 Project Full Title: Research on breast cancer induced chronic conditions supported by causal analysis of multi-source data Starting Date: 1/4/2021 Duration in Months: 48
H2020SC1-DTH-12-2020 D1.3 2|79 Deliverable version 1.0 Date 31 March 2022 Nature of deliverable Report Dissemination level Public Work Package WP 1 – User requirements and co-creation Lead Beneficiary Timelex Author(s) / Contributor(s) Jos Dumortier (Timelex), Magdalena Gad-Nowak (Timelex) Status Submitted
H2020SC1-DTH-12-2020 D1.3 3|79 Document History Version Issue Date Status Content and Changes 0.1 11 March 2022 Draft Complete draft for peer review 0.2 22 March 2022 Draft Updated according to peer review comments 0.3 25 March 2022 Draft Updated according to peer review comments 1.0 31 March 2022 Submitted Final version
H2020SC1-DTH-12-2020 D1.3 4|79 Peer Review History Version Peer Review Date Reviewed By 0.1 21 March 2022 Kjersti Tjensvoll, Ioannis Sarafis, Vasileios Papapanagiotou
H2020SC1-DTH-12-2020 D1.3 5|79 Table of Contents Document History .................................................................................................................... 3 Peer Review History ................................................................................................................. 4 Table of Contents ..................................................................................................................... 5 Abbreviations and Acronyms ............................................................................................... 7 Disclaimer .................................................................................................................................... 8 Executive Summary .................................................................................................................. 9 1 Introduction ..................................................................................................................... 10 1.1 Purpose ......................................................................................................................................................... 10 1.2 Methodology .............................................................................................................................................. 10 1.3 Structure ....................................................................................................................................................... 10 1.4 Targeted Audience ................................................................................................................................... 11 1.5 Interactions ................................................................................................................................................. 11 2 About REBECCA ............................................................................................................. 12 3 Legal framework ............................................................................................................ 14 3.1 Data protection ......................................................................................................................................... 14 3.1.1 Data collected by REBECCA ............................................................................................................. 14 3.1.2 Actors and responsibilities ............................................................................................................... 14 3.1.3 Concept of a controller, joint controller and processor ....................................................... 21 3.1.4 Identification of data flows within REBECCA ............................................................................ 24 3.1.5 Key principles of data protection .................................................................................................. 25 3.1.6 Legal basis for data processing...................................................................................................... 30 3.1.7 Definition and implementation of organizational and technical measures ................. 34 3.1.8 Information notice .............................................................................................................................. 36 3.1.9 Data subject’s rights ........................................................................................................................... 38 3.1.10 Profiling ................................................................................................................................................... 42 3.1.11 Records of data processing operations ...................................................................................... 45 3.1.12 Data breach handling and notification procedures ............................................................... 46 3.1.13 DPIA .......................................................................................................................................................... 46 3.1.14 Data transfers outside the EEA ....................................................................................................... 47 3.1.15 Appointment of a Data Protection Officer ................................................................................ 47 3.1.16 Appointment of Ethics and Data Protection Team ................................................................ 47 3.2 ePrivacy ......................................................................................................................................................... 48 3.2.1 Principles of the ePrivacy Directive .............................................................................................. 48 3.2.2 Applicability of ePrivacy principles to REBECCA ..................................................................... 49 3.2.3 Cookies and other online tracking technologies .................................................................... 50 3.2.4 Use of location data by REBECCA ................................................................................................. 51 3.3 REBECCA solution and the Medical Devices Regulation ........................................................... 52 3.3.1 Definition of a “medical device” .................................................................................................... 52
H2020SC1-DTH-12-2020 D1.3 6|79 3.3.2 Requirements of clinical investigations under the Medical Devices Regulation ........ 53 3.3.3 Article 82 of the Medical Devices Regulation .......................................................................... 54 3.3.4 Informed consent ................................................................................................................................ 55 3.3.5 Implementation in the context of REBECCA ............................................................................. 56 3.4 Cybersecurity concerns .......................................................................................................................... 57 3.4.1 NIS Directive .......................................................................................................................................... 57 3.4.2 National cybersecurity systems of Spain, Sweden, and Norway ...................................... 59 3.5 Intellectual property rights to background and results of the REBECCA project ........... 60 3.6 Impact of recently proposed EU Acts ............................................................................................... 60 3.6.1 Data Governance Act ......................................................................................................................... 60 3.6.2 European Data Act .............................................................................................................................. 62 3.6.3 Artificial Intelligence (AI) Act ........................................................................................................... 64 4 Ethical framework .......................................................................................................... 67 4.1 Ethics in research ...................................................................................................................................... 67 4.2 Ethics in Horizon 2020 projects .......................................................................................................... 67 4.3 Ethics in REBECCA..................................................................................................................................... 68 4.3.1 REBECCA participants’ rights .......................................................................................................... 68 4.3.2 Research Ethics Committees’ approvals ..................................................................................... 69 4.4 AI and causal modelling ......................................................................................................................... 69 4.4.1 Ethics requirements for Trustworthy AI ...................................................................................... 69 4.4.2 Data-driven discrimination and data bias ................................................................................. 72 5 Operational and patient restrictions and requirements .................................. 74 5.1 Operational restrictions and requirements .................................................................................... 74 5.1.1 Data access by technical partners ................................................................................................. 74 5.1.2 Data storing and processing requirements ............................................................................... 75 5.2 Patient restrictions and requirements .............................................................................................. 76 5.3 Case Report Form (CRF) data ............................................................................................................... 76 6 Conclusion ....................................................................................................................... 79
H2020SC1-DTH-12-2020 D1.3 7|79 Abbreviations and Acronyms AI artificial intelligence AI Act Artificial Intelligence Act API application programming interface BCP Breast Cancer Patients cApp companion application CCC complex chronic conditions CISP Cloud Infrastructure Service Provider CRF case report format DGA Data Governance Act EDPB European Data Protection Board EHR electronic health records GDPR General Data Protection Regulation GPU graphics processing unit MDR Medical Devices Regulation pApp patient application PBCB Prospective Breast Cancer Biobank RCT randomized clinical trials RWD Real World Data SQRBC Swedish Quality Registry for Breast Cancer UI user interface
H2020SC1-DTH-12-2020 D1.3 8|79 Disclaimer “The information, documentation and figures available in this deliverable are written by the consortium partners under the European Union’s Horizon 2020 research and innovation programme “Research on BrEast Cancer induced chronic conditions supported by Causal Analysis of multi-source data” aka REBECCA (under the grant agreement no 965231) and do not necessarily reflect the views expressed by the European Commission. While the information contained in the document is believed to be accurate, it is provided “as is” and the authors or any other participant in the REBECCA consortium give no guarantee or make no warranty of any kind that the information is for any particular purpose. The reader uses the information at his/her sole risk and liability.”
H2020SC1-DTH-12-2020 D1.3 9|79 Executive Summary Using real-world data in clinical research aiming to improve the quality of life and clinical management of cancer patients introduces several legal, ethical and operational challenges that need to be addressed. The aim of this deliverable D1.3 (“Legal, ethical and operational framework” report) is to provide an overview of the European and national frameworks for handling legal and ethical issues in Horizon 2020 research and innovation projects, and in REBECCA in particular. It describes the legal and ethical restraints as well as operational and patient requirements, that should be addressed by the partners when designing REBECCA, so as to ensure the project’s compliance with the applicable laws and regulations. It sequentially discusses the relevant EU laws (such as the General Data Protection Regulation, the ePrivacy directive, the Medical Devices Regulation, the NIS directive or the latest EC’s initiatives under the European data strategy) and their impact on REBECCA. In particular, this report points out the major challenges arising under the said legislation in the context of REBECCA and how the partners should handle those. It will then move to analyse the ethical standards applicable in research, so as to enable partners to implement appropriate measures in order to avoid ethical concerns while implementing REBECCA. Lastly, the report will focus on the operational restrictions (identified by the technical partners) and patient requirements (identified by the clinical partners and the patients themselves) and how these are going to be addressed by the REBECCA partners when designing REBECCA system.
H2020SC1-DTH-12-2020 D1.3 16|79 Norwegian branch of the clinical studies, and the additional Prostate Cancer feasibility trial for evaluating the extensibility of the REBECCA use in male patients and other cancers. Fundación para la Investigación del Hospital Clínico de la Comunidad Valenciana (INCLIVA) Spain Third major clinical partner in REBECCA. INCLIVA will perform the two Spanish trials and will lead the efforts for the realization of the intervention studies for improved patient outcomes through RWD use. INCLIVA participates in the system design and integration, by offering the clinical perspective to the process; it contributes to the creation of the causal inference models and the analysis of local, hospital-based retrospective data. Bröstcancerföreningen Amazona I Stockholms län (Amazona) Sweden Amazona provides patient input through their own members and coordinates the efforts for continuous feedback and co-creation (this includes organization of the co-creation workshops and focus groups, the dissemination
H2020SC1-DTH-12-2020 D1.3 17|79 of online surveys). AMAZONA will have a major dissemination role in the project, as the natural carriers of the REBECCA message towards the wider patient population, supporting the stakeholder engagement of the project within that framework. Region Stockholm (RSTO) Sweden RSTO has a distinct clinical role, providing information about the needs of the system and the framework of its functionality, while participating in the continuous co-creation process. RSTO also has a significant contribution for the extraction of Swedish registry datasets. Significant effort will be dedicated in the clinical data collection during the Chemotherapy-induced peripheral neuropathy (CIPN) study and RSTO will also handle the patient recruitment in the intervention study in Stockholm.
H2020SC1-DTH-12-2020 D1.3 18|79 Table 2 – Technical partners Technical partner Country Major role in the project ARISTOTELIO PANEPISTIMIO OF THESSALONIKIS (Aristotle University of Thessaloniki) (AUTH) Greece A major role in the project both as project coordinator and core technical partner. AUTH is in charge of the technical, financial and administrative management. It leads in the process of translating user needs and scenarios into functional requirements, nonfunctional requirements and use-cases of the REBECCA system. AUTH develops the patient and companion applications , leads the development of the behaviour, clinical and environment indicator extraction technologies of REBECCA and the associated cloud modules of the REBECCA platform. Ethniko Kentro Erevnas kai Technologikis Anaptyxis – Center for Research and Technology Hellas (CERTH) Greece CERTH leads the development of algorithms and tools for detailed and continuous monitoring of cancer patients (the REBECCA 360º platform); especially it is responsible for the extraction of social media and web indicators of the emotional state and
H2020SC1-DTH-12-2020 D1.3 19|79 quality of life of patients. It will also lead the development of the REBECCA edge monitoring components. CERTH will also take part in the development of the REBECCA data analysis components. Finally, CERTH will also contribute to system design, technical integration and testing and dissemination and exploitation. CHAROKOPEIO PANEPISTIMIO - Harokopio University of Athens (HUA) Greece HUA leads the work in developing the methodology for causal modelling of RWD, including methodologies for causal inference and prediction. HUA develops explainable causal models for breast cancer-related chronic conditions and will use them to perform an analysis of retrospective biobank and registry data. It will lead the cross-country analysis of prospective data from Sweden, Norway and Spain, using both aggregated data sharing and federated learning technologies. NETCOMPANY INTRASOFT SA (INTRA) Luxembourg INTRA leads the REBECCA platform architecture and
H2020SC1-DTH-12-2020 D1.3 20|79 design specification, following a security and privacy-by-design approach, as well as continuous integration and testing activities to release the operational versions of the integrated platform to support the relevant clinical studies during piloting. INTRA will lead the development of the clinicians/researchers dashboard, as well as innovation management activities and will contribute to user requirements analysis, dissemination and exploitation tasks, as well as technically support the execution of the envisioned clinical studies. EIGHT BELLS LTD(8BELLS) Cyprus The 8BELLS team leads the task of building interfaces for data acquisition from the multiple REBECCA data sources and mapping them into a common data representation format. 8BELLS will also lead the cost-benefit analysis of REBECCA which will provide concise evidence on the financial benefits of adoption of REBECCA
H2020SC1-DTH-12-2020 D1.3 21|79 and RWD for clinical research, as well as for patient monitoring and management. It will participate in the project’s horizontal activities, including dissemination and exploitation of the project’s progress and results. In order to achieve the goals of the REBECCA Action, some of the consortium members (i.e. the Data Providers), will collect, use and share with other consortium members (i.e. Technical Partners) certain personal data (including but not limited to personal data related to health) of the research participants. 3.1.3 Concept of a controller, joint controller and processor The concepts of controller, joint controller and processor play a crucial role in the application of data protection laws, since they determine who shall be responsible for compliance with different data protection rules, and how data subjects can exercise their rights in practice. Controller/joint controller Under the GDPR a controller means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data 3 . Where two or more controllers jointly determine the purposes and means of processing, they shall be the so-called “joint controllers”. As such they are obliged by the GDPR to determine – in a transparent manner - their respective responsibilities for compliance with the obligations under the GDPR, in particular as regards the exercising of the rights of the data subjects and their respective duties to provide the information referred to in Articles 13 and 14, by means of an arrangement between them unless, and in so far as, the respective responsibilities of the controllers are determined by Union or Member State law to which the controllers are subject. In the context of REBECCA virtually all of the consortium members (excluding Timelex and EHMA) process personal data of the REBECCA research participants in one way or 3 Article 4(7) of the GDPR
H2020SC1-DTH-12-2020 D1.3 22|79 the other. More importantly, all consortium members jointly determine the means and purposes of such processing, that is why and how the data is processed. As a result they meet the definition of “joint controllers” under Article 26 of the GDP and as such should conclude a proper agreement, that will duly set forth and organize their respective rights and obligation with respect to the data collected, exchanged and generated within the REBECCA project. As required under the GDPR, the essential elements of such an agreement should be made available to the data subjects. In the context of REBECCA, the essence of the joint controllership agreement should be made available to the research participants (as well as their companions, where applicable), for example through the consent form. Processor Next to the concept of controller, the GDPR introduces the concept of a processor, i.e. a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller. According to the European Data Protection Board’s (EDPB) “Guidelines 07/2020 on the concepts of controller and processor in the GDPR” 4 there are two basic conditions for qualifying as processor: that it is a separate entity in relation to the controller and that it processes personal data on the controller’s behalf. The processor must not process the data otherwise than according to the controller’s instructions. A processor will be infringing the GDPR if it goes beyond the controller’s instructions and starts to determine its own purposes and means of the processing (in which case it will be considered a controller in respect of that processing and may be subject to sanctions for going beyond the controller’s instructions). When entrusting processing to processors, a controller must use only processors providing sufficient guarantees to implement appropriate technical and organizational measures so that the processing will meet the requirements of the GDPR and ensure the protection of the rights of the data subject. Moreover, the processing shall be governed by an agreement, which will set forth the subject matter and duration of the processing, the nature and purpose of processing, the type of personal data and categories of data subjects as well as the obligations and rights of the controller. In particular a data processing agreement shall stipulate that the processor: • processes data only on documented instructions from the controller; • ensures that persons authorised to process data have committed themselves to confidentiality; 4 https://edpb.europa.eu/system/files/202107/eppb_guidelines_202007_controllerprocessor_final_en.pdf
H2020SC1-DTH-12-2020 D1.3 23|79 • implements appropriate technical and organizational measures to ensure a level of security appropriate to the risk; • respects the conditions for engaging another processor; • assists the controller in the fulfilment of the controller’s obligations; • deletes or returns all personal data to the controller at the end of the provision of services relating to processing and deletes existing copies; • makes available to the controller all information necessary to demonstrate compliance with the obligations under the GDPR and contribute to audits and inspections conducted by the controller or its auditors. • In the context of REBECCA, if at any point the joint controllers (jointly) or any of them separately engages any third party (-ies) (subcontractors) to process personal data on their behalf, those third parties will very likely meet the definition of a “processor” within the meaning of the GDPR. As a result, a data processing agreement will have to be concluded between the joint controller (-s) and the given subcontractor. This will be the case in particular with to the dedicated private cloud platform, that the REBECCA partners plan to maintain and which will be hosted on virtual machines as compute nodes on IaaS provider (i.e. Hetzner). As a general rule, cloud infrastructure service providers (CISPs) are processors within the meaning of the GDPR. CISPs provide self-service, on-demand cloud infrastructure. It is the customer who chooses if and how to use this infrastructure, including whether any personal data is uploaded to the cloud infrastructure service, and if so, how that personal data is "processed". CISPs have no control over what content the customer chooses to upload to the service (including whether or not it includes personal data). CISPs have no role in the decisionmaking as to whether or not the customer uses the cloud infrastructure service for processing personal data and for what purpose. Accordingly, CISPs are not able to ascertain whether there may be a lawful basis for the processing. As such, their responsibility is to (a) comply with the customer’s instructions as provided for in the service contract and (b) provide information about the service. 5 Since it will be the REBECCA consortium that chooses to store or otherwise process personal data using a CISP’s services, and determines the purposes and means of such 5 Data protection Code of conduct for cloud infrastructure service providers dated 9 February 2021 available at https://www.codeofconduct.cloud/wpcontent/uploads/2021/05/2021_CISPE_Cloud_IaaS_Data_Protection_Code_of_Conduct__GDPR_Compliance__EN_clean.pdf#:~:text=IaaS%20providers%20are%20referred%20to%20in%20this %20Code,personal%20data%20that%20the%20customer%20wishes%20to%20perform.
H2020SC1-DTH-12-2020 D1.3 24|79 processing, the CISP (i.e. Hetzner) will be the REBECCA consortium’s processor and the REBECCA partners will be the data controllers (joint controllers). This will require the conclusion of a data processing agreement with the CISP (i.e. Hetzner) as required under Article 28 of the GDPR, which will define the features of the service and how it is delivered and the respective rights and obligations of the CISP as regards the processing of the personal data to be stored within the REBECCA (or the inclusion of relevant provisions in the underlying service agreement). 3.1.4 Identification of data flows within REBECCA The REBECCA project aims to develop a digital cloud platform (REBECCA 360º tool) for breast cancer patients, that will be able to monitor their everyday physical and emotional state. Raw data for continuous monitoring of the patient quality of life will be collected from various sources such as wearable devices, mobile applications 6 , web browser plugin. Data from the patients` electronic health records (medical history and/or biological sample data) will be extracted to be combined with the above data. REBECCA will also use open and public data sources (such as maps, satellites, statistical authorities) to quantify the life-space of the patient (e.g. whether the patient uses sports/recreational facilities, whether she goes to restaurants, cafes or whether she mostly stays home). The collection of datasets will be stored in REBECCA cloud 7 databases and will be available for analysis that will provide results about the patient’s lifestyle, behaviour, medical history, and possible identifications of changes in functional and emotional status. This in turn would allow the medical experts/patient’s doctor to modify treatment/follow-up/provide support/counselling. The evaluation of analysed data and the overall patients’ status will be available through a web user interface that will form the clinical dashboard, available to the clinicians and medical experts at the clinical sites in Norway, Sweden and Spain. REBECCA will handle patient data at different aggregation layers including: (i) data handled only at the edge device, (ii) detailed behavioural indicators, registry data and clinical data, which will be stored securely in local data storage facilities (clinical sites/RedCap servers), and (iii) pseudonymized patient indicators which, under specific 6 Both patient and companion apps 7 A dedicated private cloud platform maintained by the consortium members will be hosted on virtual machines as compute nodes on IaaS provider (i.e. Hetzner) with data centers located within the EU (i.e. Germany).
H2020SC1-DTH-12-2020 D1.3 25|79 conditions can be shared across countries (e.g. with technical partners) for research purposes (e.g. training algorithms, causal model analysis). The data ingested in the REBECCA platform will be pseudonymized: a unique ID will be assigned to the patient, with the key allowing to re-identify the patient being held outside the REBECCA system (i.e. at the clinical site/by the patient’s doctor). Yet, the REBECCA 360º platform will have no communication with any systems that may already exist in the clinical partners’ sites (clinics). Clinical data will be inserted into REBECCA using data entry forms or using files (e.g., database exports, CSV files). The below figure explains the data flows within REBECCA. Figure 1 Data flows within REBECCA Deliverable D2.1 “Initial System Specifications” present in further detail the REBECCA system components, data types that are stored or generated within each one of those components, as well as the respective data flows in between them. 3.1.5 Key principles of data protection Article 5 of the GDPR sets out seven key principles which lie at the heart of the general data protection regime and which must be always respected by data controllers. These are as follows:
H2020SC1-DTH-12-2020 D1.3 32|79 An informed consent is linked to the principle of transparency of processing, already discussed above. To understand the processing, the data subject must be informed about its main components. The data subjects must receive at least information concerning the identity of the data controller(s), the purpose(s) of processing, the intended legal basis for processing (e.g. consent), the categories of data processed, the categories of recipient of the data processed, and - where applicable - whether the personal data will be transferred outside of the European Economic Area. This information must be provided in a clear and accessible language, in a manner ensuring that data subject will always have easy access to the above information. In the context of REBECCA, the research participants should be provided with the above indicated information, at the time of collection of their data (at the latest; preferably at the time of inclusion), in their national language (e.g. Swedish, Norwegian or Spanish). They should also receive their own copy of the information notice (e.g. in paper or electronic form, such as an e-mailed pdf file). The information notice could also be made available on the REBECCA’s website/the REBECCA mobile app. Also, should REBECCA process personal data of patients’ companions’ (e.g. name, surname, e-mail address, contact details, relation to the patient), then the companion should also be provided with the adequate information notice. • Unambiguous Consent requires a statement from the data subject or a clear affirmative act; this means that it must always be given through an active motion or an explicit declaration. Consent may be collected either in writing or through a verbal recording. It may also be collected electronically. In any case however, it must be clear to the data subject that they are granting consent to their data processing. In practice, this boils down to data subject signing a consent form. Affirmative action may be taken not only by placing a signature, but also by ticking a box, writing a short statement or another statement or conduct which clearly indicates in this context the data subject's accepts the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. Controllers must be able to demonstrate that the data subject has granted his/her consent, as part of the accountability obligation. Therefore, the consent process must take into account
H2020SC1-DTH-12-2020 D1.3 33|79 the storage of the proof of consent for a specific duration (the retention periods must be included in the information provided to the data subjects). In the context of REBECCA, research participants should sign the consent form. • Explicit (in case of special categories of data) Given the purpose and object of the REBECCA action, the majority of the personal data collected from the research participants will concern their physical health and activity 9 . As such, additional requirements for consent under Article 9 of the GDPR shall apply to the processing of those “special categories data” within REBECCA 10 . As specified in Article 9.1 of the GDPR, special categories of data encompass “personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation”. Health data self-evidently includes medical records, information about diagnosis or treatment and medical history. But it may also include other information such as whether an individual wears glasses, whether he smokes or drinks, his IQ, any allergies, any support groups he attends, any tax deductions for home alterations and medical product purchase history. The data do not have to be collected on a medical device and do not have to indicate poor health. When conclusions about an individual's health status are drawn as a result of combining non-health data (e.g. lifestyle data) they become health data. 11 9 Such as step count, heart rate, sleep tracking. 10 Article 4.15 of the GDPR. 11 A pedometer that measures the number of steps a user takes each day in isolation does not collect health data, but in combination with body mass index and mood data could build up a picture of an individual's health state; see the Article 29 Working Party’s answer to the European Commission on the
H2020SC1-DTH-12-2020 D1.3 34|79 Due to the particularly sensitive nature, processing of special categories of data is more likely to create risks to the rights and freedoms of the data subjects concerned. As such, it is prohibited as a matter of principle (see Article 9.1 GDPR). However, certain limited exceptions to this outright ban exist under the GDPR, including, in particular, the explicit consent of the data subject (Article 9.2 (a) GDPR). Given that consent is already sought for ethics purposes, and because it is used as a legal basis for the processing of other, non-sensitive categories of personal data, the explicit consent (under article 9.2 (a) of the GDPR) appears to be the most appropriate grounds for processing of special categories of data (i.e. health related data) within the REBECCA framework. According to the EDPB in its Guidelines on Consent 12 , the term “explicit” refers to the way consent is expressed by the data subject and means that the data subject must give an express statement of consent. The “explicitness” threshold will usually be reached through a signed written statement of the data subject. However, where necessary, explicit consent may also be obtained with an oral confirmation of consent, that is recorded for evidentiary purposes. As a consequence, the consent for processing both physical and mental health related data of research participants must not only meet the general criteria for consent (as set forth above), but it must also be conveyed in an explicit manner Consent for processing vs Informed consent to participate in a research study Although oftentimes both are collected in one consent form, the consent to the processing of personal data should be clearly distinguished from the consent to the participation in a research study (the latter being a separate ethics related requirement). Therefore, the REBECCA partners should make sure, that both consents are collected from the research participants and bear in mind, that obtaining one does not waive the obligation to collect the other. More on consent in the context of research participation, can be found in Section 3.3.4 “Informed consent”. 3.1.7 Definition and implementation of organizational and technical measures It is a duty of every controller, to comply with the GDPR, in particular to implement appropriate safeguards for the rights and freedoms of the data subjects, whose data clarification of the definition of “health data” in relation to lifestyle/wellbeing apps and wearable devices https://ec.europa.eu/justice/article-29/documentation/otherdocument/files/2015/20150205_letter_art29wp_ec_health_data_after_plenary_annex_en.pdf 12 https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf
H2020SC1-DTH-12-2020 D1.3 35|79 they process (this duty being mandated also with respect to scientific research projects, such as REBECCA, as provided in Article 89.1 of the GDPR). Complying with Article 89.1. of the GDPR opens the door to the facilitations provided by the GDPR for scientific research, such as flexibility in the implementation of the principles of purpose limitation or storage limitation. Pursuant to Article 32 GDPR, it is the responsibility of controllers/joint controllers to implement technical and organizational measures to ensure the level of security appropriate to the risks, including in particular: • pseudonymisation and encryption of personal data; • the ability to ensure the ongoing confidentiality, availability and resilience of processing systems and services; • the ability to restore availability and access to personal data in a timely manner in the event of a physical or technical incident; • a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing. In the context of scientific research 13 , GDPR (in its Article 89.1) emphasizes the importance of, in particular, the following safeguards for the rights and freedoms of the data subject: • the principle of data minimization, which supposes the minimal collection of data and minimal processing of the data collected (already discussed in Section 3.1.5 above); • pseudonymisation (pseudonymisation is a reversible, de-identifying procedure, the purpose of which is to ensure that personal data can no longer be attributed to a specific data subject without the use of additional information (Article 4.5 GDPR). Through pseudonymisation, a personally identifiable information within a data record are replaced by one or more artificial identifiers/pseudonyms. Any additional information that could be used to re-identify the data subject must be kept separately and be subject to technical and organizational measures, so as to ensure that the personal data are not attributed to an identified or identifiable natural person.) Bearing in mind the above, the REBECCA partners should strive to implement the above mentioned safeguarding measures. 13 EDPB Guidelines 03/2020 on the processing of data concerning health for the purpose of scientific research in the context of the COVID-19 outbreak; https://edpb.europa.eu/our-work-tools/ourdocuments/guidelines/guidelines-032020-processing-data-concerning-health-purpose_en
H2020SC1-DTH-12-2020 D1.3 36|79 In the context of REBECCA, a detailed description of the security requirements and procedures to be implemented is contained in D2.1 “Initial systems specifications”. In particular, Section 5 of that deliverable elaborates on the Security Requirements, (e.g. log management, system hardening, user authentication, application security) including privacy filters (e.g. data encryption, data pseudonymisation etc.), that will be covered within the REBECCA platform and which are essential for hosting sensitive clinical data on a cloud platform solution. 3.1.8 Information notice As discussed above, transparency of the processing is one of the fundamental principles of data protection and requires that the data subjects (i.e. patients but also companions – where applicable) be informed in advance of any processing operations that are to be carried out on their data. The nature and the contents of the information that must be provided to the data subjects are set forth by the GDPR in Articles 13 and 14 and are usually conveyed to the data subjects via information notice. Depending on whether the information has been collected directly from the data subjects themselves, or from third parties (e.g. patient’s companion), the notice will contain slightly different information and will be provided at different times. And so, where personal data are collected directly from the data subject, the notice should be provided to at the time the personal data are obtained from the data subject. If the data is collected from third parties – the information notice should be provided to the data subject no later than within one month of the data collection. The information that must be provided to data subjects under Articles 13 and 14 of the GDPR includes: • identity and contact detail of the data controller/joint controllers (and – if applicable - their representatives; DPOs – if appointed); • the source from which the data originated (if collected not from the data subject himself) and if applicable, whether it came from publicly accessible sources; • the purpose of processing; • the legal basis for processing (such as e.g. consent); • the categories of recipients of data (if any; e.g. external vendors/processors); • in cases where the controller/joint controllers intend to transfer personal data outside the EEA, justification for such transfer along with the reference to appropriate safeguards and the means to obtain access to or a copy of those; • data storage duration, or criteria used to determine such storage duration; • data subjects’ rights and how to exercise them;
H2020SC1-DTH-12-2020 D1.3 37|79 • the right to withdraw consent (where consent was the basis for processing) and that such withdrawal will not affect the lawfulness of processing based on consent that took place before its withdrawal; • the right to lodge a complaint with a competent supervisory authority; • the existence of profiling including meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject; • the possibility that the data will be further processed for scientific research purposes. As already explained above, the above information must – in compliance with the transparency principle – be concise, transparent, intelligible and easily accessible in order to avoid information fatigue for the data subjects, who must consider many elements, sometimes fairly technical. The REBECCA consortium should therefore strive to provide the above information in as clear and plain language as possible, in the language understandable to the research participant. The information should also be provided free of charge, ahead of the processing, either in writing, or orally. In the context of REBECCA, the information notice should preferably be attached to the double consent form 14 presented to the research participants. It should also be made easily available and accessible (both on the REBECCA’s website and in the mobile apps; a copy of this information could also be provided to the research participants in paper or electronic form/pdf attachment to an e-mail). Similarly, should REBECCA ingest and process personal data of the patient’s companion (e.g. name, surname, contact details, relation to the patient), then the companion should also be provided with an appropriate information notice (e.g. via the companion app dashboard). As far as the data collected via wearables, mobile app or web browser plugin, are concerned, the information notice could and should be provided in the user dashboard or attached to the terms of use of the wearable/the app/plugin or made available on the website to which the wearable will direct the patient. 14 Including the consent for processing under the GDPR as well as the consent to participate in the research study.
H2020SC1-DTH-12-2020 D1.3 38|79 3.1.9 Data subject’s rights In order to assure data subjects, that the privacy of their personal data is properly safeguarded, GDPR empowers data subjects with certain rights. Through these rights, data subjects can make a specific request and obtain assurance that their personal data is not being misused for anything other than the legitimate purpose for which they originally provided it to the controller. The fundamental rights granted to data subjects under the GDPR are as follows: • Right to withdraw consent (Article 7.3 of the GDPR) Where processing is based on data subject’s consent, the data subject has the right to withdraw his/her consent at any time. He/she shall be informed of this possibility prior to granting consent. GDPR requires that the withdrawal of consent be as easy as it was to grant it and urges, that the withdrawal shall not affect the lawfulness of the processing which took place prior to the withdrawal. In the context of REBECCA this right should be assured by giving the research participants the option to withdraw from the clinical study they participate in at any point in time for whatever reason. They should be informed of this right at the time of collection of their consent (i.e. in the information notice attached to the consent form or in the user dashboard with regards to data processed in the mobile app and web browser plugin). It should be as easy to withdraw consent, as it was to grant it in the first place. Given the chosen means of obtaining consent for the REBECCA project (interview and signing of the consent form), research participants should be able to withdraw their consent in the same manner, that is by providing a written statement, expressing their wish to withdraw. Data subjects must be appropriately informed as to the consequences of the withdrawal of their consent. In practice, this means that the research participant who withdraws his/her consent, is made aware that he/she could no longer participate in the study nor use the REBECCA wearables or the mobile app, and that no new data concerning him/her will be collected. Also it should be made clear to the data subject who withdrew his/her consent, that the withdrawal shall not affect the lawfulness of the processing of his/her data that took place prior to the withdrawal. • Right of access (Article 15 of the GDPR) Data subjects have the right to obtain confirmation as to whether or not their personal data are being processed by the controller, and where that is the case, access their personal data. The controller shall provide a copy of the personal data undergoing processing. If the request is made by electronic means (and
H2020SC1-DTH-12-2020 D1.3 39|79 unless otherwise requested by the data subject) the information should be provided to the data subject in a commonly used electronic form. In the context of REBECCA, this means that the research participants shall have the right to inquire whether and what kinds of their data are being processed by REBECCA. The REBECCA partners, as joint controllers, should establish internal procedures on how to handle these types of requests. • Right to rectification (Article 16 of the GDPR) The data subjects have the right to obtain rectification of inaccurate (incorrect or misleading) personal data concerning them. They shall have the right to have incomplete data completed, including by means of providing supplementary statement. This right is closely linked to the controller’s obligations under the accuracy principle (discussed above). In the context of REBECCA this means that the REBECCA partners who are joint controllers should be prepared to handle such request of the research participants, that their data be up-to-date date, accurate and complete. Proper procedures allowing to verify the accuracy of the data processed within REBECCA and to handle these types of requests should be put in place by the REBECCA joint controllers. As with all data subject requests, the request to have the data rectified should be handled without undue delay however no later than within one month. The time to respond can be extended by two months if the request is complex or a number of requests have been received from the same research participant. • Right to erasure/”the right to be forgotten” (Article 17, 19 of the GDPR) Data subjects shall have the right to obtain from the data controllers the erasure of personal data concerning them without undue delay. The right is not absolute and only applies in certain circumstances, in particular where: (a) the data is no longer necessary for the purpose of processing for which it was collected, (b) when the data subjects withdrew their consent and there is no other valid basis for processing available to the controller, or (c) when the personal data have been unlawfully processed. Certain exceptions to the above exist, such as the necessity of the processing for scientific purposes in accordance with Article 89(1) of the GDPR (in so far as the exercise of the right to be forgotten is likely to render impossible or seriously impair the achievement of the objectives of that processing) or the necessity of the processing for the establishment, exercise or defence of legal claims.
H2020SC1-DTH-12-2020 D1.3 40|79 In the context of REBECCA this means, that the research participants will be entitled to demand that their data be deleted from REBECCA system whenever any of the above mentioned circumstances materializes. It particular, they will be able to request to be forgotten whenever they withdraw their consent to participate in the research, and there is no other valid legal ground for continuous processing. If a valid erasure request is received by the REBECCA partners, and no exemption applies, then the REBECCA partners will have to erase the data (including from both live and backup systems (if any)). Research participants will have to be informed as to what will happen to their data when the erasure request is fulfilled in respect to REBECCA (and if applicable - that the data will remain within the backup environment for a certain period of time until it is overwritten). REBECCA partners (joint controllers) will have to communicate the erasure to each recipient to whom the data have been disclosed. • Right to restriction of processing (Article 18, 19 of the GDPR) Data subjects shall have the right to obtain the restriction of processing whenever: o they contest the accuracy of their data (for the period enabling the controllers to verify the accuracy); o the processing is unlawful but the data subjects oppose the erasure of their data and requests the restriction of their use instead; o the controller no longer needs personal data for the purposes of the processing but the processing is required by the data subjects for the establishment, exercise or defence of legal claims. In the context of REBECCA this means, that whenever any of the above materialize, REBECCA partners should implement measures that will restrict the processing of the data. This can be done by temporarily moving the data to another processing system or by making it unavailable to the users (i.e. patient’s doctor on the dashboard). It should be noted within the system, that processing of the data has been restricted. No changes or modifications can be made to the data that has been restricted for processing. All recipients, who have received the data, must be informed of the restriction of processing. The data subject should be notified before the restriction is lifted. As with other data subject’s requests, controllers should handle the request for restriction of processing without undue delay, no later than within one month. In certain exceptional cases, the time to handle the request can be extended by further 2 months. • Right to data portability (Article 20 of the GDPR)
H2020SC1-DTH-12-2020 D1.3 41|79 Data subjects shall have the right to receive their personal data, which they provided to the controller, in a structured, commonly used and machinereadable format and transmit that data to another controller without any hinderance. However, this right shall be available only where the processing is carried out based on consent, or if necessary for the performance of a contract and if carried out by automated means, and is limited by the rights and freedoms of others (i.e. it shall not adversely affect the rights and freedoms of others), including trade secrets or intellectual property (in particular the copyright protecting the software). However, the result of those considerations should not be a refusal to provide all information to the data subject. In the context of REBECCA, the exercise of this right could theoretically take the form of the research participant requesting certain data collected from him to be transferred to another controller, for example a medical professional not involved in REBECCA. In this case the research participant could request that the REBECCA partners provide him/her with the copy of his/her personal data that he/she provided directly to the REBECCA consortium 15 in an accessible and machine-readable format (for example as a csv file) or that his/her data be transmitted directly (if technically feasible). Before doing this however, REBECCA partners should confirm the identity of the data subject. Once again – the request should be handled without undue delay no later than within one month. This could be extended up to an extra 2 months in exceptional circumstances (however, if this were to be the case, the data subject should be notified of the extension prior to the lapse of the first month along with the explanation for the extension). • Right to object (Article 21 of the GDPR) Data subjects shall have the right to object, at any time, on grounds relating to their particular situation, to the processing of their personal data carried out on the following grounds only: o where the processing is necessary for the performance of task carried out in the public interest or in the exercise of official authority vested in the controller (Article 6.1 (e) of the GDPR) or 15 This does not encompass any data that was created by the controller himself: i.e. data derived, interpreted and assessed from the data provided directly by the patient. For example the right to portability would not apply to data which resulted from profiling. In the context of REBECCA it would not apply to various emotional, behavioural, living environment indicators created by REBECCA algorithms).
H2020SC1-DTH-12-2020 D1.3 48|79 3.2 ePrivacy 3.2.1 Principles of the ePrivacy Directive The ePrivacy Directive 16 concerns the processing of personal data and the protection of privacy in the electronic communications sector and deals with the regulation of a number of important issues such as confidentiality of information, treatment of traffic data, spam and cookies. The key principles of the ePrivacy Directive are as follows: • Where the e-Privacy Directive provides for a specific rule applicable to natural and legal persons in relation to processing in connection with the provision of publicly available electronic communications services in public communication networks, it prevails over the general rule set out by the GDPR (Principle of Specialty). • Electronic Communication Services and Networks must be secured through appropriate technical and organizational measures. (Principle of Security). • The confidentiality of communications and the related traffic data by means of a public communications network and publicly available electronic communications services, must be ensured (Principle of Confidentiality). • Access to, or storage of, information on users’ devices must be authorised by the users with a specific consent, unless it is “strictly necessary in order to provide a service explicitly requested by the subscriber or user” (the so called “cookie law”, Prior Consent). In other words, any website, or app should provide clear information on the cookies it deploys into the users’ devices and it should collect prior consent, where necessary. • Principles applicable to Traffic Data • Traffic data must be erased or made anonymous when it is no longer needed for the purpose of the transmission of a communication or for the purposes of processing subscriber’s billing and interconnection payments (Traffic data erasure); • Traffic data can be processed for marketing and/or for the provision of value-added services only upon specific consent of the user concerned (Consent for Marketing purposes); 16 Directive 2009/136/EC of the European Parliament and of the Council amending Directive 2002/22/EC on universal service and users’ rights relating to electronic communications networks and services, Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector and Regulation (EC) No 2006/2004 on cooperation between national authorities responsible for the enforcement of consumer protection law available at https://edps.europa.eu/sites/default/files/publication/dir_2009_136_en.pdf
H2020SC1-DTH-12-2020 D1.3 49|79 • Specific information on traffic data processing and its duration must be provided (Specific Information); • Traffic data must be processed only by persons under the authority of the service provider that are dedicated to the function or unit for which such data are necessary (e.g. handling billing or traffic management, customer enquiries, fraud detection, marketing electronic communications services or providing a value-added service – Authorisation profiles). • Principles applicable to Location Data • Location data can be processed for the provision of value-added services 17 only anonymously or upon specific consent of the user concerned (Consent for Location Data 18 ); • Users must be given the opportunity to easily refuse such processing at each connection (Updated Consent); • Location data must be processed only by persons under the authority of the service provider that are dedicated to the function or unit for which such data are necessary (Authorisation profiles). The ePrivacy Directive is a legal act of the European Union that requires member states to achieve a particular result without dictating the means of achieving that result. It has therefore been implemented into national laws and regulations. Currently a new proposal – an ePrivacy Regulation is underway. If adopted, the ePrivacy Regulation will repeal the ePrivacy Directive, and will become immediately effective as law in all member states (superseding all of the national laws, that have implemented the ePrivacy Directive). 3.2.2 Applicability of ePrivacy principles to REBECCA The general obligations derived from the ePrivacy Directive apply to the processing of personal data with regards to the provision of publicly available electronic communications services in public communications networks in the EU. 17 ‘value added service’ means any service which requires the processing of traffic data or location data other than traffic data beyond what is necessary for the transmission of a communication or the billing thereof. 18 Article 9.1 of the DIRECTIVE 2002/58/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communication) available at https://eurlex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32002L0058&from=EN
H2020SC1-DTH-12-2020 D1.3 50|79 An electronic communications service is defined as “a service normally provided for remuneration, and which consists wholly or mainly in the conveyance of signals on electronic communications networks, including telecommunications services and transmission services in networks used for broadcasting, but exclude services providing, or exercising editorial control over, content transmitted using electronic communications networks and services; it does not include information society services, as defined in Article 1 of Directive 98/34/EC, which do not consist wholly or mainly in the conveyance of signals on electronic communications networks.” The data analytics tools in REBECCA do not fall within the scope of the above definition, since they do not involve “wholly or mainly the conveyance of signals”. The primary function of the REBECCA platform (data analytics tools) is to perform analytics on data, rather than the conveyance of signals. Consequently, most obligations that apply to providers of electronic communications services will not be applicable to the REBECCA project. The ePrivacy Directive could be used to protect the privacy of REBECCA’s web-based communication channels. It could also serve as the basis for drafting the Privacy and Cookie Policy of the REBECCA website and the mobile apps. The privacy policy will be accessible via the REBECCA website or mobile app/plugin user dashboard and in accordance with the GDPR, it will provide detailed information relating to, in particular, the sharing of data within the REBECCA consortium (i.e. the essence of the joint controllership agreement) and will explain to users, the REBECCA’s policy and practices regarding the collection, use and disclosure of users’ personal information (see section 3.1.8 “Information notice”). 3.2.3 Cookies and other online tracking technologies The ePrivacy Directive is also known as the “EU cookie law” as it concerns the use of cookies and other tracking technologies that websites and apps use. According to it, all websites in the EU must collect their visitors’ consent in order to place cookies on the users’ computers or smartphones (devices). That means, that if a website uses cookies for purposes like statistics and/or marketing, the site must ask the user for his or her consent before placing the cookies, the consent being based on “clear and comprehensive information” (so called “opt-in”/active consent). Also, the upcoming ePrivacy Regulation sets forth further rules on the use of cookies and clarifies that the user consent for cookies must be based on a meaningful choice (this is not the case when it comes to cookie walls – where users must consent to non-essential cookies in order to be allowed to access the site).
H2020SC1-DTH-12-2020 D1.3 51|79 The REBECCA cookie policy should be accessible via the REBECCA website (i.e. in the website privacy policy) and in the REBECCA app/plugin user dashboard. In compliance with the data protection and the ePrivacy legislation, it should clearly explain to its users: • what the cookies do; • what the potential consequences of allowing the cookies are (i.e. that the users will be able to disable non-essential cookies); and • why REBECCA is using them. REBECCA should also obtain informed consent from users prior to deploying cookies (except for technically necessary cookies). The cookie consent will have to be active and meaningful (opt-in as opposed to pre-checked boxes). 3.2.4 Use of location data by REBECCA One of the objectives of REBECCA is to improve the quality of life of the patients by indepth analysis of their behaviour. In particular, REBECCA will attempt to do that by quantifying the life-space of the patient by monitoring patient’s local environment and identifying places of importance to him/her (such as parks, cafes, restaurants, recreational facilities, workplaces). It order to be able to do that, REBECCA will need access to the location services on the patient’s end device (mobile) to continuously monitor the local environment of the patient. For that purpose, REBECCA partners should bear in mind that: • Patient’s consent for the use and access to location data must be obtained in advance; the consent must be valid, i.e. must be freely given, specific and informed (as already described above in Section 3.1.6 “Legal basis for processing”), for example patient can express it by ticking a box (in any case it must be an explicit opt-in, affirmative action). • Patient must be informed of the details of the processing, prior to giving consent (i.e. the REBECCA app should inform what location data will be collected and processed, the purpose for which it will be processed and whether the location data will be shared with any third parties). • Patient must be able to withdraw the consent and stop the use of location data at any time (an option to disable the location data within the mobile app settings should be available when starting the app). • Location data should only be used for a specific reason (here: quantifying the life-space of the patient), and only for the duration necessary for the purpose.
H2020SC1-DTH-12-2020 D1.3 52|79 3.3 REBECCA solution and the Medical Devices Regulation Although REBECCA is not intended to be a medical device, a high level overview of the Medical Device Regulation (which covers not only the existing medical devices but also clinical investigations concerning such medical devices) is presented below for partners’ consideration, as this might be addressed by the ethical committees. 3.3.1 Definition of a “medical device” The European legal framework on ”medical devices” is currently embodied in the European Medical Devices Regulation (Regulation), 19 which lays down rules concerning the placing, making available on the market or putting into service of medical devices for human use and accessories for such devices in the European Union. The Regulation also applies also to clinical investigations concerning such medical devices conducted in the EU. According to the Regulation ‘medical device’ shall mean any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of specific medical purposes, the most prominent one being the diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease 20 . The determining factor to distinguish a medical device from any other kind of device is the intention of the manufacturer. The term ‘intended purpose’ means the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation. Software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device (as opposed to software for general purposes, even when 19 REGULATION (EU) 2017/745 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC available https://eurlex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32017R0745&from=EN 20 For a complete list of those specific medical purposes see definitione of „medical device” under Article 2 (1) of the Medical Devices Regulation available at REGULATION (EU) 2017/ 745 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL - of 5 April 2017 - on medical devices, amending Directive 2001/ 83/ EC, Regulation (EC) No 178/ 2002 and Regulation (EC) No 1223/ 2009 and repealing Council Directives 90/ 385/ EEC and 93/ 42/ EEC (europa.eu)
H2020SC1-DTH-12-2020 D1.3 53|79 used in a healthcare setting, or software intended for lifestyle and well-being purposes – which are not medical devices). REBECCA 360º patient monitoring platform is a data collection system which is intended specifically to monitor breast cancer patients and provide information which will be then used to take decisions with diagnostic or therapeutic purposes. Although it is not the intention of the REBECCA partners, that the REBECCA solution be treated as a medical device, it cannot be excluded with certainty, that some of its components, would not qualify as a medical device within the meaning of MDR. In particular the REBECCA 360º platform, which will undoubtedly serve medical purposes (i.e. will allow doctors to monitor and provide custom tailored treatment of the breast cancer patients) may be viewed by the ethical committees as a medical device within the meaning of the MDR. Therefore, in anticipation of the above, partners should ensure that REBECCA system meets the requirements of clinical investigations under the MDR. 3.3.2 Requirements of clinical investigations under the Medical Devices Regulation It cannot be denied that the intended purpose of REBECCA system is to monitor breast cancer survivors and provide information which will be then used to take decisions with diagnostic or therapeutic purposes. As a consequence, it is highly advisable that the clinical studies undertaken in the framework of REBECCA observe the requirements of clinical investigations under the Medical Device Regulation. This Regulation uses the term “clinical investigation”, defined as “any systematic investigation involving one or more human subjects, undertaken to assess the safety or performance of a device”. The Medical Devices Regulation distinguishes between two categories of clinical investigations: • clinical investigations carried out as part of the clinical evaluation for conformity assessment purposes, and • other clinical investigations undertaken to assess the safety or performance of a medical device. The first category of clinical investigations may be carried out only for medical devices which are completely ready to be put on the market, including packaging, usage
H2020SC1-DTH-12-2020 D1.3 54|79 instructions, etc. Since this is not the case with REBECCA solution, the REBECCA studies 21 envisaged, will necessarily fall under the second category, i.e. other clinical investigations undertaken to assess the safety or performance of a medical device. As such, the REBECCA study will need to fulfil the requirements of Art. 82 of the Regulation. 3.3.3 Article 82 of the Medical Devices Regulation According to Article 82, clinical investigations which are NOT carried out as part of the clinical evaluation for conformity assessment purposes (such as the REBECCA study), shall only comply with a limited number of requirements. These are as follows: • clinical investigations shall be designed and conducted in such a way that the rights, safety, dignity and well-being of the subjects participating in a clinical investigation are protected and prevail over all other interests and the clinical data generated are scientifically valid, reliable and robust. • clinical investigations shall be subject to scientific and ethical review. The ethical review shall be performed by an ethics committee in accordance with national law. Member States shall ensure that the procedures for review by ethics committees are compatible with the procedures set out in this Regulation for the assessment of the application for authorisation of a clinical investigation. At least one lay person shall participate in the ethical review. • a clinical investigation may be conducted only where all of the following conditions are met: • an ethics committee, set up in accordance with national law, has not issued a negative opinion in relation to the clinical investigation, which is valid for that entire Member State under its national law; • the sponsor, or its legal representative is established in the Union; • vulnerable populations and subjects are appropriately protected in accordance with Articles 64 to 68; • the subject or, where the subject is not able to give informed consent, his or her legally designated representative has given informed consent in accordance with Article 63; • the rights of the subject to physical and mental integrity, to privacy and to the protection of the data concerning him or her in accordance with Directive 95/46/EC are safeguarded; • the investigational device(s) in question conform(s) to the applicable general safety and performance requirements set out in Annex I of the MDR apart from 21 Studies of the REBECCA system i.e. studies 4,5 and 6 of the DoA
H2020SC1-DTH-12-2020 D1.3 55|79 the aspects covered by the clinical investigation and that, with regard to those aspects, every precaution has been taken to protect the health and safety of the subjects. This includes, where appropriate, technical and biological safety testing and pre-clinical evaluation, as well as provisions in the field of occupational safety and accident prevention, taking into consideration the state of the art; • the investigator shall be a person exercising a profession which is recognized in the Member State concerned as qualifying for the role of investigator on account of having the necessary scientific knowledge and experience in patient care. Other personnel involved in conducting a clinical investigation shall be suitably qualified, by education, training or experience in the relevant medical field and in clinical research methodology, to perform their tasks. 3.3.4 Informed consent One of the most essential requirements in the above mentioned list of requirements for clinical trials of medical devices, is the requirement regarding the informed consent of the clinical trial participant. The informed consent must comply with the rules laid down in Article 63 of the Regulation. These are quite detailed and can be summarized as follows: • informed consent shall be written, dated and signed by the person performing the interview and by the subject; • informed consent shall be documented; • adequate time shall be given for the subject to consider his or her decision to participate in the clinical investigation; • information given to the subject shall: • enable the subject or his or her legally designated representative to understand: (i) the nature, objectives, benefits, implications, risks and inconveniences of the clinical investigations; (ii) the subject’s rights and guarantees regarding his or her protection, in particular his or her right to refuse to participate in and the right to withdraw from the clinical investigation at any time without any resulting detriment and without having to provide any justification; (iii) the conditions under which the clinical investigations is to be conducted, including the expected duration of the subject’s participation in the clinical investigation; and (iv) the possible treatment alternatives, including the follow-up measures if the participation of the subject in the clinical investigation is discontinued; • be kept comprehensive, concise, clear, relevant, and understandable to the subject or his or her legally designated representative;
H2020SC1-DTH-12-2020 D1.3 56|79 • be provided in a prior interview with a member of the investigating team who is appropriately qualified under national law; • include information about the applicable damage compensation system; • include the Union-wide unique single identification number of the clinical investigation and information about the availability of the clinical investigation results; • The information shall be prepared in writing and be available to the subject; • In the interview special attention shall be paid to the information needs of specific patient populations and of individual subjects, as well as to the methods used to give the information; • In the interview it shall be verified that the subject has understood the information; • The subject shall be informed that a clinical investigation report and a summary presented in terms understandable to the intended user will be made available irrespective of the outcome of the clinical investigation, and shall be informed, to the extent possible, when they have become available. The requirement to obtain consent of the participants to a clinical study is, in almost all cases, also imposed by an ethical board or research committee, which functions at the level of a hospital, a hospital cluster. In some countries, ethical boards are organized at regional or, exceptionally, at the national level. 3.3.5 Implementation in the context of REBECCA Written approval from the competent ethical board or research committee must be obtained for the REBECCA project in each institution where patients will be recruited for participation in the clinical study (i.e., Sweden, Norway and Spain). The research participants will be contacted individually to enquire about their willingness to participate in the REBECCA study. Patients interested in participating in the study will be informed about study details and will provide written consents. The consent to the participation to the study and the consent to the processing of their personal data will be collected during this visit. All recruited individuals have to complete and sign a consent form, written in their native language. In cases of illiteracy, the patient will be informed about the content of the consent form by his/her escort or legal representative, who will complete and sign a verification form. It must be clear to all parties involved that a consent to participation to a trial or a clinical study cannot automatically be assimilated to a consent for the processing of personal data.
H2020SC1-DTH-12-2020 D1.3 57|79 These two consents (consent for processing of personal data and the informed consent to participate in the study), while collected in one single document serve two different purposes and are required by different legislations. Consent for the processing of personal data is the legal base justifying the processing of personal data and special categories of such data as required under the GDPR, which has already been addressed above. 3.4 Cybersecurity concerns 3.4.1 NIS Directive The NIS Directive is the first EU horizontal legislation addressing cybersecurity challenges. It is the cornerstone of the EU’s response to the growing cyber threats and challenges which are accompanying the digitalization of our economic and societal life. The Directive has three main objectives: • Improving national cybersecurity capabilities • Building cooperation at EU level • Promoting a culture of risk management and incident reporting among key economic actors, notably operators providing essential services (OES) for the maintenance of economic and societal activities and Digital Service Providers (DSPs). Operators of essential services The Directive compels Member States to classify key entities in various critical infrastructure sectors as “Operators of Essential Services” (OES) and to ensure that these enterprises have reached a given level of security in terms of their IT systems, while imposing a binding reporting obligation on these entities to report incidents. Secondly, and in addition to ensuring that a well-resourced CSIRT is in place, Member States will also be required to designate a National Competent Authority (or NCA) to manage reporting and compliance of the OES entities with the Directive. The rationale is that impacts of security incidents in such services may cause major disruptions to economic activities and to society at large, potentially undermining user confidence and causing major damage to the economy of the Union. The NIS Directive does not define explicitly which entities are to be considered as OES under its scope. Instead, it provides criteria that Member States need to apply in order to carry out an identification process to determine which enterprises will be considered operators of essential services and therefore subject to the obligations under the Directive.
H2020SC1-DTH-12-2020 D1.3 64|79 that its use grossly deviates from good commercial practice in data access and use, contrary to good faith and fair dealing. • An obligation of the data holder to make data available, upon request, to a public sector body, or to an EU institution, agency or body, if they demonstrate an exceptional need to use the data requested (e.g. where it is necessary to respond to a public emergency). • Obligation of the providers of data processing services to clearly include in their contracts clauses that support switching in between those services, to gradually withdraw switching charges and to respect interoperability requirements. Although it may not be now apparent how this proposed data legislation could affect REBECCA, the consortium partners should consider the proposal and assess whether – if adopted – it would apply to the data generated by REBECCA. 3.6.3 Artificial Intelligence (AI) Act On April 21, 2021 the European Commission published a draft law to regulate artificial intelligence (AI) in the European Union. The Artificial Intelligence Act imposes extensive documentation, training and monitoring requirements on AI tools and systems that fall within its scope. Any company with EU market exposure that develops or wishes to adopt machine-learning based software will fall under the purview of the AI Act. The AI act shall apply extraterritorially to any provider or distributor of AI whose products or services reach the EU market. It creates new regulatory requirements for AI tools used in a variety of sectors, including in particular financial services, education, employment or medical devices. The AI Act distinguishes three categories of AI uses: prohibited AI uses, high-risk AI uses, and systems with limited risk. The first category of completely prohibited AI uses encompasses the following: • AI systems that manipulate persons through subliminal techniques or exploit the fragility of vulnerable individuals (due to age, physical or mental disability), and could potentially harm the manipulated individual or third person; • AI systems that serve for general purposes of social scoring, if carried out by public authorities; or • AI systems that are used for running real time remote biometric identification systems in publicly accessible spaces for law enforcement purposes. The second category of AI uses (i.e. the so-called high risk AI uses), encompasses those AI systems, which are used as a safety component of a product or are covered by one of 19 specified pieces of EU single market harmonization legislation (e.g., aviation, cars,
H2020SC1-DTH-12-2020 D1.3 65|79 medical devices). Moreover, AI systems deployed in the following sectors are deemed by draft legislation to be high-risk: (a) critical infrastructure, where the AI system could put people’s life and health at risk, (b) law enforcement, administration of justice, employment, worker management and self-employment; (c) educational and vocational settings where AI systems could determine access to education or professional training, (d) migration, asylum, border control, including verifying the authenticity of travel documents, (e) essential private and public services (incl. access to financial services such as credit scoring systems). This list can be further expanded by the EC. The AI Act imposes a number of technical and regulatory obligations on organizations that develop or use high-risk AI systems. These include in particular the requirement to (a) implement safeguards against various types of biases in data sets, (b) to use prescribed data governance and management practices, (c) to ensure the ability to verify and trace back outputs throughout the life cycle of the system, (d) to incorporate provisions for acceptable levels of transparency and understandability for users of and appropriate human oversight over the given AI system. Before any AI system in a high-risk sector can be placed on the EU market, it must undergo an ex-ante conformity assessment. For AI products and services governed by existing product safety legislation (e.g. cars, aviation, machinery, medical devices or toys), the AI Act’s requirements will fall under the existing third-party conformity assessment structures and regulatory frameworks that already apply to that sector . The AI Act imposes also mandatory post-market monitoring obligations for high-risk systems. Serious incidents or faults of the AI system which breach safety laws or fundamental rights must be reported to the national supervisory body. In case of a violation of the AI Act, regulators can mandate access to the source code of a high-risk AI system. High-risk systems that violate the Act can be forcibly withdrawn from the market by the regulator. Most of the Act’s regulatory obligations fall on the party that places the AI system on the market (the “provider”), which can be a third-party provider or a company developing the AI itself. Distributors, importers, users and other third parties are subject to provider obligations if they place a high-risk AI system on the market under their name or make a substantial modification to it, in which case the original provider is relieved of the responsibility. Providers of AI systems that pose a ‘limited risk’ (such as chatbots), will be subject to transparency obligations (e.g. technical documentation on function, development, and performance) and may choose to adhere to voluntary codes of conduct. The
H2020SC1-DTH-12-2020 D1.3 66|79 transparency obligations will in particular serve to allow users to make informed decisions about how they integrate an AI software into their products and/or services. Lastly, AI systems that pose ‘minimal or no risk’, such as spam filters, will be permitted with no restrictions but providers will be encouraged to adhere to voluntary codes of conduct. The European Commission envisages that most AI systems will fall into this category. Fines for non-compliance with the draft legislation can amount to up to EUR 30.000.000 or up to 6% of the total worldwide annual turnover for the preceding financial year (if the offender is a company). The AI Act is expected to be finalised and enter into force in the second half of 2022, although a transitional period is expected to apply before the regulation takes effect.
H2020SC1-DTH-12-2020 D1.3 67|79 4 Ethical framework 4.1 Ethics in research Fundamental ethical principles apply to all scientific research and ethical issues may arise in all possible domains of scientific research. Ethics is a high priority in EU funded research and all activities implemented in the Horizon 2020 framework must comply with ethical principles, as well as with the relevant national, EU and international legislation. Research ethics is of crucial importance in all scientific domains and basic ethics principles are constantly adapted to specificities of various research domains by different professional and/or academic associations such as for example the European Science Foundation 28 . Amongst the Golden Rules of Ethical Research Conduct relevant to the project research domain, are the following principles: • Respect the integrity and dignity of persons. • “Do no harm” principle which translates in particular into the requirement that all risks must be clearly communicated to the subjects involved. • Recognize the individual’s rights to privacy, personal data protection and freedom of movement. • Obtain informed consent and maintain continuous dialogue with research subjects. • Respect the principle of proportionality: do not impose more than is necessary on your subjects or go beyond stated objectives. • Build on the understanding that any benefits are for the good of society, and any widely shared expressions of concern about threats from the given research must be considered. 4.2 Ethics in Horizon 2020 projects The Lisbon Treaty, which forms the constitutional basis of the EU, makes an explicit reference to the Charter of Fundamental Rights of the European Union (“The Charter”). The Charter focuses on the right to the integrity of a person 29 , protection of personal 28 ESF INTERNAL CODE OF CONDUCT available at https://www.esf.org/fileadmin/user_upload/esf/ESFCode-of-conduct-22.12.21.pdf 29 Article 3.1. Everyone has the right to respect for his or her physical and mental integrity;
H2020SC1-DTH-12-2020 D1.3 68|79 data 30 and family life 31 as well as rights in the field of bio-ethics 32 , academic freedom and freedom of scientific research 33 . Also the Regulation 1291/11-122013, which establishes Horizon 2020, sets forth in its Article 19, the ethical principles applicable to all research and innovation activities under Horizon 2020. In particular, all Horizon 2020 projects should observe the principle of proportionality, the right to privacy and protection of personal data, the right to physical and mental integrity of a person, the right to non-discrimination and the need to ensure high levels of human health protection. As far as the relation between the healthcare provider and the patient/research participants is concerned, this has been regulated by the World Medical Association (WMA) in their ethical guidelines contained in the “Declaration of Lisbon on the Rights of the patient” and the “Declaration of Helsinki”, which specifically addressed the Ethical Principles for Medical Research Involving Human Subjects. 4.3 Ethics in REBECCA 4.3.1 REBECCA participants’ rights In REBECCA, the decision regarding the research participation will be entirely voluntary, based on full disclosure and understanding of the participant (patient) and clinical trial information. There will be strict adherence to the requirements and procedures concerning provision of informed consent (for more on the requirements of informed consent please see Section 3.3.4), as approved by local ethical reviewing authorities (i.e. ethical committees in Sweden, Norway and Spain) and institutional guidelines (i.e. the Declaration of Helsinki). Prospective research participants will be adequately informed of the particularities of the studies (the aims, methods, sources of funding, possible conflicts of interest, institutional affiliations of the researcher, the anticipated benefits and potential risks of the studies, as well as the discomfort it may entail, post-study 30 Article 8.1. Everyone has the right to the protection of personal data concerning him or her. 31 Article 7 Everyone has the right to respect for his or her private and family life, home and communications 32 Article 3.2. In the fields of medicine and biology, the following must be respected in particular: (a) the free and informed consent of the person concerned, according to the persons; (b) the prohibition of eugenic practices, in particular those aiming at the selection of persons; (c) the prohibition on making the human body and its parts as such a source of financial gain; (d) the prohibition of the reproductive cloning of human beings 33 Article 13 The arts and scientific research shall be free of constraint. Academic freedom shall be respected.
H2020SC1-DTH-12-2020 D1.3 69|79 provisions and any other relevant aspects of the study) as well as of their right to refuse to participate in the study or to withdraw their consent at any time without reprisal. Clinical partners carrying out the REBECCA studies will collect prospective participants’ consents in the form of a paper document, consisting of the information letter and a consent form, to be signed once all the details of the planned study protocols have been clearly communicated to the subject concerned. 4.3.2 Research Ethics Committees’ approvals Before any of the REBECCA studies begin, appropriate research protocols will be submitted for consideration, comment, guidance and approval to the national/regional research ethics committees. 34 REBECCA will gain access to the required retrospective data after the appropriate ethical permissions, which will describe the precise data structure and data handling, are obtained. Also, a final report to the relevant ethics committees, containing the summary of findings and conclusions, will be also submitted upon the completion of the studies. 4.4 AI and causal modelling 4.4.1 Ethics requirements for Trustworthy AI Artificial intelligence (AI) refers to systems that show intelligent behaviour. By analysing their environment these systems can perform various tasks with some degree of autonomy to achieve specific goals. In essence, artificial intelligence systems act in the physical or digital dimension by perceiving their environment through data acquisition, interpreting the collected structured or unstructured data, reasoning on the knowledge, or processing the information derived from this data and deciding the best action(s) to take to achieve the specific goal that was given to the system. Machine learning (i.e. a discipline that teaches machines using data), is one of the technical mechanisms that underpins and facilitates AI. REBECCA will use causal modelling methodologies, combined with deep learning algorithms to study the interactions of comorbidities and lifestyle parameters in breast cancer patients. Specifically, REBECCA will develop graph-based models of the causal dependencies between clinical and lifestyle parameters in the breast cancer domain 34 Sweden: The National Swedish Ethical Review Authority; Norway: The West Norwegian Regional Committee for Medical and Health Research Ethics; Spain: The Ethical Committee for Research with Medicines of the General University Hospital of Valencia
H2020SC1-DTH-12-2020 D1.3 70|79 and will use deep learning and variational methods for modelling latent confounding factors from observational data (such as RWD). It will implement an innovative data management and analysis platform with capabilities for federated learning which supports training machine learning and causal models across distributed health data repositories. It will also develop signal processing and machine learning algorithms for comprehensive patient monitoring using RWD. In February 2020, European Commission released “A White Paper on Artificial Intelligence – a European approach to excellence and trust” 35 , the purpose of which was discuss policy options for how to achieve two goals: to promote the uptake of AI and to address the risks with certain uses of AI. The paper proposes that trust and excellence are key elements of future data regulation policy in Europe. In regards to creating an ecosystem of trust, the white paper refers to the Ethics Guidelines, and in particular the seven key requirements for AI. The European Commission identifies two categories of risks in AI: • risks for fundamental rights (including data protection, due to the large amounts of data being processed, and non-discrimination, due to bias within the AI) • risks for safety and the effective functioning of the liability regime. The High-Level Expert Group on Artificial Intelligence provided the AI Ethics Guidelines to the Commission in March 2019. The AI Ethics Guidelines forms part of a vision embracing a human-centric approach to AI, which will enable Europe to become a globally leading innovator in ethical, secure and cutting-edge AI. It strives to facilitate and enable “Trustworthy AI made in Europe” that will enhance the wellbeing of European citizens. The guidance is centred around the concept of “trustworthy AI”. Trustworthiness is defined “a prerequisite for people and societies to develop, deploy and use AI systems”. Without AI systems being trustworthy, unwanted consequences may arise and prevent the realization of the social and economic benefits of AI. The guidance puts forward 7 requirements for trustworthy AI: • Human agency and oversight AI systems should support human autonomy and decision-making, as prescribed by the principle of respect for human autonomy. AI systems should 35 https://ec.europa.eu/info/sites/default/files/commission-white-paper-artificial-intelligencefeb2020_en.pdf
H2020SC1-DTH-12-2020 D1.3 71|79 support the user’s agency, foster fundamental rights and allow for human oversight. • Technical robustness and safety AI systems should be developed with a preventive approach to risks and minimizing or preventing harm. They should be secure and resilient to attacks, should have safeguards that enable a fallback plan in case of problems and should produce accurate, reproducible and reliable results. • Privacy and data governance AI systems should guarantee privacy and data protection throughout a system’s entire lifecycle. Adequate privacy protection also necessitates data governance that covers the quality and integrity of the data used as well as data access protocols. • Transparency AI systems should be transparent, in a way that data sets and processes are traceable and explainable. Moreover, people need to be informed when they are interacting with an AI system. • Diversity, non-discrimination and fairness AI systems should ensure inclusion and diversity throughout the entire system’s life cycle. It should avoid unfair biases which could lead to discrimination and should be designed in an accessible and universal way. • Environmental and societal well-being AI systems should be sustainable and ecologically responsible to the greatest extent possible. They should be used to benefit all human beings, including future generations
H2020SC1-DTH-12-2020 D1.3 72|79 • Accountability AI systems should be accountable. This necessitates that mechanisms be put in place to ensure responsibility and accountability for AI systems and their outcomes, both before and after their development, deployment and use. These requirements should be continuously evaluated and addressed throughout the AI system’s lifecycle. When designing, developing and using artificial intelligence, REBECCA partners should assess the impact of this artificial intelligence and machine learning algorithms on human rights, particularly the right to the protection of personal data, as well as human dignity and other fundamental values. This assessment should be part of a broader data protection impact assessment and should take into account the requirements set by the High-Level Expert Group on Artificial Intelligence. To this end, the ‘Trustworthy AI Assessment List’ incorporated in the guidance document of this group can be used. 4.4.2 Data-driven discrimination and data bias When data and algorithms are used for decision making purposes, there is potential for discrimination against individuals. The Council of Europe “Study on discrimination, artificial intelligence and algorithmic decision-making” 36 points out that AI systems are often “black boxes”: it is often unclear why a system makes a certain decision. Because of the opaqueness of such decisions, it is difficult for people to assess whether they were discriminated against on the basis of, for instance, their age or gender or racial origin. AI-driven decision-making can lead to discrimination in several ways. For example, AI decision-making can have discriminatory results if the system uses biased training data. If data is poorly labelled, inaccurate, incomplete or if it reflects human prejudices, then the AI model will reproduce those same biases. Similarly, by selecting only certain features that an AI system uses for prediction, the organization might introduce bias against certain groups. The European Union Agency for Fundamental Rights Study “#BigData: Discrimination in data-supported decision making” 37 , offers the following solutions towards fundamental rights compliance in the development and use of data-driven AI, which should be followed by REBECCA: 36 https://rm.coe.int/discrimination-artificial-intelligence-and-algorithmic-decisionmaking/1680925d73 37 https://fra.europa.eu/en/publication/2018/bigdata-discrimination-data-supported-decision-making p.11;
H2020SC1-DTH-12-2020 D1.3 73|79 • being as transparent as possible about how algorithms are built and used; • conducting fundamental rights impact assessments which include among others, an assessment of the potential for discrimination in relation to different grounds – such as gender, age, ethnic origin, religion and sexual or political orientation; • checking the quality of data (algorithms used in machine learning systems and artificial intelligence (AI) can only be as good as the data on which they learn); • making sure the way the algorithm was built and operates may be meaningfully explained.