Approaches to managing GDPR and Consent in healthcare applications

GDPR is now in effect and gives Data Subjects more rights to their data both in the European Union (EU) and for citizens of the EU which affects firms inside and outside the EU. A key provision in the law is transparency and consent to use an individual’s data for specific purposes.
Lately, almost all applications recently between April and May of 2018 had an update to their terms of use, particularly if EU individuals can use the application or website. The user must perform a positive and confirming action to give consent.
For healthcare, particularly personal health and wellbeing mobile apps, a transparent and clear consent provided by the person using the application is required. I think there are three main types of presentation for consent:
- A single privacy and terms of use statement, with a separate consent agreement with an “I agree” at the end of the terms.
- A single privacy terms of use statement, where each purpose for data use is stated in plain language, with a check-box for each purpose.
- A progressive approach which extends the initial terms of use, where the user consents to each purpose as they navigate or access various features of the app.
Each has distinct implications on usability, the type of application and have their merit based on the user base. However, for healthcare this data may become sensitive information, and how it is used to make decisions, automated or manual, requires more scrutiny and control.
To capture and store this consent an option is to utilize Fast Healthcare Interoperability Resources (FHIR) which is a Health Level Seven (HL7) based specification.
Option 1: Single governing consent.
For option one, it’s simply attaching and associating a Contract resource to represent the consent with a Patient resource.

You can utilize one of the purpose codes for action reason, for example outcome measure or quality improvement where the reason is for measuring the outcome of a product or improving the quality of a product respectively. A selection of purpose codes can be found here: http://hl7.org/fhir/DSTU2/v3/PurposeOfUse/index.html.
Option 2: Multiple consent for each individual purpose.

Here we see multiple contracts being used to represent a consent for a specific purpose for the Data Subject’s data, including an option for Clinical Trial Research when enrolled. The association is directly associated with the patient, allowing for easy navigation across consents and the ability to enforce use of the Data Subject’s data set by checking the purpose among each consent.
Option 3: A single governing consent, with progressive child consent for different purposes.

This model allows for some flexibility although it introduces some complexity in managing the set of consents. The flexibility is both at the mobile application or application level, where the user can choose to restrict different purposes as they are progressively revealed. If a user does not navigate or use the predicting hypoglycemia feature of the application, it can be turned on when needed and the predictive services activated on the backend system for this patient. It allows an implementation of the services within the backend system to check for an existing consent for patient safety before performing such services.
Conclusion:
This article so far covers the creation and association of consent using FHIR based resources to cover the GDPR. The lightweight payloads, REST APIs and coverage of terms, text and duration for consent helps with maintaining or at least having the ability to provide and prove consent has been captured for the individual’s data. You can cover purpose for use by utilizing purpose codes, multiple consents and the human readable contract language using the text field in an individual contract instance.
Some of these features can be found in the IBM Watson Platform for Health GxP which contains a FHIR Data Ingestion pipeline and Consent Management based on FHIR resources. The next logical step is consent enforcement, ensuring that people, users, programs and systems that may access this data only do so for the purposes granted by the Data Subject by checking it against each consent or contract representation in the system.
An open source option for a FHIR Data Store Server based on DSTU2 specification is also available by the University Health Network which allows you to experiment with FHIR API. See the JSON payload representation and the associations below using the UHN FHIR Server. It also includes example FHIR RESTful service calls for the creation of the patient resource and associated consent.
Links:
GDPR: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/
GDPR and Consent: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/consent/what-is-valid-consent/
FHIR: http://www.fhir.org/
Watson Platform for Health GxP: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=gpateam&supplier=897&letternum=ENUS218-082
University Health Network FHIR Server: http://hapi.fhir.org/home?serverId=hapi_dev&pretty=true
IBM Cybersecurity Study on GDPR: http://www-935.ibm.com/services/us/gbs/thoughtleadership/gdpr/
Corville Allen, Technologist and Inventor.
