Task Analysis and Use Related Risk Analysis: When and How to Build Off Each Other
Task Analysis and Use Related Risk Analysis:
When and How to Build Off Each Other
A task analysis and use related risk analysis (URRA) are dependent tools which are the foundation of a successful human factors program. Both tools are important to understanding and analyzing user interactions with your device, which is critical to developing safe and effective product user interfaces.
What is a task analysis?
A task analysis is used to produce detailed descriptions of manual and intellectual activities of personnel who are operating, maintaining, or controlling devices or systems [1]. This analysis helps both researchers and manufacturers study the interactions between a user and a medical device. The task analysis follows the interactions necessary to achieve a desired result by breaking down the device use process into a discrete sequence of tasks [2,3]. By dividing the use of the device into specific tasks, a task analysis helps expose the user-device interactions that may result in potential use errors. The information collected from a task analysis then becomes the core of a use related risk analysis.
What is a Use Related Risk Analysis?
A use related risk analysis (URRA) is the process by which a manufacturer documents potential hazards and harms the end users may encounter via interaction with their product’s user interface (UI). If this sounds similar to the end result of a task analysis, it is because the task analysis helps to uncover potential use errors, which then become the inputs into the URRA. One of the most important outcomes of a URRA is the evaluation of use-related risk and the identification of critical tasks. These tasks then become the focus of future HF validation testing [3]. However, to understand and produce an effective URRA, it must be understood that this is a living document that must be revised throughout the product life cycle.
When and How to Create a Task Analysis
Conducting a task analysis is recommended early in the development process [3]. This is because the task analysis ultimately helps uncover potential use errors as inputs into the URRA, which will then support development of the user interface. A strong task analysis early in the design process helps manufacturers ensure effective risk mitigations are designed into their product user interface by uncovering potential use errors. This then sets the building blocks to successful human factors validations and ultimately safe and effective products.
The various use cases of the device must be understood in order to begin a task analysis. This understanding allows for the breakdown of the sequence of tasks required for successful use of the device by all intended users. To start, a high-level list of user-device interactions must be created to provide a foundation for associated tasks. After the list of interactions has been defined, a task list should be created for the user interactions, along with all sub-tasks required to successfully complete the functional element of use. These tasks should be defined by discrete steps to be taken by the user. When breaking down tasks into sub-tasks, it is important to incorporate order and timing in an observable and quantifiable way, when applicable. For example, terms such as “after” and “before” should be included when order of functions is important within a task and should be clearly identified within the task sequencing [4]. In addition, the wording included in the task analysis can affect the overall quality of the analysis. It is important to avoid using words that are ambiguous, as these terms will be difficult to observe or measure during a usability study. For example, words such as “adequate,” “well,” or “enough” leave performance of the device up to individual interpretation. Instead, define what is meant by ambiguous words with detail that describes the specific user interface components and the expected user-device interactions.
There should be at least one potential use error identified for each task listed in the task analysis, with the possibility for several use errors per task. According to the FDA, a use error is a user action or lack of action that was different from that expected by the manufacturer and caused a result that (1) was different from the result expected by the user and (2) was not caused solely by device failure and (3) did or could result in harm [3]. A useful strategy to identify use errors is to imagine yourself as the user and mentally walk through each task/sub-task while brainstorming various methods of error. While doing so, it is important to keep in mind the product’s intended users, uses, and use environments. Although a task analysis is one tool used to define use errors, FDA guidance states that FMEA and Fault Tree Analyses are also acceptable [3].
While thinking about the user’s interactions with the device, it is important to consider how the user could make errors of perception, cognition, and action. This is known as the PCA model that may be included within a task analysis. This model is useful in aiding to further break down user interactions into specific perceptual inputs, cognitive processes, and physical actions involved in performing each task [3]. Using the PCA model, tasks are broken down to the level of user interactions related to:
1) Perception – Perceptual information to be noticed or detected by the user.
2) Cognition – Cognitive components to be interpreted by the user.
3) Action – Physical actions taken by the user. [5]
Although use errors are ultimately described by an action (or inaction), analysis of cognitive elements and perceptual information may help to describe the cause of a use error. This detailed breakdown of possible use errors and potential causes allows manufacturers to understand the full picture of use errors related to their product. With this knowledge, manufacturers will be able to further inform their use-related risk analysis.
To learn more about tasks analyses, read: ‘How to Conduct a Task Analysis’.
How to Create an Effective URRA
To create an effective URRA, it must be understood that this analysis is a living process throughout the product cycle. The URRA should be updated as the product design evolves, and data is collected throughout the development process and post market surveillance [4]. However, once you bring the tasks, use errors, and causes from the task analysis into the URRA, the tasks analysis no longer requires updates. This information will continue to be updated within the URRA.
Once the task analysis has divided the successful use of the product into discrete tasks with related potential use errors and causes, the URRA process may begin. To further understand URRA iteration, we can look at an example formative evaluation with a single-dose auto-injector. An example of a use error while using an auto-injector device could include the user twisting the needle cap during removal, rather than pulling cap directly off the needle, as per the instruction manual.
Next, a hazard analysis should be conducted to identify potential hazards and hazardous situations. A hazard is the potential source of harm to a user or patient, and the hazardous situation is the potential exposure to the hazard that may lead to harm. So, to continue with our previous example, a potential hazard caused by the incorrect needle cap removal, could be the introduction of a foreign body to the needle. In this case, the hazardous situation would be the injection of a foreign body.
The next step to the URRA is to identify the harm associated with each potential hazard and hazardous situation. According to ISO 14971, harm is injury or damage to the health of people, or damage to property or the environment [6]. In terms of the URRA, the harm is the injury or damage that could happen to the user or patient if the hazardous situation were to occur. In our example of an auto-injector, the injection of a foreign body (hazardous situation) could result in an infection (harm) to the person receiving the injection. Notice the URRA process does not include the estimation of probability of use errors. The FDA has acknowledged that estimating probability of use errors is difficult and can even be impractical, therefore the URRA process should focus more on potential harm of use errors [3, 7].
Once each of the potential harms have been identified, the next two steps are to rate the severity of each potential harm and determine whether each task is critical or non-critical. An example of the breakdown of potential severity can be seen in Figure 1 below. However, defining potential severity of harm is up to the specific manufacturer.
These ratings generally align with critical and non-critical tasks. Based on FDA guidance, a critical task is “A task which, if performed incorrectly or not performed at all, would or could cause serious harm to the patient or user, where harm is defined to include compromised medical care” [3]. However, for critical tasks associated with combination products, FDA has removed the term “serious” from the definition to focus on any harm to the patient or user. This means that any task with use errors resulting in potential harm or compromised medical care are considered critical tasks for combination products. Medication errors should be included in the URRA, as they are the focus of the Division of Medication Error Prevention and Analysis (DMEPA) which aims to, “Eliminate medication errors in the U.S. healthcare system [8].”
The final step of the URRA is to list the risk control measures for each task line item. For each task, the risk control measures should identify the mitigations in place to reduce the likelihood or severity of the associated potential harm(s). It is extremely important to have specified risk control measures, especially those mitigating risks associated with critical tasks. This is because the data collected from testing critical tasks in an HF validation study will provide evidence demonstrating whether the implemented risk control measures are effective or ineffective. If the data collected from an HF validation study shows signs of ineffective risk controls, the manufacturer may have to revisit the user interface design and associated risk control measures. In the end, this would delay regulatory approvals and have financial consequences. [4]
To learn more about the URRA process and follow along with a case study, please visit the Agilis Consulting website, and read ‘Use Related Risk Analysis (URRA) – A Critical Living Tool Within the Human Factors Process’. This article discusses common issues seen with URRA submissions and builds a row of sample URRA data from our example of a single-dose auto-injector.
Summary
Task analysis and use related risk analysis are very important tools to product development and improving the device UI. There are several techniques you can use to create a task analysis, but ultimately, your task analysis should simply lay out the tasks necessary to successfully use your product. Your task analysis should be the blueprint for the development of your URRA, which should then guide the development of your product user interface.
We hope this article has helped provide some clarity on the relationship between a task analysis and use-related risk analysis, as well as the components to perform each analysis. The Agilis team has many years of experience consulting on task analyses, URRAs, and with providing HF data that seamlessly feeds into a manufacturer’s risk management process. We look forward to helping you with your next project that may include task analysis creation, URRA creation, defining critical tasks, and collecting HF data to ensure end users can complete tasks safely and effectively.
References:
[1] ANSI/AAMI HE75. (2009). Human factors engineering - Design of medical devices.
[2] AAMI/IEC TIR62366-2: 2016 Medical devices – Part 2: Guidance on the application of usability engineering to medical devices.
[3] FDA guidance entitled, Applying Human Factors and Usability Engineering to Medical Devices that was published by CDRH, FDA on February 3, 2016.
[4] Jackson, James. “Use Related Risk Analysis (URRA).” Agilis Consulting Group, Agilis Consulting Group, 4 Feb. 2021, https://www.agilisconsulting.com/knowledge-center/blog/use-related-risk-analysis.
[5] Smith, Clayton. “How to Conduct a Task Analysis.” Agilis Consulting Group, Agilis Consulting Group, 3 Nov. 2021, https://www.agilisconsulting.com/knowledge-center/blog/how-to-conduct-a-task-analysis.
[6] ISO/IEC Guide 63:2019, 3.1. ISO 14971 Medical devices — Application of risk management to medical devices.
[7] FDA draft guidance entitled, Contents of a Submission for Threshold Analyses and Human Factors Submissions to Drug and Biologic Applications that was released September 2018.
[8] Office of Surveillance and Epidemiology (OSE) – Divisions. Content last updated March 23, 2020. Retrieved from https://www.fda.gov/about-fda/center-drug-evaluation-and-research-cder/office-surveillance-and-epidemiology-ose-divisions.
About the Author:
Alex Hummel
Alex Hummel is a Research Associate in Human Factors Engineering at Agilis Consulting Group. Alex completed both his B.S. and M.S. in Biomedical Engineering at Wright State University. During his time at Wright State, Alex focused on medical device design and human factors principles. Alex comes to Agilis with prior experience in medical device testing as well as hazard analysis and risk assessment.