Is my software in class A, B or C?
By Mitch on Saturday 14 April 2012, 23:35 - Standards - Permalink
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.
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.
"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!
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.
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.
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.
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.
-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.
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?
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.
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?
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?
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.
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.
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.
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!
How does the software safety class A, B, C relate to the medical devices classification I, II, III ?
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.
Are baby incubators class B or class c medical devices
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.
Yes, definitely possible!
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?