The following errors in the risk analysis result in problems continuously arising in the audit or the filing of the technical documentation:

• The risks that stem from technical problems such as software errors are totally overrated. Problems due to lack of fitness for purpose are not sufficiently analysed. The causal chain of the "edge devices" to the damage is not known accurately enough.
• This is because, not all necessary roles are represented: To detect risks systematically, we need a team of physicians, developers, experts on risk analysis and connoisseurs of the clinical context, for example, nurses (see below).
• The probabilities with which these problems actually cause damage are either selected wrong or completely arbitrary in ignorance of the clinical context.
• Causes and hazards are confused. So software failure or the failure of a hardware component are called hazards.
• Only the FMEA is applied - as the only hazard analysis process - if at all. Mostly the risk analysis is called the FMEA only.

Risk analysis: The right training/qualifications

The ISO 14971 requires that the personnel responsible for the risk management staff has the necessary qualifications.

Just what are they? The IEC 80002 gives us a few pointers:

• First, you should understand something about the risk management itself. These include the procedures for risk analysis and the ability to create documents for a risk management file.
• Software engineers and staff in the test team should be involved.
• The risk manager should understand some of the software itself.
• It must be integrated domain experts who can evaluate, for example, how the product / is actually used/misused. Here I see representatives of the medical staff as necessary.
• Next someone should be included who can estimate the direct and indirect clinical consequences of a hazard situation. In my view, it should be a doctor.
• One should not - as frequently occurs - for maintenance (only) use the inexperienced developer. They are often unaware of the possible consequences of a change for the software itself, or for a patient.
• Next, the authors propose the IEC 80002 experts in software development, Soups, tools, etc.

I can only agree with these estimations. But I would go one step further: The risk management does not belong in the hands of the development department. The risk manager must be an independent person who has mastered the process and has "orchestrated" doctors, users and developers during the building of the risk management file