Philips HealthWorks on GDPR & healthcare @ Health 2.0 Amsterdam, June 2018
•Download as PPTX, PDF•
1 like•107 views
Rob van Rij and Floor Borgonjen, Philips HealthWorks: "Practical steps and considerations in applying Privacy by Design principles for MyHealthJourney, a personal health record in development." https://www.healthworks.philips.com/ This is a presentation from a Health 2.0 Amsterdam "GDPR & healthcare: towards harvesting health from our data" event that took place on the 18th of June 2018 https://www.meetup.com/Health-2-0-Amsterdam/events/250870609/
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Philips HealthWorks on GDPR & healthcare @ Health 2.0 Amsterdam, June 2018
- 1. June 2018 MyHealthJourney (PHR) Practical steps & considerations applying GDPR principles Floor Borgonjen & Rob van Rij Philips MyHealthJourney
- 2. GDPR principles and rights Data subject Rights – Right of access by the data subject (art. 15) – Right to rectification (art. 16) – Right to erasure (‘right to be forgotten’) (art. 17) – Right to restriction of processing (art. 18) – Notification obligation (art. 19) – Right to data portability (art. 20) – Data protection by design and by default (art. 25) – Principles relating to processing of personal data (art. 5) • ‘lawfulness, fairness and transparency’ • ‘purpose limitation’ • ‘data minimization’ • ‘accuracy’ • ‘storage limitation’ • ‘integrity and confidentiality’ – Conditions for Consent (art. 7) 2 Confidential June 2018
- 3. Right of Access by Data Subject (Art. 15) • Users can manage and control which data to copy in their PHR • We only provide access to data for connected sources 3 Right to rectification (art. 16) • MHJ contains copies of external sources • Rectification to be requested at the source • MHJ source data can be rectified through self service
- 4. Conditions for Consent (art. 7) • Provide simple and clear consent information • User must give explicit consent for every data request – Data set – Time of consent validity – Who/Process that will use the data – Purpose • Withdraw consent at anytime as simple as giving it • Logging and auditability of consent activities 4
- 5. Principles relating to processing of personal data (art. 5) • ‘lawfulness, fairness and transparency’ • ‘purpose limitation’ • ‘data minimization’ • ‘accuracy’ • ‘storage limitation’ • ‘integrity and confidentiality’ 5
- 6. Right to erasure (‘right to be forgotten’) (art. 17) • Self service to erase data • Self service to request account deletion and all contained data 6 Right to data portability (art. 20) • Create download file in pdf and/or machine readable format • Option before executing a erasure request
- 7. Data protection by design and by default (art. 25) • End-2-End Encryption • Access to PHR denied by default • No default data (empty PHR) • Monitoring, detect and prevent 7
- 8. Service Organization GDPR impact • How do you validate user identities? • How do you link identities to the correct account? • Automate/self service GDPR rights where possible • Escalation processes for Data breaches & Security issues • Self registration 8
Editor's Notes
- Right of Access by Data Subject: The fundamental rights on access to your data is enabled via self service where the user can select from the available external sources and define which data elements he wants to copy into his PHR. For connected institutions (Hospitals/care networks/etc…) this is an extremely cost effective way to give access to user’s data. They don’t need to handle the request themselves and save resources and time by giving user digital copies of their data. The user first has to connect to the external source via authentication using the appropriate credentials (ie. userID/password, DigID, IDN) After successful authentication and authorization the selected data will be copied into his PHR Right to rectification: When user have access to their data they are able to detect inconsistencies and error in their data. For this right they will need to contact the source of the data for rectification. MHJ only has a copy and any change required in the copy of the data should be updated at the source.
- Conditions for Consent: We have implemented a consent mechanism that is simple and easy to understand. Because withdraw consent must be as simple as giving it, we use the same interface for doing so. Each consent contains the data set, time for which the consent is given and for who or which process and what the purpose is of the consent. Based on that information the user can make an informed decision if he wants to give consent or not. At any time the user is able to withdraw the consent without further explanation. Very important part of the consent functionality is that we log the details for traceability and auditing.
- Principles relating to processing of personal data: These key principles are important and key for our Service proposition. ‘lawfulness, fairness and transparency’ Simple and clear wording in the privacy and terms of service information For all functionality clear and transparent information User owns the data and his account, at all times he is in full control ‘purpose limitation’ Purpose of functionality or data usage can never be changed without a new explicit consent ‘data minimization’ For the data collection we collect everything the user wants us too For processing we use only data that is absolutely necessary ‘accuracy’ Where the data source is MHJ we provide self service functionality so users can if needed correct the data. In case of copies from external sources we provide the information of the source so users can contact these sources for correction ‘storage limitation’ Data is stored as long as the users asks us too with a process that checks on a yearly bases the activity of the user and checks if he still wants to keep his account/data ‘integrity and confidentiality’ We use strong passwords and 2FA to minimize the risk of fraudulent access via stolen credentials DigID to be used for linking user accounts to the correct external data Integrity of data can be secured by using blockchain technology (future implementation) Data is encrypted at REST and in TRANSIT
- Right to erasure (‘right to be forgotten’) : User through self service can erase data, portions of data or their complete account. If users erase data that has been copied from an external source, we let them know that they are going to erase a copy of data that will still exist in the respective external source. When they also or only want to erase the data in the external source we tell them to request this at the external source. After erasure that data will be completely deleted from the system without the option to recover the data!!!! Right to data portability: Before executing any data or account deletion request we provide the user with the option to create a download of his data/account. The download file will be in pdf and or industry standard machine readable format.
- End-2-End Encryption: All data encrypted at REST and in TRANSIT: With all data we mean user data, log data, audit data. Whenever there is no reason todo so, encryption should be the default. Access to PHR denied by default: Only the user has access to his PHR & data No default data (empty PHR): By default the PHR of the user is empty and decides what data he wants to copy/store in his PHR Monitoring and detect: There is a clear expected behavior from a user point of view which we can monitor and detect easily anomalies. Unexpected behavior
- How do you validate user identities? Validating users manually is cumbersome and error prone. You have to request a copy of an accepted ID and verify it’s sent by the owner What must be kept How do you link identities to the correct account? Validating a user identity is one thing but how do you validate that the user is also the owner of the account? Automate/self service GDPR rights where possible: Users executing their rights can have a huge impact on the support organization. Therefore automation and embedding these rights in a self service will help to avoid massive load on the support organization Escalation processes for Data breaches & Security issues: Escalation processes to adequately handle data breach and security incidents is inevitable. Especially when dealing with the most sensitive data you can never react quick enough when this happens. When a data breach happens it can have a devastating impact on brand and trust of your company let alone the financial impact. Self registration: Because we will have citizens that will register themselves, we need to be able to support an automated and secure registration process. When scaling and having 100s-1000s of users a day registering it is impossible to support this manually.