Software in Medical Devices, by MD101 Consulting

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.