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.
Copyright © Brussels Privacy Hub