Use Error

What task analysis achieves

Task analysis translates a general description of use into a verifiable structure. As long as a process is described as "The user prepares the infusion," it is impossible to judge where a use error can arise or which step is safety-relevant. Only the breakdown into individual action steps makes potential errors addressable.

For each step, the analysis considers what the user must perceive, what the user must know or decide, and what the user must physically do: the three stages of the perception-cognition-action model. This assignment is more than an organizing aid: It determines which design measure can have any effect at all. An overlooked warning is not a problem that additional training can solve, and a comprehension problem does not disappear with a larger button.

The results of the task analysis are inputs for several downstream steps: They feed the use scenarios, the identification of critical tasks, and the use-related risk analysis (URRA). A task analysis with gaps therefore propagates through the entire usability engineering process and typically becomes apparent only in the summative evaluation, when a correction is expensive.

Hierarchical task analysis

The format most commonly used in practice is hierarchical task analysis (HTA). It arranges use in a tree structure: A top-level goal is broken down into subgoals, and these in turn into concrete action steps. The structure is complemented by so-called plans, which specify the order or conditions under which the substeps are carried out: sequentially, in parallel, alternatively, or event-driven.

These plans in particular are revealing for medical devices. They force branches to be made explicit: What happens if a self-test fails? What if the process is interrupted and resumed later? What if two users share the task? Experience shows that such branches are more error-prone than the regular sequence and are routinely overlooked in less structured analyses.

For the question of how deep a breakdown should go, HTA has established a pragmatic stopping rule: A step is broken down further only where the probability of an error and the severity of its consequences justify the added detail. A step whose failure is neither likely nor consequential does not need to be resolved into individual movements. This rule protects against the most common failure mode of task analysis: documentation that becomes unusable through sheer length.

Data collection methods in practice

A robust task analysis is not produced at a desk. It requires access to real use and, as a rule, a combination of several data collection methods:

• Observation and job shadowing in the actual use environment, the only method that reliably uncovers deviations between the documented and the actual workflow.
• Interviews with representative users of all intended user profiles, including less experienced users and those who use the product only occasionally.
• Document analysis of the instructions for use, standard clinical procedures, and training materials, as a comparison against the intended workflow, not as a substitute for observation.
• Walkthrough with subject matter experts, for example as a cognitive walkthrough, to analytically examine action steps for recognizability and comprehensibility.
• Video analysis of recorded use sequences to evaluate timing, interruptions, and parallel actions in a traceable way.

The combination is decisive because the methods have different blind spots. Interviews provide what users report about their actions, not necessarily what they do. Observation provides the behavior, but not the reasons for it. Only together do they yield a picture that withstands a use-related risk analysis.

From task to critical task

Not every task is equally relevant. The FDA defines a critical task as a task that, if performed incorrectly or not performed, would or could cause serious harm to the patient or user. What matters is the severity of the possible harm, regardless of existing protective measures. The task analysis provides the complete list of candidates; the assessment of which of them are critical takes place in the use-related risk analysis.

In practice this means: For each action step, the question is which plausible erroneous actions are possible (omission, swapping, too early or too late, wrong amount, wrong object) and whether such an erroneous action can lead to a hazardous situation. This linkage gives rise to the hazard-related use scenarios that are later tested specifically in the summative evaluation.

Task analysis is therefore the point at which it is decided whether the later summative evaluation tests the right things. A critical step that does not appear here will not be tested either, and the residual risk remains undetected.

The task analysis is thus also the central traceability document: It creates the link between the use specification, the use-related risk analysis, critical tasks, and the tasks of the summative evaluation, and it must therefore remain traceable how individual steps were carried over into study tasks and risk assessments.

Typical weaknesses in practice

• The intended process instead of the actual process. The analysis covers the workflow as it appears in the instructions for use, not the one users actually choose in daily practice, for example with shortcuts under time pressure.
• Only the regular path. Emergencies, interruptions, use errors, resumption, and emergency use are missing, even though this is exactly where the critical errors arise.
• Created once, never updated. The analysis is set up early and not kept current with design changes, so that in the end it describes a product that no longer exists in that form.
• No connection to the risk analysis. The task analysis exists as a stand-alone document, without a traceable link to the identified use errors and risks.
• Too coarse or too fine. Either the breakdown stays at a level of abstraction where no errors become visible, or it gets lost in individual movements without risk relevance.
• Team tasks are overlooked. Certain steps are carried out jointly by several people, for example in double checks or handovers, and should accordingly be modeled as team tasks rather than only from the perspective of a single user.

Regulatory reference

Task analysis is not required as a separately named process step in IEC 62366-1. However, the standard requires identifying use scenarios and, among them, the hazard-related ones, and task analysis is the established methodological way to meet this requirement in a traceable manner. IEC 62366-2 describes it as a method for deriving use scenarios.

The FDA Human Factors Guidance names task analysis as an analytical method for identifying critical tasks, which are then examined in human factors validation testing. Through the use-related risk analysis, task analysis is also interlinked with risk management according to ISO 14971.

Frequently asked questions (FAQ)

Sources

• IEC 62366-1:2015+AMD1:2020, Medical devices, Part 1: Application of usability engineering to medical devices
• IEC/TR 62366-2:2016, Medical devices, Part 2: Guidance on the application of usability engineering to medical devices
• ISO 14971:2019, Medical devices, Application of risk management to medical devices
• FDA Guidance: Applying Human Factors and Usability Engineering to Medical Devices

Related terms

• Use scenario
• Critical task
• Perception-cognition-action
• Workflow analysis
• Use-related risk analysis (URRA)
• Hazard-related use scenario
• Contextual interview

← Back to the wiki overview