Startups often ask us: Does MDR class I software exist? How does MDR class I software look like? And what features can be included in MDR class I software?
Here’s our answer: There is no answer.
Instead, this is our collection of all data we currently have available on the situation. And let me preface it with this: The MDR class I situation for software is a complete train wreck, and right now, class I software remains a gray area in which manufacturers always expose themselves to some risk of interpreting the MDR wrongly. It’s not because manufacturers are evil, it’s simply because, right now, every human on this planet interprets MDR class I devices differently.
The Situation
Medical devices, including software, are classified into one of certain classes (e.g., I, IIa, IIb, III) based on certain properties – in simple terms, mostly based on what sort of harm they can cause to patients.
In the past, under MDD, software was often classified as class I device. That meant that their manufacturers could enter the market quickly, because they didn’t need an audit by a notified body.
Now, under MDR, that sort of software is often classified as class IIa device. That makes a huge difference because, as class IIa device and higher, you need a prior audit by a notified body. In our experience, that delays market entry by at least a year and causes audits costs of a mid-five-figure sum. Due to that, many startups choose not to enter the market at all.
Or they reduce their feature set, thereby changing their intended use, to make their software a class I device under MDR. But what is a class I software device under MDR?
No one knows. That’s the situation.
So far, we have the following contradicting data points:
- The guidance document MDCG 2019-11 (pdf) which pretty much states that class I software doesn’t exist under MDR and all software is class IIa or higher.
- The guidance document MDCG 2021-24 (pdf, my comment) which lists some examples. All examples are at least class IIa, but a fertility tracking app is class I (?).
- Then there already is software on the market as MDR class I. And no, it’s not fertility tracking software. Wait, what? See below for a list.
- And finally, there are anecdotes that competent authorities have their own set of criteria under which software can be MDR class I. See below.
Our Position
There are two problems: Classification ambiguity and up-classification.
Classification ambiguity means that companies don’t know whether their products truly are MDR class I devices. They rely on a competent authority audit (which you only get by surprise) to get final certainty on whether their classification was correct. Until then they face huge legal risks because they might have to take their device off the market if their assessment was “wrong”.
We want classification ambiguity to be solved so that companies can confidently bring MDR class I software to market.
Up-classification means that lots of software which was class I under MDD will now be class IIa under MDR. This prolongs time to market for and causes significant audit costs. In the long term, this will stifle innovation while providing questionable benefits, if at all.
We want up-classification to be reduced as much as possible – specifically, to devices in which a notified body audit provides a tangible benefit to patient safety.
And finally, the current MDR class I situation creates an unlevel playing field: Some companies may have to go through long and expensive notified body audits, while their competitors enter the market with a class I device which literally has the same features. Some competent authority auditors might fine a company because they think their classification was incorrect, while other auditors might deem it acceptable. Competent authority audits must be objective and not result in a weird competition in which everyone interprets the MDR class I situation in their own way.
List of MDR Class I Software on the Market
These are all the MDR class I software device on the market which we currently know of (if you know more, reach out!). We’ve also added links to the user manuals which include the intended use. That’s probably the most interesting aspect because it shows which intended use statements have been brought to market as MDR class I software device.
We’ll also list the competent authority (CA) for each device to see whether there’s a particular trend among them of accepting or rejecting MDR class I software.
Also, credit where credit is due: This list was partially compiled by using the QuickBird directory of DiGA applications which shows, among other things, the applicable regulation (MDD / MDR and the medical device class.
We also searched in Eudamed for MDR class I software – it’s actually a surprisingly good tool because you can specifically select 1) MDR, 2) class I, and 3) software in its eudamed-device-search.
| Name | Description | CA | Links |
|---|---|---|---|
| Actimi Telecare | Software for patients with heart failure | Baden Wurttemberg, DE | Eudamed |
| companion patella | Software for patients with knee pain | Bavaria, DE | user manual (DE) |
| deprexis | Software for patients with depression | Hamburg, DE | user manual (DE) |
| elevida | Software for patients with multiple sclerosis | Hamburg, DE | user manual (DE) |
| Floy Signal | ? | Bavaria, DE | Eudamed |
| HelloBetter ratiopharm chronischer Schmerz | Software for patients with chronic pain | Hamburg, DE | user manual (DE) |
| HelloBetter Stress und Burnout | Software for patients with stress and burnout | Hamburg, DE | user manual (DE) |
| i.s.h. med | Hospital information system | NL | Eudamed |
| Kalmeda | Software for patients with tinnitus | North Rhine-Westfalia, DE | user manual (DE) |
| Kranus Edera | Software for patients with erectile dysfunction | Bavaria, DE | user manual (DE), Eudamed |
| mebix | Software for patients with diabetes | Thuringia, DE | Eudamed |
| Meine Tinnitus App | Software for patients with tinnitus | Hamburg, DE | user manual (DE), Eudamed |
| MindDoc | Software for patients with psychological diseases (?) | Bavaria, DE | Eudamed |
| neolexon Aphasie | Software for patients with aphasia | Bavaria, DE | user manual (DE) |
| optimune | Software for patients with breast cancer | Hamburg, DE | user manual (DE) |
| Oviva Direkt für Adipositas | Software for patients with obesity | Saarland, DE | user manual (DE) |
| PINK! Coach | Software for patients with breast cancer | Hamburg, DE | user manual (DE) |
| QuickBird Studios mamly | ? | Bavaria, DE | Eudamed |
| sinCephalea | Software for patients with migraine | Schleswig-Holstein, DE | user manual (DE) |
| velibra | Software for patients with anxiety disorder | Hamburg, DE | user manual (DE) |
| vorvida | Software for patients with alcohol addiction | Hamburg, DE | user manual (DE) |
| Vitadio | Software for patients with chronic diseases | CZ | user manual (DE) |
| Veye Engine | “orchestration layer around various clinical modules known as Devices” | NL | Eudamed |
Update: List of Up-Classified MDR Class I Software
A reader of our website, Clemens, kindly reached out to me that some of the user manual links were broken (thanks!). Additionally we had listed another app, Tebonin, in the MDR class I table above, but its most recent user manual states that it’s a class IIa device. Aha! That’s super interesting!
So that might be our first (?) data point of a MDR class I software being up-classified from class I to class IIa. We however have no data on how this occurred – the manufacturer might have done it to ship more “class II – like” features, or the competent authority in Hesse might have disagreed with the class I classification. We simply don’t know.
Regardless, here’s a table with all up-classified devices now:
| Name | New Class | Description | CA | Links |
|---|---|---|---|---|
| Tebonin | IIa | Software for patients with dizziness | Hesse, DE | user manual (DE) |
Update 2: List of Class IIa DiGAs
There also are DiGAs which were class IIa from the start (note: class IIb DiGAs don’t exist because they’re not allowed). While those weren’t up-classified from class I as the devices listed in the table above, it’s still interesting to look at them to gain a better understanding of what differentiates a class I device from a class IIa device (spoiler: I have no idea).
Here’s the table of class IIa DiGAs:
| Name | Class | Description | Notified Body | Links |
|---|---|---|---|---|
| Kaia COPD | IIa | Software for patients with COPD | Tüv Süd | user manual (DE) |
Competent Authority Anecdotes
Besides guidance documents which state that MDR class I software doesn’t really exist and the paradoxical reality that quite a few MDR class I software devices are now on the market, we also have conflicting anecdotes which we hear from competent authorities.
An important word of caution: These are anecdotes. So, when in doubt, ignore them and only refer to the more fact-based data above. We decided to share them nonetheless because they could be useful for kick-starting a discussion with competent authorities in the future.
And, of course, if you’re a competent authority and want to add an official statement here (that would be great!), feel free to reach out any time!
- “If the software is an app and mainly used by patients, it’s class I”
- “If the software does simple tasks like keeping a diary of tracking a blood value which you could also be doing with pen and paper, then it’s not even a medical device or maybe class I.”
- “A software for treating depression is not class I, it’s at least class IIa” (note: Software by other manufacturers for treating depression is already on the market as MDR class I device, e.g., deprexis)
Summary: We Have a Situation
Yup, so we have three conflicting data points: The MDCG guidance documents which state that MDR class I software doesn’t really exist, the market reality that shows that MDR class I software is on the market, and competent authority anecdotes.
It’s a mess.
This situation needs to be resolved. Manufacturers need much more confidence when developing and shipping MDR class I software, and right now that’s simply not the case.
Maybe, 10 years from now, we’ll be looking back at this and saying “ah, that was the point when medical software companies started targeting other markets like the US because the EU legislation was such a mess”. Let’s hope that that doesn’t happen.
