Does EU Medical Devices Directive Apply to Contact Proximity Tracing Apps?

by Erik Kamenjasevic & Elisabetta Biasin, KU Leuven Centre for IT & IP Law (CiTiP)

Introduction

The outbreak of COVID19 disease paved the ground for an extensive debate on using digital technology to monitor its spread. The research done by the European Parliament Think Tank shown that these technologies may help to fight the epidemic in many ways. Several European governments (for example, Austria, Estonia, Germany, Italy) are currently evaluating the introduction of the so-called (centralised or decentralised) contact proximity tracing apps in their respective healthcare systems. In support of this idea, researchers, academics, technology experts, and companies launched initiatives to develop apps for contact proximity tracing at a large scale. These apps should track with whom and where COVID19-positive patients come in contact as they move around their neighbourhood or city.

So far, academic research and public debate have been focused mainly on privacy and data protection aspects related to the adoption of such a kind of technology. This analysis takes a different angle, and it provides a brief overview of the possible qualification of contact proximity tracing apps as software as a medical device according to the Council Directive 93/42/EEC of 14 June 1993 concerning medical devices (‘MDD’).

DP-3T Protocol as a Use Case for Engaging in Broader Discussions

To answer if the EU medical devices’ requirements embedded in MDD have to be implemented in the contact proximity tracing apps, we wrote a working paper titled ‘A Commentary on Decentralised Privacy-Preserving Proximity Tracing in the Context of the EU Legal Framework for Medical Devices’ (the ‘Commentary’). Therein, our analysis started from a DP-3T protocol as an exemplary case (the ‘System’) as it is, for the moment, the most transparent initiative when it comes to document sharing and openness to the public scrutiny. We took into account the EU legal framework for medical devices (‘EULFMD’) consisting of MDD, the case-law of the Court of Justice of the European Union (‘CJEU’), and European Commission’s MEDDEV Guidelines on the qualification and classification of stand-alone software used in healthcare within the regulatory framework of medical devices (‘MEDDEV 2.1/6’). We adopted the five-step approach provided in MEDDEV 2.1/6 in order to assess the possible qualification of the System as a medical device. In the paragraphs that follow, we propose a synthesis of the points we have touched upon more extensively in the Commentary.

Analysis Based on MDD and MEDDEV 2.1/6

In order to analyse the qualification of the System as a medical device, it is essential to establish the material scope of MDD. That requires the evaluation of Article 1(2)(a) of MDD, namely the nature of the device (whether it is an instrument, apparatus, software, etcetera), the medical purpose for which the devices is used (diagnosis, prevention, monitoring, treatment or alleviation of disease, etcetera), its principal intended action, and whether it will be used for human beings. Furthermore, MEDDEV 2.1/6 is of pivotal importance. This non-binding document defines the criteria for the qualification of stand-alone software, when used in the healthcare setting, as a medical device and the application of the classification criteria to such software. From now on, the analysis is based on the aforementioned criteria to preliminary answer if the System falls under the scope of MDD.

Is the Product Software? (Step 1)

According to MEDDEV 2.1/6, software means a set of instructions that processes input data and creates output data. Input data is any data provided to software in order to obtain output data after the computation of this data, while output data is any data produced by the software. According to the DP-3T White Paper (the ‘White Paper’), patients who are diagnosed with COVID19 will be authorised by health authorities to upload in the system information that aids in proximity tracing (input data). As the following step, patients will instruct their phones to upload to the backend some data in the form of their digital ID (‘EphID’) for the infectious period. Other smartphones periodically query the backend for this information and reconstruct the corresponding EphIDs of infected patients locally. If the smartphone has stored a record of any of these infected EphIDs, then the smartphone’s user has been in contact with an infected person, and the smartphone computes the owner’s risk score. If this score is above the threshold, the smartphone initiates a notification process (output data). As such, the System is a set of instructions processing input data and creating output data falling under the definition of software according to the MEDDEV 2.1/6.

Is the Software a Stand-Alone Software? (Step 2)

The software has to be stand-alone. That is, according to MEDDEV 2.1/6, software which is not incorporated in a medical device at the time of its placing on the market or its making available. The System appears not to be incorporated into another medical device. Therefore, the second step is met, and the System qualifies as stand-alone software.

Is the Software Performing an Action on Data Apart from Storage, Archival, Communication, or a Simple Search? (Step 3)

The System is described as operating in four phases: (I) installation, (II) normal operation; (III) handling infected patients; (IV) decentralised contact tracing. For the analysis of the actions performed by the System in the context of this step, phases III and IV are relevant.

In phase III, if the national health authority confirms that the user has been infected with COVID19, he/she is allowed to send data to the backend server, with confirmative information about the infection. In this phase, the System only stores the user’s data to the backend server. Hence, it is not performing an action different from storage, archival, communication or a simple search. If that were the only action performed by the System, the software would not qualify as a medical device. In phase IV, every other users’ app processes the data downloaded from the backend server to compute whether the user was in physical proximity to one or more contacts identified as an infected person. Once this information is processed, the app computes the infection risk score. If the score goes above a certain threshold, the app informs the user of the infection risk and advises on what to do and where to find more information. This phase seems to indicate that the System performs an action different from those explicitly excluded. We deem this action to be different from storage, archival, communication, or a simple search. As defined by the Cambridge Dictionary, to ‘compute’ means to calculate an answer or amount by using a machine. In light of that, the System calculates the risk score of the single user.

