The GDPR and Upcoming mhealth Code of Conduct Dr Etain Quigley Postdoctoral Research Fellow (ARCH, UCD)
EU General Data Protection Regulation (May 2018) First major reform in 20 years 25 th May 2018 no transition time! Changes to the Data Protection landscape and companies need to be aware of their new obligations under the Regulation Current Regulation will be repealed
Todays Discussion Researchers and ethicists always concerned with this area particularly important in the technical age GDPR is an 88 page document today is a taster but not exhaustive! Helicopter overview of GDPR and a more detailed discussion on the mhealth Code of Conduct 3
Key Definitions Data controller: natural or legal person, public authority, agency or other body who alone or jointly determines the purpose and means of processing personal data Personal data: information relating to an identified or identifiable natural person (data subject) Data processor: natural or legal person, public authority, agency or other body who processes personal data on behalf of the controller 4
General Data Protection Regulation: Key Changes 1. Accountability 2. Consent 3. Data Portability 4. Data Process Contracts 5. Mandatory Breach Notification 6. Data Protection Impact Assessment 7. Mandatory Appointment of Data Protection Officers 8. Right to Compensation and Liability 9. Financial Penalties
Accountability Will require evidence of compliance: Protocol Document compliance journey E.g how will you deal with a breach How will you provide the user with requests for information Accountability = evidential trail of compliance, no longer good enough to be compliant must now show compliance
Consent Implicit consent no longer satisfactory Now require explicit consent this may be in the form of a signature or a notice if you continue with usage you consent. Opt out not an option anymore Must be able to withdraw consent as easily as providing it cannot be hidden amongst other text etc. Withdrawal of consent does not effect the lawfulness of processing based on consent prior to withdrawal
Data Portability New! Aim: facilitate subject moving swiftly from one service provider to another E.g Spotify ITunes Must inform subject of this right Access to dashboard select what data they wish to move? Cannot pass on cost to subject
Data Processing When processing data on behalf of a controller must have contract in place No longer sufficient to have a generic contract must be specific to the relationship E.g. Only process in accordance with the data controllers instruction Outline of security measures Outline what will happen at the end of processing More detailed and specific contract now required
Mandatory Reporting of Breach Current reporting (lack of obligation) will cease Where there is a risk and high risk (neither definition has been defined and will likely be tested at some point) must be reported Large majority of data breaches will require reporting No minimum threshold - theoretically 1 may require reporting (currently under 100 inform self and not necessary to report) Health Data: sensitive personal data requires reporting Data controller responsible for reporting to Commissioner
Data Impact Assessment Central to incorporation Privacy by Design Conduct risk assessment (document) Level of intrusion on subject by your service/product must be proportionate Risk mitigation (document) How to mitigate risk? Who is responsible for it?
Mandatory Appointment of Data Protection Officer Controller or Processor must designate a Data Protection Officer where: The processing is carried out by a public authority or body The core activities of the Controller or Processor operations which, because of their nature, scope or their purpose require regular and systematic (regular and systematic not defined but WP 29 suggest such activities as profiling and scoring for risk assessment will require testing) monitoring of data subjects on a large scale (large scale not defined but WP 29 suggest bank/insurance company will require testing) or The core activities of the Controller or Processor consist of processing on a large scale of sensitive personal data (DPO can be appointed to a number of undertakings)
Right to Compensation and Liability Recovery for distress new Currently Ireland does not provide for recovery for distress. Requirement to show loss Collins v FBD [2013] IEHC 137
Financial Penalties Two tier structure: 10m or 2% of global turnover whichever is greater 20m or 4% of global turnover whichever is greater The administrative sanction shall be in each individual case effective, proportionate and dissuasive The supervisory body shall impose a fine up to to anyone who intentionally or negligently
First Steps in Getting Ready Catalogue what type of data you collect Outline why collecting the above data Outline use of data Protocol - record how data is being collected, shared and being sent to others Protocol how will you tell subjects how their data will be used? Protocol - conduct a risk assessment Protocol - risk mitigation Develop templates for subject access response (how will you deal with access requests?) access portals/pathways? Review breach response protocol compliant? Privacy by design central component
What Does Privacy by Design Look Like? Embed privacy into design Full lifecycle protection Privacy as default setting PBD Proactive to prevent breach rather than reacting to it User centric approach Transparenc y
What Does Compliant By Design Look Like? Evidence based reporting (audits) Authorisati on work flows (transfer) Map data CBD Risk profile of data Data protection impact assessme nt Data retention schedules Subject access protocol Encrypt/ anon
mhealth Mobile health applications ubiquitous Beneficial in terms of support and selfmanagement Data potentially highly sensitive Design must ensure privacy of user optimally protected How do users know the various applications on offer meet their privacy concerns?
Purpose of Code Foster trust amongst mhealth application users Ensure users are making informed decisions related to their engagement with the application. The Code aims to facilitate data protection compliance Promote good practice Provide app developers with a Code which they can publically declare their compliance with
Purpose of the Code The Privacy Code of Conduct on mobile health (mhealth) apps, facilitated by the European Commission, will provide a competitive advantage for those who are signatory to it, and help to promote trust among users of mhealth apps. European Commission 20
What is Personal Data? Information on the user (name, address, contact information) Device identifiers Location data Any other information related to an identified or identifiable natural person
What is Data Concerning Health? Any personal data related to the physical or mental health of an individual Including: The provision of health care services Information about health status Personal information that has a clear and close link with the description of the health status of a person (e.g. raw sensor data that can draw conclusions about health status) Lifestyle data (raw data on individuals habits not inherently relate to health may not be considered health data) however, if it has a clear and close link to persons health status it may be health data!
Examples An application that allows the user to track their medication adherence in line with medical advice prescribed by their doctor classed as processing data related to health An application that tracks a persons footsteps solely to measure a persons activity and does not store the data to build an profile to evaluate the persons physical fitness or health condition is classed as processing data related to lifestyle Code applies to the former data protection law applies to both
What is Processing of Data? Any operation or set of operations performed on personal data (or sets of personal data) automated or otherwise such as, collecting, organising, recording, structuring, storing, adaption/alteration, retrieval, consultation, use, disclosure by transmission, dissemination (making available), alignment/combination, restriction, erasure or destruction. Just about anything to do with data!
Additional Legal Obligations (GDPR) Biometrics Data Personal data resulting from specific technical processing related to physical, psychological or behavioural characteristics of an individual which allows or confirms the unique identification of the individual such as facial images or fingerprint data Genetic Data Personal data related to the genetic characteristics of an individual that have been inherited or acquired, which give unique information about the physiology or the health of that individual resulting from the analysis of a biological sample from the person in question
How will the Code Operate? In line with the GDPR: mhealth Ecosystem General Assembly: stakeholders (app developers, data protection community, industry associations, and/or patient associations) meet at least twice a year to discuss the maintenance, interpretation and evolution of the Code. Consultative organ which supervises the Code but has no day-to-day input. Governance Board: Decision making powers (app developers, app developer associations and industry associations). Take decisions on the maintenance, interpretation and evolution of the Code and on the membership of the Assembly. Monitoring body: Operational tasks such as enforcement of the Code, management of the Code specific website, facilitate communication with the public, monitor compliance in line with the Data Protection Regulation
Compliance with the Code: Declaration, Monitoring and Enforcement If a developer wishes to declare adherence to the code must apply to the Monitoring Body Application process submit a privacy impact assessment and a selfdeclaration of compliance If accepted application will be identified on a centralised public register maintained by the Monitoring Body Voluntary third party audit to receive certification of their compliance with the Code at app developers own expense (audit can be completed by any organisation mandated by the Governance Board) Monitoring Body will randomly select a sample for re-checking of their continued adherence Public can lodge complaints the Monitoring Body will inform national data protection agencies of complaints received
Compliance with the Code: Declaration, Monitoring and Enforcement Once an application is placed on the Codes registry the developer may apply a trust mark made available - under the terms and conditions set out by the Governance Board. Breach the Monitoring Body will mark the application as having failed the adherence requirements. The application developer will be forbidden to make any reference to the Code or display the trust mark. 28
Practical Guidelines for Application Developers
1. Obtaining consent Consent must be sought through user friendly text - information cannot be couched in complex/long legal text Upon instillation Before data processing Health data explicit. Not sufficient that the user does not object after reading your intention You must be able to demonstrate consent Consent at various stages considered good practice Easy to withdraw including by choosing to delete their data (locally or remotely or both) or by uninstalling the app If user withdraws consent delete users data from your system unless there was prior agreement for retention
2. Main principles that must be considered A) Purpose limitation (collect and process data): Specific and legitimate purposes Purpose must be clearly defined Must bear a meaningful relationship to the functionality of the app E.g: An application that monitors blood sugar levels to assist patients with diabetes dispensing medication cannot sell this information to vendors of medication If data being used for other purpose must be completely anonymised (very difficult to do under GDPR) or informed and explicit consent of the user must be obtained
2. Main principles that must be considered B) Data minimisation: Consider what data is strictly necessary for app to provide functionality Cannot collect more data and keep for longer than is necessary (Redundant, Obsolete and Trivial) E.g: Do not collect and store DOB when age range is sufficient
2. Main principles that must be considered C) Transparency: Provide users with clear description of purpose for which data will be processed They must be able to understand what personal data is collected and why Language must be understandable
2. Main principles that must be considered D) Privacy by Design and Privacy by Default Privacy implications considered at each step of development Make it easy to consent/withdraw consent at various stages of the app use Least invasive privacy choice E.g. if the app allows users to share their data, by default this option should be off. Active consent required.
2. Main principles that must be considered E) Data Subject Rights: Right to access data Right to obtain corrections Right to object to any further processing Users should be easily able to find this and other rights based information
3) Information to provide before use Essential scope of information about data processing must be available prior to installation Clear description of how their data will be processed Identify yourself clearly and unambiguously Provide your contact information so user can ask questions and/or exercise their rights Informed if data concerning health will be stored in any other location other than the users device This information must be easy to find at and after installation Layered approach to information satisfactory first layer = most crucial information; second layer= full privacy policy
4) Keeping the data No longer than necessary for the functionalities of the app unless required or permitted by law Clear criteria must be set out related to data deletion After a certain period of time of non use of the app data should be considered expired and must be deleted even if user takes no positive action to do this Instead of deletion you may decide to irreversibly anonymise the data (this is challenging to do in manner compliant with (GDPR). If any possibility of combining with other data and making it re-identifiable it remains personal data under the Regulation
5) Security measures Required you to identify any data protection risks Take steps to mitigate these risks On-going process to ensure privacy is continually protected Conduct Privacy Impact Assessment
What Does a Privacy Impact Assessment Look Like? Requires answers to questions such as (examples required): What kind of data is being collected? Explain how this data is required for functionality For which purposes is the data being processed (functionality, technical purposes, big data analysis and monetisation)? How have you obtained consent? Have you used accessible language? Likely to be used by minors? If so, what safeguards are in place? Have you designated anyone to answer privacy related questions? If so, have you informed the user on how they can contact them? Was the app developed in conjunction with a HCP?
What Does a Privacy Impact Assessment Look Like? (cont.) Has Privacy by Design has been embedded in the design? Has data minimisation been embedded into the design? Is the data identifiable? Have appropriate authorisation mechanisms been built in? Has all information that is appropriate for encryption been encrypted? Has the app been developed using known guidelines and secure development software? Are regular security audits required? Has the app been piloted? Can incidents that affect remotely stored data be identified and addressed? Are appropriate contractual agreements in place for data transferability 40
6) Advertisements in an mhealth applications Permissible once clearly authorised by the user prior to installation Contextual advertising can be opt-out E.g. app monitoring blood sugar advertising re blood sugar but which has no data on the user and is therefore not specific to the user Profiled advertising must be opt-in E.g. app monitoring blood sugar advertising re blood sugar level data specifically related to the user must be opt-in Acceptance of advertising can be a condition. Thus non acceptance = removal of app from users device
7) Personal data for secondary use (e.g. big data) Any processing of personal data must be compatible with purpose Data for scientific and historical research or statistical purposes is still considered compatible if done in accordance with EU level rules (when GDPR comes in each country will have to derogate for this wait to see how Ireland deals with this issue) Big data required to ask for consent or completely anonymise
8) Third party for processing Must inform the user Enter into binding agreement with the processor specifying what purpose they may process data (this must be aligned with purpose described to user) Agreement must contain sufficient security obligations security may not be weakened by passing to third party Liability of the third party must be clear You are responsible for selecting an appropriate third party you may be liable towards any incidents
9) Transferring the gathered data User can store data on own phone and if you have obtained consent you can store on own server Transfer to third party must meet prior criteria and must be within EU/EEA If you want to transfer outside of EU/EEA: must have legal guarantees in place to ensure transfer is permitted under EU law Country covered by adequacy decision of the European Commission Appropriate contractual agreement under the European Commission s Model of Contracts or the Binding Corporate Rules Obtained unambiguous consent not for repeated transfers
10) Personal data breach Prepare a response to a breach before it occurs Is the breach related to personal data? Notify breach without undue delay where feasible no later than 72 hours after becoming aware of breach Notify affected individuals without undue delay Detail the breach, potential consequences and measures taken
11) Data gathered from children Most restrictive data processing approach Respect data minimisation and purpose minimisation Refrain, where possible, from collecting data through children in relation to their relatives and/or friends Parental involvement is crucial Must undertake reasonable efforts to verify that consent/authorisation is given by a person with parental responsibility
How can ARCH help? This is not new to us! Ethics and data protection has always been central to all our work and is built into all evaluations (early and late stage projects) ARCH has extensive experience in the co-design space This expertise will be available to ARCH members so talk with us early on/prior to prototype development 47
Thank You! etain.quigley@ucd.ie 01 7165410 48