Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search

Tag - Classification

Entries feed - Comments feed

Friday 22 July 2016

Is my software in class I, IIa, IIb or III - 2016 Revolution

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.

Continue reading...

Wednesday 17 February 2016

Breaking news: standalone software is not an active medical device!

Warning: obsolete content. Please read: Is my software in class I, IIa, IIb or III.
Last update on 2016/07/31.

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.

Continue reading...

Monday 26 May 2014

IMDRF consultation: Software as a Medical Device

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.

Continue reading...

Wednesday 25 September 2013

FDA issues final Mobile Medical Apps Guidance

After two years of gestation, FDA issues final Guidance on Mobile Medical Apps!

Continue reading...

Friday 1 March 2013

How to bring legacy software into line with IEC 62304? - part 2

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.

Continue reading...

Friday 22 February 2013

How to bring legacy software into line with IEC 62304? - part 1

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.

Continue reading...

Monday 21 January 2013

Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices?

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.

Continue reading...

Saturday 30 June 2012

Prometheus medical pod

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.

Continue reading...

Monday 23 April 2012

Class A, B or C (continued)

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.

Saturday 14 April 2012

Is my software in class A, B or C?

IEC 62304 defines three safety classes for software:

  • Class A: No injury or damage to health is possible
  • Class B: Non-SERIOUS INJURY is possible
  • Class C: Death or SERIOUS INJURY is possible

Here comes the eternal question: Which class my software belongs to?

Continue reading...

Friday 6 April 2012

Inflation of software medical devices - part 3

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.

Continue reading...

Friday 30 March 2012

Inflation of software medical devices - part 2

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.

Continue reading...

Monday 6 February 2012

MEDDEV 2.1/6 Guidelines on classification of standalone software released!

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.

Continue reading...

Monday 28 November 2011

New Device Classification Guidance published by GHTF: consequences for medical imaging 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.

Continue reading...

Friday 25 November 2011

Certification of software medical devices in Canada

In How to classify and CE mark software, I tried to make a thorough explanation about how to obtain CE mark for software medical devices. Here is a short explanation about Canadian rules.

Continue reading...

Friday 4 November 2011

How to classify and CE mark software

Medical devices shall have CE mark before being sold in the EU. The process to have CE mark can be summarized this way:

  1. Determining the class of the device,
  2. Choosing the CE procedure to apply,
  3. Declaring CE conformity of the device.

Software follows exactly the same process as other devices. Here are the steps to follow to CE mark software.

Continue reading...