Tag - Classification

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.

Since the last blog post on US FDA guidance on software classification, things evolved quickly with the FDA. We know where they want to go with software as medical device, but not exactly how they will implement it.
Let's do a review of what has been done since the publication of 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.

The British Standard Institute published in February 2016 a white paper titled How to prepare for and implement the upcoming MDR – Dos and don’ts. Register on BSI website to download the paper.
This white paper gives top-notch recommendations on the way to compliance with the future EU Medical Device Regulation (MDR), based on the draft version. But their interpretation of MDR classification rules on standalone software are somewhat surprising.

Most of medical devices manufacturers have legacy software that was not designed according to IEC 62304. The devices that embed legacy software were once verified and validated. These devices and their software work well and no major adverse event were raised by software issues.
But one day, the manufacturer decides that it's time to bring that legacy software into line with IEC 62304, to align the technical file of that software (or the contribution of software to technical file content) with up-to-date standard or regulatory requirements.

After a long series of posts about agile methods, let's continue with
something less serious!
If you saw Prometheus, the sci-fi movie about a team of astronauts who search
for human origins, you were probably amazed by the Weyland Corp Medical Pod
720i. Like me.

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.

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.

Today I’m going to talk about the inflation to regulations in the world of
software for medical devices. In my previous
post, I had a look at the inflation of standards for medical devices. As
the medical devices industry is heavily controlled by regulations, they deserve
a dedicated post.

New! MEDDEV 2.1/6 Guidelines on classification of standalone software released!
HIS, CIS, PDMS, RIS, PACS, LIMS … Which ones are medical devices, which ones are not?
To answer this question, the European Commission issued a new Guidelines document: MEDDEV 2.1/6, about the qualification and classification of standalone software as Medical Devices or In Vitro Diagnosis Devices. Download here
After the draft guidance of the FDA about mobile apps, after the guide on regulation of health apps by a UK medical charity, this MEDEV is the third document released in a few months about standalone software.

The GHTF (Global Harmonization Task Force) issued a draft of a new guidance on medical
device classification They recommend to implement four classes for medical
devices based on intended use: from class A (lowest risk) to class D (highest
risk). And they give a set of rules on how to choose the classification of the
devices.

Comparison with regulations

Wait, I've already seen this elsewhere. Classification of devices in Europe
(CE mark) and in Canada have systems very similar to what GHTF recommends. This
is a good thing to have an ongoing harmonization process. National regulations
copy what GHTF recommends and GHTF copies what national regulations require.
This is a virtuous circle. Maybe one day the FDA will implement this
classification system.