Hiring or looking for a job in Digital Health? Check out our Digital Health Jobs board

Articles Regulatory News

January 25, 2024

No, Telemedicine Software Is Not Class IIa Under The MDR

Dr. Oliver Eidel

How is Telemedicine software classified under the MDR? If you’re in Hamburg, the answer might be class I, class IIa, or not at all, depending on who you ask.

But let’s backtrack for a moment.

Hamburg seems to fostering its reputation as the centerpoint of controversial MDR situations in Germany. In the past, is has become well-known for being one of those states in which you could still bring a MDR class I software device to market (likely not possible e.g. in Berlin). Why? I’m not sure - it could be that they’re understaffed and just don’t check, or that they just don’t know much about medical devices.

This most recent story would be a data point for “they just don’t know much about medical devices”.

Let’s look at Hamburg’s most recent controversy which is about Telemedicine and class I devices.

What Happened?

In short, this is about two Telemedicine companies fighting each other, first reported on e-health-com.de (man, not even news websites have simple links in this industry).

Let’s call the first Telemedicine company “2a”. They’ve brought their software to market under the MDD (= before 2021), which means it now benefits from the MDR legacy device transition period. They think their product will be class IIa under the MDR (that’s why I named them “2a”). To get their IIa certification, they’re currently planning their notified body submission and audit.

Let’s call the other Telemedicine company “1”. They seem to have entered the market later - after the MDD transition date. That led them to bring their software to market as MDR class I device, which is why I call them “1”.

There’s an obvious discrepancy here - two Telemedicine companies with similar products, however one claims to be class I, the other one class IIa. Hm. And, similarly obviously, company 2a is at a disadvantage because they have to spend much more time and money on regulatory compliance. At the very least, they have to pay 40-80k€ to a bunch of auditors to check their documentation - and they even have to make sure that their documentation is complete, because, duh, a bunch of auditors is going to check it. None of those aspects apply to company 1.

So company 2a told company 1 to take their product off the market because it’s apparently not classified correctly - it should be IIa instead of I. Company 1 didn’t react to that.

Then they went to a higher court (and this, dear reader, is the point where my legal knowledge ends), and the higher court agreed! According to the higher regional court (“Oberlandesgericht”) of Hamburg, Telemedicine software should indeed be classified as IIa, and company 1 is on the market illegally.

Okay, that’s the situation. Before we look into how the court argued and how company 1 defended itself, let’s look at the guidance documents to see how Telemedicine software might be classified.

Telemedicine Software As Per MDCG 2019-11

MDCG documents are semi-official documents which are more concrete than the MDR. The process of how they are written is mostly intransparent, but the main thing an outside observer can learn is that none of the authors seem to be good at using Microsoft Word, because the PDF title of this document is “untitled”.

Regarding its content, MDCG 2019-11 provides some hints on how to classify software. In section 9d) it lists “Telemedicine systems” as an example for a “communication system”, and communication systems are classified as not a medical device.

So, umm.. yeah, case closed, after opening a PDF and scrolling down a bit. It just doesn’t get clearer than that. If you’d like further data points for this argument, scroll down, but let’s get back to the story first.

So what happened in this legal case? Neither the court in Hamburg, nor the defendant (Telemedicine company 1) mentioned this guidance document. Crazy!

Instead, they launched into a weird series of arguments and counter-arguments, and, respectfully, I think none of them had any clue what they were talking about.

What Did The Court Say?

In short, the court cited rule 11 of the MDR which, in simplified terms, classifies software which provides information for diagnostic or therapeutic purposes as at least class IIa.

They were like “hey, Telemedicine software provides this sort of information, so it’s class IIa!”. The problem here lies within the definition of who provides the information. A machine learning model which provides cancer diagnoses, for example, clearly fulfils this rule because it provides this information itself. A Telemedicine software, however, only forwards information and doesn’t provide it.

That’s what makes it a communication system, which isn’t a medical device, remember?

In the court’s interpretation, any sort of software which forwards diagnostic and therapeutic information would become a medical device. Some examples:

I hope you understand how crazy this idea is.

And the MDCG 2019-11, even though I ranted a bit about it earlier, even includes this thought: When classifying medical devices, it has something called “step 3” which says (emphasis mine):

Is the software performing an action on data different from storage, archival, communication or simple search?

Software which only provides “communication” leads to answering this with “no”, which leads to the software not being classified as a medical device.

But again, no one here was aware of MDCG 2019-11.

Let’s look at what the defendant, Telemedicine company 1, said.

What Did The Telemedicine Company 1 Say?

Telemedicine company 1 argued that rule 11 of the MDR was not written very clearly.

Yup, that was their line of arguing.

Side note: Imagine you run someone over with your car, and then in court, your defense is “the rule about running people over with cars wasn’t written very clearly”.

