When we talk about clinical evaluation of a medical device, we tend to think about a physical device like an implant or a syringe. But as we move more and more toward a digital era, we should also consider software that are classified as medical devices.

Recently Apple informed us that its Apple Watch received FDA clearance for an algorithm that detects an irregular heart rhythm.

To get this marketing authorization, this product must be validated to prove that it works. The best way for that is to build your clinical evaluation. But how do you do that?

Let’s review together what is needed for a Software as a Medical Device (SaMD).

What is a SaMD?

Before starting the clinical evaluation of a software, I want to first clarify what a SaMD is.

The official definition according to IMDRF guidance says:

How well do you really know your competitors?

Access the most comprehensive Company Profiles on the market, powered by GlobalData. Save hours of research. Gain competitive edge.

Company Profile – free sample

Thank you!

Your download email will arrive shortly

Not ready to buy yet? Download a free sample

We are confident about the unique quality of our Company Profiles. However, we want you to make the most beneficial decision for your business, so we offer a free sample that you can download by submitting the below form

By GlobalData
Visit our Privacy Policy for more information about our services, how we may use, process and share your personal data, including information of your rights in respect of your personal data and how you can unsubscribe from future marketing communications. Our services are intended for corporate subscribers and you warrant that the email address submitted is your corporate email address.

The term “Software as a Medical Device” (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.

But what does that mean: your software should not be linked to a specific hardware?

For example, when you buy an ECG monitor, it comes with the full equipment, the electrodes and inside your device, the software is already installed.

On the contrary, if you create a software that can be installed on any computer, mobile phone, and tablet then it falls under the SaMD definition.

A software can be a medical device in Europe and should then follow a certain path to get registered. If you want to know if your software should be registered as a Medical Device, you can have a look at this article “Should I register my Software as Medical Device?”

How to Clinically Evaluate a Software

The objective of your clinical evaluation is to assess and analyze the clinical data to verify a device is safe. It’s also to confirm its performance and effectiveness when used as intended by the manufacturer.

So how is that possible?

For software, there are three pillars that need to be filled to qualify your software. Those three pillars are:

  • Valid Clinical Association of a SaMD
  • Analytical/Technical Validation of a SaMD
  • Clinical Validation

These can be found in more detail in the IMDRF documents (Software as a Medical Device (SaMD): Clinical Evaluation).

Let’s review each part of it so we have a better understanding.

Valid Clinical Association – the objective here is to confirm that the output provided by your software is matching its targeted clinical conditions.

To perform that, you can use literature searches, original clinical research, professional society guidelines, secondary data analysis, and/or clinical trials (new data generated).

All SaMD should demonstrate a valid clinical association.

Analytical/Technical Validation – here, the question we try to answer is: “Does your software correctly process input data to generate accurate, reliable and precise output data?”

This phase provides objective evidence that the software was correctly constructed. It correctly and reliably processes input data to generate output data with the appropriate level of accuracy, and repeatability and reproducibility.

A manufacturer is evaluating this step during the validation and verification phase (V&V) of the software. For more information on the development lifecycle of a software, read the IEC 62304 – Software Lifecycle Management.

Clinical Validation – the final phase is necessary for any SaMD as it answers the question: “Does the use of the software’s accurate, reliable and precise output data achieve your intended purpose in your target population?”

Let’s clarify what we are trying to prove here.

For example, your software is diagnosing a certain disease on a population or an individual. In the context of clinical conditions, is the result meaningful, measurable and patient-relevant?

This clinical validity should be provided by the manufacturer as a pre-market during software development and also post-market after its distribution.

The post-market study can be obtained by collecting complaints information or safety data. This helps to further understand the customer’s needs and to be sure that the software is meeting those needs.

Additionally, the post-market study must collect real-world performance data. When before it was more a lab test, now it’s delivered to the population.

To succeed in this phase, you can reference existing data from studies conducted on the same intended use; or different intended use where extrapolation of such data can be justified.

Another possibility, the manufacturer can decide to generate new clinical data for a specific intended use.

Wrap-up

We learned that a software can also be a medical device. And for Europe, it should follow the new Medical Device Regulation (EU MDR 2017/745).

The three steps that were described for clinical evaluation will help you bring a safe product to market. It will also enable you to justify with objective evidence that you meet all the requirements during pre-market and post-market.

One aspect of SaMD still under development is artificial intelligence (AI). A software using this technology is always updating itself to learn and adapt its response to the new data received. So this dynamic aspect makes it’s more difficult to confirm that the software is safe.

Logically, the development phase will take more time as the learning phase will be also important.

To help organizations to develop these kinds of software, the FDA issued a “Software Precertification Program”. While this is still under development, the objective is to provide an AI algorithm to the health care market with more accurate, more personalized, and cheaper diagnostic solutions.

What is true for a static program with one input providing one output can be different with an AI software as the output can change while the learning process is still ongoing.

The future is still in progress with all these new technologies that will rise in a few years. The good news is that the regulation is also following these changes, which will help to keep our health care system in safe hands.

If you want to learn more on the new European Medical Device Regulation (EU MDR 2017/745), follow the free Mini-Course provided by easymedicaldevice.com