Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search


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?

Let’s do a little experience. Imagine a thermometer, which measures body temperature, with a piece of software inside. I could demonstrate that its software is class A or class C.

  • If the thermometer gives a wrong value, then the nurse is going to give a medicine to treat the fever. The wrong medicine may endanger the patient, and eventually cause death. Class C.
  • If the thermometer gives a wrong value, then the nurse may give a wrong treatment to the patient. However there is no chance that this may endanger the patient. Class B.
  • If the thermometer gives a wrong value, then the nurse is going to touch the forehead of the patient, or redo the measurement with another thermometer, or check the blood pressure of the patient to confirm the fever. No damage is possible. Class A.


This example is a dummy one but it shows that the context is very important. Class shall be set with the knowledge of physicians and the intended use of the medical device.
To make things more complex, there is no one-to-one correspondence between classes of medical devices and classes of software. You may have a class A software in a maintenance function of a class III medical device. It is true however that there is a high probability that low class software are found in low class devices and high class software in high class devices.

The wheelbarrow

Let me give you an analogy: the wheelbarrow was invented a long time ago to transport things more easily. The wheelbarrow helps our muscles do their job faster. Software was invented in the 1940’s to do computations faster. Software is the wheelbarrow of our brain. Our brain needs a level of confidence to trust the results given by its software wheelbarrow.
If we had no confidence, we could convert the electric tension of the temperature sensor to a temperature value with an abacus. The radiologist could take every measurement of the MRI and draw the points on a sheet of paper with different color pens to build an image. The surgeon could use manual micrometric screws to move its instruments instead of software controlled instruments, during a surgery.
We don’t because software allows us to do a lot of things in a snap of fingers, and we rely on it to do so. The more we’re stuck to it, without any alternative or possibility to cross its results/actions with something else, the riskier situation.
The more you have to rely on software to treat the patient, to monitor its vital constants or to give a diagnosis, the higher the class.

Consequence on design

Knowing the class has a consequence on design. I sum-up the requirements of IEC 62304 like this:

  • Class A: no design documentation, poor testing,
  • Class B: design documentation and testing,
  • Class C: deep design documentation and deep testing.

In class C, all paragraphs of the IEC 62304 shall be applied when developing the software inside the thermometer. In class A, only a few paragraphs of the IEC 62304 shall be applied. Class B is in between (no surprise).

Outclassing software may lead to unnecessary burden, which eventually won’t enhance the quality and reliability of your software. So, think twice before you assign a class to your software.

Edit: I continued the discussion in this article.


Edit of 2016: read this new article about IEC 62304 Amd1 2015 where the new software security classification system is explained.



Comments

1. On Tuesday 17 April 2012, 09:18 by Piervi

"The more we’re stuck to it, without any alternative or possibility to cross its results/actions with something else, the riskier situation.
The more you have to rely on software to treat the patient, to monitor its vital constants or to give a diagnosis, the higher the class."

This was very helpful, thank you!

2. On Thursday 17 May 2012, 12:03 by Jmv

Hi Mitch,
i understand the diferents safety classification but my question is how to explain and argue it?
For example: a simple Dicom viewer ( a PACS workstation).
At first look is a class C: "Death or Serious Injury". For example you show an image of a wrong patient, and the radiologist make a fatal mistake in the diagnostic that cause the death of the "original" patient (bad treatment applied, etc...).

A real "reasonable" classification will be B, but how to argue that the sw could only cause "Non serious injury" and not "Death or Serious Injury" when the cause ("wrong image") is the same.

Thank you a lot.

3. On Friday 18 May 2012, 12:42 by Mitch

I jm,

That kind of software is class B because it is not used alone in the diagnosis. It is always inserted in a chain of decisions for example, assessment by pairs, biopsy ... The software in its environment can not be the cause of a severe injury. There are always other measures of protection to prevent a problem if it is buggey or crashes. 

One could argue that it could even be class A. However, I consider this is a good preventive measure to set it class B, should other measures of protection in the chain of decisions be ineffective enough and lead to very unprobable injury. 