Assuming this line of arguing represents company 1’s regulatory knowledge, I would assume that their consultants (if they have any) are doing a terrible job.

So - we can conclude that neither the court nor company 1 have much idea about MDR classifications.

But wait - what about company 2a? We just learned that Telemedicine software is actually not a medical device, all the while company 2a has classified their product as class IIa and is happily preparing their audit. What the hell?

So - we can also conclude that company 2a also has no idea about MDR classifications.

So - in this court case, none of the participants involved seems to have any idea of what the hell they are talking about. I’m not a lawyer, but I’ve never heard of anything like that.

But, now get this, we have a situation in which no one has any idea, but the court has to make some sort of decision. And some sort of decision has been made.

Is it really this crazy? Or are we missing something? Let’s explore that possibility for a moment.

Are We Missing Something?

Let’s summarize: Two companies and one court all believe Telemedicine software is a medical device. No one, neither the court nor the defendant, mention evidence to the contrary even though the guidance documents clearly state that Telemedicine software is not a medical device at all.

Maybe this is a feature, not a bug? Is this a case of wanting to be a medical device for weird reasons, just as we’ve seen for all DiGAs?

Maybe. From my experience, Telemedicine companies often try to cooperate with major Health insurances, and those major Health insurances often have all sorts of weird compliance requirements. I’ve heard multiple times that they expect software of suppliers to be “certified as a medical device”, irrespective of whether it actually would be classified as a medical device.

Remember - health insurances are not medical device experts, but they are experts at enforcing their internal policies, regardless of how useful those may be.

So maybe both of these companies were going for Health insurances as customers, and both ended up thinking “dude, we have to be a medical device to get this juicy contract”? Juicy contracts can be quite a motivation to write some medical device documentation.

Anyway. Whatever their reasons were, the outcome was a mess, because they ended up in front of a court which had no idea about medical devices.

So, in summary, we have two possible explanations:

Scenario A: Both companies knew that Telemedicine software is actually not a medical device but wanted to be one at all costs because it’s a prerequisite for selling it to Health insurances (the “juicy contracts” scenario).

Scenario B: Both companies were (and still are) completely clueless about medical device compliance and both mis-classified their product as a medical device.

My money is on Scenario B, because betting on incompetence is always a safer bet than betting on bad intent, at least in the medical device compliance field.

End of rant! A big mess, and lots of work has been generated for lots of people with no improvement to patient care whatsoever. Okay, the rant wasn’t quite over. Now it is!

If you’re interested about the nitty-gritty details of this regulatory situation, I’ve written a longer summary below about why Telemedicine software is not a medical device. If you’re not interested in that, well, go off to YouTube and watch the Australian Open like I’m going to do next.

Nitty-Gritty Details: Why Telemedicine Software Is Not a Medical Device

What I already mentioned:

Additionally, there’s the MDR Borderline Classification Manual.

The MDR Borderline Classification Manual (09/2022) in section 1.1.9.1 lists an example mobile app for “STI prevention strategies” in which users enter (diagnostic!) lab data and the app lets the user know “what to do and helps him/her find the right services”, and it informs other sexual partners.

While you might say “well duh, Telemedicine software is not comparable to this”, look at how the authors argue about the medical device classification of the STI app:

The application transmits and exchanges data and information between partners. On this basis alone, the software would not perform an action on data other than communication, as per in MDCG 2019-11. The application does not prevent sexually transmitted diseases, but rather facilitates the exchange of information and communication between different users.

The exact same could be said for Telemedicine software. Let me adapt this reasoning for Telemedicine software and let’s see how it sounds (my changes in bold):

The application transmits and exchanges data and information between participants. On this basis alone, the software would not perform an action on data other than communication, as per in MDCG 2019-11. The application does not diagnose, treat or prevent diseases, but rather facilitates the exchange of information and communication between different users.

And that makes total sense, because the Telemedicine software indeed does not perform any sort of action on the data and therefore is not a medical device.

End of story.

Well, I’d like to say “end of story”, but my gut feeling is that we’ll be hearing more about this, maybe from Hamburg, maybe from somewhere else.

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 some limited consulting? It's limited because we are not many people. We guide startups from start to finish in their medical device compliance.

Congratulations! You read this far.

Get notified when we post something new.

Sign up for our free newsletter.

Dr. Oliver Eidel

I'm a medical doctor, software engineer and regulatory dude. I'm also the founder of OpenRegulatory.

Through OpenRegulatory, I've helped 100+ companies with their medical device compliance. While it's also my job that we stay profitable, I try to dedicate a lot of my time towards writing free content like our articles and templates. Maybe that will make consulting unnecessary some day? :)

If you're still lost and have further questions, reach out any time!

Comments

If you have any questions or would like to share your opinion publicly, feel free to comment below. If you'd like to reach out privately, send us a message.

No QMS on this planet will save you from creating crappy software.