Is the Action for the Benefit of Individual Patients? (Step 4)

The action performed by stand-alone software has to be for the benefit of individual patients. A definition of ‘benefit of individual patients’ is not provided in the MDD, or MEDDEV 2.1/6. However, some elements of it may be inferred with a contrario interpretation, from the explanations provided by MEDDEV 2.1/6 itself. Therein, it is stated that “examples of software which are not considered as being for the benefit of individual patients are those which aggregate population data, provide generic diagnostic or treatment pathways, scientific literature, medical atlases, models and templates as well as software for epidemiologic studies or registers”. The latter statement requires further interpretation. First, to qualify as a medical device, the software should not aggregate population data nor provide generic diagnostic or treatment pathways. Here we may already infer that the System does not aggregate population data nor it provides generic diagnostic or a treatment pathway to an unspecified number of people. The purpose of the System is for the benefit of an individual patient since it computes the individual risk score and directly notifies the user of the possible risk of infection. Besides, for this analysis, we did not find relevant the reference to “scientific literature, medical atlases, models and template”. Therefore, and for the sake of conciseness, they have been disregarded. Second, the stand-alone software should not be used for epidemiologic studies or registers. Although the System is designed to fight the epidemic and one of its objectives is to enable epidemiologists to analyse the spread of COVID19, it would be misleading to ponder that the System falls under the notion of software for epidemiologic studies or registers, and thus not being for the benefit of an individual patient. What adds to this argument is the other listed objective of the System, namely to enable quick notification of contact people at risk and give guidance on the next steps. Thus, the System is not apt to entirely fall within the case foreseen by the Guidance concerning epidemiologic studies or register.

In conclusion to this step, we deem that the computation of infection risk, and the notification thereof, reasonably appear to be for the benefit of the System’s user. As illustrated, the System assesses whether the individual user has been in physical proximity to an infected person and whether there is a risk for him or her of being infected. If this score is above the threshold, the System initiates a notification process towards the user, thus for the benefit of that person only. Hence, this action is for the benefit of individual patients who happen to be in the proximity of a patient diagnosed with COVID19.

Is it for the Purposes Defined in Article 1(2)(a) of Directive 93/42/CEE? (Step 5)

Article 1(2)(a) MDD refers to the medical devices’ purpose of diagnosis, prevention, monitoring, treatment or alleviation of disease. Article 1(2)(g) MDD defines intended purpose as the use for which the device is intended according to the data supplied by the manufacturer on the labelling, in the instructions and/or in promotional materials.

The CJEU (in C-219/11 and C-329/16) confirmed that the device’s intended purpose must be medical. However, the mere fact of using a device in the healthcare context does not suffice for a product to qualify as a medical device. For example, when the software is used for administration of general patient data, it has no medical purpose, according to MEDDEV.

The White Paper declares two purposes of the System. First is to enable quick notification of contact people at risk and give guidance on the next steps, and second is to aid health authorities in their efforts to reduce the infection growth rate by enabling epidemiologists to analyse the spread of COVID19 by providing the System’s users to voluntarily share data for reconstructing the interaction graph among infected and at-risk users.

The first purpose of the System seems to be medical. In particular, this purpose might qualify as the prevention of disease. That is because the System is designed to support health authorities in their efforts to reduce the infection growth rate of COVID19 disease. The second purpose of the System does not seem to be medical in this context. Although the System will be used in the healthcare setting, it would only serve as a means of providing data of its user (who voluntarily accepts to do so) and epidemiologists and research groups for analysis of the spread of disease. This goes in line with examples of software which are not considered as being for the benefit of individual patients, as reported by MEDDEV 2.1/6. Therefore, the second purpose does not fall within the notion of medical purpose.

Hence, if the entity which is having a role of the manufacturer declares the purpose in the same way as it is in the White Paper, then the first System’s purpose falls within Article 1(2)(a) of the Medical Devices Directive (namely, prevention of disease).

Conclusions

We used the example of DP-3T protocol to understand whether contact proximity tracing apps might qualify as a medical device. Based on the information available, and having considered relevant provisions of MDD as interpreted in MEDDEV 2.1/6 and by CJEU, we concluded that the System might fall under the definition of medical device as it is a stand-alone software computing data for the benefit of individual patients to prevent COVID19 disease. In such a case, an entity having a role of medical devices’ manufacturer needs to ensure respect of requirements stemming from the applicable (EU and national) legislation regulating medical devices.

The European Pharmaceutical Law Review (EPLR) identifies and analyses important legal and regulatory developments on the national, EU and international level. It is primarily concerned with pharmaceutical law, medicines law and issues related to the work of the European Medicines Agency (EMA). Furthermore, it provides an overview of and critically examines judgments and directives that shape the interpretation and application of EU pharmaceutical law and policy, including those by the European Medicines Agency (EMA), European Courts, international courts and tribunals such as the WTO’s Dispute Settlement Body, and higher national courts.