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.
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.
Comments
"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!
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.
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.
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.
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.
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?
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.