What about software used in human research?

Face-to-face: investigator meets regulatory affairs specialist

Let’s imagine a typical consultation at a CTU. An investigator is planning a trial using an App. So, they meet with a regulatory affairs specialist from the CTU who is helping the investigator to think through, prepare, and organise the necessary paperwork.These are some of the questions that come up in such an interaction and some of the contextualising information.

CTU: “So, you’re planning to use an App in your trial?”

Investigator: “Yes, we are. Patients love typing on their phones and it is much easier for us to collect the necessary data, such as the patient’s heart rate, digitally rather than in the traditional way. We have developed this App to give each patient the option of monitoring their own heart rate, independently.”

CTU: “What exactly does the App do with the patient data? Does it collect and transmit the data, primarily?”

Investigator: “Yes, but it does even more than that. After the data is collected, it is analysed by the software of the App. If the software detects that the patient’s heart rate is out of the normal range, the patient will receive a message that they should see their family doctor. Finally, the recorded data is transmitted directly to the study site, where the trial is taking place.”

CTU: “You know, in this case, your App falls under the definition of a medical device.”

Defining and framing medical devices in the EU

Next, in this kind of conversation, the regulatory affairs specialist often needs to explain that a medical device is not necessarily something “physical”, like a hip prosthesis. A medical device can also be intangible, like an algorithm installed on a mobile phone.

The regulatory affairs specialist also explains the new regulatory context in the EU for medical devices, the Medical Devices Regulation (MDR), and the consecutive necessary adaptations of the legal texts in Switzerland: the drafted Medical Devices Ordinance (MedDO) and the Ordinance on Clinical Trials with Medical Devices (ClinO-MD) that should enter into force in May 2020 (see the Deep Dive). In the next part of this article, you will read about future scenarios facing medical devices in this new regulatory context.

Whether the software or App is defined as a medical device will depend on its intended use. For example, if the tool is programmed to monitor the heart rate of a person who is exercising in preparation for a marathon, but without any medical recommendation, then it does not count as a medical device. However, if the App analyses the heart rate and then gives feedback to the user (such as notification that one of their values is out of normal range, that the person should stop exercising and see their doctor to prevent their health from deteriorating), then the App carries a medical purpose (MDR, art. 2).

If the App falls under the definition of a medical device, it should firstly be verified and validated, and, as a second step, be clinically evaluated. If this clinical evaluation then finds the device does not meet essential requirements relating to its safety and performance, the App should be tested in clinical investigations in order to prove these requirements.

CTU: “Thus, if your App is able to modify participants’ medical care and potentially impact their health status and not only capture and transmit data, then, you’ll have to go through the medical device regulatory process…”

Investigator: “And how should we handle the paperwork?”

Defining the classification of expected risk and preparing for clinical investigation

Above all, you need to be clear about the definition of a “clinical investigation”, as highlighted in the new ClinO-MD (art. 2, para. 1(a)) and defined in the MDR (art. 2(45)): “Clinical investigation means any systematic investigation involving one or more human subjects, undertaken to assess the safety or performance of a device.”

Moreover, the investigator (and the sponsor) must perform the trial and provide relevant documentation in accordance with the MDR (as detailed in Annex XV, chs. 1–3), cross-referenced in ClinO-MD (art. 4 and Annex I).

A risk–benefit analysis must be performed and precautions must be taken to address the identified risks (MDR, Annex XV, ch. 2, no. 2.5). In our example above of the App, the regulatory affairs specialist may raise the following questions, among others:

• “Does the App run reliably on all possible devices available to study participants, i.e. on all operating systems?
• How is the support of the software regulated (e.g. after an update of the operating system)?
• What happens if the App does not have an Internet connection? 
• Can the App be operated easily or does it require special training?”

Investigator: “What happens when we have validated our App and it fulfils the criteria you just mentioned?”

CTU: “You will need to then establish the specific risk classification of your App, which is made by considering the extent of the expected risk. Let me explain that to you in more detail.”

The classification of the expected risk must be made (MEDDEV 2.4/1 and MDR, Annex VIII) and the new rule 11 (MDR, Annex VIII, ch. 3, para. 6.3) is explained as following:

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:

• death or an irreversible deterioration of a person's state of health, in which case it is in class III; or
• a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb.

Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb.

All other software is classified as class I.

Investigator: “But why do I need this classification?”

According to the risk classification the App falls into, you’ll need to take appropriate measures to mitigate the risks. You will need to include that information in the dossier that must be sent to Swissmedic and the responsible ethics committee, to apply for the authorisation required to conduct the clinical trial.

The area of review of the ethics committee is the same as the one referred in the ClinO (art. 25).

Swissmedic reviews the aspects listed in the TPA:

• The risks associated with the devices are taken into account in clinical trials and whether the information provided on the devices is in line with scientific progress (TPA, art. 54, para. 4, let. b).
• When used as intended, a medical device should not endanger the health of users, consumers, patients, or third parties (TPA, art. 45, para. 1).

After approval, the investigator must perform their trial in accordance with the MDR, Annex XV, chs. 1 and 3 (also in line with the international standard ISO 14155:2011 on good clinical practices for clinical investigations of medical devices for human subjects), which is directly cross-referenced in ClinO-MD (art. 4).
 

Conclusion

• An App can be classified as a medical device if it does more than simply capture and transmit data.
• The development and use of clinical Apps is regulated by EU and Swiss laws.
• Considerable efforts must be made by the investigator, since the required documents represent an intense amount of work. 

Investigator: “Ok, thank you. That sounds like a lot of work. I may consider using the App for data collection and transmission only, after all.”