25 Nov eHealth at the test of privacy and medical devices rules
eHealth devices are the future of healthcare, how can they deal with legal issues raised by privacy and medical devices regulations?
Updated on 02.09.2016
Medical devices and new technologies are becoming more and more linked one to the other in order to allow medical practitioners to continuously monitor their patients’ health conditions. This happens through eHealth remote patient management systems connected to cloud databases contributing to the growth of the Internet of Things. However such technologies lead to relevant legal issues including data protection issues.
Medical device companies should assess the legal implications of eHealth technologies allowing practitioners to review the status of their patients in real time through devices that are connected to cloud databases. This should be accessed not only to review patients’ health conditions, but also to perform clinical trials. These tools can be implanted directly in the body, as is the case with biostamp electronic tattoos and insertable cardiac monitors, which have contributed to the growth of the so-called ‘wearable technologies’ sector along with smart watches, fitness bands and smart glasses.
What privacy obligations for eHealth technologies?
eHealth technologies trigger privacy issues because of the large amount of sensitive data on patients’ health conditions that is collected and then transferred to a database accessible by practitioners. Such data processing is subject to considerable data protection obligations and indeed the Italian data protection authority has recently challenged eHealth and Wellness Apps.
As already prescribed by the Article 29 Working Party (a European privacy advisory body) in its opinion on smartphone apps, the company managing the eHealth software installed on the device used for the remote monitoring system is subject to the privacy laws of the country where the device/user is located. This applies even to non-European entities. It will be insufficient merely to ask for privacy consent; rather, a data protection notice must be provided that lists all information requested under the relevant privacy law. Therefore, a pop-up message displayed following the download of most apps would not meet the regulatory requirements.
The scenario will be even more complex following the coming into force of the EU Data Protection Regulations that, as outlined in this post, will considerably expand the applicability of European privacy law.
Data protection consent and notifications
The privacy issues are more complex in countries such as Italy, which requires written privacy consent for the processing of sensitive data of eHealth technologies and allows data processing only within the limits of a general authorisation issued by the data protection authority. In such cases, a case-by-case review of products will be undertaken to determine whether such regulatory restrictions might limit the exploitation of these technologies or whether a solution might be adopted to ensure privacy compliance without limiting the functioning of the app.
Data controller, processor and sub-processor
The roles of the entities involved in the handling of collected data cannot be left to the discretion of the parties; on the contrary, the data protection authorities are strict in defining these roles. In particular, hospitals are generally considered to be the sole data controllers, with sponsors acting as data processors and cloud platform providers acting as sub-processors. Sponsors will usually need to be qualified as data controllers in order to have a higher level of discretion in the processing of the data, but data protection authorities have challenged such qualifications in several instances.
Processing of biometric data
Under Italian law, the use of eHealth remote patient monitoring systems may require notification of the data protection authority. This requirement will apply if such technologies are used either to create user profiles (which might include a profile of the user’s physical features) or to collect biometric data.
Biometric data includes any data obtained from a person’s physical or behavioural features (eg, fingerprints, facial characteristics, hand geometry, and retina and iris scans). In this respect, as outlined in this post, the Italian data protection authority has issued stringent requirements as to the modalities of biometric data collection, the security measures to be implemented for data storage and the maximum term of storage.
Purpose of data processing
A common mistake of medical device companies is to assume that once patients’ data has been collected, it may be used for any purpose and belongs to the company. This is not the case, and privacy consent – specific to the purpose for which the data will be processed – must be obtained from the patient.
Therefore, except in limited circumstances to be assessed on a case-by-case basis, personal data collected as part of medical treatment cannot subsequently be used in the performance of a clinical trial at a later stage without additional consent from the relevant patients. This requirement does not apply if collected data is then aggregated and anonymised. However, in this case the mere use of an identification code will not suffice if it is possible to connect a patient to the relevant code.
Privacy impact assesment and privacy by design
Privacy compliance has been often relegated to the arrangement of some papers, but with the new EU Privacy Regulation a thorough privacy impact assessment and the implementation of a privacy by design approach will be necessary. This are procedures that might take up to a 1 year of development, but are the sole protections against potential liabilities.
Transfer of data outside European Union
Data transfers outside the European Union can be the most challenging part of the assessment of legal implications, since it is necessary to know the role and location of all parties involved, as well as which servers are used to manage the platform distinguishing the roles between hospitals, sponsors and cloud platform providers.
Based on the information collected, the usual solution is to implement ad hoc model clauses approved by the European Commission, but these must be tailored to the peculiarities of the case. For instance, a relevant issue is to ascertain whether the data processor that appoints the sub-processor is a European or non-European entity.
Also, the matter is now even more complex in case of transfers of personal data to the United States following the invalidation of the Safe Harbor program that has now been replaced by the Privacy Shield.
The potential privacy risks of usage of eHealth technologies cannot be underestimated, given the fines for breach of privacy regulations prescribed by most EU countries and the criminal penalties that some countries – including Italy – impose for breaches in some cases (eg, if the breach has been performed to gain profit or causes damages). These penalties will become up to the 4% of the global turnover of the breaching entity as a consequence of the coming into force of the new EU Privacy Regulation.
Medical device regulations
It is also relevant to assess whether eHealth technologies qualify as medical devices. In this respect, it is necessary to distinguish between the software and hardware components of the device.
As for hardware, multi-purpose eHealth products such as tablets and personal computers are not usually considered medical devices, unless they are specifically assigned a medical role. This means that where the hardware component is not specifically used for the intended medical purpose, it should not be regarded as medical equipment and will not fall within the definition of ‘medical device’.
However, where the hardware component is used together with software qualifying as a medical device in such a way that the software will not otherwise run, the hardware should be regarded as a medical device. In this case, the software is a component and integral part of the medical device and is not regarded as a medical device on its own. Therefore, hardware and software should automatically fall into the same class of medical device.
eHealth software may be considered a medical device where:
- its use falls under one of the categories listed in the definition of ‘medical device’;
- it is intended to control or influence the functioning of a medical device;
- it is intended to be used in the analysis of patient data generated by a medical device with a view to diagnosis and monitoring; or
- it is intended to be used by patients to diagnose or treat a physical or mental condition or disease.
Therefore, software that is not intended to perform any diagnosis of collected data, but that is merely used to transmit the data to a cloud database where the data is reviewed and analysed, is not considered a medical device.
Hardware or software components of remote patient monitoring systems which qualify as medical devices may hinder the timely updating and upgrade of these new technologies, on account of the formalities and regulatory obligations that must be complied with. At the same time, stringent EU privacy regulations might create a sharp distinction between European and non-European jurisdictions where light data protection regulations could allow for the faster launch of these technologies. It remains to be seen whether regulators will be able to strike the right balance between the need to protect patients and the need to promote the potential benefits for patients arising from the exploitation of these new technologies.
Following this post, I ran a webinar on the topic whose slides are available here. We will see how regulators will react to this issue.
If you found this post interesting, please share it on your favourite social media!