Software in Medical Devices, by MD101 Consulting

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?

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.

The final version of the negotiated text of the new Medical Device Regulation (MDR) was published by the European Commission in June 2016. It is a big upheaval for all medical device manufacturers. Contrary to what the draft version of September 2015 contained, software is invited to the party.

After MHRA's guidance on standalone software, we continue with another official document published by the International Medical Device Regulators Forum (IMDRF): the consultation on software as a medical device: Possible Framework for Risk Categorization and Corresponding Controls.

We've seen in the last post how to manage changes in legacy software. Let's see it from another point of view: the type of legacy software.

In the last two posts, we've seen what a software unit is, and when to do software detailed design, according to IEC 62304 and FDA Guidances.

I didn't have time to post anything worth it this week.
To give a side view of my last post about software classes, here is a link to DO-178B on wikipedia. It is the reference about software embarked in aircrafts.
If you take time to read this document, you will see that it goes very further than what we have today in IEC 62304. The constraints about design on high classes are very very hard to respect. That's normal, when you think that software is used in flight commands and other stuff in the cockpit.
It has some side effects, mainly to stretch software development projects, and to ban software from some parts of the plane, for cost-driven reasons.
For example, a microcontroler plus software plus electric motors would be perfect to memorize and retreive the position settings of the pilot's seat. But the cost to develop such software is very high, as the pilot's seat is seen as a critical component. Aircraft manufacturers prefer replacing software and microcontroler by good old analogic electronics to do the same task on some models.
In my humble opinion, the constraints of the two highest classes for software in aircrafts would be to high for medical devices. There is always a pratician, or an emergency medical service, able to "catch" the patient if something goes wrong. Whereas there is nobody to "catch" a falling plane if its flight commands fail. The consequences of risks are far higher in aircrafts, with potentially hundreds of victims in an accident.
That is why classes A, B and C, and their design constraints are enough for medical devices.

Next week, I'll talk about exemptions of ISO13485 for standalone software medical devices.
Bye.

This article is the last of three articles which deal with the concept of "inflation" of medical devices. The first one was on inflation of standards, the second about inflation of regulations. This one, the most interesting to my eyes, is about multiplication of apps on mobile devices, especially smartphones and tablets.
More that 6000 apps are classified in the "heath", "heathcare" or "medical" categories of the Apple or Android appstores. Many of these apps are classified as medical devices and are in the scope of regulations like FDA and CE Mark. Note that some apps may be regulated the FDA but not the CE Mark or vice-versa.