Software in Medical Devices, by MD101 Consulting

A Notice was published in the Federal Register the 15th January 2021, about the exemption of a long list of medical devices from premarket notification. This list, found in table 6 of the Notice, contains 83 class II devices.
Yet, we have to wait for 120 days, to see this Notice published with the list in its final version.

The MDR 2017/745/EU and IVR 2017/746/EU define requirements, present in the Annex VII of both regulations, addressing the conformity assessment process that Notified Bodies shall put in place. It would be an understatement to say that this process will take some time.

The FDA published in July the final version of the Guidance on Multiple Function Device Products. Despite the absence of the word "software" in the title, it addresses at first software medical devices. It also addresses hardware devices, but we will focus on software in this post.

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!

We know that Drug Prescription Assistance Software are software as a medical device, thanks to the European Court of Justice. But how to CE mark that kind of software?

The GMED notified body has published a guide on substantial changes: named Guidance document for the interpretation of significant changes in the framework of article 120: “Transitional provisions” of Regulation (EU) 2017/745. This guide addresses changes according to the article 120 of the MDR. It's a decision tree in the same vein as FDA guidances on deciding when to submit a new 510k.

As a manufacturer, your mission, if you accept it, is to answer "No" for all your products CE marked with the MDD.
For hardware, be prepared to place your design in the freezer.
For software, be prepared to place your design in liquid nitrogen.

The guidance is on the page on white papers of GMED website.

To be software as a medical device or not to be.
That is the question.

And you rely on Competent Authorities to determine whether software is a medical device or not. For example, you have some practical examples on the ANSM website (google translate is my Friend): here is the lastest version.

And you wish you had a way to be noticed by the ANSM when the page changes. Hell no, no way.

Especially you wish you had been noticed when the ANSM change their mind on telesurveillance software: here is the previous version on archive.org if you want to compare with the latest.

Before: examples showing that communicating data, like tele follow-up is not a MD, with the invocation of expert function (found in MEDDEV 2.1/6 only for qualification of IVD, not MD) to exclude software without such function.
After: examples showing that tele surveillance is a MD (exit the expert function).

Arrgghh, This isn't Good Regulatory Practice.

Here is a quick follow-up of the new version of the FDA Guidance titled Medical Device Accessories – Describing Accessories and Classification Pathways, published in December 2017. This comes a bit in parallel to the Section 3060 guidance described in the previous post on the 21st Century Cures Act.

We continue this series of posts on cybersecurity with some comments on impacts of cybersecurity on the software development documentation.

This article is a follow-up of the previous article on the Draft guidance on Postmarket Management of Cybersecurity in Medical Devices.