Class C is reserved to situations where software "governs" the situation and you don't have any alternative to using it. 

Regards

Mitch.

4. On Wednesday 23 May 2012, 00:01 by BGC

Hi Mitch,

Do you have a reference for the statement

"Class C is reserved to situations where software "governs" the situation and you don't have any alternative to using it."

This would infer that all IVD devices are class B or A.

5. On Friday 25 May 2012, 14:29 by Mitch

Hi Brian!

There is a high probability that a software for IVD is class A or B hence it is not critical link in a chain of decision to diagnose a pathology. But I still think that it is possible that an IVD software could be class C.

Example:

-if the software identifies the color of chemical reactive in a test (eg: blue=yes, red=no) and the result is presented to the operator with the photo of the test. Then it is clearly class B or even A. The operator verifies the result and is the master of the decision.

-if the software count cells in a tissue sample and the operator has no possibility to verify that the number is correct (hypothesis: the number of cells is huge). And the result is used as a major parameter for a diagnosis. It is class C because operators and doctors have to trust the IVD result.

Regards.

6. On Friday 28 September 2012, 12:11 by Matt

Thanks for your fantastic blog. The last comment is interesting.

In the future genetic analysis may be increasingly used to support diagnosis and treatment. So what would be the likely classification of a DNA sequencer? Where a patient has some kind of symptoms then Doctors may not necessarily have rely solely on the genetic result. But what if "pre-emptive" treatments were applied, where there are no symptoms, does the sequencer become Class C?

7. On Friday 28 September 2012, 12:31 by Mitch

Hi Matt,

If the IVD test result is the only parameter used to apply this pre emptive treatment then it's sure that the IVD test is a keystone in the process. I would say that it depends on the hazardous situation in which the patient is put if the treatment was not necessary.

-if it's just a change in diet, e.g. no gluten, there's not risk, class A,

-if it's a chemo, then class C.

I have to say that I think this discussion is controversial. My examples are somewhat more simple than the reality. But keep in mind that the class of software has to be assessed with the consequences of the software failure on the patient.

8. On Friday 12 July 2013, 11:03 by Uriel

Hi mitch,
Thanks for this blog, very instructive, and specially this article.
Thanks also to the comments giving some very usefull examples that illustrate very well all the difficulty to be sure of the security class.

I have 3 questions:
1- For an In vitro diagnostic device giving informations on hemostasis of a patient (clotting time, coagulation facttor concentration,...), software would be Class b or C? knowing that hemostasis information is very important in surgery for example.

2- What about a "standard security class assesment" based on generic questions? if i transform informations of the examples in the comments, questions could be:
- Device can be the only element giving a kind of result in the diagnosis decisiion chain?
- Device is used by a trained operator with medical knowledge (not directly by a patient who will trust the result)?
- Does device have some accessibles items that could injure the operator?
- etc...

I guess that kind of assesment could not be enough to confirm a security class but could it be usefull or do you think that it can't be precise enough to be usefull?

3- according to your very last sentence in the previous comment ("the class of software has to be assessed with the consequences of the software failure on the patient"), security class can be sure/definitive only when the whole risk analysis is finished?

thx,
Regards

9. On Friday 19 July 2013, 15:26 by Mitch

Hi Uriel,

Thank-you for your comment.

Q1: I can't answer this question. This you and your team who should know the clinical consequences that allow to assess the software class.

Q2: A list of questions like this already exist in annex C of ISO 14971. I think a list of questions can't be accurate enough to spot on the software security class. There are too many different clinical specialities, treatments, diagnosis, and types of medical devices. Perhaps in the case of IVD, it would be possible. The subject is less open than for all medical devices.

Q3: Yes, theoretically. And the security class can be sure only at the end of software development! But in practice the security class is well established earlier in the project, usually after software requirements analysis. By the way, the risk analysis is never finished. You have to monitor risks when the device is on the market.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed