WS09

WORKSHOP

SUMMARY

WORKSHOP • 24 APRIL 2017

HEALTH AND WELL-BEING APPS- PROBLEMATIC LEGAL ISSUES

 

by Lina Jasmontaite, Brussels Privacy Hub, LSTS, VUB

SUMMARY

 

On 24 April 2017, the Brussels Privacy Hub organized a workshop addressing data protection issues in the health app industry. The workshop was part of the GDPR Workshop series, which is providing guidance and information in preparation for the implementation of the General Data Protection Regulation (GDPR).

 

The workshop focused on legal issues arising from the use of apps that perform tasks of a medical nature.. As cell phones are becoming cheaper and more accessible, the field of apps is exploding. It is important to note the range of differences that software can offer within this diverse eco-system. Some can collect materials, others will generally These questions are important when considering the type of legislation that will apply. Nicolas Carbonelle from Bird & Bird discussed the regulatory framework for medical devices (MDR). Paul Quinn (VUB/LSTS) laid down the basics and commented on the various aspects of the GDPR such as consent, security and use of special data.

 

Medical Device Regulation: The EU Directive on Medical Devices (MDD) is from 93’ but is this month replaced by the Medical Device Regulation (MDR). Similarly, the directive on in vitro diagnostic medical devices (IVD) is replaced by the regulation on in vitro medical devices (IVDR). The main aspects of the directives remain the same. It still has trouble keeping up with the evolutions of the app market but the definitions have become clearer and . The products need to comply with safety protocols before they are placed on the market. The manufacturer is responsible for assessing the app and complying with the directives. There is no system of prior approval by the regulatory bodies.

 

Qualifying a medical device: One of the major issues discussed concerned the way medical devices are qualified. Software can only be considered a medical device if the manufacturer has stated this to be the intended use. This has effectively created a loophole where an app developer can market their product as anything other than a medical device so it is not covered by the directives. There are other exceptions and grey areas. Standalone software can be broken down into modules that are assessed separately depending on their function. The directive will also cover any software that interacts with other medical devices. For example, the app that manages and displays information about the glucose meter that is connected to your body will automatically be categorized as a medical device. Participants noted that the directive falls short when it concerns any decisions made by AI. It was concluded that if the app is processing an individual’s medical information and then providing personalized advice or feedback, it will always fall within the MDR.

 

Changes brought by the GDPR: Apps are divided into 3 types. They can refrain from processing data (type 1), they can process personal data (type 2) or they can process sensitive medical data (type 3). Type 2 and 3 will automatically require application of the data protection framework. Even though they do not process personal data, type 1 apps can still be subject to other frameworks such as the privacy directive. It is important to note the type of data that is collected. Modern apps use a range of different elements from the platform to combine and analyze. Some data might not seem to be personal data but can become so after being combined with other sources. Article 9(4) of the GDPR also grants member states the option of enacting further measures in national law when medical data is concerned. Concretely this means that app developers will still see many differences in the legal status of health data in the different European states, further complicating their work. The participants agreed that the profile of the app developer might make it difficult to comply with all the directives. To understand the risks and qualifications you need a high level of both legal and technical knowledge, something that smaller developers might not always possess. The same can be said for the security aspect and data protection by design. It is questionable if the developers with fewer resources will have the required knowledge of data protection while at the same time managing the constant upkeep required to keep an app secure.

 

Legal base: Consent is the most likely legal basis used for apps. The wording regarding consent has long been a topic of discussion with the different stakeholders involved in the GDPR. Now that the technological framework has changed, the difference between explicit and implied consent has faded somewhat. General consent in the form of pre-ticked boxes is not suitable. The working party advises having a granular scheme for each separate item that requires consent. This will also help keep everyone informed in a clear and concise manner. Changes in the business model will also require re-seeking consent. The data processing must remain well defined and limited in its purpose. Aspiring developers looking for concrete examples can use the code of conduct drafted by the European Commission regarding privacy for mobile health apps (mHealth code of conduct). Although it is not binding, it covers many of the questions we have discussed in this workshop.

 

 

 

 

Connect with us

 

Brussels Privacy Hub

Law Science Technology & Society (LSTS)

Vrije Universiteit Brussel

Pleinlaan 2 • 1050 Brussels

Belgium

info@brusselsprivacyhub.org

@pivacyhub_bru

Stay informed

 

Keep up to date of our activities and developments. Sign up to our newsletter:

My Newsletter

Copyright © Brussels Privacy Hub