The medical device manufacturers define software risk management either the risk management, which they need to operate for the standalone software, or the part of risk management, that an embedded software entails.
Very often manufacturers are not able to fulfil the regulatory requirements of the software risk management. This article gives you valuable tips for it.
Regulatory requirements for the software risk management
The EU directives for medical devices, and with them the national laws, do not differentiate between products with or without software, with regards to risk management. The ISO 14971, the risk management for a harmonized standard, has no explicit software risk management. Only the IEC 62304 crosses with your philosophy, that errors in software are to be accepted with 100% probability, the principle of the ISO 14971 and its definition of risk, namely the combination of severity and likelihood of damage.
Read more here about possibilities in software.
Special features of the software risk management
Software alone does not lead to harm. Software can not hurt or even kill. At least not directly. The damage is always done indirectly via physical devices (eg quetschender table, beaming device) or for example by people who treat patients incorrectly or not all. This makes the software risk management so challenging.
So if you want to operate a risk management software, then you need to follow the cause and effect chain of the defective software to the patient (or the user).
Unlike physical devices the threat for standalone software is not on the outside of the product (in this case the display). While physical devices, the electrical energy, mechanical energy, radiation energy or the chemical materials (all the hazards) are always on the outside of the medical device, the wrong message is not a threat, even if the ISO 14971 unfortunately speaks of informational hazards.
Hazards are defined as potential sources of damage. I agree fully with the standard that viruses, ionizing radiation and moving parts are potential sources of damage. But a manual? Inadequate specification of the intended purpose? These are elements of a cause and effect chain, at the end of which there is a hazard, then a hazardous situation, then there is a loss. But neither a manual nor a specification is a potential source of harm. Unless the document falls on your foot.
The danger with a software that determines medication doses is not the wrong message, but the wrong drug - a chemical hazard!
Make sure that you do not confuse causes, hazards, hazardous situations, risks and damages in risk management. Your Risk Management file is otherwise going to be a problem during the audit. Let us know if we can help (Contact via web form).
Tips for Risk Management for Software
"How deep does the risk analysis of the software components need to go within the architecture? Do you have to go down to the class level or even down to the method level? " These are common questions raised in the free consultation Audit of Johner Institute.
The can not and will not be just one rule on how far you must "go deeper". Start with a separation between visible outward wrongdoing of a product and the resulting risks and the cause and effect chain leading to this outwardly visible wrongdoing. This corresponds to an FMEA from "edge devices".
Only in the case of a risk following a given visible outward wrongdoing, you have to investigate the cause and effect chain "inwardly", ie investigate down to component level. This corresponds to an FTA from the device edge "(direction of components).
This second study has the following objectives:
- First, they want to find out the causes and possibly the chances for this misbehavior.
Note: These causes (e.g. faulty components) have a possibility of wrongdoing, but no severity. This only exists in the outer chain.
- Secondly, you want to investigate whether there are ways in terms of a risk-minimising measure, in order to precisely interrupt this chain of causes.
You can end with the analysis, once you have defined a measure that cuts the fault tree. The higher the success level is for you, the better (ideally not within the same software system).
Even if I don’t appreciate answers like "it depends" it is still the only possible answer to the question of the depth of the research. Most firms examine too deeply and not wide enough. This leads to excessive risk tables that cause a lot of work, but do not provide real insights. Many risks remain undetected.
Just take a look at the audit guarantor. There, I present to you a number of video training sessions on risk management according to ISO 14971 in software.
Composition of the team for the software risk management
The risk management is a team sport in which you should participate:
- Risk Manager: expert on regulations, methods, documentation.
- Software or system architect: Know the internal cause and effect chain and can (only) estimate probabilities that the software or the outward system will behave incorrectly.
- Context Expert: can assess the probability that an external malfunction of the system results in a hazardous situation.
- Doctors: can judge with what probability a hazardous situation leads to a loss of a certain severity.
So you can, by no means, leave the software risk management to the software developers alone. But I refer only to the roles, not specific individuals who may hold multiple roles.
Risk management for software and security classes
If you classify a software system then a risk analysis must have already happened: It may not be absolutely necessary to consider the probabilities exactly, but definitely the severity of possible damages. If the result of this analysis shows that no damage can be caused by the software, then the safety class A justifies the definition. You then don’t have to look closer at the software, not in terms of 14971 nor 62304, for example down to component level.
Thus the risk management has started before the security classification (and also needed to start), but it does not end with. For example, you have to monitor, as part of a product tracking in the field of their own assessments, the reasons, for example, that the safety class A, was correct.
In other words, you must always comply with both the standards ISO 14971 and IEC 62304. I must write this more correctly: You must meet the basic requirements of the MDD (and others) with respect to risk management and software lifecycle.
If one has an entirely uncritical (stand-alone) software, then the amount of documentation is automatically reduced to a minimum. Ultimately, one only needs to cleanly prove that it really is uncritical.
In standalone software safety class A, I kept on asking if it was sure that it ever was a medical device ...