Software in Medical Devices, by MD101 Consulting

As mentioned in a previous article on MDR, the rule 11 impacts all manufacturers of software medical devices. Another terrible news, the rule is applicable to all software whatsoever. Standalone or embedded. For, the rule 11 doesn't contain the word "standalone" or "embedded"

In this context, I can assert that a majority of active devices will be at least in class IIa ; and most of standalone software, if not 99%, will be in class IIa.
Why?
Because of rule 11 of MDR.
The rogue, the villainous rule 11.

Class IIa for everybody

Definition of medical device

First, for software, the definition of a medical device didn't change between the directive and the MDR. Some words like "prediction, prognosis" were added, which clarify the definition. But these are minor changes. So, if your software is a medical device with the 93/42/CE Medical Device Directive (MDD), it is a medical device with the MDR.

Qualification of medical device

Software embedded in a hardware medical device is a medical device. Simple case. Standalone software is more subject to interpretations. i.e. Software running on non-dedicated hardware, like PC, tablet, smartphone etc.

Now that the European Court of Justice set a legal precedent with the MEDDEV 2.1/6, we can officially use the decision tree #1 in this MEDDEV to determine whether standalone software (aka Software as Medical Device, SaMD) is a medical device or not.
Using this workflow, if we have the three conditions:

1. Software performing functions other than storage, communication and "simple search" (simple search has a very broad interpretation, have a look at the manual on borderline classification),
2. Software delivering new information, based on individual patient's data, and
3. The manufacturer (you) claiming that this new information is for diagnosis or treatment purposes,

Then, this software is a medical device.

To make it short:
If software for diagnosis or treatment purposes then medical device.
Note: I put apart the cases of accessories and implementing rules, extensive interpretation of "simple search" of MEDDEV 2.1/6 or manual on borderline classification.

Classification of medical device

With the MDD, most of software are in class I, unless you're unlucky to fall in a higher class to per MEDDEV 2.4/1 rev.9 or the Manual on Borderline Classification.
With the new rule 11 of the MDR, things get harder. Standalone or embedded, apply rule 11 if your medical device contains software.
The tree below shows the rule in a graphical representation:

We can see that Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is in class IIa or higher (left part of the tree).

But, we know per MEDDEV 2.1/6 that standalone software is qualified of medical device if the manufacturer claims that the intended use is for diagnosis or treatment.
Thus, standalone software qualified of medical device is automatically classified in class IIa or higher. More, this rule is applicable to standalone software and embedded software, like IOT, and connected widgets of all sorts that blossomed the last 3-4 years.

To make it short:
If software in class I with MDD then software in class IIa with MDR.
Note: I put apart the cases of accessories, implementing rules, monitoring, and some residual cases of SaMD not for diagnosis or treatment purposes.

Rewriting rule 11?

We were told in our management courses that mourning and yelling isn't a good thing. Let's try being positive, and rewrite the rule 11 in a way more consistent with a risk-based approach!
We can get inspiration from the IMDRF SaMD Risk Categorization Framework. The table below comes from the IMDRF document:
This table shows that software driving clinical management (namely aid to diagnosis) for non-serious diseases is in class I. Thus, there is a consensus at the IMDRF level that an intended use claiming an aid to diagnosis on a non-serious disease can be in IMDRF category I (equivalent of EU regulatory class I).
In the examples of the IMDRF document, we find in category I (class I):
SaMD that analyzes images, movement of the eye or other information to guide next diagnostic action of astigmatism.
If this is not an aid to diagnosis, I don't know what it is.

Taking this information, we could change the rule 11 to align the regulatory classes with the consequences for the patient of a software failure. Here is the result of the modified rule 11 (wording to be improved, just food for thought):


The changes proposed to rule 11 are pure speculation or utopia. Alas, we must live with the dystopian rule 11. So, what can we do?

Action plan

You have software in class I and the medical device directive hasn't been a big deal for you so far? Here are some possible actions.

Stay away, ever!

Claiming that your product is a medical device is a marketing argument? Stay away! Don't listen to marketing departments, who want the CE mark on the device because competitors blah blah. They hardly know the consequences.
Stop a product line with medical intended use. Or carefully carve your intended use to stay outside the definition of medical device. Stay inside the limits of storage, communication, and simple search. Don't claim a medical device intended use.

Stay away, as long as possible!

Postpone new products with medical intended use to 2021 or later. Wait for the dust to fall.
Go to the American market first!

Prepare the transition, now!

If your devices are definitely medical devices, and the EU market is strategic, then you have no choice. You must plan a transition to the EU MDR. If you read these lines and have been in the MD industry for long, I suppose that you've already set up (or thought to set up) an action plan, and that you shudder at the thought of even finding a Notified Body.
If you are new to the MD industry, don't think about a transition unless you have a very good reason to do so. Go back to the first two actions, and consider seriously other markets, like the USA. I'm not happy to write that.

Costs and schedule

I can throw a few figures to give you an idea of the immensity of the task:

• 100 kEuros (or 100 kDollars, or 6.02E23 Imperial Credits) to prepare your Class IIa MDR submission,
• In the worst case, add a clinical investigation,
• At least one year to get the CE certificate,
• At least one person full-time managing the CE marking project,
• Changes you can't imagine in the design of your software,
• About 50-100 documents to write and review, and maintain in the long run,
• A PMS and PMCF to set up (If you don't know what a PMS and PMCF are: go back to the first two possible actions).

You have an idea of the order of magnitude of the human and financial effort.

Too late for the directive

Don't put hope on changing the intended use of your existing device and getting a certification with the MDD in class IIa. The notified bodies don't take new submission with the MDD. They're fully booked. The availability of Notified Bodies is a major bottleneck. Contact me in private message if you know one with spare time!
More, it is a very bad idea to CE mark a SaMD with the MDD. When the MDD expires in May 2020, the design of your device will be frozen. Something totally in contradiction with software lifecycle in general.

A new hope

Let me end, though, on a positive note.
Reading the bare-bone text of the MDR without the right interpretation can lead to exageration. In other words, the 2017/745/UE MDR lacks guidances.
Good news: a software classification guidance, written by the software WG of the CAMD Implementation Taskforce (see their roadmap), will be published by the end of 2019. We have to right to hope that they'll have a relaxed interpretation of rule 11 (no, non, nein, we didn't want to say that!).

Other good news: Notified Bodies are winning their MDR notification, to begin with BSI and TÜV SÜD. Others are in the pipe but the risk of bottleneck is still present.

Anyway, if you can stay away from the MDR and its rule 11, then stay away.