Dr.-Ing. Benedikt JannySenior Usability Engineer | Managing Partner
Last updated: October 2026
Short definition

Root cause analysis (German: Ursachenanalyse; RCA) is a systematic method for identifying the underlying causes of an observed problem, use error, close call, or safety-related event. In the usability engineering of medical devices, it serves not only to document the visible use error but to identify the causes behind it at the level of the user interface, use context, user characteristics, workflows, or organizational factors.

Role in the usability engineering process

Merely observing a use error yields only limited insight, both for regulatory purposes and for development. Only root cause analysis makes it possible to answer why an error occurred and which factors contributed to it. In human factors engineering, an observed use error is not hastily judged to be an individual failure of the user. First, it must be examined systematically whether characteristics of the user interface, the task, the use environment, or other conditions contributed. Not every use error therefore automatically proves a deficit in usability or risk control. Root cause analysis thus forms the bridge between user observation and concrete design measures.

Typical cause categories for medical devices

In practice, causes often appear on several levels at once: insufficient perceptibility of information (displays, labeling, alarms), misinterpretation of controls or status indicators, insufficient consistency of the user interface, cognitive overload of the user, use under realistic stress, time, or environmental conditions, insufficient consideration of workflows or mental models, and deficits in training, instruction, or accompanying documentation. A robust root cause analysis systematically examines which of these factors were actually causal or contributory.

Methods of root cause analysis

Several established methods are used in human factors engineering: the 5 Whys method (repeated questioning moves step by step from an observed error to the root cause), the Ishikawa diagram (fishbone diagram), which structures potential causes along defined categories such as people, machine, method, material, environment, and organization, fault tree analysis (FTA) as a top-down method for analyzing cause-and-effect relationships in safety-critical events, barrier analysis, which examines which protective mechanisms failed or were absent, and task analysis and cognitive task analysis for identifying causes within complex steps of use. A combination of these methods is often used in usability studies.

Root cause analysis in formative and summative evaluations

In formative evaluations, root cause analysis serves primarily to improve the design: Observed use problems are investigated in order to derive targeted design changes. In summative evaluations, it additionally has regulatory significance: If a critical use error occurs, it must be assessed whether its cause has already been addressed by existing risk controls, whether new risks must be identified, or whether further design measures are required. The results may make it necessary to update the use-related risk analysis and the effectiveness assessment of existing risk control measures, and to re-evaluate the residual risks.

Common mistakes in practice

A common mistake is to attribute causes hastily to the user ("user error"). Modern human factors approaches, however, regard use errors first as a symptom of a potential system problem. Other typical weaknesses are confusing symptoms with causes, focusing on individual events instead of systemic factors, failing to consider the use context, insufficient documentation of how conclusions were derived, and deriving training measures although a design problem exists. Regulatory reviews increasingly question whether the identified causes can be traced back clearly to the chosen risk controls.

Root cause analysis is closely linked to ISO 14971 and to the use-related risk analysis. If causes are identified that can lead to hazardous situations, they must be taken into account in the risk assessment. The analysis also supports evaluating the effectiveness of risk control measures and deciding whether further measures are required. This creates clear traceability between observed user behavior, risk analysis, and design decisions.

Regulatory reference

IEC 62366-1 requires the identification of safety-related characteristics of the user interface, potential use errors, hazards, hazardous situations, and hazard-related use scenarios; however, the standard does not prescribe a generally applicable root cause analysis method. IEC 62366-2 describes practical methods for analyzing use problems and deriving suitable improvement measures, treating root cause analysis as an important element for interpreting evaluation results. In its human factors guidance, the FDA recommends analyzing observed use errors and use difficulties, determining their causes, and reducing risks through suitable design measures. ISO 14971 requires the identification of hazards, the consideration of foreseeable sequences of events and hazardous situations, and the estimation, evaluation, and control of risks. However, the standard does not prescribe a universal root cause analysis for every identified risk. Root cause analyses provide important input for this.

In brief

An observed use error first describes what happened, not yet why it happened. Only root cause analysis, with methods such as 5 Whys, Ishikawa, or fault tree analysis, shows whether the actual cause lies in the design, the use context, or training, and prevents hasty "user error" attributions.

Frequently asked questions (FAQ)

Must a root cause analysis be performed for every observed use error?

Yes, but not at the same depth. Every observed use error, close call, and use difficulty is examined for its cause; the depth of the analysis depends on the risk. Errors in critical tasks, recurring use difficulties, and unexpected events are analyzed in greater depth because they can affect the risk assessment and the regulatory argumentation.

Is a use error automatically an indication of poor design?

Not automatically. However, human factors approaches first require examining systemic and design-related causes before human misbehavior is assumed to be the main cause.

Is the measure "user training" sufficient as the result of a root cause analysis?

In many cases, no. Both human factors and risk management principles prefer inherently safe design and design improvements over purely administrative measures such as training or warnings.

How does root cause analysis differ from use-related risk analysis?

The use-related risk analysis identifies and evaluates risks. Root cause analysis, by contrast, investigates why a specific use problem or risk arises. The two methods complement each other and are closely linked.

Do you want to analyze observed use errors systematically down to the root cause and derive robust design measures from them? We support you throughout the usability engineering process according to IEC 62366-1.

More about our usability engineering

Sources

Related terms

← Back to the wiki overview