Is my software in class I MDD: Stayin' alive
By Mitch on Friday, 6 December 2019, 14:10 - Regulations - Permalink
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.
Usability
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.
Comments
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! :)
Oliver
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