MDR Class 1 Devices: Do They Exist (as software)?


I’ve heard that, under the MDR, software is usually classified as class IIa device or even higher. In the past, under the MDD, many software devices were classified only as class I. That made regulatory compliance easier. Can you think of any software which would be class I under MDR?

Short Answer

Yes. Two examples come to mind: Software for the (primary) prevention of disease, and software for directly treating a disease. It boils down to reading rule 11 of the MDR and avoiding the specific categories it mentions.

Long Answer

The rule 11 of the MDR makes it very difficult for software to be class I. That’s bad, because under the old legislation (the MDD), being a class I device enabled many startups to ship innovative software without going through expensive and slow approval of a notified body. Arguably, this was a good balance between innovation and patient safety. So why did the MDR make this so much harder? I don’t know, why are you asking me? That wasn’t the question anyway. Um, back to topic.

The MDR has a section called “rule 11” which essentially makes it very, very hard to be class I. Summarized in human language, you’re not a class I device if:

  • You provide information which is used to take decisions with diagnostic or therapeutic purposes (at least class IIa)
  • You monitor physiological processes (at least class IIa).

As always, I’ve simplified everything greatly, and there are more subtleties. Like, if your software could cause death, then it’s class III.

Let’s focus on the first section, providing information which is used to take decisions with diagnostic or therapeutic purposes. Those are class IIa at least. Examples of those could be:

  • PACS / DICOM Viewers (–> diagnosing stuff on images)
  • Machine Learning plugins for DICOM Viewers (–> diagnosing more stuff on images)
  • Software for triaging patients (–> changing the therapeutic outcome?)
  • Software which checks for interactions between multiple medications (–> changing medication).

Now, thinking further, how would a software look like which doesn’t fall under this definition? It would not be allowed to provide any information to take decisions with diagnostic or therapeutic purposes.

Let’s look at two examples.

Example 1: Prevention of Disease

An app which prevents disease, specifically an app which avoids the disease from affecting a person in the first place.

Like, an app for preventing depression in healthy people. I don’t know what such an app would do. I guess you could give people some pointers and mental exercises on how to stay healthy, psychologically? Strictly speaking, it’s still a medical device (due to prevention of disease), but we’re not providing any information for diagnostic or therapeutic decisions. Cool.

But is this sort of app useful at all? Maybe. I think there are some cool things you could build in the area of prevention. Maybe you could even offer such an app to patients which already suffer from a certain disease, and you’re trying to prevent another disease (depression?) from happening to them.

Example 2: Direct Treatment of Disease

The next (and final) example I can come up with would be a software for direct treatment of disease.

Something like.. an app for treating diarrhea. Like, it would give you step-by-step instructions on how you could treat yourself: Step 1, drink water, step 2, eat bread, step 3, stay close to toilet, etc.

Clearly, this would be a medical device, because it’s treating a medical condition / diagnosis (= treatment of disease). Further, it wouldn’t provide any information for diagnostic / therapeutic decisions.

However! As soon as your app incorporates some sort of decision tree or machine learning model on whether your diarrhea needs additional treatment by a doctor, you may be in dangerous territory (quite literally). Because that information may actually be informing a diagnostic (worsening of diarrhea?) and even therapeutic (treatment by doctor?) decision. Ugh.

Then again, you could talk your way out of it by building your app strictly based on a guideline (like, an internationally-established diarrhea-treatment guideline). Then you could argue that the diagnostic / therapeutic information doesn’t originate from your app, but from the guideline which is validated – but again, this is dangerous territory.


While other people might tell you “oh my god MDR class I devices don’t exist please book our consulting package”, I think there are some legitimate software medical devices which would fall under MDR class I, and they would even provide value to patients. Let’s hope that state authorities and notified bodies follow along with that reasoning and at least provide some of the remainder of innovation potential which got destroyed by the transition to the MDR.

On a slighty different note: You want to get your medical software certified under MDR but don’t know where to start? No worries! That’s why we built the Wizard. It’s a self-guided video course which helps you create your documentation yourself. No prior knowledge required. You should check it out.

Or, if you’re looking for the most awesome (in our opinion) eQMS software to manage your documentation, look no further. We’ve built Formwork, and it even has a free version!

If you’re looking for human help, did you know that we also provide consulting? We’re a small company, so we can’t take on everyone – but maybe we have time for your project? We guide startups from start to finish in their medical device compliance.


Leave the first comment