When can clinical investigations be avoided for devices with artificial intelligence?

For manufacturers, the answer to whether and when clinical investigations are necessary when using artificial intelligence in medical devices is relevant. After all, the duration and cost of bringing these devices to market depend on this.

The good news in advance: there are cases where manufacturers can avoid clinical investigations for devices with AI. This article explains which cases these are.

1. Summary for readers in a hurry

In most cases, manufacturers will not be able to demonstrate compliance with regulatory requirements (e.g., performance) based on published clinical data. That is because the equivalence of the devices or AI models used to generate the data cannot be adequately demonstrated.

However, it is possible to use retrospective analyses to avoid prospective clinical investigations for devices with AI.

2. The legal situation

The legal situations in the EU and the USA differ. In its guidance document on Clinical Decision Support Software, the FDA defines four criteria that a software application must meet to not be considered a medical device in the USA and not to be monitored by the FDA. However, these requirements are usually not met by AI-based software, for example, because the software is used for the analysis of images or signals.

The MDR (analogous to the IVDR) requires manufacturers to demonstrate devices' safety, performance, and clinical benefit as part of the clinical evaluation or performance evaluation of IVDs. As different as the MDR and IVDR requirements for clinical evidence may be for medical devices and IVDs, they are comparable for software. The MDCG describes the special features and similarities in the clinical evaluation or performance evaluation of medical device- or IVD software in its 2020 guidance document Guidance on Clinical Evaluation (MDR) / Performance Evaluation (IVDR) of Medical Device Software, which is well worth reading.

If insufficient clinical data is available, the manufacturer must generate it. As a rule, this means that a prospective clinical investigation must be conducted.

3. The problem with equivalence

a) MDR requirements

Especially under the MDD, it was common practice to use clinical data from existing devices, thus avoiding the need for clinical investigations. The prerequisite was that the data came from equivalent devices. This also includes their technical equivalence. The required proof of technical equivalence explicitly also concerns the software algorithms:

For class III medical devices and implantable devices, it becomes even more difficult to avoid clinical investigations:

b) Technical equivalence in artificial intelligence

In the case of medical devices that use artificial intelligence and, in particular, machine learning, the models correspond to software algorithms (e.g., models such as the various forms of neural networks). These differ concerning:

• architecture of the models, e.g.,
  • number of layers
  • number of neurons per layer
  • linkage of the layers
  • activation functions (e.g., RELU)
• linking of submodels as for LSTM or LLM
• values of the fitted parameters (weight and bias)

The hyperparameters used to train the models affect the fitted parameters. However, their choice is not an aspect of technical equivalence. On the other hand, the "application conditions" are part of the technical equivalence.

So far, there is no specification of what the application conditions include in this context. Possible aspects are:

• technical environment such as hardware and operating system
• programming language and libraries used
• use and embedding of the model in the overall medical device

c) Demonstration of technical equivalence

Usually, manufacturers will not succeed in proving the equivalence of the "software algorithms" without comparing the software code of the equivalent product. As the MDCG states, this is also not necessary.

“It is the functional principle of the software algorithm, as well as the clinical performance(s) and intended purpose(s) of the software algorithm, that shall be considered when demonstrating the equivalence of a software algorithm. It is not reasonable to demand that equivalence is demonstrated for the software code, provided it has been developed in line with international standards for safe design and validation (IEC 62304, and IEC 82304-1) of medical device software.“

Comment in MDCG 2020-5, Chapter 3.1 (b)

For AI models, equivalence is not proven even with identical software code. This is because the software code (as part of the medical device) defines the AI model but not the values of the fitted parameters. These are determined by the training data and the type of training (e.g., hyperparameters). However, the software code for the training is not part of the medical device and is not covered by MDCG 2020-5.

MDCG 2020-5 requires that the "functional principle" and "clinical performance" (more on this later) be used in the equivalence comparison. For AI applications, the model architecture most closely corresponds to the "functional principle."

Sufficient clinical data are needed to demonstrate compliance with the essential safety and performance requirements. Clinical data can also be collected through other than clinical investigations (see next chapter).

4. Proof of conformity

a) Aspects/requirements to be proven

Manufacturers must use clinical data to demonstrate the safety, performance, and clinical benefit of their medical devices or IVDs. In the case of "Medical Device Software" (MDSW), this means, according to MDCG 2020-1, the demonstration of:

• clinical association/scientific validity

• technical performance/analytical performance

• clinical performance

Table 1 presents these three aspects of clinical evidence using the example of AI-based medical device software that identifies tissue suspected of having cancer in CT images.

Tab. 1: For medical device software, and thus also AI-based medical device software, three aspects of clinical evidence must be substantiated.

¹⁾ For CTs, brightness values correspond to Hounsfield Units (HU), sometimes referred to as "X-ray density".

b) Detection methods

The MDCG 2020-1 guideline suggests different methods to demonstrate the above aspects.

Tab. 2: For each aspect, it is important to use the right methods

5. Collecting clinical data

Demonstrating clinical performance is the biggest challenge for manufacturers of AI-based medical devices. However, this does not mean that prospective clinical investigations are always necessary.

a) Retrospective analyses

In a retrospective analysis, manufacturers use existing data.

In the case of cancer detection software, the manufacturer could use existing CT scans, have the software evaluate them, and compare them to existing cancer diagnoses. However, this only works if the following conditions are met:

• The images were obtained under comparable technical conditions as intended by normal use. This includes the acquisition equipment (CTs), acquisition parameters (e.g., radiation intensity, angle, patient positioning, with/without contrast agent), and image parameters (size and resolution of images, coding of Hounsfield values)
• The patient population with which the images were recorded is comparable to that intended in the intended purpose. This includes anatomic and morphologic characteristics as well as different locations, sizes, and types of tumors and possible effusions.
• The number of cases is sufficient, and the quality of the data is scientifically valid.
• Informed consent has been obtained to use the data for clinical study purposes.
• Comparability of users and the use environment would also need to be discussed. However, usability tests are easier to replicate than clinical investigations.

b) Clinical investigations in artificial intelligence

If these requirements are not met or not fully met, manufacturers must generate the clinical data, typically through a prospective clinical investigation (or clinical performance study for IVD/MD software).

This would be necessary, for example, if the software is also to be used for patients with cancer for whom sufficient clinical data are not yet available. In this specific case, the clinical investigation would at least have to demonstrate the correct segmentation of the cancer tissue for this patient population, which has not been reviewed so far.

6. Conclusion

 Attempts to demonstrate the equivalence of AI models and to prove the clinical performance of the software based on the literature usually fail. Many manufacturers even explicitly claim "better" models.

However, this does not mean that a prospective clinical investigation is necessarily required for AI-based medical devices. It is often possible to avoid these trials in whole or in part by retrospective analyses of already available data of sufficient quality and quantity.