The European Article 29 Working Party has just released its opinion 02-2013 on apps on smart devices. This detailed opinion provides very useful and detailed guidance for companies developing and distributing healthcare apps in the EU, as well as manufacturers of mobile operating systems and devices that run apps. Finally, there is also guidance for third parties.
Applies to basically all standalone software, not only apps
Many medical technology companies struggle with the application of EU privacy requirements to medical apps and other software, so I though it would be a good idea to discuss this guidance document. Even though the document says it applies to apps, I think it provides very useful guidance for standalone software in general.
EU-US harmonisation
Where the EU and US authorities do not seem to get along very well at all on regulation of medical devices (which healthcare apps may well qualify as if they are a medical device in the form of standalone software, see here, here and here) and with the US regulation of healthcare apps still not boiling down to something definite, this guidance documents refers a lot to US initiatives in this field and explicitly concurs with them. The guidance explicitly and approvingly refers to the recent FTC staff reports Mobile Privacy Disclosures, Mobile Apps for Kids reports (here and here) and the Attorney general of the Californian Department of Justice’s report. This is good news and will facilitate trans-Atlantic app development.
Risks regulated
The guidance document provides a lot of detail on the risks the EU authorities want to regulate, the EU data protection regulatory logic that they apply and finally gives a nice and convenient summary of obligations and best practices at the end. The document further ties together the acquis in data protection law in different fields, such as cloud computing, children and consent, together with a focus on mobile apps.
What are the main risks identified in the guidance?
- lack of transparency – many apps are not transparent about what they actually do with the data they collect, and a large part do not even provide users with information in a privacy policy.
- lack of free and informed consent – consent does not meet user requirements (users want a more granular choice) and – closely connected to transparency – must understand what an app does before they can give valid consent.
- poor security measures – obviously this is a risk: if there is a data breach, this may lead to unauthorized processing of data, which, in case of healthcare apps, will mostly concern sensitive personal data.
- disregard for the principle of purpose limitation – purpose limitation is one of the cornerstones of EU data protection law: a controller should not process more personal data than necessary for the purpose defined and the period necessary. Apps are generally very bad at precise purpose limitation, suffer from scope creep or ‘elastic purpose’ in this respect and are not transparent about the duration of processing.
Actors regulated
The document goes on to explain the rules that apply for the four categories of regulated actors: app developers, app stores, OS / device manufacturers and third parties. There is a good discussion of ‘privacy by design’ and ‘privacy by default’ requirements that look to become a lot stricter under the GDPR currently in the legislative pipeline. Both of these requirements already apply to a degree under directive 95/46 (Data Protection Directive) and the often overlooked directive 2002/58 (ePrivacy directive). The ePrivacy directive – which most companies will know from its cookie rules – is especially important for those who plan to store and access personal data in the user’s own hardware – consent and information requirements apply also in that case. The document also warns that the ePrivacy directive data breach requirements currently only apply to network services providers, but will most likely be extended to all data controllers under the proposed GDPR.
Where the apps concerned are also medical devices, the actors regulated under data protection law will overlap with the MAID actors regulated under the medical devices rules to an extent. Generally speaking, the developer is manufacturer, the app store is importer / distributor, the OS / device manufacturer may be accessory or medical device manufacturer and the third parties can basically have any role. From my work in the sector the distinct impression emerges that although companies may sometimes realise they are manufacturer of an app that is a medical device, there is little understanding of the other roles and how a company may have responsibilities there. For example, all of the app stores (Apple, Google, etc.) should start to prepare for their role as importer / distributor of medical devices.
The obligations/best practices by actor table
I have tried to put the summary of obligations and best practice at the end of the document in a format that can be easily used in practice in the below table, with obligations (“must”) and best practices (“should”) in rows and the actors concerned in columns:
|
|
App developers
|
App stores
|
OS / device manufacturers
|
Third parties
|
| Must |
- Be aware of, and comply with, their obligations as data controllers when they process data from and about users;
- Be aware of, and comply with, their obligations as data controllers when they contract with data processors such as if they outsource the collection and processing of personal data to developers, programmers and for example cloud storage providers;
- Ask for consent before the app starts to retrieve or place information on the device, i.e., before installation of the app. Such consent has to be freely given, specific and informed;
- Ask for granular consent for each type of data the app will access; at least for the categories Location, Contacts, Unique Device Identifier, Identity of the data subject, Identity of the phone, Credit card and payment data, Telephony and SMS, Browsing history, Email, Social networks credentials and Biometrics;
- Be aware that consent does not legitimise excessive or disproportionate data processing;
- Provide well-defined and comprehensible purposes of the data processing in advance to installation of the app, and not change these purposes without renewed consent; provide comprehensive information if the data will be used for third party purposes, such as
advertising or analytics;
- Allow users to revoke their consent and uninstall the app, and delete data where
appropriate;
- Respect the principle of data minimisation and only collect those data that are strictly
necessary to perform the desired functionality;
- Take the necessary organisational and technical measures to ensure the protection of the
personal data they process, at all stages of the design and implementation of the app
(privacy by design), as defined in in section 3.6 of this Opinion;
- Enable app users to exercise their rights of access, rectification, erasure and their right to object to data processing and inform them about the existence of these mechanisms;
- Define a reasonable retention period for data collected with the app and predefine a period of inactivity after which the account will be treated as expired;
- With regard to apps aimed at children: pay attention to the age limit defining children or minors in national legislation, choose the most restrictive data processing approach in full respect of the principles of data minimization and purpose limitation, refrain from processing children’s data for behavioural advertising purposes, either directly or indirectly and refrain from collecting data through the children about their relatives and/or friends.
- Be aware of, and comply with, their obligations as data controllers when they process data from and about users;
- Enforce the information obligation of the app developer, including the types of data the app is able to access and for what purposes, as well as whether the data is shared with third parties;
- Give special attention to apps directed at children to protect against the unlawful processing of their data, and especially enforce the obligation to present the relevant information in a simple manner, in age specific language;
- Provide detailed information on the app submission checks they actually perform, including those aimed to assess privacy and data protection issues.
- Provide a single point of contact for the users of the app;
- Provide a readable, understandable and easily accessible privacy policy, which at a minimum informs users about:
- who they are (identity and contact details),
- what precise categories of personal data the app wants to collect and process,
- why the data processing is necessary (for what precise purposes),
- whether data will be disclosed to third parties (not just a generic but a specific
description to whom the data will be disclosed), and
- what rights users have, in terms of withdrawal of consent and deletion of data.
|
- Be aware of, and comply with, their obligations as data controllers when they process data from and about users;
- Enforce the information obligation of the app developer, including the types of data the app is able to access and for what purposes, as well as whether the data is shared with third parties;
- Give special attention to apps directed at children to protect against the unlawful processing of their data, and especially enforce the obligation to present the relevant information in a simple manner, in age specific language;
- Provide detailed information on the app submission checks they actually perform, including those aimed to assess privacy and data protection issues.
|
- Update their APIs, store rules and user interfaces to offer users sufficient control to exercise valid consent over the data processed by apps;
- Implement consent collection mechanisms in their OS at the first launch of the app or the first time the app attempts to access one of the categories of data that have significant impact on privacy;
- Employ privacy by design principles to prevent secret monitoring of the user;
- Ensure security of processing;
- Ensure (the default settings of) pre-installed apps are compliant with European data
protection law;
- Offer granular access to data, sensors and services, in order to ensure that the app
developer can only access those data that are necessary for his app;
- Provide user-friendly and effective means to avoid being tracked by advertisers and any
other third party. The default settings must be such as to avoid any tracking;
- Ensure the availability of appropriate mechanisms to inform and educate the end user
about what the apps can do and what data they are able to access;
- Ensure that each access to a category of data is reflected in the information of the user
before the app’s installation: the categories presented must be clear and comprehensible;
- Implement a security-friendly environment, with tools to prevent malicious apps from
spreading and allow each functionality to be installed/uninstalled easily.
|
- Be aware of, and comply with, their obligations as data controllers when they process personal data about users;
- Comply with the consent requirement determined in Article 5(3) of the ePrivacy Directive when they read or write data on mobile devices, in cooperation with the app developers and/or app stores, which essentially provide user with the information on the purposes of data processing;
- Not circumvent any mechanism designed to avoid tracking, as it currently often happens with the “Do Not Track” mechanisms implemented in browsers;
- Communications service providers, when they issue branded devices, must ensure the valid consent of users for pre-installed apps and take on board relevant responsibilities when contributing to determining certain features of the device and of the OS, e.g. when limiting the user’s access to certain configuration parameters or filtering fix releases (security and functional ones) provided by the device and OS manufacturers;
- Advertising parties must specifically avoid delivering ads outside the context of the app. Examples are delivering ads by modifying browser settings or placing icons on the mobile desktop. Refrain from the use of unique device or subscriber identifiers for the purpose of tracking;
- Refrain from processing children’s data for behavioural advertising purposes, either directly or indirectly. Apply appropriate security measures. This includes secure transmission and encrypted storage of unique device and app user identifiers and other personal data.
|
| Should |
- Study the relevant guidelines with regard to specific security risks and measures;
- Proactively inform users about personal data breaches along the lines of the requirements
of the ePrivacy Directive;
- Inform users about their proportionality considerations for the types of data collected or
accessed on the device, the retention periods of the data and the applied security measures;
- Develop tools to enable users to customise retention periods for their personal data based on their specific preferences and contexts, rather than offering pre-defined retention terms;
- Include information in their privacy policy dedicated to European users;
- Develop and implement simple but secure online access tools for users, without collecting
additional excessive personal data;
- Together with the OS and device manufacturers and app stores use their creative talent to
develop innovative solutions to adequately inform users on mobile devices, for example through a system of layered information notices combined with meaningful icons.
|
- In collaboration with the OS manufacturer, develop control tools for users, such as symbols representing access to data on and generated by the mobile device;
- Subject all apps to a public reputation mechanism;
- Implement a privacy friendly remote uninstall mechanism;
- Provide feedback channels to users to report privacy and/or security problems;
- Collaborate with app developers to pro-actively inform users about personal data
breaches;
- Warn app developers about the specificities of European law before submitting the
application in Europe, for example about the consent requirement and in case of transfers of personal data to non-EU countries.
|
- Enable users to uninstall apps, and provide a signal (for example through the API) to the app developer to enable deletion of the relevant user data;
- Systematically offer and facilitate regular security updates;
- Ensure that methods and functions allowing access to personal data include features
aiming to implement granular consent requests;
- Actively help develop and facilitate icons alerting users to different data usage by apps;
- Develop clear audit trails into the devices such that end users can clearly see which apps
have been accessing data on their devices and the amounts of outgoing traffic per app, in relation to user-initiated traffic.
|
- Develop and implement simple but secure online access tools for users, without collecting additional excessive personal data;
- Only collect and process data that are consistent with the context where the user provides the data.
|
Overlapping responsibilities
If there is one picture that emerges from this document, it is the overlap of responsibilities of the actors concerned. As I have shown, there is further overlap with regulatory obligations under medical devices regulation. An example is the guidance referring to complaint mechanisms to implement data subjects’ rights, which can double as instruments for post market surveillance in the supply chain. Another example are the new design requirements in the proposed medical devices regulation for standalone software for ‘mobile computing platforms’. Companies will need to manage these overlaps contractually, coherently and intelligently, to avoid nasty surprises and to achieve compliance in the ecosystem of medical apps / standalone software.