Software in Medical Devices, 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.

10. On Thursday, 31 August 2017, 20:36 by Charis

Hi Mitch, kudos for your blog really helpful.

2 questions for you:

1: Which version of the IEC 62304 standard should someone use at the moment the 2006 version or the amended one of 2015?

2. In one of your comments above you mentioned that pacs dicom viewers are class B. What about medical image processing software for DTI or Perfusion which are more "a nice to have" software tool at the moment. Are they also B or A taking into consideration that when someone has a DTI or Perfusion processing software he almost definitely has also a PACS DICOM viewer so there are multiple ways to cross check if a software failure or user error like displaying the wrong patient exam before conducting the final diagnosis etc.

Thank you!

11. On Sunday, 3 September 2017, 15:15 by Mitch

Hi,

1. Use the 2015 version of IEC 62304. The previous one is getting old!

2. The software safety class depends highly on the intended use of your software. Class B should be the most probable, as an error in your software could result is a significant delay in treatment.

Bye.

12. On Thursday, 9 August 2018, 18:40 by Mike

Hi Mitch, I understand if a compromised Firmware update is installed on a diagnostic instrument it can be a hazard when the instrument produces an incorrect result or somehow after beginning a diagnostic test the result is delayed. However, do you know if still considered a hazard if an installed update causes the instrument to be non-operational meaning not able to begin tests in the first place? I can see how an inoperable instrument may cause someone to not be tested (especially if only one on-site) and therefore result in delay of diagnosis and ultimately delay in treatment. I am just not sure if that is how it is viewed by governing bodies or where the line is drawn. Thanks!

13. On Sunday, 12 August 2018, 20:40 by Mitch
Hi Mike, Yes, this is still a hazard, but with a very high detectability: the device will be put apart if it is inoperable. Thus the hazard has a very low probability. Hazards with very low probability are usually acceptable. Do the math with your risk assessment criteria to verify whether it is acceptable or not. Then apply the diagram of section 4.3 of IEC 62304 + Amd1 2015 to see if your device is in class A. Regards.
14. On Thursday, 18 April 2019, 18:58 by Mike

How does the software safety class A, B, C relate to the medical devices classification I, II, III ?
Thanks!

15. On Monday, 22 April 2019, 14:35 by Mitch

Hi Mike,
There's not direct relationship. Regulatory classes and SW safety classes are two different scales coming from two different source.
It's very likely that class I / II / III device contains class A / B / C software. But this is just a rule of thumb.

16. On Monday, 20 July 2020, 11:24 by CA

Are baby incubators class B or class c medical devices

17. On Friday, 24 July 2020, 17:14 by Mitch
Toss a coin :-)
18. On Thursday, 8 October 2020, 17:07 by Victor

Is it possible that device has class I but its software has class C? It is out of logic but 62304 does not exclude this case.

19. On Friday, 9 October 2020, 19:59 by Mitch

Yes, definitely possible!

20. On Monday, 19 September 2022, 15:24 by Shubhangi Chouhan

My SW system has three items:

1) User Interface: used for user login, (Non medical)
2) Data Storage: used for secure storage and retrieval of patients wound image Class ??
3) Image analyzer: used to sizing and segmentation of wound to suggest treatment to nurse (classIIa)

My question is about the data storage platform Item, is that consider as MD, if this only for storage purpose?

Thank you

21. On Wednesday, 21 September 2022, 18:34 by Mitch
Hi, the medical image database only for storage is not regulated as medical device. Regards.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed