Many medical device manufacturers create a “software FMEA.” However, there is no uniform understanding of what a software FMEA is.
This article provides clarity and tips on how to avoid the most common mistakes.
1. Software FMEA – what it could be
a) Software FMEA: a type of FMEA for software
An FMEA is a Failure Mode and Effect Analysis, i.e. a hazard analysis procedure that searches for unknown consequences of known or assumed errors, such as hazards or harm.
An article on FMEA describes the method in more detail and provides tips on how to document it.
Please also refer to the more general article on software risk analysis (German).
With a software FMEA, manufacturers want to identify risks caused by software errors. In other words, they examine the software – or more precisely the software components and software units – to see what happens if one of these components or units is implemented incorrectly.
b) “Scope” of the software FMEA
Manufacturers do not always agree on the end points to which the software FMEA should examine the effects. There are several alternatives: The analysis of the effects ends
- at the external interfaces of the software,
- at the external interfaces of the medical device (if it is not standalone software) or
- at the actual risks, i.e., probabilities and severities of harm.
Manufacturers should be clear about this—more on this in the “Mistake 1″ section.
c) Advantages of the software FMEA
Manufacturers of medical devices expect this form of FMEA to
- find unknown consequences of software errors more systematically,
- divide the tasks in risk management in an understandable manner (between software development and risk management),
- divide the risk management files into modules and thus make them more “maintainable.”
2. Common mistakes
Mistake 1: The wrong persons
Software FMEA is often assigned to software developers. However, risk management, especially risk analysis, requires the appropriate competencies. Software developers have their competence in software development and not in risk analysis. We are talking about roles, not people.
Software developers do not have
- the training to be able to carry out an FMEA systematically at all
- the contextual knowledge of how a malfunctioning medical device can affect the patient
- the medical understanding of the probability of hazards leading to harm of a certain severity.
The Johner Institute, therefore, recommends limiting the software FMEA to the software (see Fig. 1).
Mistake 2: Wrong level of granularity
The software FMEA – like all bottom-up procedures – cannot decide at which granularity level the risk analysis must be carried out. This decision can only be made top-down, e.g. with an FTA.
As a result, manufacturers analyze the causes of defects far too granularly, which takes its toll:
- The file becomes too extensive, which reduces efficiency and increases costs.
- The file becomes too extensive, which increases the overview and, thus, the likelihood of overlooking the real risks.
- The software architecture must be modeled down to this level of granularity as a precise component diagram that not only shows the components but also their interactions and dependencies.
Mistake 3: Imprecise interaction with the risk management file
The software FMEA’s output must be included in the overall risk analysis. However, often, not even the document structure is suitable for bringing the cause chains together cleanly. This is partly because physical components exist in the system architecture, but the software is understood as the entirety of all software, i.e., it spans these physical components.
To avoid this error, the end points of the software FMEA must act as starting points for the risk analysis.
For example, the software FMEA indicates that the software sends an incorrect command to the medical device via its external interface.
The risk analysis would then examine the consequences for patients, users, and third parties if an incorrect command is sent on the device.
3. Tips for a software FMEA
Tip 1: Specify documentation
Uniform documentation helps to create continuous, consistent, and compliant risk analyses. For example, the software development department could fill in tables, as shown in Fig. 2.
Tip 2: Limit software FMEA to software only
Make it clear to your software developers that you cannot and must not analyze risks but must describe the malfunction of the software system.
This requires that the external interfaces of the software system have been precisely specified in the software requirements.
It is also legitimate, albeit very difficult, for software engineers to estimate the probability of these errors.
Tip 3: Do not use it for all software systems
Perform a detailed software FMEA only for software systems where
- risks due to a software error cannot be controlled outside the software system but within the medical device or
- SOUP components are included.
Tip 4: Model software architecture and precisely specify and document interfaces
Model a precise software architecture. Without an architecture, you cannot trace the error chains and recognize the effects of software errors on the software’s interfaces.
If you want to identify and describe the possible external malfunctions of the software, you need to know how the software can misbehave via its interfaces. This requires precisely defined and documented interfaces.
Tip 5: Use tools
Tools for risk management are recommended to seamlessly link the chains of causes (see Fig. 1) and deal with changes. These tools should not always be Excel.
4. Conclusion and summary
In most cases, the software FMEA is the adequate method for medical devices that contain or are software. To this end, manufacturers should have a uniform understanding of what this means.
Like any method, the software FMEA also requires the necessary competencies.
Benefit from the support of the Johner Institute’s software and risk management experts. This will ensure that your risk management files meet the statutory requirements and ISO 14971 and that your devices are safe and can be brought to market quickly and safely.
Change history
- 2023-05-23: Article fundamentally revised; figure 1 added
- 2015-09-22: First version of the article published
