by Liz Mauer, MHCI
This is the fourth in a multipart series about how to effectively identify, understand, and communicate a product’s use-related risks.
It can be tempting to create your URRA by documenting the steps of use as they appear in the product’s user interface, using the same exact text and sometimes graphics found on the screen and/or in the IFU, for example. However, using this approach can mean that mitigations for use issues end up being classified (incorrectly) as user tasks, with associated potential use issues of their own, many of which may have limited meaning. This a distraction when trying to communicate to a reader (or your FDA reviewer) the true use-related risk profile of your product. It also limits your ability to document and take credit for mitigations implemented for specific use issues. After all, how can you point to a mitigation that is documented as its own task?
As an example, consider the graphical user interface for a large-volume infusion pump equipped with medication safety software. These devices typically have a set of screens that walk the user through selecting a drug from a library and programming the infusion for that drug. If the selected drug is high-risk (i.e., heparin), an additional confirmatory screen might appear asking for a second user to confirm the program, to ensure the program matches the prescription. Only after this can the user finally start the infusion.
When drafting the URRA, someone might choose to document “select the drug,” “program the infusion,” and “start the program” as individual user tasks, each with their own set of associated use issues. However, it’s been our experience that this approach tends to lead to the identification of use issues that in and of themselves are not meaningful. Your human factors validation study may end up with a group of task “failures” that aren’t actually failures at all, because they don’t harm the patient on their own. These “failures” might have the unintended consequence of making your product look more dangerous than it really is, or worse, detract from other, more clinically meaningful failures. Additionally, using this approach makes it very difficult to maintain that URRA as a living document throughout the product development process. As the GUI develops and matures, it will fall out of sync with the URRA, and eventually with your human factors validation test protocol. Keeping these documents synced is no small task – for you or those who must review and approve these things.
To avoid this, take a step back and create a task analysis for your product first. Ideally, the task analysis guides the development of your URRA, which then guides the development of your user interface. There are different methods you can use to create a task analysis, but at the end of the day, your task analysis just simply describes the tasks required to use your product, irrespective of what a user interface says (i.e., software screens, IFU, etc.). In our fictional pump example, the task documented in the URRA might be “start an infusion.” Those other “tasks” are actually mitigations designed to combat use issues related to incorrectly programming an infusion and subsequently over- or under-dosing a patient. The text and graphics on the screen can then be documented as risk control measures for that task in your URRA.