5 Major Concerns for Software As a Medical Device and AI Companies

Move over, Dr House, there’s a new diagnostician in town, and it’s not human! Thanks to the power of AI, medical devices are becoming smarter than ever, analyzing data faster than ever and creating regulatory headaches as they go.

 
From detecting irregular heartbeats to identifying suspicious moles, these devices are the ultimate sidekick for medical professionals. With AI on their side, doctors may soon be able to diagnose diseases before you even have time to Google your symptoms.
 
But, no, really. AI is expected to have a huge impact on the medical field. It has the potential to revolutionize many areas of healthcare by providing solutions for different types of medical conditions and diseases.
 
The main focus of using AI, at least for now, is that it makes it possible to analyze patient data in real-time so that doctors can make better decisions.
 
And since most clinical data are derived from medical devices, medical devices are the obvious choice for AI expansion in the medical sector. It’s nothing new since most tech advancements, from X-rays to robotics, get implemented in medical devices to provide better medical care with high accuracy.
 
But, the problem with medical device software or software as a medical device (artificial intelligence enhanced) is that it isn’t exactly the same as these previous techs. Although it is technologically similar to software as a medical device, the differences are prominent enough that most companies are struggling to get their device approved.
 

Software as a Medical Device (SaMD) and MDSW

Software as a Medical Device (SaMD) and MDSW are two names of medical devices that use the software. One is given by the FDA, and the other by MDR. Before you become too confused about it, here are definitions.

 
The definition of Software as a Medical Device (SaMD), according to the FDA, is: “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
 
According to Medical Device Regulation, the MDSW can be defined as “Software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the Medical Devices Regulation (MDR) or In Vitro Diagnostic Medical Device Regulation (IVDR).”
 
Both are often used interchangeably since, for us regular folks, a software is a software! But, there is a bit of difference between them.
 
SaMD or software as a medical device is like the star athlete of the medical device sector. It’s often a standalone software product or active device that’s specifically designed to diagnose, treat, or prevent medical conditions. Think of it as the LeBron James of healthcare tech – it’s got a serious game.
 
MDSW is more of a team player. It, while including all front-working software, also likes behind-the-scenes medical device software that powers medical devices. Unlike SaMD, it includes the little codes that tell your pacemaker when to beat or your insulin pump when to release insulin.
 
But don’t let these differences fool you – both are essential to medical device manufacturers, and you need to know both of them by heart if you are developing a device with AI in it.
 

How the CER process differs for software and regular medical devices

In Europe, as we know, different types of medical devices fall under classification rules where they are classified as Class I, II or Class III devices depending on their risk of causing harm to patients. Medical devices are regulated by both the EU and the US.
 
Depending on that, you have different technical data to collect and submit. For medical device software, the requirements vary a little. You will need to submit all data for verification and validation of the software development process.
 
These tests will have to be performed in your lab and also in the actual real-life scenes, so the regulatory people can be sure that the device actually works. You will also need to submit all hardware configurations, operating system details and all technical details. These are just the pre-requirement of the actual clinical data you will have to submit.
 
Let’s talk about clinical data, then. To show them your device conforms with the general safety and performance requirements of the Medical Device Regulation (MDR), you need to declare the intended purpose of the device first. Not that it surprises anyone, but there are some requirements to that too.
 
Anyway, after that, you have to provide enough clinical data through a clinical evaluation plan and clinical evaluation report, among other documents, to show that your device works according to the intended purpose. This is all within the clinical evidence.
 
Oh, and depending on how your device works, alone or with other hardware medical devices, you will need to provide clinical evaluation for those as well.
 

Concerns for AI Medical Device Manufacturers

So, where is the problem with AI? And why does AI CER process much more difficult than regular medical device software?
 
Well, here are some problems we faced while helping some of our clients out:
 

Scarcity of data:

So, you know, when performing clinical evaluation, you have to search and present scholarly articles published regarding that technology? Here is the thing, AI is pretty new; the use of AI in a medical device? Even newer! So, you will be hard-pressed to find enough literature to create a decent literature review.
 

Difficulty in proving the efficiency:

You will have to provide the details of the device, including the algorithm, to the EU people while submitting the device. The problem with AI devices is that you can’t easily predict and prove the efficiency of the device like you would for other medical device software. AI is always evolving and learning by itself, right? It is very unpredictable by its nature.
 

FDA vs MDR:

The FDA and Medical Device Regulation have different regulatory requirements. So, you will need to find an expert who knows the regulatory path well and has enough experience in either or both to guide you through it.
 

Clinical trials and clinical data for software:

The problem with the clinical evidence is that it is up to the medical manufacturer to justify how much clinical data is enough. Since the use of AI is new and each medical device software has a somewhat unique use of AI, there is no road map either. So, it’s very difficult to determine just how much is enough. For example, and this is purely an example, it is easy to show data for software that measure vital physiological parameters but difficult to defend an artificial intelligence software that informs clinical management whether the person would need surgical intervention or not.
 
Not to mention, following the standard clinical evaluation format and standard clinical data collection methods also prove to be challenging for AI-enhanced medical device software.
 

Unique regulatory considerations:

Everyone is a bit weary of AI. So, naturally, the notified bodies, aka people who have the job of ensuring a device is safe enough for use on humans, would be extra weary of a tech they aren’t sure they can trust yet. This complicates the process, to say the least.
 

What to do?

So, how do you get your medical device software CER certified? Here are some insider tips:
 
First, read the guidance from the medical device coordination group. They have tons of info you will need.
 
Next, make sure to set up a proper quality management system that adheres to MDR.
 
Also, be aware of your risk management principles. All medical devices have to follow the regulatory framework and ensure patient safety.
 
How do you do that? By having a solid PMCF, of course! A PMCF will give tons of clinical data on whether your device is within the intended medical purpose while giving you real-world performance monitoring.