Agile Compliance - Software Safety Classification

Before starting to develop your software you need to write a software development plan, describing all the processes and design outputs you put in place to respect the requirements of this (IEC 62304) standard.

The most important thing to determine upfront is the software safety class A, B or C. Depending on the class you need to adjust your software development plan: the higher the safety class is, the more strict your processes need to be and the more you need to document, e.g. there are some very time consuming activities you do not need to do if you develop a class A software.

Note: The standard states clearly that this needs to happen before you develop the software and before you finalize the software development plan (see 4.4.1 Purpose of software safety classification).

Tip: To work around this constraint (e.g. if you have the software development team ready to start straight away) is to have the team to make a feasibility study: Make prototypes of important algorithms, UX design etc. This can be an official phase of the product development before the software safety class is determined, it might even create important input for that process. But don’t overdo it, the longer your feasibility phase the hard it will be to determine the class

The standard gives you decision trees on how to determine the software safety class. In short the bigger the risk for the patient (or any other person implied) the higher the class (see 4.4.2 Assigning software safety classification).

Two things you need to think about when doing the software classification, is the architecture and something called segregation. Let’s look at an example for that:

Let’s assume you have some device which injects something in a patient and it can be lethal if you inject too much.

A simplified architecture could be something like the above: you have an app running on a phone which is a UI helping you to determine the dose and then to send it to the device via bluetooth. On the device you have a bit of firmware which talks to the injection hardware. Both the App and the Device Firmware you can break down into smaller components, say the UI allows you to select a dose, the BL does some math to compute the amount to inject.

Now you can argue, the UI is very stupid, the user can only select high, medium or low as a dose. That could indeed make the UI a class A. However as the amount to be injected is computed in the apps business logic (BL), say the orange box, that part is C as if it fails it will calculate the wrong dose. 

The Firmware (FW) is at least partly class C anyway as it directly controls the injection.

So you have:

Unfortunately the standard tells you that you need to treat all software with the highest class (C in this case) unless you can document a good reason not to do this.

To avoid this there is two things you can:

1. Implement risk controls

2. Segregate the software components

For the risk controls, it is important that the control is external to the SW system itself. External means it cannot share the same HW. This is also called segregation: here it’s easy as you have two physically separated devices. If you have everything running in one ‘box’ it’s far more complicated. If the different pieces of software share the same memory or CPU you cannot segregate them (just one word: blue screen).

In our example segregation is easy but still all your App software will be class C because of the little orange box. To reduce it you need to have a risk control running in the device. Two possibilities come to my mind:

1. No matter what amount in ml the App sends the device firmware limits it to a safe amount

2. You move the computation of the amount to the firmware and only send the low, medium or high selected in the App

If you manage to either control the risk of your little orange box or move it to the device it might save you hundreds or thousands of hours of work, therefore that business of designing an architecture, assigning software safety classes, thinking about risks and risk controls is very important and should be done early on.

Takeaway

The initial software architecture design can have a huge impact on software documentation requirements. Sometimes it will be better to adopt the hardware and software architecture to reduce the effort of software development and documentation needed.