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.