Skip to main content

How can risks be controlled in SaMD?

When working with software risk management, you have probably been told to assume that software constantly fails. This is a rather dull and not particularly encouraging point of view, especially for SaMD, since it consists exclusively of software (which apparently “always fails“!). However, implementing risk control measures in SaMD makes a difference. 

Let’s start by getting the foundation straight!  

Software risk management misconceptions

Let’s take a closer look at the risk probabilities according to ISO 14971, consisting of Po = P1 (probability of a hazardous situation occurring) and P2 (probability of a hazardous situation leading to a particular harm).

A common misconception is that Po should be set to 100% when working with software. That's utterly wrong, as I explain in this video or, if you prefer reading, this blog post. Furthermore, assuming that P1 is 100% just because it is software may also be wrong because a combination of factors may contribute to the sequence of events resulting in a hazardous situation.

We also know from experience that software does not constantly fail. How else would it pass a software system test before release? (I sincerely hope you don't release software that constantly fails!) 

The secret lies in understanding and distinguishing between risk evaluation before and after implementing risk control measures.

Initially, during the risk identification phase, it is correct to assume that no risk control measures are implemented. It also includes the assumption that software constantly fails.

However, by adding risk control measures, we can argue that we successfully reduce the probability of the software failing.

Let's look at the risk control options available when working with SaMD. 

Process vs Product

Typically, most risk control measures are (and should be) implemented into the product itself. For non-software products, you may also find risk control measures, such as various types of inspections in production. However, production inspection is not an option for software – or is it? kaestner

Consider pressing the compile button during development. That is, in a way, software “production”, is it not? Just as hardware production has upstream production process steps, including inspections, before the final assembly, software “production” also goes through an extensive process before reaching its final, compiled state.

Therefore, implementing inspections throughout your software development work can be considered risk-reducing activities, similar to production inspection steps for non-software medical devices. The software development standard IEC 62304 is all about reducing risk by applying a process!

A solid development process can be claimed to reduce the probability of software failure. It will, for instance, provide evidence that the software worked as intended during the system test before its release. Consequently, take advantage of the opportunity to leverage your software development process as a risk control measure in your risk analysis work!

In addition to having a solid software process, explore how the design can be improved to reduce risk.

Some argue that there is no point in exploring risk control measures in SaMD since, as previously mentioned, software will always fail. Please don’t fall into that trap; risk control measures in SaMD can have a huge risk reducing impact! 

SaMD risk control option analysis

From ISO 14971, we have learnt that risk control options come in the following flavours: 

  1. inherently safe design and manufacture; 
  2. protective measures in the medical device itself or the manufacturing process;
  3. information for safety and, where appropriate, training to users. 

Obviously, for SaMD, we can’t do much about “manufacture” and “manufacturing process” for individual risks besides following a process that will reduce general probabilities. But let’s look at the options individually and translate them into a SaMD context. 

Inherently safe design

Inherently safe design avoids requirements and designs that can result in hazardous situations by omitting such features. A non-present feature can’t cause harm. But a SaMD without features is, of course, not very attractive. Hence, the omission strategy will not suffice.  

The second-best choice is to design SaMD to avoid hazardous situations. For instance, insufficient processing capacity can result in delays that can lead to various hazardous situations. A robust operating system, prioritising critical tasks over others, is a valid risk control measure that can make a SaMD safe by design.  

In summary, if you can’t remove features or hazards, look for design approaches that prevent hazardous situations from occurring.  

Protective measures

For non-SaMD devices, a typical example is having a physical stop to prevent movement from causing harm, such as avoiding a piston penetrating a chest. SaMD has no physical surroundings offering that kind of help. Hence, protective measures must be implemented within the software.  

Assuming you have explored all the options for an inherently safe design, you should:

  1. Explore how to detect hazardous situations.  
  1. Once detected, what can you do about them?

Let's assume you are concerned about data corruption. Implementing a checksum test would detect such a failure. Once that information is available, you can decide the best course of action from a safety point of view.

In summary, SaMD protective measures are about identifying hazardous situations and taking appropriate actions.  

Information for safety and training

Relying on the user and considering information and training as risk-reducing measures are by far the least attractive risk control alternatives.

However, unless your SaMD is a service (without any user interface), SaMD has an advantage over many other medical devices since you can present the information directly in front of the user and further force the user to acknowledge information presented on a screen, such as “This is a potentially dangerous operation. Please confirm.", followed by "Yes, continue!" or "No, abort!”.

Presenting information "up front" during the function flow has great advantages over placing it in a user manual that rarely gets read.

How information is presented to the user shall, obviously, be evaluated and performed with great care. This is strongly related to human factors engineering based on IEC 62366-1.

In summary, information for safety and training can prove to be a more effective risk control measure when used in SaMD compared to other medical devices. 

Connecting the dots

Developing a safe SaMD requires a mix of risk control measures that collectively reduce the probability of harm. The various options discussed above influence Po in different ways. Let’s explore the impact using the formula Po = P1 x P2. 

Applying a process, i.e. IEC 62304, reduces P1 generically and lowers all risks. Or, as phrased in IEC/TR 80002-1:

The use of such a PROCESS can then be claimed to reduce the probability of occurrence of software ANOMALIES.” 

In SaMD, the inherently safe design reduces P1. If you remove features causing hazardous situations, then the software’s contribution to P1 = 0%. Good design strategies might be equally effective. 

Next are protective measures, which, in a SaMD interpretation, are most likely to reduce P2 because the hazardous situation is already present. In these cases, the primary objective should be to reduce the probability of harm arising from it. 

Lastly, information for safety and training can reduce both P1 and P2 depending on how the risk control measure is defined. 

In summary, if you use all the risk control options, the Po formula would look like this:

Po = P1(process) x P1(safe design) x P1(information) x P2(protective) x P2(information) 

Conclusion

A traditional risk control option analysis can be translated into a meaningful and valuable SaMD context. Working through the three risk control options provides complementary approaches to controlling risks.  

Last but not least, I advise investing in and maintaining your software development process. This investment will result in fewer bugs, happier patients, and less exposure to harm. 

About the Expert

Christian Kaestner is a consultant and entrepreneur with a wealth of knowledge about the medical device industry, working as Course instructor at Medical Device HQ. He is an expert member of the project team authoring IEC 62304 and also actively participated in the creation of IEC 82304-1.

He has extensive experience of medical device development and, as a software developer, a strong dedication to software development.

In the software domain he has worked in many roles such as software developer, project manager, auditing and quality management.