Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

Is my software in class I MDD: Stayin' alive

So we have a corrigendum (almost 100% sure. A vote by the EU Parliament is still in the pipe December the 16th, though). To corrigendumize: that's a neologism I propose to name bug fixing activities in legal matters. I corrigendumize, you corrigendumize, they corrigendumize! Any resemblance to "randomize" is purely coincidental!

Seriously, we've all waited for a step from the EU in the direction of a smoother transition to the MDR. Now, we have it. Alas, they didn't do it to please manufacturers. They did it, pushed by the unavoidable necessity brought by the lack of notified bodies, and behind that, the lack of qualified persons.

Anyway, let's see the consequences and opportunities for medical device software.

Class IIa and higher with MDD

The corrigendum doesn't bring any change. Your class IIa certificate continues to live after May 2020, provided that you freeze the design. Small changes, like bug fix and cosmetic arrangements are still possible after May 2020. But if you have bigger changes, you have to pass a MDR certification.

Class I MDD

The corrigendum brings a huge change! Your class I auto certified software can continue to live after May 2020, provided that you freeze the design. Like class IIa MDD software.

May 25, 2020 11:59pm CET

Now, you are in a race to the end of class I liberty. You are literally free to augment the intended use of your class I MDD software. After the deadline, you will be chained to a notified body. And believe me, it will be a dreadful hindrance. So, urge yourself to do everything you can as long as class I MDD is alive.

Intended use in class I MDD

Be very careful to stay in class I MDD, by adding functions matching the permissive rule 12 of the MDD. Think also about the MEDDEV guide and manual on borderline classification. With that in mind, stuff your software with as many functions as you can. Even those far in your product roadmap or at the bottom of your backlog. You won't be able to do that after May 2020.

Risk management

Here, no choice: stay compliant to ISO 14971:2012 (the year is important) but with the bare minimum. E.g. no need to have 500 risks for a class I mobile app of average size. If you have trouble to assess risks on some functions, remove them.
Include also hazardous situations related to cybersecurity in your risk assessment. That's better to design a secure device at once!

Software development

Stay compliant to IEC 62304 and IEC 82304-1, once again with the bare minimum. E.g. If you're in class A, prepare documents required for class A and only those for class A. Priority is on implementation. If your software is in class A or B, and adding new functions make you think that it can be raised to class C, then remove these functions. That's a sign that your software may not be in regulatory class I, even with the MDD.
Yet, don't do just anything and release software without major bugs. Compliance to IEC 62304 requires to ensure that residual bugs don't represent an unacceptable risk.


Do one formative evaluation, reduced to Q&A with user representatives or end-users if that's easy. Prepare a summative evaluation protocol compliant to IEC 62366-1. Once again, don't be too picky and define the number of end-users and validation criteria with the bare minimum. E.g. only unacceptable risks are assessed.

Clinical evaluation

Through literature, obviously. Craft a clinical evaluation report concluding on the essential requirements found in MEDDEV 2.7/1 rev.4. If you can't reach a positive conclusion on benefit/risk ratio, strip your software from the guilty functions. Rely as much as you can on post-market surveillance to bring data on unanswered questions.
Polish your clinical evaluation report. This is the document that your competent authority will be prone to read in details, in case of inspection.

IFU and Labelling

Be. Compliant. To essential requirement #13 on IFU and labelling found in MDD. That's so easy for a competent authority to tackle you on this. On top of that, insert in your IFU sections required by clauses on IFU in IEC 82304-1.

Final validation

Schedule a design freeze and a formal validation early in May 2020. Make sure everything is compliant, with the bare minimum. Use the template there. Keep time to fix things before the deadline.

Declaration of Conformity

Write, sign, and send the declaration of conformity, and other required documents the May 22nd, 2020. The 22nd is a Friday. Don't wait until Monday 25th 2020. this is your ultimate safety margin.

From May 26th, 2020 onwards

That's over. You can't touch your class I MDD software any more. You'll only be authorized to perform bug fixing. And you will have bugs to fix! Especially if you've waited for the last minute to add new functions to your ultimate class I MDD release. Fortunately, bug fixing is allowed.
Thus, any other tiny change will propel your software to class IIa and beyond, by the rogue, the villainous rule 11.

All of this may sound borderline to you ears accustomed to hearing concerns about compliance. It is. You may feel like it's not aligned with your own standards. Just get inspiration from this crash plan and set your own standards of compliance in this exceptional context.
Remember that after the deadline, it's the notified body you choose, who will set the standards, not you.
And it won't be the bare minimum.


1. On Tuesday, 10 November 2020, 23:01 by Oliver

Hey Mitch, great post as always :)

Quick question: Why the ISO 14971:2012 (emphasis on 2012) for risk management and not the newer version from 2019? Is there anything specific to the old version which makes it more suitable for class I devices?

Thanks! :)


2. On Friday, 13 November 2020, 17:43 by Mitch
It's not a matter of class I. Regulatory requirements on risk management are exactly the same for every class. ISO 14971:2019 isn't harmonized, this is why I didn't mention it in this article. There are lots of comments about ISO 14971:2019 not being harmonized on the web! Just take it like this: -ISO 14971:2012 is enough for the MDD/IVDD/AIMDD, with annexes ZA, ZB, ZC giving the deviations between the standard and the regulations. -ISO 14971:2019 is for the MDR/IVDR, but is not enough. You also have to make your own assessment of deviations between the annex I of the MDR, which defines requirements on risk management, and ISO 14971:2019. As soon as we have the annexes ZD, and ZE for the MDR and IVDR in EN ISO 14971:2019, this standard will be enough for the MDR/IVDR.
3. On Tuesday, 1 December 2020, 17:01 by Kahina

Hey Mitch,
Merci pour ce superbe travail!
Un logiciel de classe I selon MDD passera en IIa selon MDR, quelle serait la date butoir pour mettre en place un SMQ ?
Merci d'avance

4. On Friday, 4 December 2020, 11:40 by Mitch
Hi Kahina, A MDD class I software can be placed on the market until May 2024. Thus, the deadline to implement a QMS is May 2024 and CE mark your software in class IIa. It means that you've initiated this work 24 months before!

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed